在用例图中包含和扩展之间的区别是什么?
当前回答
当一个用例有先决条件时，就使用include。
对于有身份验证的用例，最坏的情况，或者是可选的，然后选择extend..
示例:用于寻求入场、预约、机票预订的用例 您必须填写一份表格(注册或反馈表)....这就是包容的由来。
例如:对于验证登录或登录您的帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。比如按时还书，没有预定，逾期付款，这就是延期发挥作用的地方。
不要在图中过度使用include和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用于提取两个或多个用例的行为的公共部分
还要注意UML版本:现在<<使用>>和<<包含>>已经很长时间了，已经被<<包括>>所取代，<<扩展>>由<<扩展>>和泛化。 对我来说，这往往是误导性的观点:例如Stephanie的帖子和链接是关于一个旧版本的:
在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。
事实上，除了“为物品付费”，没有其他选择!在现在的UML中，“货到付款”是一个扩展，“使用paypal支付”/“刷卡支付”是专门化的。
包含关系允许一个用例包含另一个用例的步骤。
例如，假设你有一个亚马逊账户，你想查看订单，如果不先登录你的账户，就不可能查看订单。所以事件的发展会这样。
扩展关系用于向用例流添加一个额外的步骤，这通常是一个可选的步骤…
假设我们还在谈论你的亚马逊账户。让我们假设基本用例是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，而是基本用例必须能够在没有扩展用例的情况下工作。
总结
我希望我已经说明了“包含总是，扩展有时是”的常见误解要么是错误的，要么充其量是简单的。如果你考虑到误解所呈现的箭头方向的所有问题，这个版本实际上更有意义——在正确的模型中，它只是依赖关系，如果你重构用例内容，它不会潜在地改变。
