首页 > 其他分享 >系统架构设计师论文范文

系统架构设计师论文范文

时间:2023-10-05 19:01:09浏览次数:37  
标签:架构 论文范文 系统 REST 用电 采集 终端 模块 设计师

论文目录

一、论基于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系统,将整合现有的业务系统,在整个公司内部推行使用,以解决信息孤岛带来的效率低下问题。为了以后的扩展需要,保证在业务和空间尽可能大的扩展性。因此,经过研讨,决定采用REST Web服务方式实现系统应用层。本文将就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系统,多进程设计。守护进程负责喂看门狗和对各子功能进程进行监测,发现子功能进程不正常则进行子进程重启。

经过项目组半年多的努力,项目终于成功完成了,在重庆**区进行实施部署,投运后一直非常稳定。通过本次开发实践我明白了要提高软件的可靠性就要在先期开发时就重视软件

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


标签:架构,论文范文,系统,REST,用电,采集,终端,模块,设计师
From: https://blog.51cto.com/u_15590807/7716796

相关文章

  • 三层架构与MVC的区别
    一:MVC(开发模式)C:controller控制层V:视图成(html,jsp,vue)M:模型层(分两种:第一种service,dao业务模型,第二种entity实体类模型)二:第一种:有现成前端页面(类似或者可以借鉴的)创建项目,导包或配置maven,基本框架搭建的工作准备(实体,工具类,配置文件)V:前端视图C:servletM:service(serviceim......
  • Rest架构风格
    一、什么是Rest风格?REST(RepresentationalStateTransfer)即表述性状态转移,它是一种软件架构风格(或模式)。REST架构风格重新定义Web开发:1、对web的本质回归:一种真实描述Web的方式,不被特定时期的特定应用程序概念歪曲。2.提供区分良好实践和糟糕实践的途径:判断特定项目实践是否......
  • 架构师必须掌握的架构设计原则
    软件设计原则GRASP通用职责分配软件模式来自CraigLarman的软件设计书《UML和模式应用》,Larman在书中提出软件设计的关键任务是职责分配,并提炼总结出9种(5种核心+4种扩展)软件职责分配模式,这些模式是比GoF设计模式更抽象的元模式。信息专家(InformationExpe......
  • 架构师必须掌握的架构设计原则
    软件设计原则GRASP通用职责分配软件模式来自CraigLarman的软件设计书《UML和模式应用》,Larman在书中提出软件设计的关键任务是职责分配,并提炼总结出9种(5种核心+4种扩展)软件职责分配模式,这些模式是比GoF设计模式更抽象的元模式。信息专家(InformationExpe......
  • 架构师必须掌握的架构设计原则
    软件设计原则GRASP通用职责分配软件模式来自CraigLarman的软件设计书《UML和模式应用》,Larman在书中提出软件设计的关键任务是职责分配,并提炼总结出9种(5种核心+4种扩展)软件职责分配模式,这些模式是比GoF设计模式更抽象的元模式。信息专家(InformationExpe......
  • 架构师必须掌握的架构设计原则
    软件设计原则GRASP通用职责分配软件模式来自CraigLarman的软件设计书《UML和模式应用》,Larman在书中提出软件设计的关键任务是职责分配,并提炼总结出9种(5种核心+4种扩展)软件职责分配模式,这些模式是比GoF设计模式更抽象的元模式。信息专家(InformationExpe......
  • 软件架构设计师历年论文题目(2012-2)
    2.论决策支持系统的开发与应用决策支持系统(DecisionSupportSystems,DSS)是以管理科学、运筹学、控制论和行为科学为基础,以计算机技术、仿真技术和信息技术为手段,以人机交互方式进行半结构化和非结构化决策的信息系统。它调用各种信息资源,并提供各种分析工具,为决策者提供分析问题......
  • 软件架构设计师历年论文题目(2012-3)
    论企业应用系统的数据持久层架构设计数据持久层(DataPersistenceLayer)通常位于企业应用系统的业务逻辑层和数据源层之间,为整个项目提供一个高层、统一、安全、并发的数据持久机制,完成对各种数据进行持久化的编程工作,并为系统业务逻辑层提供服务。它能够使程序员避免手工编写访问......
  • 软件架构设计师历年论文题目(2012-4)
    论基于架构的软件设计方法及应用基于架构的软件设计(Architecture-BasedSoftwareDesign,ABSD)方法以构成软件架构的商业、质量和功能需求等要素来驱动整个软件开发过程。ABSD是一个自顶向下,递归细化的软件开发方法,它以软件系统功能的分解为基础,通过选择架构风格实现质量和商业需......
  • 架构师必须掌握的架构设计原则
    软件设计原则GRASP通用职责分配软件模式来自CraigLarman的软件设计书《UML和模式应用》,Larman在书中提出软件设计的关键任务是职责分配,并提炼总结出9种(5种核心+4种扩展)软件职责分配模式,这些模式是比GoF设计模式更抽象的元模式。信息专家(InformationExpe......