从中摘录的内容之二__用例之间的关系

      用例存在主要的三种关系：包含关系，扩展关系，泛化关系。

      包含关系主要是站在用户的角度， 而扩展关系,泛华关系则是开发人员的观点了， 所以我们的用例图可以分开：用户的用例图, 开发人员的用例图，前者用例图只有包含关系。

      在建立用例关系时的原则：

      不要将用例之间的关系搞得太复杂，不要过度的使用包含关系或扩展关系，不要将用例描述分割得太零散，以免失去了用例叙述清晰明确且易读的特点与目标。始终记得用户的一个目的可以对应的得出一个用例，我们可以从用户接触系统的目的来着手寻找用例。用例是段有头有尾的使用过程，最终它会生成可供用户评价的明确服务或结果。

 

包含关系要点表

      1. 需要共享的相同流程，才能够独立出来。

      2. 暂存数据或访问数据库的操作，不要轻易独立出来。

      3. 如果只是一两句相同的流程叙述，不需要大费周章地独立出来。

 

 

扩展关系要点表

      1. 谨慎地使用扩张关系，避免因为滥用扩展关系而让用例图变得很难理解。

      2. 扩展关系通常用于系统上线之后的改版，可以在不变动已经写好的用例叙述的情况下，利用扩展关系，加上一段新的用例叙述，以满足新的需求。

      3. 不一定会执行的流程，可以放在替代流程中；要是想要跟其他用例共享这段流程的话，也可以使用扩展关系。

 

泛化关系

      两者必须是同一个概念，只不过在细节上有一些细微的差异。泛化关系也可以说是继承关系。

 

UML风格

第71条指南----用例＂一定＂会启动，适用包含关系

第72条指南----用例＂可能＂会启动，适用扩展关系

第73条指南----谨慎使用扩展关系

第74条指南----描述相似的业务逻辑时，适用泛化关系

 

第76条指南----用例之间的包含关系或扩展关系，避免达到两层以上

第77条指南----把被包含用例放置在基础用例的右方

第78条指南----把扩展用例放置于基础用例的下方

第80条指南----把子用例放置于父用例的下方

第81条指南----应用“就像是”规则来判断参与者之间的泛化关系

第82条指南----把子参与者放置于父参与者的下方

第83条指南----避免使用扩展点

第84条指南----只有在不够清楚的情况下，才使用扩展条件

 

第59条指南----使用领域术语为用例名称（也就是用用户的术语去为用例命名）