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