论软件三层结构的设计

摘要

随着市场的建立和发展，卫生行业面临了很多问题，一些制约卫生事业发展的矛盾和问题日益显现，因此，国家卫生部要求各医院采用信息化管理。前不久，我所在的部门承担了了一个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质量。该系统除了目前常见的结费系统、电子病历外，还包括门诊医生工作站、住院医生工作站、护士工作站等分系统。考虑到需要通过 Intranet 实现功能，并有部分的 Internet 功能，本项目平台最后采用了 Java 平台。我在项目中主要负责项目的的前期规划，即选择合适的开发方案，并建立部分的数据流，在系统实施过程中推动其顺利前进。此系统开发成功后投入运行，获得医院相关工作人员的好评。

正文

前不久，我所在的部门承担了了一个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质量。客户是一个市级医院，医院很早就开始从事信息化管理，但主要是针对结费这一块，后来，对其进行了改进，加入对病人电子病历的管理和采集这样当病人二次就诊时，可以很容易地得到病人的既往病史。但随着系统的运行，院方希望对现有系统进行改进，为了更好得为病人服务，医院考虑加入一些其它的分系统，比如门诊医生工作站、住院医生工作站和护士工作站等等。因此我所在的部门承接了该 HIS 的开发

开发的成果是一个典型的Java技术在 Intranet 上的应用在开发前期，首先要设计出详细的系统功能规范，这一部分所花费的时间很少，因为卫生部在 2002 年曾经颁发了一个有关医院管理系统功能规范的通知，我们参考了该规范，很快确定了各分系统以及每个分系统的的基本功能。但在选择合适的系统平台上有一番讨论，考虚到医院原有系统在某些地方运行良好，是否有必要将原有系统淘汰重新设计，另外新的分系统到底采用何种平台结构也是需要考虑的问题。

医院原有的结费系统和电子病历系统数据流向范围比较固定，主要集中在交费处和挂号处，一旦引入了新的系统，必然要将数据流向医院的各个部门。医院的 Intranet 已经实施因此首先考虑采用 B/s 架构体系，旧系统的数据模型尽可能保留，在系统的软件平台上，我们考虑使用Java平台，可以让数据在整个系统安全、有效地流动，另外现在也有很多的 HIS系统可供我们参考，虽然往往是单机版的系统，但其中的数据模型有很好的参考价值。医院的现有网络系统和操作系统多种多样，这就要求我们选择的软件平台必须具有开放性、平台无关性。而在不同的系统上安装相应的 Java 客户端虚拟机并不困难，最后，在项目组的讨论和征求客户意见下，项目组采用了此方案。

在项目中，我们这样设计 Java 架构系统，将系统分为三层:

(1表示层采用 Jsp 实现页面输出，这也是用户直接访层，表示层接受来自网络浏览器的 HTTP 请求，然后返回给客户端浏览器可以显示的 HTML页面

(2)中间件层用 Java 实现对数据库的访间，考虑到数据的分布特点，我们使用了数据库连接池技术，

(3)数据库层用 SQL Server 实现数据的管理和存储过程

JSP 以其执行的高效性和使用的方便性，已成为近年来大家首选的因特网开发技术，JSP是一种页面开发技术，它以Java 为其服务器端语言，结合Java Script 作为其客户端语言能方便地实现页面的表示。选择 Jsp 作为前台语言，是考虑到它的平台无关性，能够兼容其他的操作系统和数据。利用 Jsp 可以将 HTM 文件很方便地发送到客户 Ve 浏览器，同时也可以支持一些非 HTTT格式的文档发送。我们在网站中的用户层页面设计中，广泛地参考了现有的一些成功案例，在节约设计和开发的费用的同时也得到了用户的认可，比起单纯的Servlet 技术，Jsp 在页面元素上也更为丰富，在这里，我们为今后客户页面定制做了部分尝试，设计了一个比较简单的模块，用户可以通过选择控件来动态生成页面提供打印，当然在这部分我们设计中，可提供的数据库字段是固定有限的，灵活性没有很好体现。

我们大量工作主要放在中间件层，由于系统中的医生工作站分系统是主要部分，因此数据库的负载成为一个不得不考虑的问题，综合考虑，我们决定采用数据连接池技术，因为基本上每个医生都对应一个客户终端，无论是病人资料的查讯或录入，或者医嘱的处理，都涉及到对数据库的频繁读写，服务器对于数据连接的频繁打开和关闭必然导致性能下降。一方面，我们预先考虑数据库的连接量，在系统初始阶段建立相应的存储空间，当数据库连接打开和关闭时都对该连接池进行处理，另一面，我们也使用了高速缓存技术，对某些固定的 SQL查讯结果，例如药品查讯、药性禁忌等，将结果采用缓存存储，以加快对数据库的访问，降低了服务器端的负载，提高性能。值得一提的是，为了尽可能得避免纠纷，医院要求采用医生签名制度，我们设计了电子签名，采用加密算法保证各环节产生数据的有关人员不能抵赖数据库层我们选择了 SQL Server，程序员比较熟悉此平台的开发和设计。在前期，我们到医院做了大量的走访工作，了解整个数据流，同时广泛参考现有的系统，虽然对医院行业不是很熟悉，但数据层开发遇到的问题的并不是很大，在概要设计阶段，我们使用了一些计算机辅助开发工具，这也加快了详细设计的进程。比如使用了 Sybase 的PowerDesigner 工具在概要设计中规划了 E-R 图和各个分系统以及分系统之间的数据流图，然后让工具直接生成

后台数据库中的基本表结构，大大提高了开发效率。整个项目实施完成后，医院相关工作人员反映良好，但其中也暴露出了一些问题，值得

改进，首先，用JSP 编程时容易导致系统信息的扩散。如果有人恶意攻击服务器，程序执行将出现异常。这时，就会在页面上打印出相应的错误信息。这些信息会暴露出这台服务器的路径信息。这个漏洞往往会被人利用，程序员对此也一头雾水，下一步我们考虑从服务器入手采用通用的异常说明界面，解决该问题。

其次，在设计上，可以使用更多的辅助开发工具和建模工具，比如 Rational Rose，可以利用它的代码自动生成功能，来大大提高开发速度，在用户界面定制方面，我们希望通过不断的实践，加强其灵活性，尽可能把可供选择的字段扩大到整个数据库。最后，大量使用 Java 技术，势必对服务器的负载过大，在今后的开发中，除了现有的数据库连接池和缓存技术，我们考虑使用更多的数据库脚本来替代部分 Java代码，来高速实现逻辑，相较而言，数据库脚本的执行速度较有优势，结合结果缓存，应该对服务器的性能有较大的提高。

上面是我在今后的系统设计和开发中需要注意和加以改进的地方，也是我今后应该努力的方向

论软件三层结构的设计

摘要

我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，2003 年1月，我主持了远期结售汇系统的开发，该系统是我行综合业务系统 XX2000 的一个子系统，由于银行系统对安全性，可靠性，可用性和响应速度要求很高，我选择了三层 c/s 结构作为该系统的软件体系结构，在详细的设计三层结构的过程中，我采用了字符终端为表示层，CICS TRANSATION SERVER 为中间层，DB2 UDB 7.1为数据库层，并采用了 CICS SWITCH组，并行批量的办法来解决设计中遇到的问题，保证了远期结售汇系统按计划完成并顺利投产，我设计的软件三层结构得到了同事和领导的一致认同和称赞。但是，我也看到在三层结构设计中存在一些不足之处，比如中间层的负载均衡算法过于简单，容易造成系统负荷不均衡，并行批量设计不够严谨，容易造成资源冲突等

正文

我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个“二八定理”即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好地服务大客户，适应我国对外贸易的蓬勃发展态势，促进我国对外贸易的发展，2003 年1月，我行开展了远期结售汇业务。

所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭证与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交制当天的外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业务系统 X2000 的一个子系统，它主要包括了联机部分、批量部分、清算部分和通兑部分，具有协议管理、合约管理、报价管理、外汇敞口管理、帐务管理、数据拆分管理、报表管理、

业务缩微和事后监督等功能。我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划、需求分析设计、编码和测试阶段的工作。由于银行系统对安全性，可靠性，可用性和响应速度要求很高，我选择了三层 c/s 结构作为该系统的软件体系结构，下面，我将分层次详细介绍三层c/s 软件体系结构的设计过程。

1、表示层为字符终端。我行以前一直使用 IBM的 YISUALGEN2附带的图形用户终端来开发终端程序，但在使用的过程中，分行的业务人员反映响应速度比较慢，特别是业务量比较大的时候，速度更是难以忍受，为此，我行最近自行开发了一套字符终端 CITE，它采用VISUAL BASIC作为开发语言，具有响应速度快，交互能力强，易学，编码快和功能强大的特点，在权衡了两者的优点和缺点之后，我决定选择字符终端 CITE 作为表示层。

2、中间层为CICS TRANSATION SERVER(CTS)。首先，我行与 公司一直保持着良好的合作关系，而我行的大部分技术和设备都采用了 IM公司的产品，其中包括了大型机，由于CICS 在 IBM 的大型机上得到了广泛的应用，并在我行取得了很大的成功，为了保证与原来系统的兼容和互用性，我采用了 IBM 的 CTS 作为中间层，连接表示层和数据库层，简化系统的设计，使开发人员可以专注于表示逻辑和业务逻辑的开发工作，缩短了开发周期，减少开发费用和维护费用，提高了开发的成功率，其次，对于中间层的业务逻辑，我采用了我行一直使用的VISUALAGE FORJAVA作为开发平台，它具有简单易用的特点，特别适合开发业务逻辑可以使开发人员快速而准确地开发出业务逻辑，确保了远期结售汇系统的顺利完成，

最后，由于采用了 CTS，确保了系统的开放性和互操作性，保证了与我行原来的联机系统和其他系统的兼容，保护了我行的原有投资。

3、数据层为DB2 UDB7.1于D2在大型事务处理系统中表现出色，我行一直使用DB2作为事务处理的数据库，并取得了很大的成功，在 DB2 数据库的使用方面积累了自己独到的经验和大量的人才，为了延续技术的连续性和保护原有投资，我选择了 DB2 UDB7.1作为数据层

但是，在设计的过程中我也遇到了一些困难，我主要采取了以下的办法来解决:

1、CICS STITCH组，众所周知，银行系统对于安全性，可靠性，可用性和响应速度要求很高，特别是我行最近进行了数据集中，全国只设两个数据中心，分别在双和Y 两个地方这样对以上的要求就更高了，为了保障我行的安全生产，我采用了 CTS SWITCH组技术，所谓的CICS SWITCH组，就是一组相同的 CTS，每个CTS 上都有相同的业务逻辑，共同作为中层，消除了单点故障，确保了系统的高度可用性。为了简化系统的设计和缩短通讯时间，我采用了简单的负载均衡法，比如这次分配给第1个CTS，下次则分配给第 I1个CTS当到了最后一个，就从第一个开始，为了更好地实现容错，我采用了当第I个CTS 失效的时候，把它正在处理的业务转到第 1 个上面继续处理，这样大大增加了系统的可用性，可以为客户提供更好的服务，此外，我还采用了数据库连接池的技术，大大缩短了数据库处理速度，提高了系统运行速度。

2、并行批量。银行系统每天都要处理大量的数据，为了确保白天的业务能顺利进行，有部分的帐务处理，比如一部分内部户帐务处理，或者代理收费业务和总帐与分户帐核对等功能就要到晚上批量地去处理，但是，这部分数据在数据集中之后就显得更加庞大，我行以前采用串行提交批量作业的办法，远远不能适应数据中心亿万级的数据处理要求，在与其他技术骨干讨论之后，并经过充分的论证和试验，我决定采用了并行批量的技术，所谓的并行批量，就是在利用 IBI的PC (Tivoli Operations，Planning and Control)技术，把批作业按时间和业务处理先后顺序由操作员统一提交的基础上，再利用 DB2的 PARTITION技术把几个地区分到一个 PATITON 里面分别处理，大大提高了银行系统的数据处理速度，确保了远期结售汇系统三层结构的先进性，在并行批量的设计过程中，我考虑到批量作业有可能因为网络错误或者资源冲突等原因而中断，这样在编与批量程序和作业的时候必须支持断点重

提，以确保生产的顺利进行。由于我软件三层结构设计得当，并采取了有效的措施去解决设计中遇到的问题，远期结售汇系统最后按照计划完成并顺利投产，不但保证了系统的开发性开放性、可用性和互用性取得了良好的社会效益和经济效益，而且我的软件三层结构设计得到了同事和领导的一致认

同与称赞，为我行以后系统的开发打下了良好的基础。在总结经验的同时，我也看到了我在软件三层结构设计中的不足之处:首先，负载法过于简单，容易造成系统的负荷不均衡:由于每个业务的处理时间不一样，有的可能差距很远，简单的顺序加一负载分配算法就容易造成负载不均衡，但是如果专门设置一个分配器，则增加了一次网络通讯，使得系统的速度变慢，这样对响应速度要求很高的银行系统来说也是不可行的，于是我决定采用基于统计的分配算法，即在收到请求的时候，根据预先设定的权值，按概率，直接分配给 CTS。

;其次，由于批量作业顺序设计得不过够严谨等各种原因，容易造成资源冲突，在远期结售汇系统运行了一段时间之后，数据中心的维护人员发现了，系统有的时候会出现资源冲突现象，在经过仔细的分析之后，我发现，由于每天各个业务的业务量大小不一样，顺序的两个作业之间访问同一个表的时候便会产生资源冲突，另外，在 OPC 作业运行的过程中，操作员提交的其他作业与这个时间的 oC 作业产生也有可能产生资源冲突。对于第一种情况，可以在不影响业务的情况下调整作业顺序或者对于查询作业运用 DB2 的共享锁的技术，而第种情况则要制定规范，规定在某时间断内不允许提交某些作业来解决。为了更好地开展系统分析工作，我将在以后的工作实践中不断地学习，提高自身素质和能力，为我国的软件事业贡献自己的微薄力量

论软件开发平台的选择与应用

摘要

本文讨论选择新软件开发平台用于重新开发银行中间业务系统。银行中间业务系统是指银行通过与企事业单位、机关团体的合作，为客户提供金融服务的系统。X 省农行银行的原中间业务系统软件开发平台是以UNIX 系统为操作系统，使用的数据库是 Sybase，采用二层的 C/S 结构，使用 DB-Library，T-SQL编程随着业务的不断发展和软件开发维护工作的剧增，该软件开发平台表现出工作效率低，开放性差，开发出的产品不易管理等突出性的问题。为了解决原软件开发平台的不足之处和基于该银行长远发展目标的要求，我们引入新的软件开发平台 SP PrePbranch。在文中阐述了选择软件开发平台的原则:要求开放性好，可复用性高、开发出的软件易于管理、风险可控、技术能与发展主流趋势相一致并易于掌握，并总结了应用新软件开发平台开发银行中间业务系统所带来的优势

正文

银行的中间业务系统是指银行依托自身的电子化平台、网点网络和人员等资源，通过与企事业单位、机关团体的合作,为客户提供代收代付、资金转帐结尊、业务代理和咨询、增值理财等金融服务的平台。X 省农业银行的中间业务系统主要包括由五大类业务组成，即批量业务，如代发工资、国库统发工资、批量代收代付，单笔缴费业务，如柜台代收学费、行政管理费等，通信类业务，主要是指要与外单位进行实时通信的业务，如固定电话缴费系统，手机缴费系统等，增值服务业务，如代客理财、银证资金转帐和结算，其他业务，如业务咨询和代理等。

该行原中间业务系统是 c/s 结构，采用 DB-Lbrary/c 编程，使用的数据库是 Sybase;以UNIX作为操作系统该开发平台在开发中间业务系统是工作效率比较低，开发周期比较长复用性差。针对上述开发平台的实际情况和存在的主要问题我们引入新的国内某公司的基于中间件技术的软件开发平台“oSP PrePbranch”用于重新开发该银行的中间业务系统。在整个项目期间我参与了软件开发平台的选型，系统的分析，开发和设计，测试的工作。

在选择 OsP PrePtranch 平台时，我们主要遵循了以下原则:利用选择的平台开发出的新系统能和基础业务系统有机集成的原则，选择的开发平台易于掌握的原则，选择的开发平台开放性好、贫用率高的原则，选择的平台易于管理的原则。

应用新软件开发平台开发出来的系统要能够和基础业务系统有机集成是引入软件开发平台的基本条件，它也是选择软件开发平台的原则之一。OSP PrePtranch 软件开发平台是一个独立的开发平台，使用该软件开发平台开发的中间业务系统能方便通过基础系统的接口直接调用，不需要另外开发接口调用中间业务系统，而且OSP PrePtranch 厂商进行了现场演示和提供了正式的书面文档。这样，通过简单的调用能实现基础业务系统和中间业务系统的有机集成。

选择的开发平台要遵循易掌握性原则。引入一项过于复杂或难以掌握的软件开发平台是毫无意义的。基于中间件技术的 0SP PrePbranch 软件开发平台采用的操作系统是 uniz，使用C/C++和嵌入式的 T-SQL语言为开发工具。C/C++、SQL它们都是该银行软件工程师比较熟悉的编程语言，因此该软件开发平台易于掌握。使得该银行选用该软件开发平台在较短的时间就能掌握它，应用它。

选择的开发平台要遵循开放性好、复用率高的原则。OSP PrePtranch 系统提供的每个原子交易都定义了规范的接口说明，调用时入参、出参的类型、个数、顺序方面都有明确的定义，使用的场合范围，如文件的上传/下传服务就有详细的定义，上传文件名，传输方式，存放的目录等方面都有详细的说明。在开发时只要根据实际情况和应用说明文档就可以实现述明调用了。0SP PrePbranch 软件开发平台在应用层提供了网关 (GateWay)服务，使得中间业务系统与协作单位的通信不需要银行开发人员自己开发，而由OSP PrePranch 直接提供;0SP PrePbranch还提供了通信的包格式的定义，通信连接方式的定义，通信格式加包头，通行打包，通信格式去包头，通信格式解包等原子交易。

除了上述OSP PrePbranch 系统本身具有良好的开放性，提供大量可复用的原子交易外在此次开发新系统时根据银行中间业务系统的特点还自制作了大量可复用的原子交易，如帐户的入帐、帐户明细的查询、帐户性质的判断、卡折之间的转帐、各人帐户和对公帐户之间的转帐等，把这些模块加载到OSP PrePbranch 系统的构件库中，与0SP PrePbranch本身的原子交易一起提供服务。对自制的原子交易也提供了规范的接口说明，参数调用说明，应用场合等规范性文档。它们和 OSP PrePtranch 软件开发平台本身直接提供的原子交易对于所有的程序员是透明的，程序员使用时只要查阅规范文档就可以直接使用，而根本不需要了解它们的具体实现的细节。有了这的开发平台，在开发新系统时只要根据不同的业务品种编写必需银行核心功能模块，然后从oSP PrePbranch 构件库中选择所需的原子交易就可以快速开发出金融交易。这样提高了软件的复用率，该变了过去重复开和重复测试的大量工作，极大地缩短了开发地周期，大大加快了研制进程，因此，无论 SP PrePtranch 软件开发平台本身还是后继的开发都保持了良好的开发性，较高的复用率。选择的开发平台要遵循易于管理的原则。该银行中间业务系统改造之前客户端前台软件升级时，采用手工作业方式，工作量大，不便于管理。新系统中把各网点终端信息收集在一起，保存中间业务系统应用数据库中，若软件需升级更新时，把升级软件放在中间业务平台的指定目录下，每天网点开启中间业务系统时，前台软件自动执行版本更新升级程序，保证网点及时、自动地从后台取回最新版本软件并投入生长运行。因此，新系统极大地减少了软件升级所带来地工作量，使得中心机房可对各网点运行的软件进行统一升级、版本控制、集中管理、方便管理，

由于选用的软件开发平台 OSP PrePtbranch 是基于中间件技术的，它由前台开发子系统主控守护进程 ubridge，后台开发子系统和数据库连接与管理子系统组成的。中间件技术是当前信息技术发展的一种主流技术，因此OSP PrePtranch 软件开发平台在相当长的一段时期内保持技术领先的优势。

OSP PrePtranch 软件开发平台具有良好的开放性，复用性高，它所采用的是先进的中间件技术。特别是OSP PrePtranch 系统的开放性好，可复用性高方面在应用该软件开发平台开发中间业务系统时，可以方便的使用 SP PrePtranch 提供的开放的接口，大量现成的原子交易，在具体开发时只要根据业务需要编写必须的核心代码就可以快速开发出金融交易，缩断了软件开发的周期，提高了工作的效率，提高了软件的复用性，加快了研制开发的进程。使得该银行能在较短的时间内开发出新的金融产品，提高了银行的市场竞争力。

任何一种软件开发平台的选用都具有一定的风险，特别是在金融业中引入新的软件开发平台要谨慎从事。首先，它是一个基于中间件技术的成熟的产品，在此之前已经在国内金融业有多个成功应用的先例，其次，该软件开发平台大部分是采用 C/C++语言开发的，它易于掌握，因此就不存在选用一个不易掌握或不能掌握的平台;再次，该软件开发平台实施成本低。因此我们从软件开发平台的成熟性，易掌握性，实施成本等多方面进行了论证和考察，它所带来的风险是在可以控制的范围之内的。当然，我们在选择OSP PrePbranch 软件开发平台主要是基于该银行的实际情况的需要。在不同的应用领域有不同的选择，如企业应用集成可以选择 EJB 规范的 J2EE 平台，它具有开放性，平台应用的无关性等特点。但是无论那种软件开发平台，它们都应该朝着开放性、平台无关性、可移植性、能够实现异构集成等方向发展和演变，同时它们应该代表着先进的技术发展方向。

论基于构件的软件开发

摘要

本文以我主持的某商业银行交易监控分析系统项目为实例，探讨了作为开发方公司基于构件技术开发项目碰到的问题以及解决的方法。文章首先解释了基于构件技术开发软件的基本概念，认为目前大多数开发单位的产品在存在重复的功能模块，而重复的开发工作，直接导致了项目周期以及成本不必要的增加，针对这一问题，提出了应该及时整理已有的系统，形成企业构件库，针对性的选择构件，从而基于构件开发新的软件项目，在保证软件产品质量的前提下，缩短项目周期和开发成本，最终使企业盈利

我在项目中担任了开发方的项目经理，自始至终参与了整个项目的建设，自 2008年3月项目启动至 2008年10 月验收历时8个月，系统至今运行稳定，取得了客户的一致好评,项目能够保证质量的前提下迅速完成，最终节约了成本，很大程度上得益于基于构件开发软件的应用。

正文

目前，银行间竞争已日趋激烈，降低银行的服务成本，提高对客户的服务质量，已成为银行竞争的关键。随着服务种类的增多、日交易量的增大，针对这些交易数据进行有效的管理变得迫在眉睫。首先，需要将各种交易实时监控，保证能够对异常交易进行及时处理，提高客户满意度。其次，需要对对这些交易数据进行统计分析支持高层管理人员的决策，提高银行的竞争力。基于上述需求，2008 年初，某市商业银行招标建设一个交易监控分析系统，我所在的单位中标后，我有幸参加了该项目的建设，承担了开发方的项目经理

职。交易监控分析系统主要包含 4 个子系统，基于 B/S 结构的管理平台，处理多种不同报文格式交易信息的数据转换平台，基于 B/S 结构的联机分析处理平台，数据维护子系统众所周知，基于构件的软件开发是一种自底向上的、基于包装好的构件来构造应用系统的方法。它主要包含构件的检索与提取，理解与评价构件，修改构件，组装构件，应用部署等工作。

目前软件行业间的竞争程度趋于白热化。建设方更倾向于选择已经有成功案例或者有类似项目成功案例的开发方。我认为，对于开发方来说，大多数开发单位的产品在存在重复的功能模块，而重复的开发工作，直接导致了项目周期以及成本不必要的增加，如何利用已有的软件项目构造新的系统，而不仅仅是将其作为投标的筹码变得越来越重要。针对这一问题，我在采用及时整理已有的系统，形成企业构件库，针对性的选择合适的构件，加大对已修改构件的管理力度等方法，有效的实施了基于构件的软件开发工作。

形成构件库是基于构件开发软件的前提。我们在已经成功实施的项目中，抽取一些共有的模块作为单独的组件，封装其内部操作，对外提供一致的调用接口。我们分析发现，一些常用的模块例如登录模块，只需要很少的改动就可以复用到新的系统中，对于一些看似不同的模块，例如查询银联交易流水，查询 POS 交易流水，查询设备状态信息等，如果从对数据库操作的方式去分类的话，都离不开增、删、改、查四个操作，因此，我们对表示层，业务层，数据层进行了面向接口的整理工作，封装成一个组件，使用 Hibermate 技术管理数据库操作，对于表示层需要列表显示的对象，通过参数的方式传递到业务层。在本项目中，我们的工作就集中在了 Model 层对象设计上，建立Mode 层对象与数据库的映射关系之后，直接使用构件组合待查询的交易信息，极大的减少了系统的重复性开发工作针对性的选择构件是基于构件开发软件的关键。构件的选择有多种途径，一是从构件库中提取符合要求的构件，二是从市场上购买现成的构件，三是根据特殊应用需求开发在本次项目中，我们选择的构件来自于第三方和企业构件库。

考虑到银行的前置机，核心主机都是 Un 操作系统，而部分外围服务运行与 Windows或 Linu 平台，所以我们采用了与系统无关的 J2EE 平台构架

关于系统与后台主机的通讯，DCOM和 CORBA 都是适合于服务器一服务器间通信的成熟规范，由于选定了开发平台，我们选择使安装 Java 自带的 ORB 进行通信。后台主机将处理的交易信息使用 UDP 协议发送到监控系统，从而实现了交易数据的获取。获取的报文需要经过转化为监控平台统一格式才可以使用，因此，我们需要数据转换服务，如果选择第三方的构件，面临的问题是无法对其进行源码级的修改，所以我们选择自主开发新的构件用于数据转换服务，平台处理 XML格式的数据，数据转换服务实现 XL 报文与银行后台报文的转换。

几乎所有的信息管理系统都包含了登录模块，这一块我们直接从构件库中提取，业务层，数据层都不需要修改，只需要更换表示层中的界面图片即可，系统使用验证客户端 IP的方式，限制可访问系统的客户端，避免非法连接。用户权限使用角色，用户组等方式进行管理，便于权限分配。这些组件都是我们经过长期使用并且不断完善的模块，可直接从

构件库中提取。加大对已修改构件的管理力度是为今后的构件开发软件项目做好准备。在每个项目中，我们都或多或少的生成一些新的功能模块。在本次项目中，对数据维护子系统，就是新开发的一个组件，它负责定期进行对应用系统中的数据进行抽取，清洗工作，并将操作结果存储到数据仓库中，用于支持决策分析，其接口使用 XL定义对于这样的新开发的构件，经过测试之后，我们将其按照企业目前的标准进行严格定义，形成相关的文档，一起录入到企业构件库中，以便复用于后续的项目。对于一些修改过的构件，如数据转换模块，我们对它也进行了详细的描述，指定版本号以及各个版本之间的差异，便于以后针对不同的情况使用不同版本的构件。

在项目中，我们也发现了一些不足之处，例如要使已经完成的构件能有效的支持项目开发，对构件的管理与维护，员工对构件的理解程度都是不容忽视的问题。通过本项目的实施，我们了解到了仅仅是对企业软件构件进行严格定义并且有效的管理还不能保证员工对其理解程度一致，在项目开发过程中，开发人员通常从构件库中检索获取构件，而随着构件的增加，不同的构件也可能存在部分的功能几余，要在合适的系统上使用合适的构件就对开发人员提出了较高的要求。针对这一问题，我们除了采用培训员工的办法，还定期以知识竞答的方式组织员工进行知识竞猪，创造一种积极的氛围，促使员工对企业构件库有较高程度的理解。

综上所述，经过整个项目组精心准备和严密实施，项目如期完成，自 2008 年3月项目启动至 2008年10 月验收历时8个月，系统至今运行稳定，得到了用户的一致好评。回顾项目的实施过程，我体会最深的是，随着基于构件技术开发软件的成功实施，我们在享受它带来的便利的同时，也要注重企业内部的构件积累，从通用性的角度来看，企业新开发的构件不如经过市场验证的第三方的成熟构件，从行业的角度来看，企业开发的构件能够满足其业务领域的大部分开发工作，这正是第三方构件无法做到的。感觉自己在结合第三方构件与企业内部构件进行软件开发的能力还有待加强，我将在后续的项目中努力做好这些工作

论软件开发平台的选择和应用

摘要

本文从一个行业 MIS 系统的开发实践，讨论了软件开发平台的选择和应用。首先，作者从项目的实际情况确定了软件开发平台的一些原则，技术成熟兼一定先进性、高效集成的开发工具、开方人员熟练掌握等，随后就系统平台、软件开发平台、数据库平台的选择作了详细论述。之后，作者就开发过程中就保持系统开放性，对数据导入导出、与 P3 软件集成、WEB查看权限采取了相关措施，就保持系统先时性，提到了多种软件技术合成及 技术两项措施。最后，作者对近期商业应用软件开发平台的主流--微软的.net 及 J2ee 进行了介绍，比较了其优缺点，对今后本部门在软件开发平台的发展方向作了一定的评估。

我公司是大型电源建设项目的专业建设公司，曾以总承包方式承建设了多个电厂，在工程建设过程中逐步建立了一系列完整、科学的工程管理体系，与此相应的是逐步建立电力建设项目工程管理信息系统(简称电建 MIS)，原版本的不足之处是应用模块不多，且多以简单文本为主，

正文

2002 年，浙江省某规模为4 台 60 万千瓦机组的发电厂二期工程建设上马该工程作为个大型能源投资项目，将有力地拉动地方经济的增长，并且将为浙江和华东地区的经济和社会发展提供强大的能源支持和保障，工程由多方共同出资建设，由我公司承担工程总承包建设任务。借此工程建设的契机，我公司决定重新开发电建 MS 3 版主要模块拟包括办公自动化、施工总平管理、合同管理、物资管理、质量管理、安全管理、图档管理、公用信息管理、综合查询(包括 E 查)、系统维护，基本涉及我项目部的各个职部门

软件采用二层c/s 与三层B/w/s 相结合的方式其中B/w/s方式用于查询和测览，c/s方式用于主要数据录入和维护，采用 c/S 和 B/S 结合的合体系结构，较好地满足系统功能的需求，并符合可持续发展的原则，使系统有较好的开放性和易扩展性。

软件采用我公司和外部软件公司合作开发的形式，版权由我公司独家所有。因多种原因，与我们合作开发的软件公司有 2 个，我是软件开发的负责人。

在开发平台的选择上，我们考虑了本 MIS 项目的特点:该项目要求在规定的时间(6个月)内完成，并要求有较高的质量，且要为以后的进一步开发提供基础。某于此，我们对选择开发平台的原则达成共识

一、技术上成熟且具有一定的先进性;

二、有高效、集成的开发工具

三、应为开发人员熟练掌握。

四、软件平台提供商对该软件平台的后续支持能力。

首先，在系统平台的选择上，有两点考虑:1、公司现有的各级软件系统都是基于微软windows 系列平台的，且公司没有在日后使用其它平台的打算，2、微软的windows 平台完全能满足开发、运行该类 Windows 系统的要求。因此确定新开发的 MIS 系统也就是基于此平台的对二层C/s 在开发平台的选择，考虑采用微软的 VB60或 Syase的 Powerbuilder8.0前者是公司前两版 IIS 系统的开发平台，后者则更为现有的开发人员所熟悉。两者在开发上技术都很成熟。在开发界面的亲和性上， 做得较好，而对从数据库设计到编程的全过程而言，Powerbuilder 具有更好的集成性，用其集成工具Powerdesign设计的逻辑数据库可以很方便地生成物理数据库。从当时情况看，无论是微软，还是 Sybase，对各自软件平台的后续支持能力都较好。最后综合各种情况，选择了 Powerbuilder，其最重要的一点是开发人员的熟悉程度。

首先，在系统平台的选择上，有两点考虑:1、公司现有的各级软件系统都是基于微软wWindows 系列平台的，且公司没有在日后使用其它平台的打算，2、微软的 windovs 平台完全能满足开发、运行该类 MS 系统的要求。因此确定新开发的 IS 系统也就是基于此平台的对二层C/S 在开发平台的选择，考虑采用微软的 VB6.0或 Syase 的 Powerbuilder8.0前者是公司前两版 IS 系统的开发平台，后者则更为现有的开发人员所熟悉。两者在开发上技术都很成熟。在开发界面的亲和性上，y 做得较好，而对从数据库设计到编程的全过程而言，Powerbuilder具有更好的集成性，用其集成工具Powerdesi设计的逻辑数据库可以很方便地生成物理数据库。从当时情况看，无论是微软，还是 Sybase，对各自软件平台的后续支持能力都较好。最后综合各种情况，选择了 Powerbuider，其最重要的一点是开发人员的熟悉程度。

对三层C/s 在开发平台的选择，考虑采用的比较方案是微软的 IIS+ASP 组合及 pache+PP 组合开发人员的经验还是在 IIS+ASP 上，对于Aache十PHP 少有实践，基于此，选用第一种方案。

在数据库平台的选择上，有微软的 SQL Server 和甲骨文的 racle 可以选择。前者是前两版MIS的数据平台而oracle数据库是目前公认的最优秀的大型数据库,和微软的 SQL SERVER相比，它具有更好的稳定性和安全性----这通常是企业用户最关心的两个特性。开发人员对两种数据库都有相应的开发经验。最终选用了 oracle 数据库平台在开发中考虑了系统的开放性和先进性。在开放性方面，有以下措施。1.针对原有大量已积累数据(大多是 EXCEL 格式的)的导入，及系统中数据可能的导出设计了专门的导入导出模块。使得操作人员一方面从繁重的初始数据录入工作中解脱出来，一方面随时可以导出系统中的数据作个别分析。并预留了与公司总部及其它协作单位进行数据交换的接口。

2.IIS 系统与 P3 软件(大型项目管理软件)要求做到集成。为此设计了专门的模块，通过ODBC 方式进行后台的数据交换，使得两套软件做到无缝集成，在 P3 软件中操作的结果可以在MS软件中反应出来而在MS软件中相应模块中输入的数据也能在 P3软件中反应出来这样做的好处是大多数工程师无须操作 P3 软件即可输入有关工程进度的数据，并通过 P3软件的功能自动计尊出相应的数据并得到横道图，而少数工程师仍可在 P3 环境工作，而工作结果同样反应在 MIS 中

3.B/s 部分的使用对象不仅仅局限于项目部的员工，还包括公司本部人员及众多协作单位的人员。而由此相关的权限及安全问题必须考虑，即不同身分的人员能查看的权限是不一样的。ASP 在此方面的功能相对较弱，为此在 B/s 的服务端专门设计了基于 COM 技术的身份认证&ActiveX组件。

在先进性方面，有以下措施。

1.采用了多种软件技术的合成，如在 IS 系统中合成了工作流技术，在工作流技术中调用了微软OFFICE 的宏技术作流技术上考虑与系统更好地集成，采取了基于数据库的方案,自行开发了相关的模块。其最终效果是在 IS 中实现了办公自动化的功能，极大地方便了使用者。

2.采用了先过的 VPN技术，使得部分外出员工可以通过 Internet，借助 PN访问内部的MIS 系统，从而完成远程办公系统运行后收到了良好的效果，用户对该软件的满易度较前两版有较大的提高。该系统随后应用于多个电厂建设项目的管理中

近期商业应用软件开发平台的主流越来越集中在微软的net 及 J2ee，其共同特性是更多地支持面向 Internet 的开发net 的优势是支持多种开发语言，开发人员容易掌握，产品集成好，总体成本较低，不仅在开发的时候容易介入，在日后维护时也更能掌握主动权，其缺点是事实上只支持 Windows

平台J2ee 的优点是跨平台，可以选择多家公司的相关产品，但开发相对复杂，且只支持 JAVA语言Powerbuilder 虽然有最新的面向分布式及三层B/s结构的新版本推出，但终不及前两者。对于象我们在非软件企业的 IT 部门，在开发新的软件系统时，如采取自行开发或与其它软件公司合作开发的方式，，.net 应该是比较好的选择

论软件的可维护性设计

摘要

2008年3月1日至12月20日，我参加了“数据安全访间平台”项目的开发，担任系统分析员的工作。该项目是某行业用户“数据中心二期”建设的主要内容，目标是:建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。

由于系统交付后，存在较长维护期，同时系统存在升级与扩展的情况，因此本项目对系统的可维护性设计要求较高。本文结合作者实践，讨论了从软件设计上提高可维护性的方法和措施:通过模块化设计方法和提高设计文档质量，改善软件的可理解性，通过提供测试接口和采用测试框架工具，改善软件的可测试性，通过动态库加载和针对接口编程的方法，提高软件的可扩展性，最后分析了采用方法的效果

正文

一、项目概述

2008年3月1日至2008年12月20日我参加了“数据安全访问平台”项目的开发担任系统分析员的工作。“数据安全访问平台”是某行业用户“数据中心二期”建设的主要内容。在一期建设中已建成数据的统一存储和统一分发框架。但主要存在以下问题:无法获得应用用户对数据库的操作日志，开发人员对数据库的使用不规范，查询的结果集过大，导致数据库的性能大幅下降，应用直接使用数据库的登录数据库，存在着一定的安全隐患。“数据安全访问平台”的目标是:建立数据统一访接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段

该项目具有较高的业务需求风险和技术风险。由于没有成熟系统做为参照，该项目需求不是很明确，而且系统涉及甲方多个利益相关方，各方对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，某些观点之间还存在冲突。同时系统作为“数据中心”的基础设施之一，所有的应用系统都要通过本系统完成数据库访问，系统的可靠性和性能直接影响到应用系统的正常运行。整个系统分为 6个子系统，包括 JDBC驱动封装子系统、ADo.Net驱动封装子系统、WebService 接口子系统、管理配置网站、存储子系统(SQL Server2005数据库，存储配置信息)和监控子系统(据库网络协议分析与连接控制)

二、项目中的可维护性设计工作

1、系统可维护性

本系统有较高的可维护性需求。首先，系统作为数据中心应用的基础平台，数据中心的新建应用系统必须依赖于本系统，系统具有较长生命周期，同时合同中规定系统正式上线后，公司需要提供  年的免费维护。其次，本项目中的接口子系统是基于 JDBC50 和ADo.Net2.0 实现的，随看 JDDC 与 ADOet 的升级，接口子系统也需要升级。然后，监拉子系统对0racle和SQL Server 数据库的络包进行解析，由于商用数据库网络包格式不公开，我们在解析时会有遗漏，用户要求，当发现未能解析的数据包时，需要及时添加到监控子系统中。最后，由于没有成熟系统做为参照，该项目开始时需求不是很明确，在开发过程中用户提出了一些新需求，由于工期的限制，经过与用户协商，这些新需求不在本项目中完成，用户准备视系统的运行情况，设立新的项目完成这些剩余需求。因此可维护性是本系统的一个重要质量指标。

为了增加系统的可维护性，减少维护人员理解和修改系统的难度，我们在本系统的设计上，不仅仅关注系统的功能需求实现，而且重视系统的可维护性需求。决定软件可维护性的因素主要包括，软件的可理解性、可测试性和可修改性。在整个系统设计过程中，我们都注重改善系统的可理解性、可测试性和可修改

2、改善软件的可理解性本系统涉及的问题域有一定的复杂性，如果将整个问题域的复杂性完全暴露给维护人员，维护人员很难理解整个系统。因此，首先，我们将整个系统划分为功能独立的六个子系统，其次，在各个子系统设计时，我们都采用了模块化的方法，即将内聚性高的业务逻辑合并封装成独立的模块，最后，重视设计文档质量，对设计文档做了内部审核，确保文档清晰准确了描述了设计。

3、改善软件的可测试性

维护人员对代码进行修改后，必须进行测试，才能保证软件的质量，并且，用户对系统的可靠性要求很高。因此，在软件设计的整个过程中，我们都考虑了测试的问题。首先，各个子系统的内部模块必须是单向依赖，对出现循环依赖的模块，我们采用调整功能分布，抽取公共模块等方面消除循环依赖。其次，对于接口子系统，我们需要对某些模块内部进行深入的测试，而由于模块接口的封装性，无法直接访问内部数据，对于这样的情况，我们在设计这样的模块时，专门提供了测试接口，最后，开发中采用了 CppUnit、NUnit 和JUnit 测试框架，通过测试框架来组织测试驱动程序

4、软件的可扩展性

监控子系统采用网络监听的方式获取数据库访问的信息，这种方案的优点是不给业务系统增加性能负担，缺点是由于商用数据库协议不公开的，虽然我们经过大量的测试，但是肯定是有遗漏的

为了当发现未能解析的数据包时，及时添加到监控子系统，同时不重新编译系统，我们进行了可扩展性设计。我们采用了动态库加载和针对接口编程的方法，监控子系统启动后，会加载指定目录下的动态库《符合名字规范)，这些动态库都实现了规定的接口。子系统当收到一个网络包后，会依次询间所有的动态库是否能解析该网络包，这样只需要将新开发的动态库拷贝到制定目录，并重启动监控子系统就可以完成系统的升级。

三、总结在系统的维护阶段，发现了较严重缺陷 2个与8 个一般缺陷，同时，发现了监控子系统不能解析的 5 种协议包，维护阶段的开发人员与开发阶段有了较大变化由于在系统设计上重视可维护性，软件进行模块化设计，提供了完备的设计文档，维护人员可以较快的定位与解决问题，由于考虑了系统的可测试性，提供了回归测试集，维护人员可以运行回归测试验证软件质量，由于考虑监控子系统的扩展性，维护人员可以及时增加了新的协议包解析功能。综上所述，由于在设计中考虑了软件的可理解性、可测试性与可扩展性，很大程度上提高了系统的可维护性

论异构数据库的集成

摘要

本文讨论了*数据集市项目的数据集成方法与过程。该系统在 2008 年12 月启动，在2009年5月正式上线使用该系统是以oracle 系统为主要的数据库，同时集成 DB2系统中的数据。每天的话费清单系在 DB2 数据库中存储，通过EL调度程序把 DB2中的数据进行汇总并把结果写入到 ORACLE 数据仓库中。本文首先讨论了建立数据集市项目异构数据库的两个数据库系统的背景以及用户对该项目的需求。接讨论了使用 Per1 技术来集成两个数据库中的业务逻辑的过程，并说明了该技术在集成过程中出现的问题，如:数据分层，ETL 调度程序改造，以及参数化 SQL 处理等问题，最后讨论了该集成方法的优点和缺点，并对改进该项目提出了优化 Per1 技术的设想。在本次的项目开发过程中，我主要担任了系统分析与设计的工作。

正文

**数据集市项目是在 2008 年 12 月启动的，我所在的部门旨了该项目的开发过程我有幸在该项目中担任了系统分析与设计的工作。该项目的实施是基于以下的背景的。在2005年 12 月，我们部门已经组织了开发料经营分析系统，该系统已经建立了数据仓库系统，把 BOSS，财务数据，DSMP，IIS 等项目的业务操作数据作为数据源，通过清洗，转换,装载等方式把所有的清单一级的数据全部集中到该系统中了，该经营分析系统是基于 DB2的数据库开发而成的，把数据仓库分为了 STAGE 层，ODS 层，EDS 层，REF 层STAGE 层是数据清单的原始数据，ODS 层是经过日汇总的数据，EDS 层是经过维度统一化后的数据，REF 层是维度数据层。每一层数据之间的业务逻辑是通过 ETL 调度程序实现，该程序主要调用的是数据库中的存储过程或者 She11 脚本完成每层中的数据汇总的过程对于数据集市项目，我们比较有优势的就是该项目是基于上面的系统进行扩展而成，使用经营分析系统的经验和技术，我们可以快速开发完成。但是该项目由于企业的需求以及供应厂商等间题，最后企业选用了 ORACLE 数据库作为该项目的建立主要数据库，在该项目中必须把所

有的 EDS 层的汇总数据记录在以 ORACLE 的主的数据库中以供企业的每个地市使用在上面的背景与需求下，对于采用两种数据库系统集成的问题是我们完成该项目的主要障碍。为了完成该项目的开发，我们对原有的系统和新开发系统的做了一些技术和方法的调整。这些方面主要有如下方面:

重新规划数据层次。通过我们对用户需求的分析，对数据分布的理解，觉得了在集成异构数据库层的时候，我们采用尽量保护数据的原则。我们按照之前的数据分层方法，在 ORACLE 的数据仓库中，重新增加了两个层次的数据，分别是 DM层和 REF 层，其中 DII层的数据是 EDS 层数据的较大的粒度汇总过程，主要的来源数据是 DB2 的 EDS 层通过话度业务逻辑程序，实现如下的数据汇总过程，STAGE 层记录数据库洁单的原始数据，没有经过任何的转换和变化，而 ODS 层主要是针对时间和地市维度进行的第一级汇总的数据该数据基本上是以天为单位的历史数据。EDS 层是对其他维护进行统一化后的汇总数据该数据主要是对 ODS 数据进行转换和汇总的过程结果。Dl 层则是在 DS 层的数据上，通企业需要的业务逻辑，如每月统计数据，平均值，指标考核值，预测值等业务逻辑，把 DDS层的数据汇总到 Dm层的数据中，并且通过特定的数据库权限和视图的方法，把各个地市需要查询的数据汇总到该层的数据库表中。通过这样的数据划分后，我们就等到的很好的数据分层结构，为下面进行异构数据库业务逻辑集成奠定了重要的基础。

二、ET 调度程序的异构数据库处理，在规划了数据分层后，我们遇到的另外一个难题是 ETL 调度程序如何在这两个数据库中调度处理的过程，按照我们原先的设想是通过She11程序来调度两个数据库中不同的存储过程，完成汇总数据的过程。但是这样的方法显然会出现异构数据库中很多的调度问题，而且会出现在调度程序中出现 She11 再调用She11 等问题，使得业务逻辑混乱而无法以后的维护结果。为了缓解这样的问题，我们大胆的采用了 Per1 技术作为业务逻辑层的脚本处理平台。通过该平台，我们只要处理不同数据库的 SQL 就可以了，对于连接数据库以及调度的脚本的开发，调试，测试等提供了重要的保障，另外 Per1 程序另外一个特点就是可以面向对象，这样只要我们开发一些公共的模块，通过对象的形式，就很容易把业务逻辑的 SQL 入到 Per1 程序中，从而解决异构数据库集成的问题。

三、异构 SQL 的函数处理。在搞好可以统一调度的问题后，数据仓库基本上能够通过调度程序跑出对应的数据了，但是我们开发人员在开发的过程中非常的头疼，因为他们比较熟悉的 DB2函数，在ORACLE 中要寻找其他的替换方法，并月某些业务逻辑还要书写两套的 SQL 语句来处理业务逻辑。这样的妨碍了我们快速开发的目的。为了解决该问题，我们设计了一套通过的 Per1函数库，该函库式以 SQL-92 标注为基础，通过DB2 中我们经常使用的函数集合的汇总过程，我们通过参数的输入设计方法，把按照我们标准编写的 SQL语句转换成数据库中真正执行的 SQL 语句，通过正则表达式以及 SQL 字符特定分解的程，转换成特定数据库的 SQL，并通过 Perl函数执行该业务逻辑。这样，我们完成了异构数据库集成的中的 SQL 异构的处理

通过以上的三个种处理过程，我们最终解决了数据集市项目中的异构数据库问题，并且在 2009 年5月份完成了该项目的验收，把真正的数据通过经营分析系统的 ETL 调度程序下发到各个地市中，获得了用户的一致好评。同时由于该系统集成的时候充分考虑了开发人员的使用 SQL 习惯，所以开发的效率比较高，比使用存储过程的开发过程减少了三分之一的开发时间。但是该系统还是存在很多的问题，首先是异构 SQL 的函数还不是很多，并且对于一些特殊的函数，由于需要考虑到两个数据库转换等问题，曾经出现果效率的瓶颈问题，后来经过多方的考虑，把某些功能定义为只能有一个数据库使用的方法来解决。另外，在 Per1执行的业务逻辑中，我们还是比较陌生，虽然开发处理了很多的通用模块但是没有定义比较好的接口，如果以后需要改进的时候，可能会出现大面积的修改工作量我们建议在 Per1开发平台上，应该多做一些规划，如果能够把 Per1模块做成数据库连接构件，SQL 执行构件，函数转换构件等等构件化的形成后，并且定义良好的接口形式，这样会使数据集市项目在集成异构数据库上更加的好，同时可以集中解决一些性能的问题，以优化系统的运行效率

论基于UML的需求分析

摘要

2008年3月1日至12月20日，我参加了“数据安全访间平台”项目的开发，担任系统分析员的工作。该项目是某行业用户“数据中心二期”建设的主要内容，目标是:建立数据统一访间接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。由于该系统是所有应用的基础平台，对系统的可靠性与性能有较高要求，同时由于没有成熟的现有系统作为参照，该项目存在较高的风险。本文结合作者实践，讨论了在项目中其于M的需求分析。我们使用用例图描述用户与系统的交互，使用类图描述系统的核心概念:使用部署图描述系统的网络部署，使用活动图描述系统的应用流程。由于采用了 UML中的多种技术，使得我们能从多个方面完整的把据需求，有效的保证到了需求工作的质量。最后，分析了需求工作中存在的问题和改进的方法

正文

一、项目概述

2008年3月1日至2008年12月20日我参加了“数据安全访问平台”项目的开发担任系统分析员的工作。“数据安全访问平台”是某行业用户“数据中心二期”建设的主要内容。在一期建设中已建成数据的统一存储和统一分发框架。但主要存在以下问题，无法获得应用用户对数据库的操作日志，开发人员对数据库的使用不规范，查询的结果集过大，导致数据库的性能大幅下降，应用直接使用数据库的登录数据库，存在着一定的安全隐患。“数据安全访问平台”的目标是，建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段该项目具有较高的业务需求风险和技术风险，由于没有成熟系统做为参照，该项目需求不是很明确，而且系统涉及甲方多个利益相关方，各方对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，某些观点之间还存在冲突。同时系统作为“数据中心”的基础设施之一，所有的应用系统都要通过本系统完成数据库访问。系统的可靠性和性能直接影响到应用系统的正常运行。整个系统分为 6 个子系统，包括JDBC 驱动封装子系统、ADOet驱动封装子系统、WebService 接口子系统、管理配置网站、存储子系统(SQL Server2005据库，存储配置信息)和监控子系统(数据库网络协议分析与连接控制)

二、UML在需求工作中的应用

项目组采用一个精简 RUP 开发模型指导项目的整个开发流程。在初始阶段主要采用用户访谈、用户调查和联合讨论会捕获用户需求，进行初步分析，完成《需求规格说明书》初稿，通过用户评审，在细化阶段，对需求进行了细化，并在采用原型法验证用户需求，完成《需求规则说明书》更新稿，通过用户评审，作为项目验收的依据。项目开发中，我们采用了统一建模语言 (UML)，并使用了 Rational Rose 具在需求工作中，我们主要使用了  中的用例图、类图、活动图和部署图。

1、用例技术的应用

整个需求开发都是围绕着用例技术开展的。首先，我们明确了系统的利益《查书)相关方、确定了系统边界和建设目标，以及主要功能特性。由于系统涉及甲方多个利益相关方，包括:应用科、维护科、网络科、信息中心领导和应用开发方，他们对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，同时本系统与已建成的网管系统和单点登录系统存在着交互关系，这给确定系统的目标和边界带来一定的难度。项目初始阶段开始，我们先通过用户访谈、用户调查了解了各个用户对系统的观点;随后，我们召开了联合讨论会，会上我们描述了各个用户的观点，以及之间可能的冲突，供各方进行充分的讨论，会议最后，信息中心的领导统一了各方的意见，对系统达成一致的目标，并明确了系统主要的功能特性，确定本系统了与网关系统和单点登录系统的关系。

其次，我们建立用例模型，并细化关键用例。明确了系统的目标和主要功能特性后，我们采用用例模型对需求进行分析。整个系统包括六个用例包:访问接口包用例包、审计信息管理用例包、用户认证信息管理用例包、数据库连接资源管理用例包、访问控制信息营理用例包、数据库连接监控管理用例包和审计日志管理用例包，共包含 55 个用例。对大部分用例我们只描述了一个基本正确流程，只对 5个关键高风险用例进行了细化描述包括:前置条件、后置条件、甚本流、扩展流和相关约束。这项工作完成后，我们编写了《需求规格说明书》初稿，提交用户进行了审核。经过修改后，通过用户评审，作为初始化阶段的主要成果

最后，细化用例模型，在细化阶段，我们细化描述了所有的用例，完成《需求规则说明书》更新稿，通过用户评审后，作为项目验收的依据。

2、类图的应用

用例技术描述了系统需求的动态结构，但对于需求特性和用例中出现的概念，并没有统一的分析。我们使用类图描述系统的核心概念。本项目中涉及的核心概念主要包括，逻辑连接、用户、应用、受限角色、认证 SQL 语、参数取值范围的约束和查询结果集的限制。在分析核心概念时，我们主要关注:概念之间的关联关系，是否具有相同的生命周期，和具体的对应关系(一对多、多对多和多对一)

3、部署图与活动图的应用

由于整个系统包含多个子系统，各个子系统部署在不同的节点，需要考虑用户的网络结构是否能支持。在需求阶段，我们也描述了整个系统的部署。其中监控子系统比较特殊，由于其是通过分析 0racle 数据库的网络数据包进行工作的，因此监控子系统必须接入核心交换机的镜像端口。我们将部署图与网络科进行了确认。我们使用活动图描述系统的应用场景。由于本系统对应用系统的开发增加了一层管理，因此应用系统的开发方与信息中心存在一个交互流程:应用开发方首先使用本系统的开发版进行本地开发，并填写基本配置数据，然后，在用户的生产环境中部署应用，并提交基本配置数据，最后，信息中心的管理员对配置数据进行修改后，应用在生产环境中才能运行。我们使用流程图描述了整个过程。用通道表示应用开发方和信息中心，并描述了各个通道内的流程以及通道之间的交互。

三、总结

由于没有成熟系统做为参照，该项目具有较高的需求风险。由于在整个开发过程中使用了 u的用例图、类图、部署图和活动图，这使得我们能从多个方面完整的把握需求，有效的保证到了需求工作的质量。

本项目的需求工作中，我们也遇到的一些问题，主要是维护 od 文档与模型的一致性。我们使用 RationalRose建模，使用Tord 与文档，通过截图的方式将模型插入文档因此需要手工维护两者的一致性。这种方式较警琐，容易出错。今后的工作中，我们准备使用Rational公司的 Soda 工具，自动将Rose 中的模型插入到 Word 文档中

论软件的性能优化设计

摘要

本文结合我 2008 年在*人民银行实施的E 户通电子转账系统的经历，就软件的性能优化设计进行了详细讨论。在系统的设计中针对实际应用环境主要从以下几方面对系统性能进行了优化设计，(1)选择当前成熟的三层 c/S 体系结构进行开发，以减轻数据库服务器的负担，(2)优化数据存取策略以降低系统运行对网络带宽的要求:(3)对客户端应用进行优化，如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。通过以上优化设计，系统满足了企业百万级以上主题数据库处理要求，系统开发获得了成功。最后对系统中存在的不足进行了简要的总结，如未考虑查询的需求等等

正文

近年来，各银行的信息化发展非常迅速，直接带动了银行中间业务的发展。银行随着多年的建设，已经在中间业务上建立了多个业务系统:如行内的通存通兑系统、定期借记系统、定期贷记系统等。由于这些系统都是由各银行的内部需求为主导建设的，只能支持单个银行系统内部的服务，难以实现银行间的服务。如以银行代收水电费为例，如工行能代收水费，农行能代收电费，老百姓如果需要同时交纳水电费，就必须同时在这两家银行开户，十分麻烦。与此同时，银行因开展业务的需要，不得不与不同的收款单位联网，如水厂，电厂等。数量一多，银行也很麻烦，安全控制越来越复杂。老百姓和银行都迫切要求进一步提升服务质量，实现银行中间业务联网，合理规划和利用银行的总体资源。为此，**人民银行领导经过研究决定于 2005年利用自身技术力量开发设计 E户通电子转账系统，作为银行间的电子转账业务支撑平台，实行 7X24 小时连续运行，满足银行间的跨行转账业务、定期借、贷记业务，并支持各商业银行在此基础上建设新的中间业务，我作头工程实施组组长，组建了12 人的开发队伍，全程参与了项目建设。项目从05年7月启动06年4月结束，历时9个月，

E 户通系统涉及到与相关银行、相关企业的联网，支持批量和两种业务处 理模式，支持定期借记(如定期代收水电费)普通借记(如支票)、定期贷记(如代发工资、普通贷记(如银行间转账)、银行柜面现金微费(如老百姓缴养路费等)、客户签约管理、网上业务授理等。除了满足以上的业务功能需求以外，还要应对如下性能方面的需求，系统的大部分业务工作都由分散全市的银行网点和联网企业受理，相应要求系统适合于分布式的应用环境并提供较好的性能，要能支持 500 个并发实时处理，必须在较小的网络带宽占用下完成日常业务处理，在使用 64KB的 DDN 与我系统连接，要求实时业务处理(128 字节笔)要求在 20 秒以内完成对于批童业务数据采取包处理制，最大 800 笔一包(约 150KB)要求对包中每笔数据进行 AC验证正确后转发至相关银行，每包处理时间不能超出45秒要求查询时，最迟必须在 15 秒内返回结果，资金清算，报表统计与生成工作等，不能昌响其它业业务的正常进行。

根据银行的业务和管理特点及上述提出的对软件性能方面的要求。在对软件的性能优化设计中我和系统分析人员进行了系统分析:因为该项目的硬件投资较为宽裕，可以购买性能较好的服务器。因此，系统分析主要集中在数据库的设计和编码问题。对于 500个并发问题，考虑到目前主要商业银行已经实现数据集中，各银行网点的交易数据是通过其管辖行发起，交易量会很多，但是银行总量不会很多，因此交易模式拟采用长连接模式，一方面是保证交易效率，一方面是保证交易可靠性，简化设计。由于是异构环境开发，最好采用成熟的应用服务器，对于实时交易时间问题，数据包的大小不是问题，关键是合理安排交易各区段的时间划分问题，考虑到受理方的处理能力，应至少保证它有 10 秒的处理时间，对于批量系统的时间要求，主要在于两个方面:一是 AC 验证的时间，二是对包内数据的区分和路由转发。其中后者是重点，需要在网络实环境下进行验证。对于查询性能要求，考虑到主要是对交易历史的查询，应适当分离当前库和历史库。鉴于以上的分析，我们在系统开发中做了以下的设计和安排:首先我们选择了目前在数据库开发方面非常成熟的 BEA 公司的 WEBLOGIC 应用服务器模式，数据库服务器采用SYBASE EAServer。这样，系统具有良好的兼容性与可扩展性的同时，也为系统的性能改善提供了可能。

其次，在系统中我们根据业务处理分散在异地的特点，采用了三层 c/s 体系结构，通过三层C/s 体系结构的设计可以将数据库的访问及业务处理逻辑移到应用服务器进行。由于系统应用特点，我们在应用服务器的设计中主要采取了长连接池和负载均衡的技术来提高系统性能。对于客户的新数据库连接我们首先去查找连接池中是否有可用的连接，如果没有才则建立之，否则直接利用连接池中的连接来处理客户端的请求，这样做可以有效降低系统因建立与数据库的连接而带来的性能影响，同时也可以较好的节约系统资源。我们针对系统主题数据库容量上百万及日常业务处理繁重的情况，充分利用 BEAVEBLOGIC应用服务器系统提供负载均衡的功能，如在业务处理高峰期系统将会自动通过调配服务器组的利用率，提高了应用服务器的响应能力。同时，在系统开发中我们采用了大量的存储过程对业务进行处理，既简化了业务逻辑变化带来的维护工作量，在提升数据库服务器的处理能力也提高了系统的性能。

第三，合理确定实时交易的时间区段。对于此类交易，我方只是转发，处理的重点在于受理方。受理方可能有各种原因会导致时延。因此我们设定受理方有 10 秒的受理时间若超过此时间，我方将会自动提示发起方业务超时。为防止业务多次超时引起系统等待造成效率下降，我们在程序中设置了闻值，对达到闽值的网点实行交易限制。第四，对于批量交易处理问题，在**研究所的大力支持下，我们找到了合适的网络MAC 加密机，能够满足系统对 MAC 运算的时间要求我们要重点解决批量业务交易包问题为此，我们需要第一手数据。我们模拟了一批数据，进行网络实环境的测试，我们发现，在数据包满载且包内数据目的地为不同银行的时候，在交易高峰期，很容易超时。一方面是受理银行可能超时，一方面是中心端可能超时。因此，经过仔细分析，我们确定以下组包原则:按照业务种类和单一受理行组包，业务发起方只需要关注业务包是否发送到中心，而不必关心是否到受理行。这样，一方面可以简化中心端的操作，另一方面是发起方等待时间短。

第五，合理规划设置查询服务，专门设置查询服务器，提供对当前日以前各交易的查询活动。这样，既可以满足客户的需求，又可以有效防止对交易的影响，客观上提高了数据库的处理能力。

第六，我们在客户端主要采取 GUI方式与用户进行交互，使用多线程技术对用户输入进行处理，如用户输入完相关资料在提交时，系统利用线程来进行处理，这样系统主线程就不会因等待处理结果而停顿。另外，系统在查询中也大量使用了线程技术，系统首先利用线程对用户要求的资料进行查询，待结果出来后再交给主线程将结果显示出来。在显示浏览表格或用户查询结果时并不是一下将所有的结果都从服务器提取过来，而是每次传输60 条记录，屏幕上显示 20 条，还有40 条暂存在本地，如果用户继续查看则进行“翻页”操作以提高系统的响应速度。

另外，我们将批量业务处理、报表处理等大作业量尽量在系统闲时进行处理，一方面可以缓解业务高峰期的性能压力，另外还可以实现系统性能。

通过综合利用以上技术，系统于 2009 年 4 月投入运行时就取得了较好的效果，实时交易时间一般不会超过 3 秒，最长 15 秒，系统峰值处理能力远超过设计要求，经受住了5倍数据量的考验，批量交易数据处理一般在 15 秒内就得到了应答客户查询交易一般在6秒左右得到应答。系统主要性能到了设计要求，得到了银行和企业的好评。

尽管系统建设取得了成功，但是我也看到了不足之处。设计中只考虑了满足联机交易均衡负载和提高性能，但是在实际应用中，发现银行客户对交易的查询是大量的，设计的前瞻性不足，余度不大，容易引发服务器堵塞，需要进一步考虑查询优化。

此次系统的顺利实施为我在中、大型软件性能设计方面积累了较多的经验，为我以后的工作提供了很好的帮助。同时，软件技术的日新月异也促使我要不断更新自己的知识结构，为应对不同体系结构的软件分析与设计做好准备。

论软件架构的选择与应用

摘要

2006年5月，我所在的公司承担了某省社会保险管理信息系统的开发工作，我在该项目中担任系统架构设计师职务，主要负责设计应用系统架构和网络安全体系架构。该系统以IC卡为信息载体，完成劳动和社会保险的主要业务管理，即“五保合一”管理，包括养老保险、医疗保险、劳动就业和失业保险、工伤保险、女工生育保险。整个业务流程十分复杂，牵涉面相当广泛

本文以社会保险管理信息系统为例，讨论了软件架构的选择和应用。整个系统采用具有四层的层次式软件架构的设计思想，在业务管理层的设计中，采用了互连系统构成的系统的架构，把整个业务管理系统划分为八个从属系统。各从属系统的架构可以相同，也可以不同。整个系统的开发工作历时 19 个月，目前，该系统已经稳定运行 1年多的时间实践证明，这种架构设计有效地降低了维护成本，提高了系统的开放性、可扩充性、可重用性和可移植性。

正文

2006年5月，我所在的公司承担了某省社会保险管理信息系统(以下简称为“SIMIS系统”)的开发工作，我参加了该项目前期的一些工作，担任系统架构设计师职务，主要负责设计应用系统架构和网络安全体系架构。

1.项目概述

SIMIS 服从于国家劳动和社会保障部关于保险管理信息系统的总体规划，系统建设坚持一体化的设计思想，总体目标是建立比较完备、高效、与劳动和社会保障事业发展相适应、与国家经济信息系统相衔接的劳动和社会保险管理信息系统，实现劳动和社会保险管理体系的技术现代化、管理科学化。

SIMIS 系统以IC卡为信息载体，完成劳动和社会保险的主要业务管理，即“五保合一”管理，包括养老保险、医疗保险、劳动就业和失业保险、工伤保险、女工生育保险。整个业务流程十分复杂，牵涉面相当广泛，SIMIS 系统由省、地市、县三级组成，网络纵向覆盖全省各级劳动和社会保障机构，横向与财税、银行、卫生、邮政、企事业单位联网，是一个典型的广域网络系统，系统设计按照社会保险与个人账户相结合的模式，以养老保险为重点，并以此为全省劳动和社会保险管理信息网络主干网络，带动劳动力市场等其他社会保险业务管理信息系统建设

2.架构设计

虽然国家劳动和社会保障部对整个业务有一套规定的指导性流程，但是，在调研的过程中，我们发现各市、县都或多或少地存在使用“土政策”的情况，正是这种“土政策”致使软件在设计阶段具有很多的不确定性需求。另外，我们还考虑到将来用户需求可能会发生变化，为了尽量降低维护成本，提高可重用性，我们引入了层次式软件架构的设计思想。SIMIS 系统采用层次式软件架构的基本出发点在于，这种软件结构不但能够满足不同规模的用户《县级，地、市级)的需求，可以方便地在最小的完成基本功能的基本系统和最大的完成所有复杂功能的扩充系统之间进行选择安装，而且通过还层功能扩展的方法来进行软件实现，有利于程序设计和构件开发。同时，一定级别的抽象层可以作为一种知识积累，对于同类软件的快速开发有着很大的作用。

根据调研的结果，我们把 SIIMIS 系统设计成具有通用核心层、基本应用层、业务管理层和扩展应用层四个层次的层次式软件体系构，如图所示

通用核心层完成的是软件的一些通用的公共操作，这些操作能够尽量做到不与具体的数据库和表结构相关。基本应用层是 SIMIS 系统数据采集的主要来源，业务管理层是对基本应用层的进一步扩展，主要完成 SIMIS 系统的业务管理，管理内容涉及劳动者个人、企业和其它劳动组织的微观信息，能够实现数据的初步汇总。业务管理层与其内包含的两层一起构成了 SIMS 的典型应用系统扩展应用层是在典型应用系统的基础上扩充了一些更为复杂的功能，如对政策决策提供依据和支持，对政策执行状况进行监测、社会保险信息发布及个人账户电话语音查询系统等。

SIMIS 的设计和开发重点放在业务管理层上，在这一层的设计中，我们采用了互连系统构成的系统的架构，把整个业务管理系统划分为失业保险管理、养老保险管理、医疗保险管理、女工生育保险管理、工伤保险管理、工资收入管理、劳动关系管理、职业技能开发管理等八个从属系统，所有的从属系统共用同一个数据库管理系统，每个从属系统作为单独的系统，由不同的开发团队进行独立开发。从属系统可以自成一个软件系统，脱离上级系统而运行，有其自己的软件生命周期，在生命周期内的所有活动中都可以单独管理，可以使用不同的开发流程来开发各个从属系

各从属系统的架构可以相同，也可以不同。例如，在开发“养老保险管理系统”这个从属系统时，选择了正交软件架构。我们将整个系统设计为三级正交结构，第一级划分为八个线索，每个一级线索又可划分为若干个二级线索，每个二级线索又可划分为若干个三级线索。一条完整线索如图所示。

每一条线索完成整个系统中相对独立的一部分功能，所有线索是相互独立的，即不同线索中的构件之间没有相互调用。由于采用了正交结构的思想，在系统开发时，我们分成若干个小组并行开发，视开发难度情况，每个小组负责一条或数条线索，由一个小组来设计通用共享的数据存取构件。由于各条线索之间没有相互调用，所以各小组不会相互牵制

大大提高了编程的效率，缩短了开发周期，降低了工作量。虽然各个从属系统相对独立，可以以进行并行开发，但我们尽量注意了软件重用，以节约开发成本，加快开发进度，例如，“基金收缴”是失业保险、养老保险、医疗保险、女工生育保险和工伤保险五个从属系统中都要进行的操作，且其操作流程大致一样，只是基金收缴的参数有所区别。我们就只安排养老保险从属系统的开发团队开发一个通用构件，提供参数接口供其他从属系统使用

3总结

在 SIMIS 系统的架构设计中，我们引入了层次式软件架构的设计思想。根据调研的结果，把 SIMIS 系统设计成具有通用核心层、基本应用层、业务管理层和扩展应用层四个层次。SIMIS 的设计和开发重点放在业务管理层上，在这一层的设计中，采用了互连系统构成的系统的架构，把整个业务管理系统划分为八个从属系统。每个从属系统作为单独的系统，由不同的开发团队进行独立开发。各从属系统的架构可以相同，也可以以不同以上设计有效地降低了维护成本，提高了系统的开放性、可扩充性、可重用性和可移植性。但 SIMIS 的设计和开发也存在一些不足例如，由于采用了互连系统构成的系统的软件架构，使资源管理开销增大，各从属系统的开发进度无法同步等。又如，由于采用了B/S 和 C/S 结构混合的异构结构，使外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强等