为了简化,

为包括

当基本用例执行时，包含的用例将每次执行一次。 基本用例需要完成所包含的用例才能完成。

一个典型的例子:在登录和验证密码之间

(登录)——<< include >>——>(验证密码)

为了使登录过程成功，“验证密码”也必须成功。

为扩展

当基本用例被执行时，扩展用例只是偶尔执行 扩展用例仅在满足某些条件时才会发生。

一个典型的例子:在登录和显示错误消息之间(只偶尔发生)

(登录 ) <--- << 扩展> >——(显示错误消息)

“show error message”只在登录过程失败时才会出现。

这可能会引起争议，但“包含总是，扩展有时是”是一个非常常见的误解，现在几乎已经取代了事实上的含义。以下是一个正确的方法(在我看来，并与雅各布森、福勒、拉尔曼和其他10个参考文献进行了对比)。

关系是依赖关系

包含和扩展用例关系的关键是要认识到，与UML的其余部分一样，用例之间的虚线箭头是一种依赖关系。我将使用术语“基本”、“包含”和“扩展”来指代用例角色。

包括

A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. (This is contrary to a popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).

在单向依赖的最佳实践中，基本用例知道(并引用)被包含的用例，但被包含的用例不应该“知道”基本用例。这就是为什么包含的用例可以是:a)它们自己的基本用例和b)由许多基本用例共享。

扩展

扩展用例依赖于基本用例;它从字面上扩展了基本用例所描述的行为。基本用例本身应该是一个完全功能的用例(当然包括了)，没有扩展用例的附加功能。

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

The base use case represents the “must have” functionality of a project while the extending use case represents optional (should/could/want) behavior. This is where the term optional is relevant – optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence. In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception). It can be used to extract out subsequences of the base use case, especially when they represent ‘exceptional’ complex behavior with its own alternative flows.

需要考虑的一个重要方面是，扩展用例可以在基本用例流中的几个地方“插入”行为，而不是像被包含的用例那样只在一个地方插入。由于这个原因，扩展用例不太可能适合扩展多个基本用例。

至于依赖关系，扩展用例依赖于基本用例，同样是单向依赖，即基本用例不需要序列中任何对扩展用例的引用。这并不意味着您不能演示扩展点或在模板的其他地方向扩展用例添加x-ref，而是基本用例必须能够在没有扩展用例的情况下工作。

总结

我希望我已经说明了“包含总是，扩展有时是”的常见误解要么是错误的，要么充其量是简单的。如果你考虑到误解所呈现的箭头方向的所有问题，这个版本实际上更有意义——在正确的模型中，它只是依赖关系，如果你重构用例内容，它不会潜在地改变。

当一个用例有先决条件时，就使用include。

对于有身份验证的用例，最坏的情况，或者是可选的，然后选择extend..

示例:用于寻求入场、预约、机票预订的用例 您必须填写一份表格(注册或反馈表)....这就是包容的由来。

例如:对于验证登录或登录您的帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。比如按时还书，没有预定，逾期付款，这就是延期发挥作用的地方。

不要在图中过度使用include和extend。

保持简单，傻瓜!!

我不建议用这个来记住这两点:

我的用例:我要去城市。

包括->驾驶汽车

Extends ->填充汽油

我宁愿你用: 我的用例:我要去城市。

Extends ->驾驶汽车

包括->加油

扩展关系延续了基类的行为。基类功能必须在那里。 另一方面，包含关系类似于可能被调用的函数。梅是粗体字。

这可以从 用例模型中的重用

我认为msdn在这里解释的很容易理解。

包括[5]

包含用例调用或调用包含的用例。包含用于显示用例如何分解为更小的步骤。所包含的用例位于箭头末端。

扩展[6]

同时，扩展用例将目标和步骤添加到扩展用例中。延期只在特定条件下生效。扩展用例位于箭头末端。

当您理解您的用例过于复杂时，可以使用Extends。因此，您将复杂的步骤提取到它们自己的“扩展”用例中。

Includes用于在两个用例中看到相同的行为。因此，您将常见的行为抽象到一个单独的“抽象”用例中。

(参考:Jeffrey L. Whitten, Lonnie D. Bentley，系统分析与设计方法，McGraw-Hill/Irwin, 2007)