(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. 结算中心前一工作日日终已经完成。
继续进行新一工作日的日初处理。
2. 手工输入的新工作日日期不符合要求：提示修改工作日日期，直到合格。
n 使用频率：每个工作日一次
太原同城系统中包括上述用例在内所有用例的设计，其设计风格都与Alistair Cockburn在《Writing Effective Use Cases》一书中推荐的风格相同。其中，下横线部分是准备继续扩展描述的下一级用例，为省篇幅本文从略。
这里，应当突破UP声称的对用例的认识局限，意识到用例并不足以驱动所有事情。事实上，用例只是全部需求，甚至只是全部功能需求的一部分，对诸如用户界面需求、商务规则、非功能需求的描述，仅靠系统用例是不够的，有必要以基本界面原型、界面流程图、CRC卡等加以补充。
⑵ 针对“概要级别用例”、“用户级别用例”及“子功能级别用例”使用数据流图进行逐层分析，了解各用例所涉及的数据源点与汇点之间的关系。
通过数据流分析这种传统的分析手段，我们可以汇总出数据字典，并作为静态数据结构设计的依据。下面的数据流图实例就是太原同城系统中针对用户级别用例――“实时提出”所做的分析。依托数据流图，“实时提出”功能所涉及到的各个数据存储、各个数据源点和终点、各个加工都一目了然。
⑶ 根据数据流图进行数据建模。
在UML中，数据模型并没有很好的建模制品进行表达，但我们有必要提供数据模型制品，并为后面诸如数据库表静态结构设计、UML类图设计等工作做准备。以下展示的，就是人行结算中心数据建模工作的一小部分结果。
项目组为完成该项设计，专门召集了数据建模会议。会议方式是项目经理组织全体项目成员集体讨论，集思广益。最终讨论结果以PowerDesigner为数据建模工具当场记录和修改，主要涉及库表结构定义、各数据项定义、表间关系定义、主外键定义等内容。不论是在当时的建模会议上，还是以后进行修改时，PowerDesigner在对数据建模结果进行快速修正和记录方面都体现了强大的功能。
⑷ 参照静态数据结构、数据流图、用例描述获得数据流向设计图。
这一独创的制品具有与UML时序图异曲同工的效果。但如此表达更符合程序员的编码习惯，更有利于实现从伪代码到真实代码的转化。至于设计范围，主要依据用例描述来确定。以下是“中心日初始化”这一子功能级别用例的数据流向设计实例：
“中心日初始化”数据流向
查询系统运行控制表
if 有记录
{
定位到工作日期最晚的一条记录
if 工作状态 <> 0<日终>
{
退出日初始化处理
}
手工选择工作日期 ××××-××-××
判断该日的记录是否已经存在
if 存在
{
提示并退出日初处理
}
判断该日是否小于库中的最大日期
if 小于
{
提示并退出日初处理
}
在系统运行控制表写入一条记录（手工选择工作日期 ××××-××-××工作状态1<日初>；工作场次1；是否平帐0<未清算>）
清空业务库表：网点日提出票据表、网点日提入票据表、网点日提入错误票据表、网点磁盘日待提入票据表、网点磁盘日提入登记表、网点日清算表、清算行日清算表、管辖行日清算表、清算帐户日清算表
更新网点状态权限表所有记录的网点日对帐标记为0<未对帐>，提入流水号为1
更新网点统计监控表所有记录的提出笔数、清分笔数、提入笔数、出错笔数为0；场次为1；通信状态为0<断开>
行号表是否需更新：
从版本控制表中查询>当前行号表版本号的记录，如果有记录，依次判断该记录的生效日期是否到期
if 有到期记录
{
备份当前行号表到备份行号表
更新行号表
更新网点状态权限表、网点统计监控表
修改系统运行控制表的当前行号表版本号
}
在系统运行控制表中修改记录（工作日期 ××××-××-××工作状态2<日间>；工作场次1；是否平帐0<未清算>）
}
else
{
手工选择工作日期 ××××-××-××
在系统运行控制表写入一条记录（手工选择工作日期 ××××-××-××工作状态2<日间>；工作场次1；是否平帐0<未清算>）
}
在数据流向设计中，总的设计方式是参照流程顺序和时间顺序。其中，横线部分是此制品涉及到的数据库表。对相应库表的重要改动内容也同时记录在旁边，状态字段的内容改动其含义记录在“< >”中。
可见，通过上述各环节的分析设计工作，系统的制品已大大突破了UML所定义的制品范围。虽然这其中所完成的基本界面原型设计、界面流程图等制品尚未加以罗列，事实上其存在与制作对于系统的透彻分析是很有必要的。
3.2.3太原同城系统的简单化和目标明确化实践
当然，太原同城系统的开发实践还注意了“简化工作过程”与“明确最终目标”这两项AM精神的贯彻。比如，建造制品时对UML明确定义的部分制品的舍弃、在类图的制作过程中仅着重核心类的建模、在各阶段建模过程中注意点到为止，使制品量与其对开发的指导价值相匹配……等等，都体现了简单化的用意。而所有这一切，其实都是为完成最终目标――目标软件本身而服务的。
笔者认为，这两方面的实践虽然相对更加哲学化、抽象化一些，但在开发过程控制中依旧要始终加以留意，使之真正起到指导思想的作用。
4. 总结
综上所述，对于统一过程而言，敏捷建模是在保持统一过程原有基本优点的前提下，加强这一重量级软件过程敏捷程度的有效途径。相信，会有越来越多的统一过程软件开发实践将受益于对敏捷建模精髓的汲取，而太原同城系统开发的成功实践就是其中一个很好的例子。
文章来源于领测软件测试网 https://www.ltesting.net/
