|
使用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的类图：
套用交易模式，并且经过调整之后，系统分析员可以获得初步的静态结构。
分析PIM-2的状态图之后，系统分析员可以为类增加属性及操作。
分析PIM-1搜集来的窗体，系统分析员可以为类增加更多的属性。
经过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阶段的设计，并交由程序员按图编码，编写出适用于特定具体平台的代码。
|
