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

标签: dssa 软件架构 设计 | 发表时间:2013-01-18 00:36 | 作者:jinhailiao
出处:http://blog.csdn.net

摘要

去年三月份,我所在的公司启动国网电力用户用电信息采集系统项目,我被任命为项目负责人。国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。由于公司之前为南网(主要是广东省)开发过类似用电信息采集系统,且公司准备在电力行业做强做大,我提出了采用DSSA技术来研发国网用电信息采集系统,得到公司领导层的一致赞同。

由于项目功能实现上具有明显的阶段性,我决定采用演化方式来实现DSSA及完成应用产品开发。一是对原有系统、文档及国网用电信息系统功能规范进行分析,完成DSSA;二是对原有系统进行部件提取,做为核心资源的公共部件;三是加强对核心资源的管理,方便研发工程师查找部件及扩展部件。

经过近一年的努力,终于完成了公司用电信息采集系统核心资源的建立,也完成了国网电力用户用电信息采集系统项目。

 

正文

去年三月份,我所在的公司启动国网电力用户用电信息采集系统项目,我被任命为项目负责人。国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。公司之前开发过广东电网公司计量营销一体化系统,类似于用电信息采集系统。

我对广东电网公司计量营销一体化系统的功能规范和国网电力用户用电信息采集系统的功能规范进行分析,发现除了系统内各自的通信协议不同外,其它的功能需求大体上相同。整个采集系统都是分三层实现,主站层,采集终端层和电能表层。由于电能表已经规范化了,有专门的表计生产厂家,这一层不需要投入资源进行研发。从公司目前现状来看,主站层投入研发工作量较少,一是主站的开发中模块化做得比较好;二是用户的需求基本一致。国网用电信息采集系统仅需要在广东电网公司计量营销一体化系统主站进行界面调整和支持国网用电信息采集系统通信协议即可达到要求。

根据之前开发的经验,用电信息采集系统开发的重点是采集终端的开发。因为采集终端需要安装到现场,而现场的用电环境各异,能够到达的远程信道也不同。采集终端可维护性低或可靠性低,则会产生大量的维护工作,影响公司品牌及利润。根据用电信息采集系统的要求,采集终端分为集中抄表终端、专变采集终端和公变采集终端。广东电网公司计量营销一体化系统的采集终端大体上也分为上述三类:低压集抄终端、负荷管理终端、配变监测终端。通过对采集终端的功能要求进行分析,可以看出它们归属于一个产品家族。我在项目组启动会议上提议采用DSSA技术进行采集终端产品的研发,建立公司用电信息采集系统核心资源,同时将计量营销一体化系统的采集终端也归结到产品家族中。

众所周知,DSSA(特定领域软件架构)就是在一个特定的问题领域中支持一组应用的开发,这些应用形成产品家族。DSSA是软件重用的一种手段,它由领域模型、参考需求、参考架构组成重用元素。

用电信息采集系统各终端基本需求都是对外接的电能表或测量点的读数进行采集,稍做处理后通过GPRS/CDMA信道远程传输给采集系统主站端。采集终端的功能模块一般包括测量点采集模块,表计规约模块,现场总线模块,PPP拨号模块,主站命令模块,本地维护模块,程序升级模块,数据存储模块,交流采样模块,负荷控制模块等等。

由于采集终端在现场使用的特殊性,它的非功能性要求主要集中在可靠性、可修改性和易用性。现场用电环境复杂,信道各异,要求采集终端具有高可靠性。由于市场上的电能表支持的规约各异及现场总线发展快速,要求采集终端可扩展性强,能快速支持新的表计规约和现场总线,且支持远程升级操作。由于在现场施工时多是由工程队进行安装,工程队人员的素质高低不齐,要求采集终端在本地操作具有一定的智能化,且要求调试简单。

根据以上分析,采集终端软件架构采用分层设计比较合适。分层设计的软件可修改性和可扩展性比较好。由于分层开发,将关注点分离到各层,将系统的复杂度分到各层中,相应可靠性也可以得到提高。

在用电信息采集系统研发中,我决定采用演化方式进行开发。

首先对原有系统、文档及国网用电信息系统功能规范进行分析,完成DSSA。在项目启始阶段,我对计量营销一体化系统及用户需求文档及设计文档进行分析,将用户需求用EXCEL表格列出来。然后再对国网用电信息采集系统的功能规范进行分析,用同样的方式列出用户需求,需求比对后发现它们之间的功能要求大体上是一样的。但由于通信协议不同,会导致一些功能在实现上有差别,如主从终端连接功能,用电信息采集系统采用一条命令完成主从终端的所有通信,而计量营销一体化系统分成建链、传输、断链三条命令来实现。于是我决定将基础业务模块做成通用的模块,根据不同的参数来初始化模块,或各具体产品自己适配模块。按照这个需求,我对核心资源进行分层设计。

总体上,核心资源分成三层,由低到高依次是:基础资源层,基础业务层,扩展业务层。基础资源层包括多进程框架,GUI系统,系统API和驱动封装,虚拟通道模块等等。由于采集终端的操作系统是LINUX,而且通讯口资源比较多,采用一个进程管理一个通讯口,单一管理便于维护,因此提供多进程框架,方便应用开发时的进程增加。对系统API和驱动进行封装,方便以后代码的移植。基础业务层主要包括用电信息采集系统的各个基础功能模块,有现场总线模块、表计规约模块、测量点采集模块、交流采样模块、负荷控制模块等等。扩展业务层主要对基础业务层中的各个模块进行参数化和适配,以适应本系统的需要。根据目前的情况,扩展业务层主要有计量营销一体化系统部件包和国网用电信息采集系统部件包。

其次对原有系统进行部件提取,做为核心资源的公共部件。计量营销一体化系统的采集终端在研发时由于没有采用组件开发技术,各功能模块和应用层耦合较强,在提取公共部件时需要对应用层解耦。各个具体的功能都有相应的控制参数,而控制参数可以由主站命令模块进行读写,将控制参数管理模块做成中介者模式,很好地实现了各功能模块的解耦。如PPP拨号模块,和应用层的拨号参数读写命令耦合在一起,通过参数管理模块将主站命令模块和PPP拨号模块解耦。

在对计量营销一体化系统的采集终端进行部件提取过程中,每完成一个部件的提取,则对原采集终端软件系统进行重构,并完成集成测试和确认测试。这样可以始终端保持原采集终端软件系统可行,成为第一个验证部件的产品。

最后加强对核心资源的管理,方便研发工程师查找部件及扩展部件。到了开发的后期,核心资源库的公共组件慢慢多起来了,同时由于在扩展业务层对很多基础部件进行了参数化和功能扩展,很多部件在标识和功能上都差异不大,出现了有点混淆的问题。为了更好地管理,我建立了WIKI服务器,采用WIKI服务器进行组件管理,在WIKI服务器上对组件的标识、功能、接口及与相关组件的差别等等进行了描述。研发工程师输入相关的关键字就能找到匹配的组件及每个组件详细的说明,方便研发工程师使用。

随着用电信息采集系统核心资源库的建立,国网用电信息采集系统项目的功能也逐渐完善起来。采集终端软件系统在今年8月份通过了国家电网电力科学研究院的全功能测试,这对全体项目组成员是一个振奋人心的好消息,说明我们的努力得到了认可。

作者:jinhailiao 发表于2013-1-18 8:36:51 原文链接
阅读:0 评论:0 查看评论

相关 [dssa 软件架构 设计] 推荐:

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

- - CSDN博客推荐文章
去年三月份,我所在的公司启动国网电力用户用电信息采集系统项目,我被任命为项目负责人. 国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分. 由于公司之前为南网(主要是广东省)开发过类似用电信息采集系统,且公司准备在电力行业做强做大,我提出了采用DSSA技术来研发国网用电信息采集系统,得到公司领导层的一致赞同.

软件架构设计

- - 企业架构 - ITeye博客
软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:. 1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.

软件架构设计(二)——软件架构设计过程

- - BlogJava-首页技术区
      一般来讲,涉众包括客户(资方)代表、承接方(劳方)代表、用户代表.       对于要明确实现某种标准的软件系统,通常确定边界非常容易,直接按标准圈定的scope分析即可,比如像SIPServlet容器,是要求遵从JSR168规范的,那么软件系统的Scope就是JSR168规定的Scope,但是也有例外,比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件,那么Scope就不同了.

企业架构思想在软件架构设计中的引入

- - 人月神话的BLOG
很多时候我们在谈企业架构的时候都是正对跨流程,跨业务和跨应用系统的总体规划和分析,企业架构核心好处就是真正体现业务驱动IT,将业务和IT能够真正的匹配起来思考整个企业层面的架构问题. 而很多时候我们谈软件架构的时候仅从软件实现层面来考虑问题,针对一个业务系统的开发,我们有业务建模和软件架构,但是这两个却进行了分离而缺少了系统性的思考,所以原来我们喜欢用系统分析师这个词来综合业务分析师和软件架构师两个岗位的工作.

软件架构

- - 研发管理 - ITeye博客
    对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的.     1、为大规模开发提供基础和规范,并提供可重用的资产,软件系统的大规模开发,必须要有一定的基础和遵循一定的规范,这既是软件工程本身的要求,也是客户的要求. 架构设计的过程中可以将一些公共部分抽象提取出来,形成公共类和工具类,以达到重用的目的.

软件架构风格 - welfear

- - 博客园_我所说的,都是错的
文档名称:软件架构风格(software architecture style). 文档维护:Xuefeng Chang(welfear@gmail.com). 文档创建:2013.07.27. 如果说设计模式是从代码角度为系统降低耦合度,那么架构风格便是从数据角度解耦. 架构是更加宏观和全面的视角,它不再是解决单一的技术问题,而是为系统提供更加.

软件架构师的沟通修炼

- - 博客 - 伯乐在线
在架构师的角色中,沟通是要求有效果的必备技能与工具. 换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的,也可能会跨好多个行业单位. 由于不能直接管理他人,所以架构师指示别人或群体完成特定行动的能力就受到限制.

软件架构师的职责

- - 研发管理 - ITeye博客
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调.     在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求.

软件架构师不等同于资深程序员

- - 研发管理 - ITeye博客
本文的作者Armel Nene是ETAPIX Global公司的首席架构师,他居住在伦敦,他参与过的开源项目包括 Apache Lucene,,Apache Nutch, Liferay 和 Pentaho等. 如今很多的公司的IT部门仍然认为招聘一个资深的程序员,他同样也能承担软件架构师的角色. 资深程序员对整个软件生命周期很了解,他们可以经过培训成为架构师,但他们不等同于架构师.

如何开展软件架构之需求分析

- - CSDN博客架构设计推荐文章
如何开展软件架构之需求分析.  在开始讨论如何开展软件架构之前,先让我们来看一张漫画. 相信大家看到这漫画的时候,总会不自主地会心一笑,客户希望得到礼物,我们却给了他一骨头. 一):未进行充分地需求分析. 解析:架构师未能初别用户群及使用环境约束因素,也许在接到项目时,他还在想着上一个为狗开发的项目,在这个项目中自然而然地认为用户是狗.