这里已经解释了两者之间的区别。但没有解释的是，<<include>>和<<extend>>根本不应该被使用。

如果你读过Bittner/Spence，你就知道用例是关于综合的，而不是分析的。用例的重用是毫无意义的。它清楚地表明您已经错误地切割了您的域名。附加值本身必须是唯一的。我所知道的唯一附加值再利用方式就是特许经营。如果你是做汉堡生意的，很好。但在其他任何地方，你作为BA的任务是试图找到一个USP。这必须在良好的用例中呈现。

每当我看到人们使用其中一种关系时，都是在尝试进行功能分解的时候。这是完全错误的。

简单地说:如果你可以毫不犹豫地回答你的老板“我做了……”，那么“……”就是你的用例，因为你这样做得到了钱。(这也清楚地表明“登录”根本不是一个用例。)

在这方面，找到包含或扩展其他用例的独立用例是非常不可能的。最终，您可以使用<<extend>>来显示您的系统的可选性，即一些许可模式，它允许包含某些许可的用例或省略它们。但除此之外，就避免他们。

用例用于记录行为，例如回答这个问题。

一种行为延伸了另一种行为，如果它是行为的补充，但不一定是行为的一部分，例如研究答案。

还要注意的是，如果你不试图回答这个问题，研究答案也没有多大意义。

如果一个行为是包含行为的一部分，则该行为被包含在另一个行为中，例如登录到堆栈交换。

为了澄清，只有当你想在堆栈溢出中回答这个问题时，这个例子才成立。

这些是UML 2.5第671-672页的技术定义。

我强调了我认为重要的几点。

扩展

扩展是一个从扩展UseCase(扩展)到扩展UseCase (extendedCase)的关系 如何以及何时将扩展UseCase中定义的行为插入到扩展UseCase中定义的行为中。 扩展发生在扩展的UseCase中定义的一个或多个特定扩展点上。

当有一些额外的行为应该被添加到行为中时(可能是有条件的)使用Extend 定义在一个或多个用例中。

扩展的UseCase的定义独立于扩展的UseCase，并且具有独立于扩展的意义 UseCase。另一方面，扩展的UseCase通常定义了本身不一定有意义的行为。 相反，扩展的UseCase定义了一组模块化行为增量，以增加扩展UseCase的执行 在特定条件下。

...

包括

Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase (the includingCase). The including UseCase may depend on the changes produced by executing the included UseCase. The included UseCase must be available for the behavior of the including UseCase to be completely described.

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa.

...

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

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

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

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

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

保持简单，傻瓜!!

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

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

在我看来，这是:

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

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

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

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

让我们说清楚一点。每当我们想表达一种情况的存在依赖于另一种情况的存在时，我们就用包含。

例子:

用户只有登录账号后才能在网上购物。换句话说，在他登录自己的账户之前，他不能购物。

在材料被上传之前，用户不能从网站上下载。 所以，如果什么都没有上传，我就无法下载。

你明白了吗?

这是关于条件后果的。如果之前我没有这样做，我就不能这样做。

至少，我认为这是我们使用Include的正确方式。 我倾向于认为上面的笔记本电脑和保修的例子是最有说服力的!

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

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

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