3.太原同城系统开发中的敏捷建模实践

    在上述方针的指导下，可以利用敏捷建模对统一过程施行改造。以下将以山西省太原市人民银行同城票据清算系统v2.0（以下简称“太原同城系统”）为例，说明应用AM原则与实践在改造一个UP开发项目过程中的一些体会。

    3.1太原同城清算系统介绍

    3.1.1开发背景

    太原同城系统是在金融体制改革的形势下，由北京市泰通电子技术公司承担开发的，在太原市辖区范围内建设的一个连接该市各个商业银行和与人民银行清算中心的票据实时清算系统。通过实时处理贷记、借记票据交换业务，可以改变传统的票据手工交换方式，以电子流代替票据流，使资金可即时抵用，为各商业银行提供统一、快捷、安全、可靠的资金清算渠道，也为人民银行提供了监控资金流量与流向的现代化手段。

    3.1.2系统体系结构

    太原同城系统是一个基于交易中间件、复合平台、多语言联合开发的三层C/S结构系统。其三层架构分别为：

    (1）数据层：运行在人行结算中心的数据库服务器上，OS为TurboLinuxEnterprise8.0，DBMS为Oracle9iEnterpriseforlinux。

    (2）中间层：运行在人行结算中心的应用服务器上，OS为TurboLinuxEnterprise8.0，用C++语言实现了核心商业服务，开发工具选用BorlandC++BuilderX1.0Enterprise。

    (3）表示层：运行在各商业银行的PC前端机（SCOUNIX5.05平台，270台）及人行结算中心的PC前端机（Win2000/RedflagLinux4.0平台，5台）上。商行前端程序用C语言实现；人行前端程序用JAVA语言实现，开发工具选用BorlandJBuilder7Enterprise。

    上述三个层次分别安装了东方通科技公司的消息中间件TongEASY4.5forLinux/SCOUNIX/Windows，整个系统的事务处理功能即由它保证。TongEASY作为一个基于三层C/S体系结构的中间件，其构成的交易管理平台提供了交易管理、负载均衡、应用调度等功能。其包含的通讯管理模块还提供了可靠的数据传输、网络监控、流量控制等功能。

    3.2太原同城系统开发中的敏捷建模实践

    本人作为太原同城系统的项目经理，按照上文所述观点，将敏捷实践中“明确最终目标、快速迭代反馈、多种模型建模、简化工作过程”这四方面的内容与实际开发的过程控制进行了结合。以下是对其中这几方面实践内容的总结。

    3.2.1太原同城系统的快速迭代与增量式开发实践

    这一实践体现了“快速迭蠢钡木瘛Ｌ窍低车幕救砑滩捎肦UP。按照Rational公司对UP的定义，软件开发的生命周期被划分为初始、细化、构造、交付四个阶段，每个阶段结束于定义良好的里程碑――即某些关键决策必须做出的时间点。为了更好地控制变更、减少开发风险，太原同城系统的开发遵循了RUP所规定的从一个迭代过程到下一个迭代过程的递增式增长，从而形成了最终系统。具体而言，这些迭代过程包括：

    (1）第一次迭代（历时一个半月）：

    跨越UP所定义的初始阶段。该次迭代实现的UP规程主要包括：初步业务建模、捕获业务需求、建立开发环境等。通过该次迭代，完成了架构方案的确定，实现了部分子系统中最关键的业务用例的分析设计与编码、测试――比如票据发送、票据接收、票据文件生成等。同时，通过测试比较，项目组明确了系统的体系结构，即：立足于基于消息中间件的三层C/S结构系统。此外，还根据上述体系结构的特点，确定了开发语言与开发工具。值得一提的是，该次迭代的初衷并非单纯针对太原同城系统，但太原同城系统事实上成为了此次迭代过程的第一个受益者。

    (2）第二次迭代（历时两个半月）：

    跨越了UP所定义的细化阶段和构造阶段。该次迭代实现的UP规程包括业务建模、需求分析、体系结构设计、编码实现，它所包括的数次小的迭代过程分别侧重于分析、设计和编码实现。首先，通过本次迭代，基本完成了对所有概要级别用例、用户级别用例及大部分子功能级别用例的分析，同时，还完成了类设计、基本数据静态结构设计与数据动态流向设计。系统架构的整体搭建也在此阶段完成。之后，在上述架构的基础上实现了相应的编码工作。

    (3）第三次迭代（历时两个半月）：

    跨越了UP所定义的构造阶段和移交阶段。该次迭代实现的UP规程包括补充业务建模、补充需求分析、补充编码实现、系统测试、运行和支持等。通过该次迭代，完成了对各级别用例的修改、补充，补充完善了各功能模块的代码，完成了系统测试和部署准备。

    当然，系统最终迭代次数的变更结果取决于太原同城系统的实际部署效果和部署后用户的意见反馈。

    同时，系统在进行某一阶段的建模工作时，还注意尽量避免在该阶段只专注于一个制品的制作。比如，在用例建模阶段，还同时进行了用户界面原型的设计工作；在数据建模阶段，还将设计会议包括进来。

    3.2.2太原同城系统的多种模型建模实践

    太原同城系统的过程控制实践很注重改造系统启动时组织内部因沿袭UP思维方式而可能存在的不符合AM原则的文化障碍。比如，根据AM“多种模型建模”的精神，太原同城系统的建模过程就没有受限于UML规定的若干建模制品。

    虽然UML定义了一系列的建模制品，但很显然，完整创建其定义的所有建模制品是没有必要的。另一方面，UML建模制品至少在分析需求时并不完备，也存在盲点。比如，UML无法满足用户界面建模需求、UML的活动图无法描述一个信息存储的位置信息等等。因此，在太原同城系统的开发中对UML制品根据需要进行了取舍。针对UML建模制品的不足，还补充了其它一些制品，包括一些UML问世之前就存在了的建模制品（如数据流图），甚至包括一些有独创性的建模制品（如数据流向设计）。下面是太原同城系统分析设计过程中一些制品的制作情况描述：

    ⑴编写有效用例，透彻描述和分解需求规格说明书中提出的各项功能需求。

    比如，对于“中心日初始化”这一功能而言，我们需要清楚地说明人行结算中心在每个工作日业务开始时，日初始化功能涉及到的主执行者、目标、前置条件、触发条件、主要场景、意外情况处理等细节情况。其有效用例主要部分摘要如下：

    “中心日初始化”处理用例

    n主执行者：人行结算中心系统管理员

    n语境中的目标：人行结算中心系统能开始处理税票信息。

    n级别：用户目标。

    n项目相关人员和利益：

    1.人行结算中心操作员

    2.人行结算中心业务领导

    3.人行结算中心

    n前置条件：人行结算中心操作员、系统管理员或业务领导登录成功。

    n触发事件：人行结算中心系统工作人员登录成功后开设新工作日。

    n成功保证：人行结算中心新工作日开设成功，并且工作状态进入日间状态。

    n最小保证：人行结算中心系统工作人员登录验证。

    n主成功场景：

    1.人行结算中心前一工作日日终判断。

    2.人行结算中心本工作日日初注册：人行结算中心系统获取新的工作日日期；人行结算中心该工作日由日初状态进入日间状态。

    n扩展：

    *a.任意时刻，系统崩溃：（略）

    *b.任意时刻，网络连通出现故障：（略）

    1a.结算中心前一工作日日终尚未完成：

    继续进行结算中心前一工作日日终处理，直到日终成功。

    1b.结算中心前一工作日日终已经完成。

    继续进行新一工作日的日初处理。