Rose建模历程(1 用例视图)

一 用例视图

需求工作流程中使用了名为用例视图的构架视图，用例视图是其它视图的核心，它的内容直接驱动其它视图的开发。它主要是作为需求分析阶段的一个主要利器，是外部用户所能观察到的功能。

1 用例图UseCase Diagram

角色(Role)： 参与者， 用例    

参与者之间的关系： 泛化(超类)

参与者与用例的关系：关联association，实例化

用例之间的关系：关联association，相识(包含include与扩展exterd), 泛化generalization

用例图关系(难点)：

包含关系：如果基本用例中有一部分功能，该用例的执行与否由它的结果唯一决定，而不是由产生该结果的方法来决定，则可以将这一部分功能分离出来，放到一个附加用例中。采用包含关系，可以将附加用例显式插入基本用例中。

扩展关系：如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么您可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。利用扩展关系，可以将附加用例隐式插入基本用例中。

泛化关系：基本用例(父用例)与附加用例(子用例)之间的关系，之间使用继承。

示例：

以订单管理系统的用例模型部分为例进行说明。

在本图中，具体用例分别是“电话订购”（由客户主角发出）和“Internet 订购”（由 Internet 客户发出）。这些用例都是更普通的“订购”用例的变形。在本示例中，“订购”用例是一个抽象用例。“索要目录”用例代表一个可选行为段，它不是“订购”用例主要目标的组成部分。它已经被分离出来，形成了一个抽象用例，用于简化“订购”用例。“提供客户数据”用例是一个已分离出的行为段。它之所以被分离出来，是因为它是一个独立功能，只有它的结果才能影响“订购”用例。“提供客户数据”用例还可以在其他用例中复用。“索要目录”用例和“提供客户数据”用例在本示例中都属于抽象用例。

本用例图显示订单管理系统的用户模型部分。

下表显示了三个不同用例关系之间更详细的比较：

问题	扩展关系	包含关系	泛化关系
该关系有什么方向？	附加用例引用基本用例。	基本用例引用附加用例。	附加用例（子用例）引用基本用例（父用例）。
关系是否存在多重性？	是，在附加用例一方。	否。如果您希望不只一次包含相同的行为段，则必须在基本用例中声明。	否。
该关系是否存在某个条件？	是。	否。如果您希望在该包含关系中表达某个条件，则必须在基本用例中明确说明。	否。
附加用例是否为抽象用例？	通常是，但不一定。	是。	通常不是，但也有可能

 

2 活动图 Activity Diagram

活动图是状态图的一种特殊形式。其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。活动图支持嵌套。

           活动状态表示在工作流程中执行某个活动或步骤。

            转移表示各种活动状态的先后顺序。这种转移可称为完成转移。它不同于一般的转移，因为它不需要明显的触发器事件，而是通过完成活动（用活动状态表示）来触发。

             决策，为其定义了一组警戒条件。这些警戒条件决定在活动完成后将执行一组备选转移中的哪一个转移。您也可以使用判定图标来表示线程重新合并的位置。决策和警戒条件使您能够显示业务用例的工作流程中的备选线程。

              同步示意条用于显示平行分支流。同步示意条使您能够显示业务用例的工作流程中的并行线程。

 

“机场登记”业务用例模型中“个人登记”业务用例的活动图

可以使用垂直实线将活动图划分为泳道。每条泳道代表整个工作流程的某个部分的职责，该职责由组织的某个部门来执行。泳道最终可以由组织单元或者业务对象模型中的一组类来实施。