1、系统架构设计师论文论文目录一、论基于 DSSA 的软件架构设计与应用二、论基于 Rest 服务的 web 应用系统设计三、论软件可靠性设计与应用一 论基于 DSSA 的软件架构设计与应用【摘要】去年三月份，我所在的公司启动国网电力用户用电信息采集系统项目，我被任命为项目负责人。国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。由于公司之前为南网（主要是广东省）开发过类似用电信息采集系统，且公司准备在电力行业做强做大，我提出了采用 DSSA 技术来研发国网用电信息采集系统，得到公司领导层的一致赞同。由于项目功能实现上具有明显的阶段性，我决定采用演化方式来实现 DSSA 及完成应
2、用产品开发。一是对原有系统、文档及国网用电信息系统功能规范进行分析，完成DSSA；二是对原有系统进行部件提取，做为核心资源的公共部件；三是加强对核心资源的管理，方便研发工程师查找部件及扩展部件。经过近一年的努力，终于完成了公司用电信息采集系统核心资源的建立，也完成了国网电力用户用电信息采集系统项目。 【正文】去年三月份，我所在的公司启动国网电力用户用电信息采集系统项目，我被任命为项目负责人。国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。公司之前开发过广东电网公司计量营销一体化系统，类似于用电信息采集系统。系统架构设计师论文我对广东电网公司计量营销一体化系统的功能规范和国网
3、电力用户用电信息采集系统的功能规范进行分析，发现除了系统内各自的通信协议不同外，其它的功能需求大体上相同。整个采集系统都是分三层实现，主站层，采集终端层和电能表层。由于电能表已经规范化了，有专门的表计生产厂家，这一层不需要投入资源进行研发。从公司目前现状来看，主站层投入研发工作量较少，一是主站的开发中模块化做得比较好；二是用户的需求基本一致。国网用电信息采集系统仅需要在广东电网公司计量营销一体化系统主站进行界面调整和支持国网用电信息采集系统通信协议即可达到要求。根据之前开发的经验，用电信息采集系统开发的重点是采集终端的开发。因为采集终端需要安装到现场，而现场的用电环境各异，能够到达的远程信道也
4、不同。采集终端可维护性低或可靠性低，则会产生大量的维护工作，影响公司品牌及利润。根据用电信息采集系统的要求，采集终端分为集中抄表终端、专变采集终端和公变采集终端。广东电网公司计量营销一体化系统的采集终端大体上也分为上述三类：低压集抄终端、负荷管理终端、配变监测终端。通过对采集终端的功能要求进行分析，可以看出它们归属于一个产品家族。我在项目组启动会议上提议采用 DSSA 技术进行采集终端产品的研发，建立公司用电信息采集系统核心资源，同时将计量营销一体化系统的采集终端也归结到产品家族中。众所周知，DSSA（特定领域软件架构）就是在一个特定的问题领域中支持一组应用的开发，这些应用形成产品家族。DSS
5、A 是软件重用的一种手段，它由领域模型、参考需求、参考架构组成重用元素。用电信息采集系统各终端基本需求都是对外接的电能表或测量点的读数进行采集，稍做处理后通过 GPRS/CDMA 信道远程传输给采集系统主站端。采集终端的功能模块一般包括测量点采集模块，表计规约模块，现场总线模块，PPP 拨号模块，主站命令模块，本地维护模块，程序升级模块，数据存储模块，交流采样模块，负荷控制模块等等。系统架构设计师论文由于采集终端在现场使用的特殊性，它的非功能性要求主要集中在可靠性、可修改性和易用性。现场用电环境复杂，信道各异，要求采集终端具有高可靠性。由于市场上的电能表支持的规约各异及现场总线发展快速，要求采
6、集终端可扩展性强，能快速支持新的表计规约和现场总线，且支持远程升级操作。由于在现场施工时多是由工程队进行安装，工程队人员的素质高低不齐，要求采集终端在本地操作具有一定的智能化，且要求调试简单。根据以上分析，采集终端软件架构采用分层设计比较合适。分层设计的软件可修改性和可扩展性比较好。由于分层开发，将关注点分离到各层，将系统的复杂度分到各层中，相应可靠性也可以得到提高。在用电信息采集系统研发中，我决定采用演化方式进行开发。首先对原有系统、文档及国网用电信息系统功能规范进行分析，完成 DSSA。在项目启始阶段，我对计量营销一体化系统及用户需求文档及设计文档进行分析，将用户需求用EXCEL 表格列出
7、来。然后再对国网用电信息采集系统的功能规范进行分析，用同样的方式列出用户需求，需求比对后发现它们之间的功能要求大体上是一样的。但由于通信协议不同，会导致一些功能在实现上有差别，如主从终端连接功能，用电信息采集系统采用一条命令完成主从终端的所有通信，而计量营销一体化系统分成建链、传输、断链三条命令来实现。于是我决定将基础业务模块做成通用的模块，根据不同的参数来初始化模块，或各具体产品自己适配模块。按照这个需求，我对核心资源进行分层设计。总体上，核心资源分成三层，由低到高依次是：基础资源层，基础业务层，扩展业务层。基础资源层包括多进程框架，GUI 系统，系统 API 和驱动封装，虚拟通道模块等等。
8、由于采集终端的操作系统是 LINUX，而且通讯口资源比较多，采用一个进程管理一个通讯口，单一管理便于维护，因此提供多进程框架，方便应用开发时的进程增加。对系统 API系统架构设计师论文和驱动进行封装，方便以后代码的移植。基础业务层主要包括用电信息采集系统的各个基础功能模块，有现场总线模块、表计规约模块、测量点采集模块、交流采样模块、负荷控制模块等等。扩展业务层主要对基础业务层中的各个模块进行参数化和适配，以适应本系统的需要。根据目前的情况，扩展业务层主要有计量营销一体化系统部件包和国网用电信息采集系统部件包。其次对原有系统进行部件提取，做为核心资源的公共部件。计量营销一体化系统的采集终端在研发
9、时由于没有采用组件开发技术，各功能模块和应用层耦合较强，在提取公共部件时需要对应用层解耦。各个具体的功能都有相应的控制参数，而控制参数可以由主站命令模块进行读写，将控制参数管理模块做成中介者模式，很好地实现了各功能模块的解耦。如 PPP 拨号模块，和应用层的拨号参数读写命令耦合在一起，通过参数管理模块将主站命令模块和 PPP 拨号模块解耦。在对计量营销一体化系统的采集终端进行部件提取过程中，每完成一个部件的提取，则对原采集终端软件系统进行重构，并完成集成测试和确认测试。这样可以始终端保持原采集终端软件系统可行，成为第一个验证部件的产品。最后加强对核心资源的管理，方便研发工程师查找部件及扩展部件
10、。到了开发的后期，核心资源库的公共组件慢慢多起来了，同时由于在扩展业务层对很多基础部件进行了参数化和功能扩展，很多部件在标识和功能上都差异不大，出现了有点混淆的问题。为了更好地管理，我建立了 WIKI 服务器，采用 WIKI 服务器进行组件管理，在 WIKI 服务器上对组件的标识、功能、接口及与相关组件的差别等等进行了描述。研发工程师输入相关的关键字就能找到匹配的组件及每个组件详细的说明，方便研发工程师使用。随着用电信息采集系统核心资源库的建立，国网用电信息采集系统项目的功能也逐渐完善起来。采集终端软件系统在今年 8 月份通过了国家电网电力科学研究院的全功能测试，系统架构设计师论文这对全体项目
11、组成员是一个振奋人心的好消息，说明我们的努力得到了认可。（2811 字）二 论基于 rest 服务的 web 应用系统设计【摘要】2011 年上半年，我在上海中软资源软件有限公司(ICSS) ，作为项目组长参与了公司人事管理(HR)系统开发。在系统开发前，公司在信息化建设中，也已采用请假流程、薪资管理、招聘等系统，虽然较为成熟，但彼此间互相独立，业务数据无法共享。且公司各个分公司间，对 HR 系统使用情况也截然不同，有的分公司由于各种原因，仍然采用手工管理本应信息系统化的业务流程。公司是以软件外包业务为主，所以人力资源管理系统在公司信息化建设中的地位至关重要。这次开发的 HR 系统，将整合现有
12、的业务系统，在整个公司内部推行使用，以解决信息孤岛带来的效率低下问题。为了以后的扩展需要，保证在业务和空间尽可能大的扩展性。因此，经过研讨，决定采用 REST Web 服务方式实现系统应用层。本文将就 HR 系统开发过程，描述一下对 REST 服务的使用和认识的体会。【正文】上海中软 HR 管理系统整体采用基于 B/S 的三层架构设计。我做为项目组长参与系统需求分析至测试和部署的整个过程，直接向 IT 部门总监汇报。负责沟通需求，建立项目组，确定系统架构风格和技术实现方案。预定开发周期为 120 天，系统部署后有两个月的试运行期，项目组人数在 5-10 人间变动。由于项目开发资源（比如时间）紧
13、张，公司 HR 系统业务逻辑复杂，旧系统改进与新需求交织，项目组对业务并不熟悉，难以在一开始预估将所有业务移植到新系统的时间。因此，在开发模型选择上，采用螺旋式增量开发。首先不必追求大而全，在开发完系统基本框架基础上，优先移植最系统架构设计师论文亟待改进的业务。经与领导和 HR 部门沟通研究， 递交了系统准备实现的功能列表，按不同实现优先级排列，标记为 P1 的功能优先级最高，必须实现。标记为 P2/P3/P4 的功能优先级依次降低，必要时可以根据资源情况需要进行裁剪。在开发技术的选择上，由于本公司业务以微软外包为主，公司的开发人员大都熟悉一项或多项微软开发技术，作为微软公司合作伙伴可以低成本
14、获取软件开发和管理工具，方便地获取技术支持。 所以决定该系统采用微软技术：表示层基于 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
15、 服务；一台数据库服务器 Windows Server 2008 + SQL Server 2008。经过试运行，于 7 月份投入正式使用。目前系统状况良好，经运行评估，实现了全部必须功能，性能、安全性等质量均达到了原定设计要求。目前系统正在根据业务需要，由后续项目组做二次开发中。采用 REST 服务方式实现系统业务逻辑层，完全符合项目开发时考虑的两个因素：简单和灵活。传统的 Internet Web 服务一般基于 SOAP 协议，构造 SOAP 请求 XML 虽然目前.NET Framework 已实现较好地封装，但不便非.Net 语言调用，如客户端页面中大量采用了 Ajax 技术，使用 J
16、avaScript 构造 Soap 请求非常困难。在调用服务的 Web 页面开发完成前，为了调试和测试服务，必须写单独的测试程序，十分不便。相比之下，而 REST 服务具有非常出色地灵活性。既能被服务器端面向对象语言调用，又可以直接被客户端的脚本语言调用。也很方便用浏览器和 Fiddler 工具进行测试。我们系统架构设计师论文在项目中，并没有将 REST 服务单纯视为一串地址的响应，但基于 HTTP 协议，可以最大地利用 HTTP 协议的语义特性。如数据的增删改查操作对应不同 Http Method(Put/Delete/Update/Get)。用户可以用相同访问服务结点(Endpoint)，
17、根据需要，通过在请求头中设置不同的 Accept-Type，获取不同形式的数据结果，比如JSON（用于 Ajax)或 XML(用于后台)。更好的性能和缓存支持 由于不需要构造 Soap 消息，请求 Rest 服务显然开销更小。 REST 类 Web 服务可以利用高速缓存控制头，从而减少带宽的需求，从而 REST 可以改善响应时间和改进用户体验。可扩展性和无状态性 每个请求都是独立的。一旦被调用，服务器不保留任何会话，这样就可以更具响应性。通过减少事件后通讯状态的维护工作，提高了服务器的可扩展性。在为系统开发 REST 服务时，也遇到一些问题：一、安全性方案。并不是指 REST 服务安全性不足，
18、其本身没有内置的安全支持，但所有 HTTP 支持安全模式和框架几乎都可以用于 REST 服务。真正潜在风险存在于 REST灵活的使用方式上，既可以被服务器端调用又能被客户端调用，所以一开始就要明确地区分用户访问权限和系统访问权限，区分 Web 页面权限和 REST 服务权限，但有时在开发中经常混为一谈，所以要加强设计阶段这方面的文档和评估工作。二、服务接口规范性。REST 服务基于 URI 地址访问，有非常强的语义性，服务接口的每个操作都基于一个 URI 模板。在实际业务中，功能类似的操作被做成多个重载，随之重载的增多，URI 模板如何约定，如何扩展便成为一个规范性问题。开始时，对此未予以足够
19、重视，在多人开发服务，以致一些服务操作语义产生了混乱，影响了理解和正确使用。后来，又额外花费时间资源统一了规定了操作 Uri 格式。这一方面，源于业内尚无明确的标准，更重要是，应该从设计时就全面考虑将来如果需要重载等功能扩展，URI 模板的语系统架构设计师论文义扩展方式。还有一些其他的规范问题，诸如一些操作包括增删改查中的一种以上的数据操作，Http Method 如何定义，也应该一并考虑。三、WCF REST 自身限制。 WCF 从 3.0 发展到 4.0，已经是较为成熟。而 WCF 的REST 构件，则是全新的技术，WCF 作为.NET 平台 Web Service 的替代者，无论在开发还
20、是管理上，都极大的灵活性。而 WCF REST 的灵活体现在开发和使用上，在管理维护情况下，WCF REST 服务接口操作未提供如 WCF 一样的灵活的配置功能， URI 模板等元素必须在代码中设置，消息格式虽然可以根据客户端请求输出，但不能在配置文件中设置。总的来说，虽然 REST 服务仍然在发展中，经验与技术还有很大进步空间。但毫无疑问，基于 REST 服务的 WEB 应用程序拥有很多优势，未在在 WEB 系统，将有更光明的应用前景。（2259 字）三 论软件可靠性设计与应用【摘要】去年三月份，公司启动电力用户用电信息采集系统项目，我被任命为项目负责人。电力用户用电信息采集系统是国家电网公
21、司坚强智能电网建设的一部分。电力用户用电信息系统实现对所有用户的用电信息的采集，用户面广量大，用电环境各异，能够到达的远程信道不同，现场安装的终端类型也各不同。因此公司提出了软高的可靠性要求。为了满足电力用户用电信息采集系统的可靠性要求，我带领团队对系统的运行环境和特点等进行分析，找出可能影响系统运行可靠性的原因。根据分析出的结果制定了提高系统可靠性的措施：一是应用架构设计风格和设计模式，降低采集终端软件的复杂度；二是采用补采及数据校验机制，保证数据的完整性和正确性；三是在采集终端中采用看门狗和进程心跳检测机制。系统架构设计师论文项目完成后在重庆*区进行实施部署，投运后一直非常稳定，得到重庆*
22、供电局的一致好评。【正文】我所在的公司从属于电力行业，去年三月份，公司启动电力用户用电信息采集系统项目，我被任命为项目负责人。电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分。用电信息采集系统从总体上分三层实现：主站层、终端层和表计层。主站层主要有营销业务处理子系统、前置采集子系统和数据库管理子系统。终端层主要负责表计数据采集和简单的处理存储。主站和终端的通信方式目前用得比较多的是 CDMA/GPRS。终端主要通过 RS485 串口、电力线载波和表计进行数据交换。公司根据已有的人力资源和经验，决定对主站应用软件和终端软硬件进行研发，表计统一进行采购。主站层主要进行应用服务器的软件
23、研发，主要满足供电局营销部门的业务要求。终端层，根据采集系统规范的要求，现场终端分为三类，一是集中器抄表终端，主要对居民用户表的用电信息进行采集；二是专变采集终端，主要对大客户（如工厂）的用电信息进行采集及进行负荷管理；三是公变采集终端，主要对公用变压器的用电信息进行采集及对电能质量进行监控。电力用户用电信息系统实现对所有用户的用电信息的采集，用户面广量大，用电环境各异，能够到达的远程信道不同，现场安装的终端类型也各不同。由于系统使用环境的复杂性，以及用电信息数据的完整性和正确性，因此公司提出了软高的可靠性要求。要提高产品的可靠性指标，首先要分析影响产品可靠性的原因。一般来说影响产品可靠性的原
24、因有如下一些：一、运行环境，软件可靠性定义是相对于运行环境而言的，一样的软件在不同的运行环境下其可靠性是不一样的。不同的用户操作习惯不同，会影响软件的可靠性。软件的可系统架构设计师论文靠性是软件缺陷和用户的可预测性的一个复杂函数。二、软件规模，也就是软件的大小。一个只有几百行代码的软件和一个几千万行代码的软件是不能相提并论的。三、软件内部结构，结构对软件可靠性的影响主要是软件的复杂程度，一般来说，结构越复杂的软件，所包含的软件缺陷数就可能越多。在进行软件设计时就要有意识地采用各种降低复杂度的架构策略，如模块化设计，分层设计等等。分而治之的方法是最好的降低复杂度的方法。四、软件的开发环境和开发方
25、法，软件工程表明，软件的开发方法对软件的可靠性有显著地影响。例如，与非结构化开发方法相对，结构化方法可以明显减少软件的缺陷数。五、软件的可靠性投入，软件在生命周期中的可靠性投入包括可靠性设计、可靠性测试、可靠性管理和可靠性评价等方面投入的人力、资源、资金和时间等。我根据用电信息采集系统本身的特点，结合以上五个影响软件可靠性的因素，除了加强可靠性管理外，我制定了提高用电信息采集系统可靠性的三点措施。一、应用架构设计风格和设计模式，降低采集终端软件的复杂度。好的设计是成功的一半。在项目开始我就牢牢把握设计关。采集终端应用软件根据功能要求主要分为采集子系统和主站通讯子系统。在进行采集子系统的设计时，项目组一致认为采用分层设计比较符合实际情况。按层次由上到下分为应用层、表计规约层、现场总线规约层和数据链路层。表计规约层和现场总线层都采用工厂方法设计模式，来获得具体的表计规约对象和现场总线对象。总体流程是采集子系统应用层根据具体的表计类型获得表计规约对象，完成表计规约的组帧工作；然后交给现场总线层，现场总线层根据当前的通道类型获得具体的现场总线规约对象，完成现场总线规约的组帧工具；最后将报文帧传送给数据链路层发出去。返回时按相反的顺
