用UML做好系统分析

CIM-1：定义业务流程

定义及分析业务流程（Business Process）是为了尽快理清系统范围，以便估算开发成本及时间，可不是为了要改造业务流程。系统分析员千万别误解了此步骤的目的。所以，系统分析员在定义及分析业务流程时，要记得挑选跟系统有关的业务流程。

CIM-1定义业务流程的生成，主要有如下的业务用例图和简述。请看图2-1的业务用例图，图中的每一个业务用例代表一条业务流程，业务执行者则代表位于企业外但会启动或参与业务流程的人。投资人到银行临柜申购基金，启动了银行内部的一段关于申购基金的业务流程。再者，投资人也可能临柜办理赎回基金，这又引发了另一条业务流程。

至于业务用例简述，简洁扼要即可，我们主要用它来记录和区分业务流程。

CIM-2：分析业务流程

通过CIM-1圈出了系统将参与的业务流程之后，针对每一个业务用例，系统分析员得开始分析它的工作流程，并且绘制活动图（Activity Diagram）与业务人员取得共识。随后到了CIM-3时，才能够依此定义出系统可以协助之处，并且规划出系统范围。

此处，我们挑选一般的申购基金流程当示范，并绘制出如图2-2所示的活动图，展示了单笔申购基金的一般交易流程。

CIM-3：定义系统范围

经过了CIM-1的定义业务流程，以及CIM-2的分析业务流程之后，终于进入到CIM-3这场压轴戏了。CIM-1和CIM-2的生成文件，跟CIM-3的生成文件之间，有如下的关联性：

• CIM-2活动图中的每一个动作，都可能成为CIM-3的系统用例。
• CIM-1中的业务执行者，以及CIM-2中的动作负责人，都可能成为CIM-3的系统执行者（System Actor）。

针对上述的图2-2一般流程的活动图，我们分析得出如图2-3的系统用例图，以及下述的用例简述。

PIM-1：分析系统流程

在CIM阶段，系统分析员大约花1～2周的时间，尽快生成初步的系统用例，以便让相关的决策人员可以从中挑选出首期开发的系统用例，而这也就是首期的系统范围。

随后，项目正式进入PIM阶段，也是正式进入分析阶段，所以系统分析员将投入更多的时间，针对首期的系统用例详述规格，作为正式需求文件的一部分，也作为业务人员与开发人员之间的沟通文件。

所以，系统分析员在PIM-1的主要工作，将针对每一个系统用例，分析其内部细节，并编写详尽的系统用例叙述（UC Description）。UML并未提出标准的叙述格式可供遵守，不过系统分析员可以在网络上找到许多实用的用例叙述格式，或者翻阅一些UML或用例相关书籍，也可以发现许多很有特色的用例叙述格式。

此处，我们示范编写“网络申购单笔基金”和“网络申购定期定额基金”的系统用例叙述，如下图2-4和图2-5所示：

PIM-2：分析业务规则

企业通过一组规则（Buisness Rules）来控制整体的运作，包括人员、流程、系统、概念的运作，皆受制于业务规则。由此足见业务规则之重要，所以早从PIM-1的系统用例叙述，一直到此处的PIM-2状态图以及稍后的PIM-3类图，我们都会要求系统分析员必需通过这些UML图，记录且呈现重要的业务规则。

例如，在经过PIM-1的步骤之后，我们认为“定期定额申购”是很重要的业务对象，而且涉及许多重要的业务规则，所以决定为它绘制如图2-6的状态图，以便组织业务规则，同时也对定期定额申购有更深入的理解。

PIM-3：定义静态结构

在PIM-3中，系统分析员用类图来表达系统内部的静态结构。系统只有具备稳定且具弹性的静态结构，才能够顺应需求变更，迅速支撑多样化的系统用例。之后，类图可能通过设计师之手，进行调整，并且成为程序员最关切的设计图之一。程序员通常会按照类图的内容，来编写并组织源代码。

在PIM-3的过程中，系统分析员寻找操作绝对优先于寻找属性。因为属性随处可见，特别是从PIM-1搜集而来的窗体，里头多的是对象必须保存的属性。而寻找操作就没这么直接简单了，系统分析员必须多动脑筋才能定义出操作，所以先别管属性了，记得优先找操作。

进行PIM-3时，系统分析员可以通过下列步骤，建立出如图2-7的类图：

1. 套用交易模式，并且经过调整之后，系统分析员可以获得初步的静态结构。
2. 分析PIM-2的状态图之后，系统分析员可以为类增加属性及操作。
3. 分析PIM-1搜集来的窗体，系统分析员可以为类增加更多的属性。
4. 经过PIM-4的序列图，系统分析员可以为类增加更多的操作，并且描述操作的方法。

PIM-4：定义操作及方法

在PIM-4中，系统分析员可以用序列图来表达，系统内部一群对象合力完成某一个系统用例时，执行期间的交互情形。之后，序列图可能通过设计师之手，进行调整，并且成为程序员最关切的设计图之二（另一张是类图）。程序员通常会按照序列图的内容，编写出方法的源代码雏型。

此外，PIM-1的系统用例叙述和PIM-3的类图，对PIM-4的序列图有不可或缺的贡献。从PIM-1的系统用例叙述中，系统分析员可以分析出系统流程。而在PIM-3的类图中，系统分析员定义出系统内部的静态结构。随后，到了PIM-4的序列图时，则结合了系统用例以及静态结构两者。

系统分析员通过序列图的思考与表达，试图安排依据类们所生成的一群对象之间的交互，让这一群对象可以合力完成某一个系统用例。同时，在序列图中，一群对象交互所引发的操作，则可以反馈给类图，定义出更多的操作及属性，甚至发现之前未发现的其他类及关系。

系统分析员可参考下述步骤来绘制序列图：

1. 扮演启动者的执行者对象放置于序列图最左方；扮演支持者的执行者对象放至于序列图的最右方。
2. 针对系统用例叙述里所记载每项流程步骤，判断执行时需要使用到哪些数据，且可指派拥有该数据的对象负责该项工作。
3. 试着执行序列图，以便调整流程，并且为操作加上参数。
4. 把绘制序列图时所找到的操作及属性，反馈给类图。

以“网络申购单笔基金”系统用例之主要流程为例，我们示范绘制出如图2-8所示的序列图。

最后，系统分析员可以试着执行一次序列图的流程，并且为操作加上参数。增加输入（in）及输出（out）参数如下：

1. 查询托售基金清单（out 基金名称清单）
2. 查询基金名称（out 基金名称，基金代号）
3. 查询扣款账号（out 扣款账号）
4. 单笔申购基金（in 基金代号，申购金额）
5. 计算手续费（in 申购金额，out 手续费）
6. 查询银行折扣（out 银行折扣）
7. 查询基金管理费（out 基金管理费）
8. 查询综存账户余额（out 综存账户余额）
9. 查询综存账户余额（in 扣款账号，out 综存账户余额）
10. 确认单笔申购（out 凭证号码）
11. 扣款（）
12. 扣款（in 交易金额）
13. 设定申购日期（）
14. 产生交易编号（out 凭证号码）

由于，单笔申购和定期定额申购计算手续费的方法相同，所以系统分析员可以将单笔申购类里的“计算手续费”操作移至申购交易类，并汇总上述序列图所新增的操作与相关属性，更新类图如2-9所示。

在CIM与PIM之后

由于我们采用MDA（Model-Driven Architecture）开发程序，作为专业分工的依据，因此系统分析员的工作聚焦于CIM与PIM阶段，至于PSM及编码阶段，则交由其他的设计师负责之。MDA主要将生成的UML模型，分为下列三个阶段：

• CIM（Computation Independent Model）──聚焦于系统环境及需求，但不涉及系统内部的结构与运作细节。
• PIM（Platform Independent Model）──聚焦于系统内部细节，但不涉及实现系统的具体平台（Platform）。
• PSM（Platform Specific Model）──聚焦于系统落实于特定具体平台的细节。例如，Spring、EJB2或.NET都是一种具体平台。

因此，系统分析员执行了前述的CIM与PIM步骤，并且获得高质量的生成之后，设计师会依据具体平台进一步生成PSM阶段的设计，并交由程序员按图编码，编写出适用于特定具体平台的代码。

本文节选自机械工业出版社新推出的《系统分析师UML实务手册》中的第2章《做好系统分析》。

《系统分析师UML实务手册》通过一个完整的仿真实例，介绍了从需求到生成UML的用例图及其叙述、活动图、类图、序列图和状态图等，一应俱全，过程细腻，步骤详细。主要内容包括：定义业务流程、分析业务流程、定义系统范围、分析系统流程、分析业务规则、定义静态结构、定义操作及方法、基金模拟项目、语音备忘器等。

与此同时，机械工业出版社还授权InfoQ中文站独家为大家提供额外的样章进行试读：欢迎下载第10章《基金模拟项目》