包含关系指的是两个用例之间的关系，其中一个用例（称为基本用例，Base Use Case）的行为包含了另一个用例（称为包含用例，Inclusion Use Case）的行为。也就是说基本用例会用到包含用例，表示基本用例中重用包含用例中的步骤。在UML图中，包含关系使用带虚线的箭头表示，并在线上标有<<include>>，如图4.7所示。

在包含关系中，箭头的方向是从基本用例到包含用例，也就是说，基本用例是依赖于包含用例的。

扩展关系的基本含义与泛化关系类似。扩展关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。扩展的基本用例中将存在一个扩展点（Extension Point），只有当扩展点被激活时，子用例才会被执行。在扩展关系中，对于扩展用例（Extension Use Case）有更多的规则限制，即基本用例必须声明若干扩展点；而扩展用例只能在这些扩展点上增加新的行为和含义。扩展关系是从扩展用例到基本用例的关系，它说明扩展用例定义的行为如何插入基本用例定义的行为中，也就是说扩展用例并不在基本用例中显示。

在以下几种情况下，可以使用扩展用例：

（1）表明用例的某一部分是可选的系统行为（这样就可以将模型中的可选行为和必选行为分开）。

（2）表明只在特定条件（如例外条件）下才执行的分支。

（3）表明可能有一组行为，其中的一个或多个可以在基本用例中的扩展点处插入。所插入的行为和插入的顺序取决于在执行基本用例时与主角进行的交互。

在UML图中，扩展关系使用带虚线的箭头表示，并在线上标有<<extend>>，如图4.8所示。在还书的过程中，只有在例外条件（读者遗失图书）的情况下，才会执行交罚款的分支。

泛化关系指的是一般与特殊的关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，它继承了父用例所有的结构、行为和关系。用例之间泛化关系如图4.9所示。

在一些用例图中，用例的数目可能很多，这时就需要把这些用例组织起来。这种情况在一个系统包含很多子系统时就会出现。另一种可能就是，当我们按顺序和用户会谈，收集系统需求时，每个需求必须用一个单独的用例来表达，这时就需要某种方式来对这些需求进行分类。

最直接的方法就是把相关的用例放在一个包中组织起来。一组用例可以放在一个文件夹中。

综上所述，用例之间存在着一定的关系，这些关系既有联系又有区别。在扩展关系中，基本用例是一个完整的用例，即是可以独立存在的用例。一个基本用例在执行时，可以执行也可以不执行扩展部分。

在包含关系中，基本用例可能是、也可能不是一个完整的用例。在执行基本用例时，一定会执行包含用例部分。

当需要重复处理两个或多个用例时，可以考虑使用包含关系，实现一个基本用例对另一个用例的引用。

当处理正常行为的变型而且只是偶尔描述时，可以考虑只用泛化关系。

当描述正常行为的变型而且希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。

《UML 2.5基础、建模与设计实践》(李波，姚丽丽，朱慧)【摘要 书评 试读】- 京东图书 (jd.com)