用UML做好系统分析.docxVIP

用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中，系统分析员可以用序列图来表达，系统内部一群对象合力完成某一个系统用例时，执行期间的交互情形。之后，序列图可能通过设计师之手，进行调整，并且成为程序员最关切的设计图之二（另一张是类图）。程序员通常会按