UML用例图三种关系详解.doc

《UML用例图三种关系详解.doc》由会员分享，可在线阅读，更多相关《UML用例图三种关系详解.doc（5页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、1 UML用例图中包含(include)、扩展(extend)和泛化(generalization三种关系详解共性：都是从现有的用例中抽取出公共的那局部信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含Inclusion用例来封装一组跨越多个用例的相似动作行为片断，以便多个基Base用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例

2、的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例与删除用例，那么划分太细。这时包含关系可以用来理清关系。2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展Extension用例加以封装，再让它从基用例中声明的扩展点

3、Extension Point上进展扩展，从而使基用例行为更简练与目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。例如，系统中允许用户对查询的结果进展导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印与查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：4、泛化(generalization)泛化关系：子用例与父用例相似，但表现出更特别的行为；子用例将继承父用例的所有构造、行为与关系。子用

4、例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示： 上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此根底上结合自己的系统，对工程(在线购物系统)的用例做了整体的描绘。 * (1)系统整体用例图按照先整体用例，后子系统用例来进展描绘的，欢送大家提出好的建议!转：UML中扩展与泛化的区别 泛化表示类似于OO术语“继承或“多态。UML中的Use Case泛化过程是将不同Use Case之间的可合

5、并局部抽象成独立的父Use Case，并将不可合并局部单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下： 泛化侧重表示子用例间的互斥性； 包含侧重表示被包含用例对Actor提供效劳的间接性； 扩展侧重表示扩展用例的触发不定性；详述如下： 既然用例是系统提供效劳的UML表述，那么效劳这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况： 无条件发生：肯定发生的； 有条件发生：未必发生，发生与否取决于系统状态； 因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服 务，但用例提供效劳的方式可分为间接与直接两种，依据于此，泛化中的子用例提供的是直接效劳，而包含中的被包含用例提供的是间接效劳。同样，扩展用例提供的也是直接效劳，但扩展用例的发生是有条件的。 另外一点需要提及的是：泛化中的子用例与扩展中的扩展用例均可以作为根本用例事件的备选择流而存在。第 5 页