UML用例图中泛化，继承等的区别

UML用例图中包含(include)、扩展(extend)和泛化区别

 (2010-04-12 21:40:23)

转载▼

标签： 

uml

 

include

 

extend

 

泛化

 

扩展

 

包含

 

杂谈

 

a include b 表示 b是a中执行不可缺少的一部分 b是a不可缺少的一部分 b 一般不单独存在 并且 b 不知道a的存在 a知道b的存在
 （1）b通常是a和c 中共同操作部分抽象出的部分或者（2）b是a的子过程为了避免太复杂单独抽象出来的部分
a extend b 表示 b是a在系统某些情况下（特定条件）触发产生的 b不是a中必须存在的部分 b可以单独存在 b知道a的存在 但是a不知道b的存在 （因为a不知道谁/怎样扩展了它）
b是对a在一些基本功能上具体的扩展（在a的扩展点处）

include 是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样），例如 UseCaseA 中包括了 a 和 b 两个流程，而 UseCaseC 中包含了 c 和 b 两个流程。为了提高复用性，可以把 b 提取出来，形成另一个用例 UseCaseB，此时，UseCaseA include UseCaseB（表现为一条指向 UseCaseB 的虚线，箭头在 UseCaseB 侧），UseCaseC 也 include UseCaseB。因而，当有 include 关系时，被 include 的用例通常会被两个以上的其他用例 include（否则就不需要重用，也就不需要提取出来了），用例图如下：

在 include 关系中，“UseCaseA 和 UseCaseC 知道 UseCaseB 的存在，而 UseCaseB 根本不知道有 UseCaseA 和 UseCaseC）；

extend 则恰好相反。假设 UseCaseA 的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种，例如通过邮件发送、通过短信发送等。在需求分析阶段，可能无法明确到底有多少种方式， 在用例分析阶段，UseCaseA 需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如 UseCaseB 是“通过短信发送”，而 UseCaseC 是“通过邮件发送”，此时，UseCaseB 和 UseCaseC extend 了 UseCaseA，表现为两根虚线，箭头指向 UseCaseA，用例图如下：

在 extend 关系中，UseCaseA 不知道 UseCaseB 和 UseCaseC 的存在，但 UseCaseB 和 UseCaseC 却是知道 UseCaseA 并且知道如何在 UseCaseA 中作扩展的。

另：在用例图中，有时会看到两个用例之 间有依赖关系（表现为一条单向或双向的实线），这是错误的，说明用例没有提纯。

也许有人会问“如果两个用例之间，一个要调用另一个时，怎么办？”（有可能是混淆了用例和模块的关系），那么，首先要区分概念，用例就是用例，用 例不是模块，也不是组件（虽然一个用例能发展成为“一个或多个”模块或组件）；其次，从用例分析的角度来看，如果用例 A 确实要调用到用例 B，那么，可以进一步分析：A 是调用了 B 的所有流程呢，还是其中一部分流程？
（1）如果是调用了一部分，此时可以把 B 中的那部分流程提取出来，形成用例 C，然后 A 和 B 都 include C；
（2）如果是调用了所有流程，那么，A 直接 include B 即可；
（3）如果 A 没有调用 B 中的任何流程……faint，那还画那条代表依赖的实线干嘛？

1 、包含(include)

   

      包含关系：使用包含（Inclusion ）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base ）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
  
     包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件 流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗 粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序 中调用这一子过程。 　

     例 如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和 删除用例，则划分太细。这时包含关系可以用来理清关系。

  

   

  2 、扩展(extend)

  扩展关 系：将基用例中一段相对独立并且可选的动作，用扩展（Extension ）用例加以封装，再让它从基用例中声明的扩展点（Extension Point ）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状 态来判断是否执行自己。但是扩展用例对基用例不可见。

   

  对 于一个扩展用例，可以在基用例上有几个扩展点。   
  
  例如，系统中允许用 户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行 为。因此可以采用扩展关系来描述：
  
  

  4 、泛化(generalization)

   

  泛化关系：子用例和父用例相似，但表现出更特别的行为；子 用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存 在。

  例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化 关系表示：
  
  

   

  

  上 面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目( 在线购物系统) 的用例做了整体的描绘。
  
      *****************************************************************
  
      (1) 系统整体用例图
  
  

  

  

  

   

  按照先整 体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

  
  转：UML 中扩展和泛化的区别 
  
           泛化表示类似于OO 术语“ 继承” 或“ 多态” 。UML 中的Use Case 泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case ，并将不可合并部分单独成各自的子Use Case ；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
            ● 泛化侧重表示子用例间的互斥性；
            ● 包含侧重表示被包含用例对Actor 提供服务的间接性；
            ● 扩展侧重表示扩展用例的触发不定性；详述如下：

  
          既然用例是系统提供服务的UML 表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
           ⒈ 无条件发生：肯定发生的；
           ⒉ 有条件发生：未必发生，发生与否取决于系统状态；

           因此，针对用例的三种关系结合系统状 态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor 提供服 务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供 的也是直接服务，但扩展用例的发生是有条件的。

           另外一点需要提及的是：泛化中的子用 例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。