关于论文

系统架构设计师论文

论文目录

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

二、论基于 Rest 服务的 web应用系统设计

三、论软件可靠性设计与应用

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

【摘要】

去年三月份， 我所在的公司启动 国 电力用户用电信息采集系统 项目，我被任命为项目

负责人。国 电力用户用电信息采集系统是国家电 公司坚强智能电 建设的一部分。 由于

公司之前为南 （主要是广东省） 开发过类似用电信息采集系统， 且公司准备在电力行业做

强做大，我提出了采用 DSSA 技术来研发国 用电信息采集系统，得到公司领导层的一致

赞同。

由于项目功能实现上具有明显的阶段性，我决定采用演化方式来实现 DSSA 及完成应

用产品开发。一是对原有系统、文档及国 用电信息系统功能规范进行分析，完成 DSSA；

二是对原有系统进行部件提取， 做为核心资源的公共部件； 三是加强对核心资源的管理， 方

便研发工程师查找部件及扩展部件。

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

电力用户用电信息采集系统项目。

【正文】

去年三月份， 我所在的公司启动国 电力用户用电信息采集系统项目， 我被任命为项目

负责人。国 电力用户用电信息采集系统是国家电 公司坚强智能电 建设的一部分。 公司

之前开发过广东电 公司计量营销一体化系统，类似于用电信息采集系统。

系统架构设计师论文

我对广东电 公司计量营销一体化系统的功能规范和国 电力用户用电信息采集系统

的功能规范进行分析， 发现除了系统内各自的通信协议不同外， 其它的功能需求大体上相同。

整个采集系统都是分三层实现， 主站层，采集终端层和电能表层。 由于电能表已经规范化了，

有专门的表计生产厂家， 这一层不需要投入资源进行研发。 从公司目前现状来看， 主站层投

入研发工作量较少， 一是主站的开发中模块化做得比较好； 二是用户的需求基本一致。 国

用电信息采集系统仅需要在广东电 公司计量营销一体化系统主站进行界面调整和支持国

用电信息采集系统通信协议即可达到要求。

根据之前开发的经验， 用电信息采集系统开发的重点是采集终端的开发。 因为采集终端

需要安装到现场， 而现场的用电环境各异， 能够到达的远程信道也不同。 采集终端可维护性

低或可靠性低， 则会产生大量的维护工作， 影响公司品牌及利润。 根据用电信息采集系统的

要求，采集终端分为集中抄表终端、 专变采集终端和公变采集终端。 广东电 公司计量营销

一体化系统的采集终端大体上也分为上述三类： 低压集抄终端、 负荷管理终端、 配变监测终

端。通过对采集终端的功能要求进行分析， 可以看出它们归属于一个产品家族。 我在项目组

启动会议上提议采用 DSSA 技术进行采集终端产品的研发，建立公司用电信息采集系统核

心资源，同时将计量营销一体化系统的采集终端也归结到产品家族中。

众所周知， DSSA（特定领域软件架构）就是在一个特定的问题领域中支持一组应用的

开发，这些应用形成产品家族。 DSSA 是软件重用的一种手段，它由领域模型、参考需求、

参考架构组成重用元素。

用电信息采集系统各终端基本需求都是对外接的电能表或测量点的读数进行采集， 稍做

处理后通过 GPRS/CDMA 信道远程传输给采集系统主站端。采集终端的功能模块一般包括

测量点采集模块，表计规约模块，现场总线模块， PPP 拨 模块，主站命令模块，本地维

护模块，程序升级模块，数据存储模块，交流采样模块，负荷控制模块等等。

系统架构设计师论文

由于采集终端在现场使用的特殊性， 它的非功能性要求主要集中在可靠性、 可修改性和

易用性。现场用电环境复杂，信道各异， 要求采集终端具有高可靠性。 由于市场上的电能表

支持的规约各异及现场总线发展快速， 要求采集终端可扩展性强， 能快速支持新的表计规约

和现场总线， 且支持远程升级操作。 由于在现场施工时多是由工程队进行安装， 工程队人员

的素质高低不齐，要求采集终端在本地操作具有一定的智能化，且要求调试简单。

根据以上分析， 采集终端软件架构采用分层设计比较合适。 分层设计的软件可修改性和

可扩展性比较好。由于分层开发，将关注点分离到各层， 将系统的复杂度分到各层中， 相应

可靠性也可以得到提高。

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

首先对原有系统、文档及国 用电信息系统功能规范进行分析，完成 DSSA。在项目启

始阶段，我对计量营销一体化系统及用户需求文档及设计文档进行分析，将用户需求用

EXCEL 表格列出来。然后再对国 用电信息采集系统的功能规范进行分析，用同样的方式

列出用户需求， 需求比对后发现它们之间的功能要求大体上是一样的。 但由于通信协议不同，

会导致一些功能在实现上有差别， 如主从终端连接功能， 用电信息采集系统采用一条命令完

成主从终端的所有通信， 而计量营销一体化系统分成建链、传输、 断链三条命令来实现。于

是我决定将基础业务模块做成通用的模块， 根据不同的参数来初始化模块， 或各具体产品自

己适配模块。按照这个需求，我对核心资源进行分层设计。

总体上，核心资源分成三层， 由低到高依次是： 基础资源层， 基础业务层， 扩展业务层。

基础资源层包括多进程框架， GUI 系统，系统 API 和驱动封装，虚拟通道模块等等。由于

采集终端的操作系统是 LINUX ，而且通讯口资源比较多，采用一个进程管理一个通讯口，

单一管理便于维护，因此提供多进程框架，方便应用开发时的进程增加。对系统 API 和驱

动进行封装， 方便以后代码的移植。 基础业务层主要包括用电信息采集系统的各个基础功能

系统架构设计师论文

模块，有现场总线模块、表计规约模块、测量点采集模块、交流采样模块、负荷控制模块等

等。扩展业务层主要对基础业务层中的各个模块进行参数化和适配，以适应本系统的需要。

根据目前的情况， 扩展业务层主要有计量营销一体化系统部件包和国 用电信息采集系统部

件包。

其次对原有系统进行部件提取， 做为核心资源的公共部件。 计量营销一体化系统的采集

终端在研发时由于没有采用组件开发技术， 各功能模块和应用层耦合较强， 在提取公共部件

时需要对应用层解耦。 各个具体的功能都有相应的控制参数， 而控制参数可以由主站命令模

块进行读写，将控制参数管理模块做成中介者模式，很好地实现了各功能模块的解耦。如

PPP 拨 模块，和应用层的拨 参数读写命令耦合在一起，通过参数管理模块将主站命令

模块和 PPP 拨 模块解耦。

在对计量营销一体化系统的采集终端进行部件提取过程中， 每完成一个部件的提取， 则

对原采集终端软件系统进行重构， 并完成集成测试和确认测试。 这样可以始终端保持原采集

终端软件系统可行，成为第一个验证部件的产品。

最后加强对核心资源的管理，方便研发工程师查找部件及扩展部件。到了开发的后期，

核心资源库的公共组件慢慢多起来了， 同时由于在扩展业务层对很多基础部件进行了参数化

和功能扩展， 很多部件在标识和功能上都差异不大， 出现了有点混淆的问题。 为了更好地管

理，我建立了 WIKI 服务器，采用 WIKI 服务器进行组件管理，在 WIKI 服务器上对组件的

标识、功能、接口及与相关组件的差别等等进行了描述。 研发工程师输入相关的关键字就能

找到匹配的组件及每个组件详细的说明，方便研发工程师使用。

随着用电信息采集系统核心资源库的建立， 国 用电信息采集系统项目的功能也逐渐完

善起来。采集终端软件系统在今年 8 月份通过了国家电 电力科学研究院的全功能测试，

这对全体项目组成员是一个振奋人心的好消息，说明我们的努力得到了认可。（ 2811 字）

系统架构设计师论文

二论基于 rest 服务的 web 应用系统设计

【摘要】

2011 年上半年，我在上海中软资源软件有限公司 (ICSS)，作为项目组长参与了公司 人

事管理 (HR) 系统开发 。在系统开发前，公司在信息化建设中，也已采用请假流程、薪资管

理、招聘等系统，虽然较为成熟，但彼此间互相独立，业务数据无法共享。且公司各个分公

司间，对 HR 系统使用情况也截然不同， 有的分公司由于各种原因， 仍然采用手工管理本应

信息系统化的业务流程。 公司是以软件外包业务为主， 所以人力资源管理系统在公司信息化

建设中的地位至关重要。 这次开发的 HR 系统，将整合现有的业务系统， 在整个公司内部推

行使用， 以解决信息孤岛带来的效率低下问题。 为了以后的扩展需要， 保证在业务和空间尽

将就 HR 系统开发过程，描述一下对 REST服务的使用和认识的体会。

【正文】

上海中软 HR 管理系统整体采用基于 B/S 的三层架构设计。

我做为项目组长参与系统需求分析至测试和部署的整个过程， 直接向 IT 部门总监汇 。

负责沟通需求，建立项目组，确定系统架构风格和技术实现方案。预定开发周期为 120 天，

系统部署后有两个月的试运行期，项目组人数在 5-10 人间变动。由于项目开发资源（比如

时间）紧张，公司 HR 系统业务逻辑复杂，旧系统改进与新需求交织，项目组对业务并不熟

悉，难以在一开始预估将所有业务移植到新系统的时间。 因此，在开发模型选择上，采用螺

旋式增量开发。 首先不必追求大而全， 在开发完系统基本框架基础上， 优先移植最亟待改进

的业务。经与领导和 HR 部门沟通研究， 递交了系统准备实现的功能列表，按不同实现优

先级排列，标记为 P1 的功能优先级最高，必须实现。标记为 P2/P3/P4 的功能优先级依次

系统架构设计师论文

降低，必要时可以根据资源情况需要进行裁剪。

在开发技术的选择上， 由于本公司业务以微软外包为主， 公司的开发人员大都熟悉一项

或多项微软开发技术， 作为微软公司合作伙伴可以低成本获取软件开发和管理工具， 方便地

获取技术支持。 所以决定该系统采用微软技术：表示层基于 ASP.NET 4.0 ； 中间业务层采

用 REST服务实现，基于 WCF(Windows Communication Foundation) 4.0; 数据访问层

基于微软的 ORM 构件 -AEF(ADO.Net Entity Framework) 4.0 。在构件的选择上，尽可能

降低开发工作量， 提高效率， 力求避免把主要精力放在通用的技术细节， 而是放在业务逻辑

的研究和实现上。

系统部署共有三台服务器：两台 Web 服务器 Windows Server 2008 + IIS 7.5 ， 分

别运行系统 站及 REST服务；一台数据库服务器 Windows Server 2008 + SQL Server

2008 。经过试运行，于 7 月份投入正式使用。目前系统状况良好，经运行评估，实现了全

部必须功能，性能、 安全性等质量均达到了原定设计要求。目前系统正在根据业务需要，由

后续项目组做二次开发中。

采用 REST 服务方式实现系统业务逻辑层，完全符合项目开发时考虑的两个因素：简

单和灵活。传统的 Internet Web 服务一般基于 SOAP 协议，构造 SOAP 请求 XML 虽然目

前.NET Framework 已实现较好地封装，但不便非 .Net 语言调用，如客户端页面中大量采

用了 Ajax 技术，使用 JavaScript 构造 Soap 请求非常困难。在调用服务的 Web 页面开发

完成前，为了调试和测试服务，必须写单独的测试程序，十分不便。

相比之下，而 REST服务具有非常出色地灵活性。既能被服务器端面向对象语言调用，

又可以直接被客户端的脚本语言调用。 也很方便用浏览器和 Fiddler 工具进行测试。 我们在

项目中， 并没有将 REST服务单纯视为一串地址的响应，但基于 HTTP 协议，可以最大地利

用 HTTP 协 议 的 语 义 特 性 。 如 数 据 的 增 删 改 查 操 作 对 应 不 同 Http

系统架构设计师论文

Method(Put/Delete/Update/Get) 。用户可以用相同访问服务结点 (Endpoint) ，根据需要，

通过在请求头中设置不同的 Accept-Type ，获取不同形式的数据结果，比如 JSON（用于

Ajax) 或 XML( 用于后台 )。

更好的性能和缓存支持——由于不需要构造 Soap 消息，请求 Rest 服务显然开销更小。

REST 类 Web 服务可以利用高速缓存控制头，从而减少带宽的需求，从而 REST 可以改善

响应时间和改进用户体验。

可扩展性和无状态性——每个请求都是独立的。一旦被调用，服务器不保留任何会话，这

样就可以更具响应性。通过减少事件后通讯状态的维护工作，提高了服务器的可扩展性。

在为系统开发 REST服务时，也遇到一些问题：

一、安全性方案。并不是指 REST服务安全性不足，其本身没有内置的安全支持，但所

有 HTTP 支持安全模式和框架几乎都可以用于 REST服务。真正潜在风险存在于 REST灵活

的使用方式上， 既可以被服务器端调用又能被客户端调用， 所以一开始就要明确地区分用户

访问权限和系统访问权限，区分 Web 页面权限和 REST服务权限，但有时在开发中经常混

为一谈，所以要加强设计阶段这方面的文档和评估工作。

二、服务接口规范性。 REST服务基于 URI 地址访问，有非常强的语义性，服务接口的

每个操作都基于一个 URI 模板。在实际业务中，功能类似的操作被做成多个重载，随之重

载的增多， URI 模板如何约定，如何扩展便成为一个规范性问题。开始时，对此未予以足够

重视，在多人开发服务， 以致一些服务操作语义产生了混乱， 影响了理解和正确使用。 后来，

又额外花费时间资源统一了规定了操作 Uri 格式。这一方面， 源于业内尚无明确的标准，更

重要是，应该从设计时就全面考虑将来如果需要重载等功能扩展， URI 模板的语义扩展方式。

还有一些其他的规范问题，诸如一些操作包括增删改查中的一种以上的数据操作， Http

Method 如何定义，也应该一并考虑。

系统架构设计师论文

三、WCF REST 自身限制。 WCF 从 3.0 发展到 4.0，已经是较为成熟。 而 WCF 的 REST

构件，则是全新的技术， WCF 作为 .NET 平台 Web Service 的替代者，无论在开发还是管

理上，都极大的灵活性。而 WCF REST的灵活体现在开发和使用上，在管理维护情况下，

WCF REST 服务接口操作未提供如 WCF 一样的灵活的配置功能， URI 模板等元素必须在代

码中设置，消息格式虽然可以根据客户端请求输出，但不能在配置文件中设置。

总的来说， 虽然 REST服务仍然在发展中， 经验与技术还有很大进步空间。 但毫无疑问，

基于 REST 服务的 WEB 应用程序拥有很多优势，未在在 WEB 系统，将有更光明的应用前

景。（ 2259 字）

三论软件可靠性设计与应用

【摘要】

去年三月份， 公司启动 电力用户用电信息采集系统 项目，我被任命为项目负责人。 电力

用户用电信息采集系统是国家电 公司坚强智能电 建设的一部分。 电力用户用电信息系统

实现对所有用户的用电信息的采集， 用户面广量大， 用电环境各异， 能够到达的远程信道不

同，现场安装的终端类型也各不同。因此公司提出了软高的可靠性要求。

为了满足电力用户用电信息采集系统的可靠性要求， 我带领团队对系统的运行环境和特

点等进行分析， 找出可能影响系统运行可靠性的原因。 根据分析出的结果制定了提高系统可

靠性的措施： 一是应用架构设计风格和设计模式， 降低采集终端软件的复杂度； 二是采用补

采及数据校验机制， 保证数据的完整性和正确性； 三是在采集终端中采用看门狗和进程心跳

检测机制。

项目完成后在重庆 **区进行实施部署， 投运后一直非常稳定， 得到重庆 **供电局的一致

好评。

系统架构设计师论文

【正文】

我所在的公司从属于电力行业， 去年三月份，公司启动电力用户用电信息采集系统项目，

我被任命为项目负责人。 电力用户用电信息采集系统是国家电 公司坚强智能电 建设的一

部分。用电信息采集系统从总体上分三层实现：主站层、 终端层和表计层。 主站层主要有营

销业务处理子系统、 前置采集子系统和数据库管理子系统。 终端层主要负责表计数据采集和

简单的处理存储。主站和终端的通信方式目前用得比较多的是 CDMA/GPRS 。终端主要通

过 RS485 串口、电力线载波和表计进行数据交换。

公司根据已有的人力资源和经验， 决定对主站应用软件和终端软硬件进行研发， 表计统

一进行采购。主站层主要进行应用服务器的软件研发， 主要满足供电局营销部门的业务要求。

终端层，根据采集系统规范的要求， 现场终端分为三类， 一是集中器抄表终端，主要对居民

用户表的用电信息进行采集；二是专变采集终端， 主要对大客户（如工厂） 的用电信息进行

采集及进行负荷管理； 三是公变采集终端， 主要对公用变压器的用电信息进行采集及对电能

质量进行监控。

电力用户用电信息系统实现对所有用户的用电信息的采集， 用户面广量大， 用电环境各

异，能够到达的远程信道不同， 现场安装的终端类型也各不同。 由于系统使用环境的复杂性，

以及用电信息数据的完整性和正确性， 因此公司提出了软高的可靠性要求。 要提高产品的可

靠性指标，首先要分析影响产品可靠性的原因。 一般来说影响产品可靠性的原因有如下一些：

一、运行环境， 软件可靠性定义是相对于运行环境而言的， 一样的软件在不同的运行环

境下其可靠性是不一样的。 不同的用户操作习惯不同， 会影响软件的可靠性。 软件的可靠性

是软件缺陷和用户的可预测性的一个复杂函数。

二、软件规模， 也就是软件的大小。 一个只有几百行代码的软件和一个几千万行代码的

软件是不能相提并论的。

系统架构设计师论文

三、软件内部结构， 结构对软件可靠性的影响主要是软件的复杂程度， 一般来说， 结构

越复杂的软件， 所包含的软件缺陷数就可能越多。 在进行软件设计时就要有意识地采用各种

降低复杂度的架构策略， 如模块化设计， 分层设计等等。 分而治之的方法是最好的降低复杂

度的方法。

四、软件的开发环境和开发方法， 软件工程表明， 软件的开发方法对软件的可靠性有显

著地影响。例如，与非结构化开发方法相对，结构化方法可以明显减少软件的缺陷数。

五、软件的可靠性投入， 软件在生命周期中的可靠性投入包括可靠性设计、 可靠性测试、

可靠性管理和可靠性评价等方面投入的人力、资源、资金和时间等。

我根据用电信息采集系统本身的特点， 结合以上五个影响软件可靠性的因素， 除了加强

可靠性管理外，我制定了提高用电信息采集系统可靠性的三点措施。

一、应用架构设计风格和设计模式， 降低采集终端软件的复杂度。 好的设计是成功的一

半。在项目开始我就牢牢把握设计关。 采集终端应用软件根据功能要求主要分为采集子系统

和主站通讯子系统。

在进行采集子系统的设计时， 项目组一致认为采用分层设计比较符合实际情况。 按层次

由上到下分为应用层、 表计规约层、 现场总线规约层和数据链路层。 表计规约层和现场总线

层都采用工厂方法设计模式， 来获得具体的表计规约对象和现场总线对象。 总体流程是采集

子系统应用层根据具体的表计类型获得表计规约对象， 完成表计规约的组帧工作； 然后交给

现场总线层， 现场总线层根据当前的通道类型获得具体的现场总线规约对象， 完成现场总线

规约的组帧工具； 最后将 文帧传送给数据链路层发出去。 返回时按相反的顺序解包， 最后

得到需要的数据返回给应用层。 分层设计的优点是层与层之间通过接口通信， 下层为上层提

供”虚拟机”， 这种设计方法为采集子系统支持各种类型的表计和丰富的现场总线提供了方

便。

系统架构设计师论文

在主站通讯子系统中， 我们采用管道 -过滤器风格的设计， 并辅以设计模式的命令模式。

主站命令帧的格式可以明显分成三部分： 帧框架处理、 应用数据处理和具体功能处理。 帧框

架处理器对帧长度和帧校验进行处理， 成功后将命令帧的帧头帧尾、 帧长和校验码去除， 提

取出应用数据后交给应用数据处理器， 应用数据处理器主要进行帧序 处理、 帧时限处理和

用户密码验证， 成功后提取出具体的功能码传递给功能处理器。 具体功能实现采用命令模式，

这样可以将功能执行部分和命令分析部分解耦。

二、采用补采及数据校验机制， 保证数据的完整性和正确性。 用电信息采集系统对采集

数据的完整性和正确性要求非常高，完整性要达到 98% ，正确性要达到 100% 。

我们对采集子系统进行分析， 发现影响采集成功率的主要原因是采集信道的不稳定， 现

场总线目前主要有 RS485 和电力线载波。 而电力线载波的抗衰减和抗干扰的能力都比较差，

导致采集成功率降低。 为了达到要求， 数据采集子系统增加补采功能， 对于未采集成功的数

据进行多次重试。

数据在存储和传输时都进行数据校验， 最大限度防止出错。 在采集终端中， 数据文件是

主要的存储方式， 我们采用”校验和”的方式对数据文件进行正确性校验。 采集数据在从表

计到采集终端这一部分主要采用电力线载波进行传输。 由于电力线载波的不稳定性， 极易导

致数据出错。我们采用在数据传输帧中加入 CRC 校验的方式来保证数据的正确性。另外由

于表计行度等用电信息都是采用 BCD 码来传输和保存，在数据处理之前对数据进行 BCD

码验证，发现非 BCD 码则说明数据错误。通过这些手段，有效地保证了数据的完整性和正

确性。

三、在采集终端中采用看门狗和进程心跳检测机制。 采集终端安装在现场， 由于维护较

麻烦，需要提高采集终端的可靠性。采集终端采用 LINUX 系统，多进程设计。守护进程负

责喂看门狗和对各子功能进程进行监测，发现子功能进程不正常则进行子进程重启。

系统架构设计师论文

经过项目组半年多的努力，项目终于成功完成了， 在重庆 **区进行实施部署，投运后一

直非常稳定。通过本次开发实践我明白了要提高软件的可靠性就要在先期开发时就重视软件

的可靠性设计，实施可靠性管理。