uml
<!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} @font-face {font-family:宋体; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-alt:SimSun; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:536871559 0 0 0 415 0;} @font-face {font-family:"\@宋体"; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; mso-pagination:none; font-size:10.5pt; mso-bidi-font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:宋体; mso-font-kerning:1.0pt;} /* Page Definitions */ @page {mso-page-border-surround-header:no; mso-page-border-surround-footer:no;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt; mso-header-margin:42.55pt; mso-footer-margin:49.6pt; mso-paper-source:0; layout-grid:15.6pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:757285699; mso-list-template-ids:559449438;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; mso-ansi-font-size:10.0pt; font-family:Symbol;} @list l1 {mso-list-id:955410971; mso-list-template-ids:-683115688;} @list l1:level1 {mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2 {mso-list-id:1036084874; mso-list-template-ids:-190967348;} @list l2:level1 {mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3 {mso-list-id:2106461959; mso-list-template-ids:2144781816;} @list l3:level1 {mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4 {mso-list-id:2122527313; mso-list-template-ids:462466930;} @list l4:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} -->
用 UML 做好系统分析
转自 邱郁惠
使用 UML 如何能让我们做好系统分析的工作呢？就让我们通过本章的基金模拟项目，先睹 为快，抢先体验一番。
定义及分析业务流程（ 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 的序列图，系统分析员可以为类增加更多的操作，并且描述操作的方法。
<!---->5. <!---->
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. <!---->扣款（