用例图中的三种关系包含、扩展、泛化

            用例图使用户 与开发人员交流的一种重要的方式，是对用户需求的一种描述。开发人员从用户的角度整体上理解系统的功能。

             用例图主要有三种元素：参与者（Actor），用例，以及用例图中对象间到的关系。其中关系有包含、扩展是用例图中特有的，泛化在其他类图中同样存在。

             包含:当可以从两个或两个以上的用例中提取公共行为时，应该使用包含的关系来表示它们。其中这个提取出来的公共用例成为抽象用例，而把原始用例成为基本用例或基础用例。其中“<>”是包含关系的构造型，箭头指向抽象用例。

例如，在机房收费系统中“注册学生信息”和“充值”两个用例都需要操作员或者管理员登陆，为此，可以定义一个抽象用例“用户登陆”。用例“注册学生信息”和“充值”与用例“用户登陆”之间的关系就是包含关系。

如图               

有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以抽象出一个基用例，来包含这些颗粒的用例

       作用：当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段时间流在不同用例中的描述出现不一致。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某段事件流抽象成为一个被包含的用例。

2、扩展关系

        如果一个用例明显地混合了两种或者两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样可能会使描述更加清晰。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此他能根据基用例中扩展点的当前状态来决定是否执行自己。而扩展用例对基用例不可见。如机房收费系统中“维护学生信息”操作时如果发现信息有误或者更新则需要使用“修改学生信息”用例完成更新，所以用例“查询上机记录”和“导出EXCEL”之间的关系就是扩展关系。“<>”是扩展关系的构造型，箭头指向基本用例。

如图                   

包含关系和扩展关系的联系和区别

       联系：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

    区别：扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。

         包含关系中基本用例的基本流执行时，包含用例一定会执行。

3、泛化

       当多个用例共同拥有一种类似的结构和行为时，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，它继承了父用例的所有结构、行为、关系。其中三角箭头指向父用例。假如在机房收费系统的注册可以通过本地注册和网上注册。则

用例图如           

同样，一般用户，操作员，管理员之间也存在泛化的关系

如图                  

转：UML中扩展和泛化的区别 

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

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

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

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