用例关联
目标：
- 以文本和图形两种形式，使用包含和扩展关联将用例联系在一起。
用例彼此之间可能具有联系。通过关联将用例组织起来，不会对系统需求和行为产生影响。相反，这只是简单的组织机制，能够促进对用例的理解和沟通、减少文本重复、改善用例文档的管理。
在一些使用用例的软件公司中，花费了过多事件争论用例图中如何管理用例，而没有关注更重要的工作：编写用例文本。这实际反映了软件项目中分析工作的深层问题：人们在低价值的分析和建模活动中花费了太多精力。如果你认为一开始就必须分析清楚，就会不可避免地时分析工作陷入瘫痪的麻烦。
因此，尽管本章讨论用例关系，但是首先应意识到，用例关系具有一些价值，但更重要的工作时编写用例文本。说明需求时通过编写用例文本完成的，而不是通过组织用例完成的，组织用力只是可选步骤，可能会改善对用例的理解、减少重复。
在UP和其他迭代方法中，将用例关系主旨起来可以在细化阶段逐步演化；在项目开始阶段，如同瀑布方法那样，视图定义和精化完整的用例图及其关系，并没有益处。
包含关系
这是最常见，最重要的关系。
多个中立中存在部分相同的行为，这是常见的现象。于其重复文本描述，不然将这部分交互欣慰分离未单独的子宫内用例，并适用包含关系加以只是。则是对文本的简单重构和连接，可以避免冗余。
当在两个或多个独立用例中存在重复，而你想避免这种冗余时，可以使用包含关系。还有一个动机，就是将过于冗长的用例简单地分解未子单元可以方便对其的理解。
在一部事件处理中使用包含关系
包含关系的另外一个用途时描述一部事件的处理。
最基本的表示法时在扩展部分中使用诸如a, b这种形式的标记。这种风格意味着扩展或事件可以在任何时候发生。范围i标记时一种辅助变体，例如3-9，如果一部事件可以在相对较大的用例步骤范围中发生，则使用范围标记，但也不全都如此。
总结
对大部分涉及用例间的关系问题，都可以使用包含关系处理。如下情形可以分解出子功能用例并使用包含关系：
- 用例在其他用例中重复使用。
- 用例非常复杂并冗长，将其分解未子单元便于理解。
使用包含关系来处理用例之间的关系时首要原则。
术语：具体用例、抽象用例、基础用例和附加用例
具体用例是由参与者发起，完成了参与者所期望的完整行为。它们通常是基本业务过程用例。
抽象用例永远不能被自己实例化；它是其他用例的子功能用例，它不能独立存在，只能是其他用例的一部分。
包含其他用例的用例，或者是被其他用例扩展或泛化的用例被称为基础用例。
被其他用例包含的用例，或者扩展、泛化其他用例的用例称为附加用例。
附加用例通常是抽象用例。基础用例通常是具体用例。
扩展关系
假设某个用例文本英文某些源于不能被修改。那么，如何向用例添加内容？
扩展关系为此提供了答案。其思路是，创建扩展或附加用例，并且在其中描述：在何处和何种条件下该用例扩展某基础用例的行为。
需要注意的是，扩展点的使用以及扩展用例是由某些条件所出发的。扩展点是基础用例中标记，扩展用例是通过该标记来引用扩展点的，因此基础用例的步骤编号可以改变，而不会影响扩展用例。
基础用力对扩展用例没有任何应用是扩展关系的最重要特征。
事实上，直接更新基础用例的扩展部分是推荐的方法，这样避免了创建复杂的用例关系。
泛化关系
注意：许多用例专家即使不使用这种可选关系也能够完成公里工作，这些关系对用例增加了另一层复杂度，并且业内人士也未就如何从中获益达成共识。用例顾问们共同观测结论是，大量用例关系会导致复杂结果，并且会花费大量徒劳的时间。