我喜欢把“包含”看作基本用例的必要前提/伴随。这意味着如果没有基本用例所包含的用例，就不能认为基本用例是完整的。我将给出一个向客户销售商品的电子商务网站的例子。如果不先选择商品并将其放入购物车，你就无法支付商品。这意味着用例“Pay for Item”包括“select Item”。

扩展的用途多种多样，但我喜欢将其视为一种可能使用也可能不使用的替代方法。例如，仍然在电子商务网站。在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。

想要更清楚地了解用例的规则，请阅读我的文章:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行以完成基本使用。

如。 考虑一个电子邮件服务的案例，这里“Login”是一个包含的用例，必须运行它来发送电子邮件(基本用例)

另一方面，“Exclude”是扩展基本用例的可选用例，基本用例即使不调用/调用扩展用例也可以成功运行。

如。 考虑“Laptop Purchase”作为基本用例，“Additional Warranty”作为扩展用例，在这里你可以运行基本用例“Laptop Purchase”，甚至不需要额外的保证。

还要注意UML版本:现在<<使用>>和<<包含>>已经很长时间了，已经被<<包括>>所取代，<<扩展>>由<<扩展>>和泛化。 对我来说，这往往是误导性的观点:例如Stephanie的帖子和链接是关于一个旧版本的:

在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。

事实上，除了“为物品付费”，没有其他选择!在现在的UML中，“货到付款”是一个扩展，“使用paypal支付”/“刷卡支付”是专门化的。

我经常用这个来记住这两点:

我的用例:我要去城市。

包括->驾驶汽车

Extends ->填充汽油

“加油”不一定总是被要求，但也可以根据车里剩余的汽油量来选择。“开车”是一个先决条件，所以我把它包括在内。

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

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

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

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

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

保持简单，傻瓜!!

这可能会引起争议，但“包含总是，扩展有时是”是一个非常常见的误解，现在几乎已经取代了事实上的含义。以下是一个正确的方法(在我看来，并与雅各布森、福勒、拉尔曼和其他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，而是基本用例必须能够在没有扩展用例的情况下工作。

总结

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