当前位置: 首页 > news >正文

软考高级-系统架构设计师 论文范文参考(二)

文章目录

    • 论企业应用集成
    • 论软件三层结构的设计
    • 论软件设计模式的应用
    • 论软件维护及软件可维护性
    • 论信息系统安全性设计
    • 论信息系统的安全性设计(二)
    • 论信息系统的架构设计
    • 论信息系统架构设计(二)

论企业应用集成

 摘要: 2016年9月,我国某省移动通信有限公司决定启动VerisBilling6.0项目,该项目实现了在线计费、离线计费、内容计费、账务处理、信控管理等子系统的整合,我作为系统分析师全程参与了项目的建设。本文以VerisBilling6.0项目为例,论述企业应用集成中界面集成、数据集成、应用集成在软件集成过程中的实际应用及效果。通过界面集成,实现了账务前台、产品前台、信控前台界面的整合,把几个独立系统经过集成也一个整体展现给用户。通过数据集成,将各之前各系统产生的“信息孤岛”进行了整合,数据的一致性得到有效保障。通过应用集成,从业务逻辑上为各功能系统提供统一的数据接口,使业务逻辑更规范。通过以上集成技术的应用,项目于2017年4月成功上线,各项性能指标达到客户要求,获得省移动通信公司各级领导的好评。
  近几年来某省移动用户增长至3000多万,随着移动数据流量资费的新一轮下调,导致GPRS数据流量成爆发式增长,OpenBillingNG版系统在话单处理上瓶颈显现。16年春节期间,GPRS日话单达到30亿条,话单处理处于积压状态,直到节后两周才将积压话单追完,大量跨月的话单引发了大批用户投诉,给移动业务支撑中心带来的压力非常大;该省移动通信公司相关领导联合系统运营商遂展开会议讨论解决方案,最终决定将该省OpenBillingNG版升级至VerisBilling6.0版本,以解决OpenBillingNG版本遇到的瓶颈问题。作为移动通信BOSS业务支撑的核心,VerisBilling6.0需支持24x7连续运行,满足话单的实时处理,还需要把在线计费、离线计费、内容计费、账务处理、产品管理等在OpenBillingNG版时独立的系统进行整合。我作为系统分析师全程参与了VerisBilling6.0项目的建设,VerisBilling 6.0项目由产品管理组、研发组、测试组、对账组、运维组、数据组、专家组共120人组成的项目团队,耗时8个月完成,项目从2016年9月初启动,至2017年4月30日上线。
 作为系统分析师,我深知在VerisBilling6.0项目中系统集成方法对该项目的重要性。通常情况下,企业应用集成中常用的集成有界面集成、数据集成、应用集成等方法。其中界面集成通过将各系统界面进行整合,从而实现了为用户提供一个统一的系统界面的效果,增强了各系统间的交互性能。数据集成的集成点在数据访问层,通过中间件更新数据库的方式,保持数据一致;通过对数据库中通常需要同步的数据表的集成,实现各系统的数据高效同步,保证了系统数据的一致性。应用集成的集成点都在程序的内部结构中,需要根据业务的实际情况,重组结构,重新开发;是基于业务逻辑层面的集成方法,通过对系统业务逻辑进行集成,为各系统提供统一的业务接口,属于较高层次是集成方式,也是难度较大的集成。三种集成方法相辅相成,互为补充。
 如何为VerisBilling6.0项目选择合适的集成方法呢?首先,作为BOSS系统的核心,Veris Billing6.0项目是一个庞大、复杂的项目,涉及账务系统前台、产品管理系统前台、信控管理系统前台的界面集成。其次,VerisBilling6.0项目还涉及计费产品库、账务产品库、信控系统数据库等数据库的整合。最后,项目还涉及在线计费、离线计费、内容计费等几个系统业务逻辑方面的集成。接下来我将从界面集成、数据集成、应用集成三个方面来具体阐述,在VerisBilling6.0项目中,我的团队是如何使用这些方式实现企业应用集成的。
 界面集成的应用。在VerisBilling6.0项目中,我们实现了账务系统前台、产品管理前台、信控管理系统前台进行整合。首先,我们对信控系统页面重新做了布局,将账务系统前台、产品管理前台的功能页合并到信控管理系统的主界面上,并增加了相应的链接功能菜单。其次,在做界面集成时,我们充分的考虑了系统界面的用户友好性,对几个界面做了扁平化设计,并将几个系统的界面样式风格调整一致,使得集成后的系统看上去更像一个整体。最后,我们增加了系统导航功能菜单,完善了系统间的交互性能。经过界面集成,三个系统界面被集成到一个系统页面上,形成了一个整体。当用户登录信控管理系统后台就可以对账务管理系统、产品管理系统、信控管理系统进行操作。由于三个系统都存在独立的系统表,且都实现了自身的权限管理等功能,要想实现单点登录后进行各系统功能的操作,还需要对用户数据进行集成。
 数据集成的应用。在OpenBillingNG版本中,存在账务产品库、计费产品库、局数据产品库、信控数据库等,在以往的生产过程中,经常会因数据变动后同步不及时而产生错误引发用户投诉。VerisBilling6.0项目要求将所有产品库进行整合,合并到一个中心数据库,首先,我们对各功能系统的数据库进行分析,将各库中的数据表进行梳理比对,并将平时需要做同步处理的表提取出来分析。接下来,将提取出来的数据表合并到公共数据库,实现了将分散的数据信息进整理合并。最后,将那些系统间无直接关系的表直接割接到公共数据库,经过梳理加工后,完成了对数据的集成,实现了数据的统一管理,数据的一致性得到了保障。经过数据集成,可以有效避免“信息孤岛”的产生,由于系统之间直接调用公共数据表的数据,使得系统数据在任何时候都是完整的、一致的,有效避免数据同步不及时的问题。
  应用集成的应用。VerisBilling6.0项目中,大量的外围系统需要通过接口访问计费MDB和账务MDB。由于这个版本中,MDB数据表的变动非常大,为了保障CRM等外围系统对MDB的访问不受影响,首先,我们对所有的MDB接口进行了梳理并同外围系统研发人员进行了确认。接下来,针对每个接口,我们进行了重新定义,并将设计文档发与给外围系统研发负责人,然后按设计文档要求开发出相应的接口。最后,在系统测试过程中,要求各外围系统参与联调测试。由于接口的修改涉及到系统业务逻辑的调整,应用集成难度极大,对外围系统的影响面较广,在该集成方法的使用过程中,参与的人员最多,联调周期最长。应用集成对于各方参与研发的人员综合素质要求也比较高,需要充分考虑逻辑业务的变化对系统的性能的影响,对任何一个接口的疏忽都会产生较为严重的后果。
  通过以上集成技术的应用,VerisBilling6.0项目于2017年4月底上线,经过半年的运行,系统各项性能指标达到可以要求,并通过客户验收,获得省移动通信公司各级领导好评。在项目结束后的讨论会上,大家也指出了项目中存在一些不足。在项目中由于MDB发生了变动,所以需要做业务逻辑的调整,我们在项目中要求所有外围系统都需要参与联调测试,但有几个接口CRM没有按要求进行相应的调整,导致系统上线当天出现CRM访问MDB出现异常。
  通过VerisBilling6.0项目,使我深刻的认识到在项目实施过程中,每一个细节都需要把控好。首先,在项目中需让专家团队及时对风险进行评估,并针对每个风险点需要提供相应的应对措施,这些措施在项目出现问题时能得到有效的处置。其次,需要制定好实施计划,并严格安计划进行实施,特别是一些需要做联调测试的内容上,必须严格按要求完成,避免出现联调测试不完整这类似问题。最后,在项目中一定要严格把控好每个细节,并实现将系统每个细节的把控落实到个人。

论软件三层结构的设计

摘要:
 我所在的单位是国内主要的商业银行之一,作为单位的主要技术骨干,2009年1月,我主持了远期结售汇系统的开发,该系统是我行综合业务系统的一个子系统,由于银行系统对安全性,可靠性,可用性和响应速度要求很高,我选择了三层C/S结构作为该系统的软件体系结构,在详细的设计三层结构的过程中,我采用了字符终端为表示层,CICS TRANSATION SERVER为中间层,DB2 UDB 7.1为数据库层,并采用了CICS SWITCH组,并行批量的办法来解决设计中遇到的问题,保证了远期结售汇系统按计划完成并顺利投产,我设计的软件三层结构得到了同事和领导的一致认同和称赞。但是,我也看到在三层结构设计中存在一些不足之处:比如中间层的负载均衡算法过于简单,容易造成系统负荷不均衡,并行批量设计不够严谨,容易造成资源冲突等。
正文:
 我所在的单位是国内主要的商业银行之一。众所周知,银行的业务存在一个“二八定理”:即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好地服务大客户,适应我国对外贸易的蓬勃发展态势,促进我国对外贸易的发展,2009年1月,我行开展了远期结售汇业务。 所谓的远期结售汇就是企业在取得中国外汇管理局的批准后,根据对外贸易的合同等凭证与银行制定合约,银行根据制定合约当天的外汇汇率,通过远期汇率公式,计算出交割当天的外汇汇率,并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业务系统的一个子系统,它主要包括了联机部分﹑批量部分﹑清算部分和通兑部分,具有协议管理﹑合约管理﹑报价管理﹑外汇敞口管理﹑帐务管理﹑数据拆分管理﹑报表管理﹑业务缩微和事后监督等功能。 我作为单位的主要技术骨干之一,主持并参与了远期结售汇系统的项目计划﹑需求分析﹑设计﹑编码和测试阶段的工作。由于银行系统对安全性,可靠性,可用性和响应速度要求很高,我选择了三层C/S结构作为该系统的软件体系结构,下面,我将分层次详细介绍三层C/S软件体系结构的设计过程。: 1﹑表示层为字符终端。我行以前一直使用IBM的VISUALGEN 2.0附带的图形用户终端来开发终端程序,但在使用的过程中,分行的业务人员反映响应速度比较慢,特别是业务量比较大的时候,速度更是难以忍受。为此,我行最近自行开发了一套字符终端CITE,它采用VISUAL BASIC作为开发语言,具有响应速度快,交互能力强,易学,编码快和功能强大的特点,在权衡了两者的优点和缺点之后,我决定选择字符终端CITE作为表示层。 2﹑中间层为CICS TRANSATION SERVER(CTS)。首先,我行与IBM公司一直保持着良好的合作关系,而我行的大部分技术和设备都采用了IBM公司的产品,其中包括了大型机,由于CICS在IBM的大型机上得到了广泛的应用,并在我行取得了很大的成功,为了保证与原来系统的兼容和互用性,我采用了IBM的CTS作为中间层,连接表示层和数据库层,简化系统的设计,使开发人员可以专注于表示逻辑和业务逻辑的开发工作,缩短了开发周期,减少开发费用和维护费用,提高了开发的成功率;其次,对于中间层的业务逻辑,我采用了我行一直使用的VISUALAGE FOR JAVA作为开发平台,它具有简单易用的特点,特别适合开发业务逻辑,可以使开发人员快速而准确地开发出业务逻辑,确保了远期结售汇系统的顺利完成; 最后,由于采用了CTS,确保了系统的开放性和互操作性,保证了与我行原来的联机系统和其他系统的兼容,保护了我行的原有投资。 3﹑数据层为DB2 UDB7.1.由于DB2在大型事务处理系统中表现出色,我行一直使用DB2作为事务处理的数据库,并取得了很大的成功,在DB2数据库的使用方面积累了自己独到的经验和大量的人才,为了延续技术的连续性和保护原有投资,我选择了DB2 UDB7.1作为数据层。 但是,在设计的过程中我也遇到了一些困难,我主要采取了以下的办法来解决: 1﹑CICS SWITCH组。众所周知,银行系统对于安全性,可靠性,可用性和响应速度要求很高,特别是我行最近进行了数据集中,全国只设两个数据中心,分别在XX和YY 两个地方,这样对以上的要求就更高了,为了保障我行的安全生产,我采用了CTS SWITCH组技术,所谓的CICS SWITCH组,就是一组相同的CTS,每个CTS上都有相同的业务逻辑,共同作为中间层,消除了单点故障,确保了系统的高度可用性。为了简化系统的设计和缩短通讯时间,我采用了简单的负载均衡算法,比如这次分配给第N个CTS,下次则分配给第N+1个CTS,当到了最后一个,就从第一个开始;为了更好地实现容错,我采用了当第N个CTS失效的时候,把它正在处理的业务转到第N+1个上面继续处理,这样大大增加了系统的可用性,可以为客户提供更好的服务;此外,我还采用了数据库连接池的技术,大大缩短了数据库处理速度,提高了系统运行速度。 2﹑并行批量。银行系统每天都要处理大量的数据,为了确保白天的业务能顺利进行,有一部分的帐务处理,比如一部分内部户帐务处理,或者代理收费业务和总帐与分户帐核对等功能就要到晚上批量地去处理,但是,这部分数据在数据集中之后就显得更加庞大,我行以前采用串行提交批量作业的办法,远远不能适应数据中心亿万级的数据处理要求,在与其他技术骨干讨论之后,并经过充分的论证和试验,我决定采用了并行批量的技术,所谓的并行批量,就是在利用IBM的OPC(Tivoli Operations, Planning and Control)技术,把批量作业按时间和业务处理先后顺序由操作员统一提交的基础上,再利用DB2的PARTITION技术,把几个地区分到一个PATITON里面分别处理,大大提高了银行系统的数据处理速度,确保了远期结售汇系统三层结构的先进性。在并行批量的设计过程中,我考虑到批量作业有可能因为网络错误或者资源冲突等原因而中断,这样在编写批量程序和作业的时候必须支持断点重提,以确保生产的顺利进行。 由于我软件三层结构设计得当,并采取了有效的措施去解决设计中遇到的问题,远期结售汇系统最后按照计划完成并顺利投产,不但保证了系统的开发性开放性﹑可用性和互用性,取得了良好的社会效益和经济效益,而且我的软件三层结构设计得到了同事和领导的一致认同与称赞,为我行以后系统的开发打下了良好的基础。 在总结经验的同时,我也看到了我在软件三层结构设计中的不足之处: 首先,负载算法过于简单,容易造成系统的负荷不均衡:由于每个业务的处理时间不一样,有的可能差距很远,简单的顺序加一负载分配算法就容易造成负载不均衡,但是如果专门设置一个分配器,则增加了一次网络通讯,使得系统的速度变慢,这样对响应速度要求很高的银行系统来说也是不可行的,于是我决定采用基于统计的分配算法,即在收到请求的时候,根据预先设定的权值,按概率,直接分配给CTS。 其次,由于批量作业顺序设计得不过够严谨等各种原因,容易造成资源冲突:在远期结售汇系统运行了一段时间之后,数据中心的维护人员发现了,系统有的时候会出现资源冲突现象,在经过仔细的分析之后,我发现,由于每天各个业务的业务量大小不一样,顺序的两个作业之间访问同一个表的时候便会产生资源冲突,另外,在OPC作业运行的过程中,操作员提交的其他作业与这个时间的OPC作业产生也有可能产生资源冲突。对于第一种情况,可以在不影响业务的情况下调整作业顺序或者对于查询作业运用DB2的共享锁的技术,而第二种情况则要制定规范,规定在某时间断内不允许提交某些作业来解决。为了更好地开展系统分析工作,我将在以后的工作实践中不断地学习,提高自身素质和能力,为我国的软件事业贡献自己的微薄力量。

论软件设计模式的应用

摘要:
 本人2009年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上,为了满足高精度,高性能,高效率的要求开发的测井系统。该系统由井下成套仪器,测井遥测系统,测井地面系统,测井软件系统,测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。设计模式是前人设计面向对象软件的经验和总结,在软件设计中灵活的使用设计模式可以极大的提高系统的稳定性,可扩展性,以及良好的可维护性。本文描述了在测井软件系统开发过程中,如何分析和发现相关模式,以及如何选择和应用设计模式,特别是介绍了MVC模式在软件框架和相关系统模块中的应用和使用效果。在文章的最后,讨论了在实际项目开发中,设计模式应用的有关想法和教训。
正文:
 随着当前石油测井技术的发展,为了能更快,更好的得到储层地层信息,解决目前国内测井系统不统一,测井精度不高,效率低下的缺点,2009年1月中国石油集团公司科技局成立了高性能数控测井系统项目,目的是为国内测井行业提供一个从井下到地面以及解释评价的整套测井系统。系统的设计目标是一次测井,取得所有合格资料,并且能保证60井次的免维修率。整个系统由井下成套仪器,测井遥测系统,测井地面系统,测井软件系统,测井解释评价系统等子系统组成。我主要是负责测井软件系统的分析,设计和部分开发工作。整个测井软件系统完成三个主要任务: 测井数据的采集、 测井数据的工程值计算、测井过程的监控。测井数据采集主要是采集井下仪器通过测井遥测系统传输的测井数据,并保证数据的完整性,正确性。测井数据工程值计算主要是把采集的数据根据不同仪器刻度计算方法进行工程值的计算。测井过程监控主要是把计算的测井数据用曲线和图像的方式实时的显示在屏幕和打印成图,由测井操作员进行实时监控。 设计模式是前人设计面向对象软件的经验和总结,在软件设计中灵活的使用设计模式可以极大的提高系统的稳定性,可扩展性,以及良好的可维护性。在测井软件系统框架进行分析和设计时,考虑如何提高系统的稳定性、可扩展性和可维护性时,我们采用了MVC设计模式。 MVC模式构架包括三个部分:模型(Model)、视图(View)、控制(Control)。模型主要是对系统的数据和逻辑运算的封装。它独立与系统的界面和I/O。视图把表示模型的数据和逻辑关系用特定的形式展示给用户。控制处理用户和软件之间的交互操作,当模型的数据有所变化时,控制负责通知视图做出相应的更新。模型、视图、控制的相互分离有利于模块之间内聚性的提高,耦合更加松散。一个模型可以对应多个视图,由控制来传播模型的变化从而更新视图。 MVC模式如何在测井软件系统实现,我们主要是从如下四个方面进行: 一、分析系统功能,分离功能模型 首先根据系统的主要任务进行系统的模块分解。根据测井软件系统数据采集、数据转换和测井监控三个主要任务,把系统分为三个模块对应于MVC模式的三个部分。其中模型(Model)对应于数据的采集和工程值的计算。测井视图(View)对应于测井监控功能。测井模型所要实现的功能包括:测井数据的采集、数据的刻度计算、数据的存储、数据的操作。测井数据的采集负责硬件平台的初始化,下井仪器的初始化, 井下仪器数据的中断相应,数据帧的采集,数据帧的重组等。数据的刻度计算主要是根据不同的仪器实现数据的刻度计算,包括刻度系数表的获取、刻度计算、深度延迟计算等。数据存储主要是原始数据的存储和测井数据的存储。这里我们采用的是测井公用的XTF格式做为数据存储格式。数据的操作是视图和模型之间数据交互的接口。它主要是提供数据输入和输出功能。 二、视图的设计与实现 视图主要是提供测井数据的图形显示。通过调用模型中的数据操作方法,提取测井数据,根据不同的测井数据提供曲线、波列、图像等多种表现形式。在本系统的实现中,为了提高数据采集的稳定性和程序的健壮性,采用进程间通讯的方式。就是说视图的实现本身一个独立的程序。它与模型之间的通过TCP/IP网络进行通讯。视图主要包括数据源、数据表象对象、绘图打印模块等部分组成。数据源负责得到模型(Model)的数据,然后把数据分配给每个数据表象对象。数据表象对象是个有层次的类家族,其基类是绘图类(CDrawObj),所有的数据表象包括道(CDrawTrack)、曲线(CDrawCurve)、波列(CDrawWave)、图像(CDrawImage),数值对象(CDrawData)等都是从其派生的。最后有绘图打印模块提供管理,负责视图的区域更新,数据表象的绘制和打印等功能。 三、控制的设计与实现 控制主要功能是提供用户的输入输出反馈,同时监控模型的数据变化,通知视图进行更新。由于控制和视图的耦合非常的紧密,在架构实现中,控制和视图是在一个应用程序中实现的。控制主要分为井下仪器控制和视图控制两个部分。其中井下仪器控制主要是由操作人员根据视图中的曲线和图像信息,对仪器发出的状态控制命令,以保证测井过程中数据和仪器的安全。视图控制则是操作人员对视图显示参数的调整,包括鼠标的响应和键盘的响应以及用户对测井原始图的特殊要求如道大小,曲线位置的摆放,颜色的调整等。 四、使用可动态添加算法模型 由于每次测井作业中下井仪器串的仪器种类和仪器的数量都是变化的,为了能更好的抽象出实际的测井模型,提高系统的灵活性,在模型中数据刻度计算部分,我们采用的动态添加的方式。我们把不同测井仪器的刻度算法封装到动态连接库,然后根据测井作业的不同,调用用不同的仪器动态库中的刻度算法。由于视图和控制与模型之间的松耦合,当用户添加算法模块,视图与控制基本不要修改。 在采用MVC模式的软件框架后,整个系统分为两个部分,数据采集管理器和数据实时浏览器。数据采集管理器对应于模型(Model)的实现,数据实时浏览器对应于视图(View)和控制(Control)的实现。我们采用的是Visual C++.net 基于Window2003平台来进行系统开发。采用MVC模式给我们带来了如下好处: 1、由于模型(Model)与视图(View)和控制(Control)之间的松耦合,使得我们非常容易就实现了一个模型运行同时建立多个视图。这在调试仪器时非常有用,当硬件人员调试仪器时直接连接网线就可以一边看仪器一边看数据。不再需要象以前必须到地面系统控制室查看数据了。 2、适合多硬件平台的跨接。由于不同的硬件平台上采集数据的方式都不同,有的系统采用的是PCI总线,有的是USB接入,有的是ISA卡接入。由于模型(Model)和视图(View)的松耦合,当要移植到不同的硬件平台上是我们只有修改相应的模型(Model),有可以实现对不同硬件平台的支持。 3、良好的可维护性和扩展性。由于采用MVC模式,系统模块功能划分明确,代码实现也相对容易。代码的错误不会在系统中扩散,同时由于可以动态添加仪器算法模块,当用户添加新仪器时,不需要更改系统程序,只有添加仪器动态库DLL就可以了。 在整个系统的开发中,我们还应用了一些别的模式, 有些模式是在进行系统设计时,就考虑到而特意实现的, 有些模式是在采用别的方法实现后,效果不太理想,在代码重构时引进的。在应用设计模式进行系统设计和开发后,整个系统各个模块之间逻辑变的相对独立,耦合也很松散,结构的扩展性良好。而且使得代码的重用的程度变好,减少了错误的发生和错误在代码中的扩散。但是在实际应用模式的过程中,我还发现模式应用的经验越丰富,模式应用的就越好。有时在采用何种模式时,有几种模式方案可以采用,但是具体采用那个模式就需要不断的尝试,看看模式是否满足实际的需要。特别要注意的是不能为了设计模式进行设计,也就是过分设计的问题。这样会导致设计过于复杂,偏离程序设计简约够用的基本原则。 目前设计模式在软件开发中的应用正引起广大开发人员的注意,各大软件开发商也在软件开发工具中提供了有关设计模式的自动应用的工具,相信设计模式会越来越多应用于软件的设计和开发中。

论软件维护及软件可维护性

摘要:
 本人2010年有幸主持并参与了国内某银行小额信贷综合系统的开发研制工作,作为技术经理主要负责需求分析、概要设计及核心模块的设计实现等工作。该系统主要面向中小企业及个人客户,为其提供融资贷款服务。由于银行项目软件通常有较长的维护周期,并且要求有效地控制维护成本和维护风险,因此需要采用多种措施来提高软件的可维护性。本文结合作者实践,讨论了软件维护的三种类型,改正性维护、预防性维护和完善性维护的特点,阐明了影响软件可维护性的三个主要因素,即分析阶段要尽可能地模块化设计,高内聚低耦合;缺陷预防需要新技术新工具的支撑;变更控制要通过UCM方式来进行闭环管理。本文结合该项目的开发过程,详细介绍了在项目中所进行的软件维护活动,为提高软件可维护性所采取的措施,并基于这些评价了实施过程中的效果。最后总结了项目在软件维护及可维护性方面取得的成绩和需要改进的地方。
正文:
 众所周知,当前以中小、小微企业及个人为主的小额借款人“融资难,融资贵”的问题仍然比较突出,为解决这个问题国家出台了一系列政策措施鼓励和支持银行业开展小额信贷等创新型金融服务。 2010年5月,我所在单位受国内某银行委托开发研制该行小额信贷综合业务系统。 该系统主要为中小企业及个人客户提供无担保无抵押的信贷资金。借款人可以通过网上银行、电子邮件、手机短信、电话及邮寄等多种途径申请贷款。系统收到贷款申请后,先通过外部征信系统获取到借款人的信用信息,并基于信用信息对其进行风险评级,给出参考额度和贷款利率,再由客户经理通过系统进行复审及放款。贷款发放后,风险经理可以通过系统对借款人的还款情况进行实时监控和跟踪。与此同时,该系统还可以针对不同情况给出相应的催收建议及催收措施,从而帮助银行回收贷款,降低不良率。该系统主要包括网上银行、风险评级、授信审批和贷后监控部分,具有客户管理、账务管理、合约管理、催收管理和报表管理等功能。 我作为单位的技术骨干,担任该项目技术经理一职,主持并参与了该项目,主要工作有:需求分析,概要设计,核心模块的设计实现,协助项目经理制订项目计划。由于银行软件系统通常生命周期较长,尤其是软件的维护周期较长,往往还需要一个小型团队专职进行项目的维护工作。为了能够有效控制维护成本,提高软件的可维护性,我们团队在开发工程中采取了一系列方法措施。下面我将详细论述这些方法措施在软件维护方面的作用和意义。 通常比较常见的软件维护类型有:改正性维护、预防性维护和完善性维护。通俗来讲,改正性维护即修改软件交付后发现的缺陷,主要通过提供修复后的新版本、修复脚本或者修复补丁等方式。预防性维护是指在软件开发过程中预防缺陷的产生,是一种防患于未然的措施,正确地进行缺陷预防能够很好地降低软件的开发机维护成本。完善性维护是指由于用户在使用软件的过程中,业务需求发生了变化,因而需要对软件系统的功能进行变更的一种维护,这种维护手段不仅要求软件自身有较好的扩展性,同时也要求从管理的角度做好变更的跟踪和控制。 我认为影响软件可维护性的主要因素有三点,首先,系统在分析设计阶段是否很好地遵循了规范,有没有使用成熟可靠的通用构件,系统构架是否扩展性强,模块设计是否高内聚松耦合。其次,缺陷预防的投入是否足够,有没有使用新技术、新工具来提高效率和质量。再次,变更控制管理是否到位,有没有做到问题闭环管理,对于代码的修改是否有评审监控,对于修改后的版本是否有效管理。我们在实际开发中使用了多种技术手段、管理手段来落实以上三点。 1. 尽可能多地使用成熟、稳定的通用构件来增强系统的可靠性、可维护性和可扩展性。 在本项目开发过程中,我们考虑到银行会根据国家政策的调整来调整风险评级的规则,会根据央行的基准利率和计算方法来调整利息的计算方法。如果每一次调整都需要修改源代码,重新编译、打包、回归测试、部署,势必会影响到维护效率,缩短系统的在线时间。我们引入了Drools业务规则引擎和Groovy脚本引擎来解决这一问题。Drools引擎可以把一系列风险评级的推理判断规则封装在一个规则文件中,该文件是一个文本文件,可以方便地对其进行修改编辑。值得一提的是,Drools规则文件的语法使用自然语言风格,即领域定义语言(DSL),这样业务人员也可以轻松地阅读、编写、评审规则文件。Groovy脚本引擎可以动态地执行数学公式,将计算结果返回给主程序。公式中所用到的参数变量可以由业务人员通过Web页面在系统中自行设置,而无需开发人员修改程序或者修改数据。Groovy脚本引擎在计算时,会将业务人员定义的参数以键值对的方式代入公式,从而达到灵活计算的效果,正是由于采用了Drools业务规则引擎和Groovy脚本引擎,我的团队才能有效地提高了系统的可维护性,即当业务规则和利率计算公式发生变化时,业务人员可以不依赖于开发人员和系统管理员的参与,也无需修改程序,重新部署新版本等繁琐步骤就能完成系统的修改升级,大大地提高了系统的在线时间。 2. 使用新技术、新工具进行缺陷预防。 我们认为在软件开发过程中有效的缺陷预防胜于疲于奔命的缺陷修复,因此我们引入了一系列新技术、新工具来进行缺陷预防。首先推行持续集成技术,即采用Jenkins持续集成引擎,每隔15分钟对项目代码进行一次构建,并自动执行单元测试用例,每隔2小时执行一次集成测试用例、代码静结构分析和代码覆盖率分析,并将结果通过邮件发送给项目成员。其次,优化开发人员的集成开发工具,1)使用JUnit做单元测试;2)使用Emma做代码覆盖率测试;3)使用Findbugs和PMD做代码静结构分析;4)使用Checkstyle做代码规范检查。与此同时,测试人员使用EasyB和Selenium来开发自动化回归测试用例,并将其与Jenkins引擎集成。质量控制人员使用Sonar对代码质量、规模和设计进行度量。这样就可以使团队成员从多种角度对项目质量把关,进而使整个系统的设计、开发、集成、测试过程透明可见,真正地做到了让项目在“阳光”下进行,从而有效地达到了进行缺陷预防的目的,大大地降低了缺陷逃逸率。但是另一方面,有项目成员抱怨,太多的检查预防措施耽误了开发进度,连项目经理也会有相同的顾虑。我通过和公司另一项目A做了对比来说服他们,A项目基本不做预防检查,表面上看似很快的进度却在系统测试阶段搁浅了,反反复复地“回归”,以至于模块、代码千疮百孔、缝缝又补补、补丁摞补丁,甚至在上线后发现了严重缺陷,造成了公司和客户的损失。项目组成员听取了我的建议,不但没有了抱怨,更是从严、从深地积极做好缺陷防范工作,正是由于我们的项目在开发过程中就夯实了基础,才在验收测试及试运行是无任何故障,受到客户的好评。 3. 使用UCM变更控制 我们在项目开发过程中使用IBM Rational ClearCase和ClearQuest对变更和缺陷实施UCM管理。在项目维护期,闭环的变更和缺陷管理显得尤为重要。所谓UCM,是指客户提出的变更申请和缺陷进行统一管理,包括分类,优先级评定和状态跟踪等。在我们项目中,客户通过ClearQuest提出变更请求,待项目经理及变更委员会批准后,新需求会分配给相应的开发人员。开发人员只可以根据ClearQuest的任务签出相应模块的程序代码进行修改,而对于其它不相关的代码,他们则无权限访问。开发人员完成代码修改和提交后,变更请求流转至测试人员处进行复测和回归测试,最后经用户确认后,才由发版经理发布部署。整个流程可管理、可追踪、有记录并与版本控制系统无缝集成。 4. 结束语 综上所述,我们在项目开发过程中采用成熟文档的通用构件,并引入新技术、新工具进行缺陷预防,同时结合UCM变更控制管理等一系列手段来提高系统的可维护性,有效地降低了软件的维护难度和维护成本。自系统上线至今未发现任何严重缺陷,系统稳定可靠,得到了客户和公司领导的肯定。同时,我也发现了一些不足之处,例如,如何平衡缺陷预防、质量控制和项目进度的关系。我相信我和我的团队可以再不断地尝试、摸索和总结中解决好这一问题。我在日后的工作中会更努力地提高专业技术水平,为我国的软件事业贡献出自己的力量。

论信息系统安全性设计

摘要:
 随着国内航空业的高速发展,机场空中交通日趋繁忙,机场空管有必要提前掌握空中态势,做好空中交通管制的准备工作。现阶段各个机场空管系统的信息获取手段单一,依赖本机场雷达提供的信息已不能满足场内空中交通管制的需要。为了改变这种现状,我单位对民航部分系统实施改造,开发了一个空管综合数据定制系统,使得机场空管能够根据业务需要自主定制所需信息,实现资源共享。 在整个项目中,我担任空管综合数据定制系统的主任设计师,负责空管综合数据定制系统分析、设计和开发工作。空管综合数据定制系统是B/S结构的WEB应用系统,用户登录系统后可以在有限的范围内自主定制飞行情报、气象情报等信息。 在项目开发过程中,我们注重系统的安全性。在系统安全方面,我们采用登录控制、授权管理等方法保证用户访问安全;用日志记录加数据备份保障系统数据安全;用双机热备系统保障服务器系统运行安全。
正文:
 国内民航空中交通管制按地理区域划分,由各大地区空中交通管理机构通过区域中心管制系统实现对各个机场空管系统的管理工作。机场空管的信息数据通过内部网络或专线等方式汇集到区管中心,运用数据融合等情报处理技术形成多种信息的统一态势,以便于对管制区内的飞行统一实施空中交通管制。 现阶段各个机场空管系统的信息获取手段较为单一,管制所需的数据来源处于一个“被动”状态。为改变这种现状,实现空管信息资源共享,我单位对地区空中交通管制系统进行初步改造,以实现机场对飞行情报、气象情报、飞行计划等信息的按需定制。 在该项目中,我参与项目的需求分析,并担任用户按需定制功能的主任设计师,负责设计和开发“空管综合信息数据定制系统”。该项目于2010年8月开始启动,历时7个月完成项目的开发工作,并于2011年3月投入试运行。目前系统已交付,运行至今相当稳定。 根据系统的功能需求,空管综合信息数据定制系统按功能分为用户管理,信息定制、数据查询与维护等部分。用户管理分为用户帐户管理、用户基本信息维护、用户定制权限管理。根据用户的类型,系统设置了两种用户的角色,分别是管理员用户和定制用户。信息定制功能根据信息的类型分为飞行情报定制、飞行计划定制、气象情报定制和飞行流量定制等。定制用户根据其定制类型权限可以分别不同类型的信息。数据查询与维护功能包括定制状态查询、日志数据查询、基础数据查询与维护等。 在系统开发初期,我们对系统的层次架构和系统环境进行仔细分析。定制并不限于在用户系统的哪一个席位上进行操作,并考虑到实现用户定制应对用户的客户端影响最小化,所以我们决定采用B/S架构,以WEB方式实现用户定制功能。这样也使得应用程序都存放在WEB服务器上,方便了系统的部署与维护,实现了零客户端。考虑到空管系统中UNIX操作系统的HP服务器,我们以JAVA为主要开发语言。为使系统有更好的可扩充性、灵活性与逻辑性,并实现系统的业务处理与显示相分离,系统采用MVC模式,结构分为表示层、业务层(控制层、业务逻辑层、数据访问层和消息发送层)、数据层。在系统中采用Tomcat作为Web服务器,数据库服务器则使用原来在空中交通管制系统中作为数据库服务器的Oracle9i。 空管行业是一个比较特殊的行业,他们的系统有一个独立的网络,在物理上与互联网隔离。空管综合信息数据定制系统也是运行在他们内部网络上的WEB应用系统,所以在安全问题上,我们重点保证用户访问安全、数据安全以及系统的运行安全。 (一)保障用户的访问安全的措施 虽然系统运行在空管内部网络上,但是也必须保证只有合法用户才能访问系统。我们采用登录页面作为用户访问系统的首页,这也是WEB应用系统的通用模式。在这个页面上需要输入用户名与口令,系统验证正确后,用户才能进行下一步操作。用户名与密码需要从用户使用的客户端传输到WEB服务器上进行验证。如果是定制用户,则用户使用的计算机很可能与WEB服务器不在一个网段中,那么必须考虑对用户名与密码信息进行保护,防止数据的机密性的破坏。我们查找相关的HTTP安全技术,决定使用HTTPS安全技术保护用户名和密码信息在网络中的传输。TOMCAT对HTTPS提供了直接的支持,实现起来也不复杂,但由于HTTPS连接过程比一般的HTTP连接要慢,所以我们也只在登录页面使用了HTTPS连接。 用户名和密码被保存在服务器端的数据库相关的用户信息表中,所以具有相应权限的数据库用户可以通过oracle客户端或者Sql Plus工具直接查看用户信息表的内容。为了防止用户密码的泄露,我们对密码字段的内容进行加密,然后再存储到数据库的表格中。我们编写了一个中间转换类实现对密码字段的转换,方便了系统对密码的读写操作。 在开发需求中,系统用户分为管理员用户和定制用户,这两种用户对系统有不同的访问范围和操作方式,而定制用户对定制情报数据也有不同的地理范围权限。因此,对用户进行操作权限控制也是我们必须考虑的安全性问题。 我们在用户登录时就根据用户名对用户的身份进行判断,针对不同类型的用户设计不同的访问界面和菜单,这也就使管理员和定制用户对应不同的功能。对于定制用户不同的定制地理范围权限,我们设计了一个类似定制界面中的ActiveX地图控件,管理员用户在授权管理时,在这个地图控件中绘制出一个地理区域,并将结果保存到定制用户的权限表中。这样在定制用户实施定制操作时,系统将他的地理范围权限显示在定制界面中的地图控件上,他所绘制的定制区域不能超出其地理范围权限,否则告警并要求他重新输入。 (二)数据安全的保护措施 对于系统的数据安全问题,我们通过两个方面的措施,一个是记录用户操作的日志;二是定时备份系统数据。 我们对定制用户的每一个定制操作及取消定制操作都进行了日志记录,以便于查找定制用户是否正常使用系统,和检查用户的定制范围是否在授权范围内。管理员需要对用户信息进行维护,对用户权限进行管理,以及对系统基础数据维护。我们对管理员的每一个操作也进行了日志记录。日志记录不但可以用于查询管理员和定制用户的操作历史记录,还有助于分析系统其它的功能问题,防止用户的误操作。 我们在UNIX服务器设置了一个定时任务,每天对系统的关键数据进行了备份;每周自动进行一次数据全备份。定时任务是个服务器上的SHELL脚本,执行数据库表格数据的备份,和一些运行数据文件的备份。对于系统自动产生的备份文件,我们采用人工的方式按期拷贝出来,转存到备份盘上,以释放服务器上的磁盘空间。 (三)系统运行安全机制 为保证系统的运行安全,我们采用了双机热备的方式。在服务器端运行着一主一备的服务器。服务器上运行着集群软件,主备服务器用“心跳”来检测对方的状态。这些状态包括数据库状态、WEB服务器状态以及其它子进程的状态。备机一旦发现主机的某个子进程的状态失效,立即自动切换。这两台服务器上oracle数据库搭建了高级复制,以保证数据库中表格数据的同步。 从系统的实际运行效果上看,系统在安全性方面很好地符合了用户的需求。安全性是一个WEB应用系统必须重视的问题,不管系统运行在内网还是互联网。用户登录、用户权限、数据安全,以及系统运行安全等方面是WEB系统重要安全问题。我们在系统运行安全方面还有个异地备份需要考虑。现在状况是只在一个区域中心的系统运行综合数据定制系统,如果本地的系统出现故障,还需要一个异地和备中心来接替运行。但在主备中心的数据同步和状态通信上还存在不少需要解决的问题。

论信息系统的安全性设计(二)

摘要:
 2011年我有幸参加了某单位遥感卫星测控系统项目的研制,我在系统中担任软件分系统负责人,主要负责软件开发的管理工作、软件需求分析,软件设计方面的工作。遥感卫星测控系统主要完成对遥感成像卫星的遥测,遥控和数传任务,软件分系统作为整个系统的分系统之一,主要完成系统硬件设备工作参数设置,系统运行状态监视和遥感图像数据的管理功能。由于卫星测控系统的操作牵涉到卫星资源的控制和遥感影像产品的管理,系统的安全性设计变得十分重要。在项目的需求分析阶段,项目组对系统的安全性进行了分析,得出的结论是系统可能存在物理安全隐患,网络通信安全隐患,和系统安全隐患,在项目的设计阶段项目组针对系统安全风险分析报告中提到的系统安全隐患做了相应的设计方案。主要采用异地备份来解决可能发生的自然灾害对系统造成的不可恢复的损坏。采用防火墙技术和入侵检测系统对网络访问加以控制,采用非对称加密技术和数字签名技术保证重要数据的安全性和可靠性。本文对系统的安全性设计进行了详细介绍,最后总结了系统运行的效果和不足之处,以及针对不知之处采取的补救措施。
正文:
 2011年我参加了某单位遥感卫星测控系统项目的开发工作,我在系统任命中担任软件分系统负责人,主要负责软件开发小组的管理和对系统进行软件需求分析和设计。遥感卫星测控系统由发射分系统,接收分系统,测试标校分系统,天伺馈分系统和软件分系统组成,系统的五个分系统各施其职,协调工作,完成对遥感卫星的跟踪,遥测,遥控和数传任务。软件分系统在系统中扮演指挥者的角色,主要负责对系统工作状态的监视,工作参数的设置,执行卫星跟踪任务计划和管理遥感影像数据。软件系统也是整个系统的人机接口,工作人员在执行任务时对设备的大部分操作都要通过软件分系统完成,系统对防误操作方面的要求比较高,软件分系统承担了卫星遥控计划的执行和卫星遥感数据的管理,因此,系统对安全保密性要求比较高。 软件分系统采用C/A/S三层体系结构,数据库服务器主要完成对系统的任务计划,遥感数据和系统日志信息进行存储管理;业务服务器主要完成系统的业务处理,主要包括与上级指挥中心的网络通信功能,与其他硬件分系统的嵌入式软件之间的串口通信功能,对系统工作参数的设置和工作状态的监视功能,执行上级指挥中心下发的任务计划,对遥感影像数据进行管理等功能。系统包括多个客户端软件,主要完成人机接口功能。系统的数据库服务器,业务服务器,多个嵌入式监控软件和部分客户端处于同一个局域网内,部分客户端部署在指挥中心,通过光纤网络与业务服务器通信。系统与指挥中心的网络接口是系统与外界的唯一一个外部接口。 项目组在分析了系统的网络结构和组成后,我们发现系统在物理方面,网络通信方面,系统安全性方面都存在安全隐患。物理方面,由于系统由多个服务器和大量磁盘阵列组成,系统保存了大量的中药数据,尽管系统本地也采取的备份措施,但是如果发生火灾,洪灾,地震等不可抗击的自然灾害,将可能永久性损坏系统服务器和存储设备,导致大量的宝贵数据丢失;在网络传输方面系统对外有一个网络接口与指挥中心进行通信,这个非法访问者提供了机会,可能存在外部的非法入侵行为。在网络上传输的数据会被非法获取,导致重要信息的泄密,或者外部非法入侵者冒出指挥中心给系统发送错误的任务计划,导致系统执行错误的遥控指令,这将会导致严重的后果。在系统内部,应用服务器和其他硬件设备的嵌入式软件通过串口传输控制命令和设备状态,有少部分设备由于设备位置离系统机房比较远,并且要经常移动位置,所以不得不采用无线通信的方式,这也给非法入侵者提供了机会。可能通过截获无线信号获取设备控制命令,或者伪造设备命令导致设置执行错误的指令。所以网络通信将是系统实施安全防护的重点部分。在系统访问控制方面,系统的服务器采用windows server2008操作系统,客户端采用windows xp操作系统,虽然操作系统提供了比较安全的用户身份认证和访问控制权限控制,基本上满足了系统安全性要求,但是也有可能因为系统的漏洞或者系统感染病毒或木马程序导致非法入侵者可以访问系统资源。在应用系统层面,主要存在工作人员误操作的隐患。 经过需求阶段的系统安全分析,项目组得出了系统安全风险报告,项目组根据报告中提到的问题进行了系统安全性方案设计,物理方面的安全问题主要是自然灾害导致的,并且一旦发生也是不可抗拒的,我们采取将系统重要数据定时进行异地备份,在指挥中心建立一个重要数据备份库。予解决系统物理方面的安全问题。 在网络通信方面,我们采取了两方面的解决措施,一方面是在系统外网入口处安装应用防火墙,控制外部用户对系统内的资源访问,通过设置访问ip端口号限制,已经通信服务方面的限制,阻止非法用户通过网络进入系统,同时安装入侵检测系统,达到及时发现网络访问异常告警的目的,根据入侵检测系统报告的网络情况,及时修改防火墙设置。另一方面是对系统与中心传输的数据进行加密和合法性验证,主要采用了非对称加密技术RSA和数字签名技术。有效防止数据被窃取,也保证了数据源的合法性,同时也防止双方的抵赖性。对于系统内部的无线传输,我们采用具有加密功能的无线数传模块,发送方在发送数据之前进行数据加密,接收方接收到数据后先进行解密即可得到正确的命令。防止了无线通信可能造成的数据泄密。 在操作系统级,我们关闭了很多没用的网络通信服务,设置了用户访问权限、策略。对用户的访问权限进行控制,同时安装杀毒软件定期进行病毒扫描,防止系统被病毒感染或者木马程序入侵。及时安装系统补丁,定期更新病毒库。定期更新用户密码。对重要的数据采用加密软件进行加密存储。在应用软件方面,我们主要采取用户身份认真和访问权限控制,将用户等级分为管理员,操作用户和监视用户;管理员可以创建用户和执行一切操作,操作用户可以控制设备,执行任务计划,监视用户只能对系统工作状态进行监视。这样可以防止卫星测控系统软件被不相干人员随意操作。 系统经过一年多的运行,目前运行稳定,没有发现非法访问和泄密事件发生,说明我们的系统安全性设计方案是成功的,但是在系统运行中也发现一些考虑不周全的地方,用户可以通过PE光盘启动系统,绕过已经安装的操作系统直接访问系统硬盘,这相当于操作系统设置的用户名和密码,用户访问权限没有用了。我们发现这个问题后,封闭了所有设备的光驱和USB接口,并加强了安全管理方面的工作,对系统机房实行二十四小时监控,防止非法人员接近系统主机,经过这个项目,我们总结出信息系统的安全工作必须从技术上和安全管理制度以及工作人员的思想上全面考虑。单从技术上无法保证系统绝对的安全性,系统安全任重道远,我们时刻准备对系统不足之处进行改进。

论信息系统的架构设计

摘要:
 本文结合作者所参与研发的前台业务报表系统升级改造项目对如何设计信息系统的架构进行了论述。前台业务报表系统是国内某大型商业银行全行的通用报表平台,每日通过从各业务系统采集的数据进行报表展现,为该银行的决策者和经营管理人员提供各类系统交易的日报表信息平台。项目的主要内容是将原有的前台业务报表系统进行报表展现产品升级,对技术架构进行重构,对业务功能进行扩充,全面满足海内外的管理部门、业务部门对查看日趋复杂的大量的报表需求。 本文首先说明了作者在需求分析之后,软件设计之前为何重视架构设计的原因,并描述了通过分析本项目的规模、复杂程度、变化的因素等进行的新系统的架构设计。在此基础上依据具体的数据论述了作者采用的架构对于项目质量的效果。最后作者对本项目在架构设计的不足之处也做了简要分析,并提出了改进建议。
正文:
 我在国内一家较大的商业银行的软件开发中心工作。由于我行前台业务报表从99年试点投产以来已经运行多年,其使用的报表产品版本对新操作系统的兼容等已经存在问题需要升级;原系统的技术架构及业务功能也已无法满足现今的业务报表要求。2010年2月,总行规划并立项于10月前完成对业务报表进行改造,对使用的报表展现产品升级,对技术架构进行重构;根据日趋复杂的报表需求,对业务功能进行扩充。我有幸参与了该项目并担任系统架构设计和项目管理工作。 本项目的主要任务是将国内前台业务报表和海外业务报表应用已有功能进行重构,实现境内外框架一体化,支持多语言与多时区,境内外分行均使用统一应用体系架构实现各业务类报表的处理、展现及打印功能;将国内版数据处理和存储集中在各个一级分行,海外版数据统一集中存放在海外数据中心;对使用的报表产品进行升级,采用SAP公司提供的CRYSTAL报表工具,完成报表体系架构的调整及报表程序的移行升级。 架构是信息系统的基石,对于信息系统项目的开发来说,一个清晰的架构是首要的,架构在软件需求与软件设计之间架起一座桥梁,着重解决软件系统的机构和需求向实现平坦地过渡的问题。架构在软件开发中为不同的人员提供了共同交流的语言,体现并尝试了系统早期的设计决策,并作为系统设计的抽象,为实现框架和构建的共享和重用、基于架构的软件开发提供了有力的支持。本系统是一个系统改造项目,涉及国内37家分行,16家境外机构,规模庞大而复杂,开发周期长,为保证项目质量,我们在需求分析之后,明确了本项目的开发任务,软件设计之前进行了详细的软件架构设计。 考虑到以下几点: 1、我行各分行及海外机构分布较散,另外随着INTERNET的迅速发展,部分报表信息需要通过网络向总行领导汇报展现; 2、各分行对数据查询速度要求高,每日各网点产生的数据量很大,要求每日报表在10秒内展现,并能进行批量打印; 3、银行内对数据的保密性要求高; 4、增强系统的可扩展性,并能访问若干年前的报表数据。 典型的软件架构风格有很多。例如,设计图形用户界面常用的事件驱动风格、设计操作系统常用的层次化设计风格,设计编译程序厂用电管道与过滤风格、设计分布式应用程序常用的客户机/服务器风格等。一个实用的软件系统通常是几种典型架构风格的组合。 经过分析,发现之前的前台业务报表系统C/S模式体系结构已显示出了他在异构的、分布式的网络环境中的不足,可维护性和发布性等较差,并不利于系统扩展,难以满足新系统的要求,基于B/S体系的WEB应用有利于系统的扩展性、维护性。C/S 一般建立在专用的网络上,小范围里的网络环境,局域网之间再通过专门服务器提供连接和数据交换服务。B/S 建立在广域网之上的, 不必是专门的网络硬件环境,有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行;C/S一般面向相对固定的用户群,对信息安全的控制能力很强。一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息。B/S 建立在广域网之上, 对安全的控制能力相对弱。结合CS和BS架构的优缺点,我们最终采用C/S和B/S混合的架构设计。 一、系统支持分布式部署和集中式部署两种方式。 国内采用分布式部署方式,应用环境部署在各一级分行,数据库部署两个Oracle实例。 海外采用集中式部署方式,应用环境部署在海外数据中心,数据库部署两个Oracle实例,两实例间通过DBLINK进行参数表的同步。 客户端程序国内部署于各二级分行、支行和网点;海外部署于海外分行。 二、报表文件的生成: (1) 为减少传输的数据量,批量打印及离线归档采用文本方式,并且文本可以进行压缩传输,可有效减少网络传输流量。 (2) 所有报表数据文件都预生成,生成文本文件的批量服务器端进行自行开发,不依赖于报表工具产品,以根据数据本身的特色进行开发提高批量处理效率。例如采用SQL嵌入到C编程语言中,利用C语言提高对文件处理的效率。 (3) 在批量服务器输出文件的同时,把相关的结果也写入到数据库的B/S查询表中供B/S客户端查询展现,B/S查询表的数据库表的结构与批量打印使用的文本文件结构一致。 三、报表查看、批量打印部分: (1) B/S架构:报表查看结果的HTML页面由服务器生成,客户端本地不处理任何数据。对于B/S客户端方式,是一个纯集中式系统,数据的逻辑处理以及显示处理都是集中式的。对于B/S的报本查询需设立缓存机制。 (2) C/S架构:是一个服务器与分布式结合的报表处理系统。服务器端主要工作是数据的逻辑处理,例如报表的汇总、统计、字典转换、币种折算、数据表关联等各类数据的逻辑处理。 四、版本在线自动更新功能: C/S客户端提供版本在线自动更新功能。打开客户端程序后,客户端会根据临时文件夹及更新日志记录自行检查是否与服务器版本号相符,若发现不符合,则客户端自行下载最新的版本,并自行安装新版本,解决网点的由于报表频繁升级的安装管理维护问题。 前台业务报表升级改造项目最终在2010年底投产并取得了较大的成功。完全符合海内外各分行及总行管理部门的需求,得到了大家一致好评。 当然,本项目的是存在一些不足之处的。我们在设计时将大部分的精力都放在了整体功能测试上,对于性能的设计上只考虑整体情况,较少考虑具体的数据库性能优化,例如表的索引设计以及锁事务处理机制我们有所忽略。导致投产后仍有少量交易因SQL访问效率问题出现了响应时间过长的情况。这一点也是我们今后的项目设计中需要注意改进的地方。

论信息系统架构设计(二)

摘要:
 本人于2010年7月参加国内某某知名港口供电业务系统的开发工作,在该项目中主要担任系统架构师工作,主要负责该系统架构和网络安全体系架构设计。近年来随着港口吞吐量的增加,港口供电业务信息化需求越来越强,而传统的管理方式已经无法满足业务需求,因此我们开发此系统。通过需求分析,我们将该系统分解为港口供电系统电费管理、生产调度管理、安全管理、机电设备管理、物资管理、申报流程管理、网上办公管理、报表及查询分析管理。 本文以某某港口的供电业务系统为例,分析了管道/过滤器体系架构风格、事件驱动风格、层次架构风格以及客户端浏览器风格,以及以上三种架构风格是如何在该系统中应用的,充分说明了体系架构风格对系统开发的重要性。实践证明,采用良好的软件体系架构风格,不仅可以节省开发和维护成本,提高系统开发的效率,而且可以使系统具有很好的开放性、易扩展性,便于移植性。
正文:
 本人于2010年7月参加了国内某某知名港口供电业务系统的开发工作,在该项目中担任系统架构师工作,主要负责系统架构和网络安全体系架构的设计。随着港口生产业务的发展,港口供电线系统越来越繁忙,而传统的管理方式越来越无法满足港口供电系统信息化管理需求。原来存在一的些信息系统“信息孤岛”现在较为明显。因此,开发新的系统满足日系增长的港口供电业务系统信息化要求日益强烈,为了消除“信息孤岛”现象,同时使新开发的系统能够适应港口未来业务的发展,新的系统架构必须设计良好,具备兼容性、可扩充性。 通过需求分析我们将该系统分为电费管理、生产调度管理、安全管理、机电设备管理、物资管理、申报流程管理、网上办公管理、报表及查询分析管理模块。为了适应港口供电系统信息化不断发展的需求以及对整个系统架构的分析。我们采用面向服务(SOA)的架构,运用WCF技术进行设计。数据库采用oracle10g,系统通过微软的.net平台C#进行开发。为了高效的开发出此系统,我们采用以下方法来实现此系统功能。 首先,系统整体采用层次架构设计模式。我们将这个系统架构分为四层。首先,我们通过需求分析,将客户端用户需求分解为一个个服务。由于该系统涉及港口供电业务系统方方面面,在该系统中需要编写很多服务。我们在前端编写的服务以插件(plugin)的形式进行注册,通过统一的端口以申请访问服务器上的服务。中间契约层作为提供服务的接口,通过契约层将所有的服务操作暴露给用户,所有的服务都需要在契约层上通过ServiceContract进行发布,客户端所有需要的服务也在契约层上进行查找,客户端无须知道每一个服务(service)是如何实现。服务实现层具体实现如何完成每一个服务,所有的服务层要和契约层相关联,通过注册表以访问数据库, 实现和数据库相关的所有操作。服务发布层和服务实现层相关联,通过XML语言实现和服务实现层相关联。将所有的服务注册到相关的应用服务器,以提供契约层成功查找服务。进而实现系统的通信功能。通过采用这种层次架构风格给系统带来了很大益处,实现了系统的高可复用性。如安全信息管理模块、物资管理,港口其他单位的信息化需求较为相似,等在为其他企业开发项目的系统的时候,只需要为该企业开通权限,允许调用此服务即可。同时通过此层次架构的开发,增强了系统网络安全性,由于跟个层次的功能明确,客户端将无法直接访问数据库层,取而代之的是专门的应用服务器去访问访问服务,而其通过对服务器的访问安全设置,提高了对数据库的访问安全性。此外,大大提供企业应用的集成度,在该系统中,港口供电系统的所有应用被集成到一个统一的平台下,如财务部门、劳资人事部门、生成管理部分都需要调用人员信息,在统一的系统平台下,该信息只要一次完成,多次调用即可,打破了传统的同一个界面在不同的应用系统中要重复开发的现象。 其次,在该系统中通过采用管道/过滤器架构风格,实现从人力资源管理系统到供电业务系统的对接。目前港口的人力资源管理系统有专门的系统。我们从该系统中找到需要的数据输出报表接口。供电业务系统开发相应的接口对应获取并分析处理数据,将数据转化为供电业务所需要的数据类型。通过这种方式实现了数据共享功能,避免了数据重复录入,以及和最新的人事信息保持同步问题。 再次,通过采用事件调用架构风格,实现了流程申报管理和生产调度模块和物资管理的对接。在本供电业务管理系统中,申报的流程管理需要关联于此相关联的生产调度信息以及物资相关内容。当在申报流程中填写申请单审批通过后,将自动关联生产派工单以及物资申请单据。 生产调度部门在完成相关任务,物资仓管人员完成物资的派送后,申报流程界面将自动出现此信息,然后根据具体工作审批内容,走公司管理的各种流程化管理步骤。通过此模式成功实现了与申报流程相关内容的自动管理,无需其他手工操作,当以后改进系统时候,可以很方便操作。 第四,通过采用客户端/浏览器(B/S)风格,实现了网上办公模块的管理。对于供电系统宣传模块,以及公司考勤管理、部门工作计划、公司通讯录等内容放到供电系统网站上,这样供电系统的员工不论在公司,还是在外出差,都能方便的使用这些功能。在该部分的设计中,由于考虑到系统涉及很多公司内部管理数据,所以对安全方面做了比较严格的控制,引入了PKI/CA体系的安全认证。系统与用户之间的信息交互都是加密进行的,如此设计,既能满足用户的“随时随地”使用办公模块,又保障了系统的安全性,同时增强了系统的可维护性。 该系统已经于2011年8月,成功通过了供电业务部门的验收,大大提高了港口供电系统信息化管理水平,提高了港口供电系统生产效率,得到了用户的肯定。但是目前该系统由于开发时间有限,系统架构仍存在一些需要改进之处。由于港口供电业务系统平台注册的服务很多,系统用户也很多,有些服务调用响应时间较长,如电费收取模块本身计算较为复杂,在加上服务查找时间,导致客户端获取数据较慢。今后,我们将对层次架构风格系统进行应用服务器分类,将服务按功能发布到不同服务器上,同时提供备份应用服务器,当主服务器无法工作时,备用服务器可以接替主服务器进行工作。这样将提升服务性能,确保系统正常运作。在采用管道/过滤风格的系统将加强对输入数据的校验,如我们发现在人力资源管理系统中输入的数据有些格式错误,数据不正确,这就要求系统提供智能化识别功能。在采用事件架构风格进行系统设计时候,将提供回滚机制,如在此系统中的流程申报出错,系统会提示与此相关联的所有操作撤销,以确保系统的一致性状态。 对于一个成功系统,往往融入好几种体系架构,在该系统中,我们通过共同使用这几种架构,大大提高了系统开发效率,节省系统开发和维护成本,使系统具有更好的开放性、易扩展性,以及可移植性。在今后的日子里,本人一定会更加努力钻研专业基础知识,提高自身水平,为国家信息化建设尽自己绵薄之力。

相关文章:

  • kkFileView安装及使用
  • settimeout和setinterval区别
  • gitee提交大文件夹
  • RVOS的任务调度优化
  • unet算法发展历程简介
  • 643SJBHflash个人网站
  • SQL通用语法和注释,SQL语句分类(DDL,DML,DQL,DCL)及案例
  • KDCJ-400kv冲击耐压试验装置
  • 中华传承-医山命相卜-铁板神数
  • useMemo + memo + useContext 性能优化实战:从无感重渲染到丝滑体验
  • EVAL长度限制突破
  • 探索 JavaScript 中的 Promise 高级用法与实战
  • 研究生面试常见问题
  • EDID结构
  • 第六章:6.6输入以下的杨辉三角形,要求输出10行
  • 嵌入式系统中Flash操作全面解析与最佳实践
  • 通过 Tailwind CSS 自定义样式 实现深色模式切换
  • JavaScript 所有操作数组的方法
  • 并发设计模式实战系列(1):半同步/半异步模式
  • index: 自动化浏览器智能体
  • 一季度提高两只医药基金股票仓位,中欧基金葛兰加仓科伦药业、百利天恒
  • 前瞻2025丨无糖茶,站在转折点?
  • 18条举措!上海国际金融中心进一步提升跨境金融服务便利化
  • 一周人物| 萨韦利上海画展,陆永安“从董源到塞尚”
  • 杨国荣丨阐释学的内涵与意义——张江《阐释学五辨》序
  • 我国成功发射试验二十七号卫星01星~06星