[转]论基于DSSA的软件架构设计与应用

【摘要】 
  去年三月份,我所在的公司启动国网电力用户用电信息采集系统项目,我被任命为项目负责人。国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。由于公司之前为南网(主要是广东省)开发过类似用电信息采集系统,且公司准备在电力行业做强做大,我提出了采用DSSA技术来研发国网用电信息采集系统,得到公司领导层的一致赞同。 
  由于项目功能实现上具有明显的阶段性,我决定采用演化方式来实现DSSA及完成应用产品开发。一是对原有系统、文档及国网用电信息系统功能规范进行分析,完成DSSA;二是对原有系统进行部件提取,做为核心资源的公共部件;三是加强对核心资源的管理,方便研发工程师查找部件及扩展部件。  
  经过近一年的努力,终于完成了公司用电信息采集系统核心资源的建立,也完成了国网电力用户用电信息采集系统项目。 
【正文】  
  去年三月份,我所在的公司启动国网电力用户用电信息采集系统项目,我被任命为项目负责人。国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。公司之前开发过广东电网公司计量营销一体化系统,类似于用电信息采集系统。 
  我对广东电网公司计量营销一体化系统的功能规范和国网电力用户用电信息采集系统的功能规范进行分析,发现除了系统内各自的通信协议不同外,其它的功能需求大体上相同。整个采集系统都是分三层实现,主站层,采集终端层和电能表层。由于电能表已经规范化了,有专门的表计生产厂家,这一层不需要投入资源进行研发。从公司目前现状来看,主站层投入研发工作量较少,一是主站的开发中模块化做得比较好;二是用户的需求基本一致。国网用电信息采集系统仅需要在广东电网公司计量营销一体化系统主站进行界面调整和支持国网用电信息采集系统通信协议即可达到要求。 
  根据之前开发的经验,用电信息采集系统开发的重点是采集终端的开发。因为采集终端需要安装到现场,而现场的用电环境各异,能够到达的远程信道也不同。采集终端可维护性低或可靠性低,则会产生大量的维护工作,影响公司品牌及利润。根据用电信息采集系统的要求,采集终端分为集中抄表终端、专变采集终端和公变采集终端。广东电网公司计量营销一体化系统的采集终端大体上也分为上述三类:低压集抄终端、负荷管理终端、配变监测终端。通过对采集终端的功能要求进行分析,可以看出它们归属于一个产品家族。我在项目组启动会议上提议采用DSSA技术进行采集终端产品的研发,建立公司用电信息采集系统核心资源,同时将计量营销一体化系统的采集终端也归结到产品家族中。 
  众所周知,DSSA(特定领域软件架构)就是在一个特定的问题领域中支持一组应用的开发,这些应用形成产品家族。DSSA是软件重用的一种手段,它由领域模型、参考需求、参考架构组成重用元素。 
  用电信息采集系统各终端基本需求都是对外接的电能表或测量点的读数进行采集,稍做处理后通过GPRS/CDMA信道远程传输给采集系统主站端。采集终端的功能模块一般包括测量点采集模块,表计规约模块,现场总线模块,PPP拨号模块,主站命令模块,本地维护模块,程序升级模块,数据存储模块,交流采样模块,负荷控制模块等等。 
  由于采集终端在现场使用的特殊性,它的非功能性要求主要集中在可靠性、可修改性和易用性。现场用电环境复杂,信道各异,要求采集终端具有高可靠性。由于市场上的电能表支持的规约各异及现场总线发展快速,要求采集终端可扩展性强,能快速支持新的表计规约和现场总线,且支持远程升级操作。由于在现场施工时多是由工程队进行安装,工程队人员的素质高低不齐,要求采集终端在本地操作具有一定的智能化,且要求调试简单。  
  根据以上分析,采集终端软件架构采用分层设计比较合适。分层设计的软件可修改性和可扩展性比较好。由于分层开发,将关注点分离到各层,将系统的复杂度分到各层中,相应可靠性也可以得到提高。 
在用电信息采集系统研发中,我决定采用演化方式进行开发。  
  首先对原有系统、文档及国网用电信息系统功能规范进行分析,完成DSSA。在项目启始阶段,我对计量营销一体化系统及用户需求文档及设计文档进行分析,将用户需求用EXCEL表格列出来。然后再对国网用电信息采集系统的功能规范进行分析,用同样的方式列出用户需求,需求比对后发现它们之间的功能要求大体上是一样的。但由于通信协议不同,会导致一些功能在实现上有差别,如主从终端连接功能,用电信息采集系统采用一条命令完成主从终端的所有通信,而计量营销一体化系统分成建链、传输、断链三条命令来实现。于是我决定将基础业务模块做成通用的模块,根据不同的参数来初始化模块,或各具体产品自己适配模块。按照这个需求,我对核心资源进行分层设计。 
  总体上,核心资源分成三层,由低到高依次是:基础资源层,基础业务层,扩展业务层。基础资源层包括多进程框架,GUI系统,系统API和驱动封装,虚拟通道模块等等。由于采集终端的操作系统是LINUX,而且通讯口资源比较多,采用一个进程管理一个通讯口,单一管理便于维护,因此提供多进程框架,方便应用开发时的进程增加。对系统API和驱动进行封装,方便以后代码的移植。基础业务层主要包括用电信息采集系统的各个基础功能模块,有现场总线模块、表计规约模块、测量点采集模块、交流采样模块、负荷控制模块等等。扩展业务层主要对基础业务层中的各个模块进行参数化和适配,以适应本系统的需要。根据目前的情况,扩展业务层主要有计量营销一体化系统部件包和国网用电信息采集系统部件包。 
  其次对原有系统进行部件提取,做为核心资源的公共部件。计量营销一体化系统的采集终端在研发时由于没有采用组件开发技术,各功能模块和应用层耦合较强,在提取公共部件时需要对应用层解耦。各个具体的功能都有相应的控制参数,而控制参数可以由主站命令模块进行读写,将控制参数管理模块做成中介者模式,很好地实现了各功能模块的解耦。如PPP拨号模块,和应用层的拨号参数读写命令耦合在一起,通过参数管理模块将主站命令模块和PPP拨号模块解耦。 
  在对计量营销一体化系统的采集终端进行部件提取过程中,每完成一个部件的提取,则对原采集终端软件系统进行重构,并完成集成测试和确认测试。这样可以始终端保持原采集终端软件系统可行,成为第一个验证部件的产品。 
  最后加强对核心资源的管理,方便研发工程师查找部件及扩展部件。到了开发的后期,核心资源库的公共组件慢慢多起来了,同时由于在扩展业务层对很多基础部件进行了参数化和功能扩展,很多部件在标识和功能上都差异不大,出现了有点混淆的问题。为了更好地管理,我建立了WIKI服务器,采用WIKI服务器进行组件管理,在WIKI服务器上对组件的标识、功能、接口及与相关组件的差别等等进行了描述。研发工程师输入相关的关键字就能找到匹配的组件及每个组件详细的说明,方便研发工程师使用。 
  随着用电信息采集系统核心资源库的建立,国网用电信息采集系统项目的功能也逐渐完善起来。采集终端软件系统在今年8月份通过了国家电网电力科学研究院的全功能测试,这对全体项目组成员是一个振奋人心的好消息,说明我们的努力得到了认可。

原文地址:https://www.cnblogs.com/nerd/p/11506291.html

时间: 2024-10-14 07:55:09

[转]论基于DSSA的软件架构设计与应用的相关文章

软件架构设计学习总结

软件架构设计就是软件系统的'布局谋篇',是软件抽象发展到一定阶段的产物.软件设计人员学习软件架构知识,旨在站在较高的层面上,整体的解决好软件的设计,复用,质量和维护等方面的实际问题.本文以图形的方式进行总结归纳,从软件架构的描述,设计,风格,评价,形成方法进行阐述. 软件架构设计总述: 软件架构的概念 软件架构的意义 软件架构的风格 分层架构 面向服务的架构(SOA) 特定领域的架构(DSSA) 软件产品线 基于架构的软件开发(ABSD) 软件架构与质量属性 软件架构评估 -----------

SoC嵌入式软件架构设计之四 :内存空间规划分配

本文继续阐述基于低端控制器CPU的SoC固件架构设计.第一节 SoC嵌入式软件架构设计之一:系统内存需求评估 讲述了系统内存需求的评估.这一节讲述内存空间的具体规划分配.CPU有两种体系结构:哈佛结构和冯诺依曼结构.哈佛结构是一种将程序指令存储和数据存储分开的存储器结构,如80251,代码空间与数据空间完全分开,独立编址:冯诺依曼结构是一种将程序指令存储器和数据存储器合并在一起的存储器结构,如MIPS,ARM等,其代码和数据空间是统一编址.这里就以冯诺依曼体系结构为例. 一.嵌入式系统软件分层

软件架构设计系列总结

架构引用维基百科:软件体系结构是构建计算机软件实践的基础.与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础.从和目的.主题.材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟.一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计.软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作.逻辑和流程.软件

SOA实践之基于服务总线的设计

在上文中,主要介绍了SOA的概念,什么叫做“服务”,“服务”应该具备哪些特性.本篇中,我将介绍SOA的一种很常见的设计实践--基于服务总线的设计. 基于服务总线的设计 基于总线的设计,借鉴了计算机内部硬件组成的设计思想(通过总线传输数据).在分布式系统中,不同子系统之间需要实现相互通信和远程调用,比较直接的方式就是“点对点”的通信方式,但是这样会暴露出一些很明显的问题:系统之间紧密耦合.配置和引用混乱.服务调用关系错综复杂.难以统一管理.异构系统之间存在不兼容等.而基于总线的设计,正是为了解决上

(转)软件架构设计

[一]-软件架构设计过程 软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考: 1.业务分析:针对目标行业的业务战略.蓝图.业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.他是一个系统组,同时明确各系统间的支撑关系. 3.系统功能设计:明确信息化系统功能列表及功能层次(层次,例如经验决策层工,管理层功能,业务操作功能等)

详细介绍软件架构设计的三个维度

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 架构设计是一个非常大的话题,不管写几篇文章,接触到的始终只是冰山一角,更多的是实践中去体会.这篇文章主要介绍面向对象OO.面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用. 架构设计有三个维度,或者说是我们在考虑架构时需要思考三个方向. 这三个维度分别为面向对象.面向方面.面向服务. 这三个维度可以看作是正交的,但不同维度会互相印证,互相支撑,整个架构的示意图如图所示. 面向

小议软件架构设计要点

如何更好地进行软件架构设计,这是软件工程领域中一个永恒的重点话题.过去几十年来,国际软件工程界在软件架构设计方面已经获得了长足发展,大量图书.文章和文献记载了这方面的成熟经验与成果.软件架构设计往往是一件非常复杂的工作,涉及到很多细节和方方面面,可探讨的话题也非常之多.囿于篇幅限制,以下只能根据笔者个人理解,遴选出软件架构设计的个别要点,结合当前流行的敏捷软件工程思想,与大家分享一下自己在软件架构设计方面的心得和体会. 架构决定成败 软件架构是软件产品.软件系统设计当中的主体结构和主要矛盾.任何

SOA之基于服务总线的设计

在上文中,主要介绍了SOA的概念,什么叫做"服务","服务"应该具备哪些特性.本篇中,我将介绍SOA的一种很常见的设计实践--基于服务总线的设计. 基于服务总线的设计 基于总线的设计,借鉴了计算机内部硬件组成的设计思想(通过总线传输数据).在分布式系统中,不同子系统之间需要实现相互通信和远程调用,比较直接的方式就是"点对点"的通信方式,但是这样会暴露出一些很明显的问题:系统之间紧密耦合.配置和引用混乱.服务调用关系错综复杂.难以统一管理.异构系统

软件架构设计之基础概念

架构定义 软件架构的概念分组成派和决策派两类,组成派以软件本身为描述对象,分析软件组成,决策派以人的决策为描述对象,归纳架构决策的类型. 组成派定义示例: 软件架构将系统描述为计算组件及组件之间的交互.计算组件是泛指,可进一步划分为处理组件.数据组件.连接组件等,可以指子系统.框架.模块以及类等不同粒度的软件单元. 决策派定义示例: 软件架构包括以下一系列问题的重要决策:(1)软件系统的组织:(2)选择组成软件系统的结构元素和它们之间的接口:(3)如何组合这些元素,使它们合成为更大的子系统:(4