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

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

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

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

<include>和<extend>都依赖于基类，但<extend>是可选的，也就是说，它是从基类派生的，但在用户的角度来看，它可以被使用，也可以不被使用。

<include>被合并到基类中，也就是说，在用例中必须使用<include>，否则它将被认为是不完整的。

eg:

在ATM机构造上(根据用户角度):

1:提现、存现、支票账户属于<extend>，因为它取决于用户是提现、存款还是支票。这些都是用户可以选择做的事情。

2:“输入pin，放置卡片，移除卡片”这些是在<包括>下的事情，因为用户必须，而且应该，放置卡片并输入有效的pin进行验证。

包含关系允许一个用例包含另一个用例的步骤。

例如，假设你有一个亚马逊账户，你想查看订单，如果不先登录你的账户，就不可能查看订单。所以事件的发展会这样。

扩展关系用于向用例流添加一个额外的步骤，这通常是一个可选的步骤…

假设我们还在谈论你的亚马逊账户。让我们假设基本用例是Order，扩展用例是Amazon Prime。用户可以选择定期订购商品，也可以选择亚马逊Prime，以确保他的订单以更高的成本更快到达。

但是，请注意，用户不必选择Amazon Prime，这只是一个选项，他们可以选择忽略这个用例。

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

总结

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

我认为理解includes和extends的意图很重要:

“包含关系旨在重用已建模的行为 通过另一个用例，而扩展关系是为 向现有的用例中添加部件，以及为可选的系统服务建模”(Overgaard和Palmkvist，用例:模式和蓝图。addison - wesley, 2004)。

在我看来，这是:

包含=功能的重用(即所包含的功能在系统的其他地方被使用或可能被使用)。因此Include表示对另一个用例的依赖。

Extends =添加(而不是重用)功能和任何可选功能。因此，Extends可以表示以下两种情况之一: 1. 向用例中添加新特性/功能(可选或非可选) 2. 任何可选的用例(是否存在)。

简介: 包含=功能的重用 Extends =新的和/或可选的功能

您将经常发现扩展的第二种用法(即可选功能)，因为如果功能不是可选的，那么大多数情况下它被内置到用例本身，而不是作为一个扩展。至少这是我的经验。(Julian C指出，当项目进入第二阶段时，你有时会看到扩展的第一次使用(即添加新功能)。

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

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

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