用例图中，“include”和“extend”的区别是什么？

也要注意UML版本：现在已经有很长时间没有使用<>和<>，而是用<>，<>用<>和generalization代替。对我来说，这通常是一个误导点：例如Stephanie的帖子和链接是关于旧版本的。
当支付物品时，您可以选择货到付款、使用PayPal支付或使用卡片支付。这些都是“支付物品”用例的替代方案。根据我的喜好，我可以选择任何一种选项。
实际上，“支付物品”并没有真正的替代品！在现今的UML中，“货到付款”是一种扩展，“使用PayPal支付”/“使用卡片支付”是特殊化。

“包含”用于扩展基本用例，是必须的条件，即包含的用例必须成功运行才能完成基本用例。
例如， 考虑电子邮件服务的情况，在这里，“登录”是一个包括在内的用例，必须运行才能发送电子邮件（基本用例）。
另一方面，“排除”是可选的用例，它扩展了基本用例，即使不调用扩展用例，基本用例也可以成功运行。
例如， 将“购买笔记本电脑”作为基本用例，“额外保修”作为扩展用例，您可以在没有购买额外保修的情况下运行基本用例“购买笔记本电脑”。

这里已经解释了两者之间的区别。但没有解释的是，根本不应该使用<<include>>和<<extend>>。
如果你读过Bittner/Spence，你就会知道用例是关于综合的，而不是分析。重用用例是无意义的。这清楚地表明你已经错误地切割了你的领域。附加值必须是独特的。我所知道的唯一附加值的重用是特许经营权。所以如果你在汉堡业务中，很好。但是在其他任何地方，你作为BA的任务是尝试找到一个USP。这必须在良好的用例中呈现出来。
每当我看到人们使用其中之一时，就是他们试图做功能分解。这是完全错误的。
简单来说：如果你可以毫不犹豫地回答你的老板“我已经完成了……”，那么“……”就是你的用例，因为你得到了钱。 （这也将清楚地表明“登录”根本不是用例。）
在这方面，找到自包含的用例，这些用例包括或扩展其他用例是非常不可能的。最终，你可以使用<<extend>>来显示你的系统的可选性，即某些许可模式允许包括一些用例或省略它们。但是除此之外 - 尽量避免使用它们。

我不建议使用这种方法来记住这两个词:

我的用例：我要去城市。

包括 -> 驾驶汽车

扩展 -> 加油

我更希望您使用以下内容： 我的用例：我要去城市。

扩展 -> 驾驶汽车

包括 -> 加油

被教导说，扩展关系将继续基类的行为。基类功能必须存在。 另一方面，包含关系类似于可以调用的函数。可能是加粗的。

这可以从 agilemodeling 重用用例模型中看到。

include 关系允许一个用例包含另一个用例的步骤。
例如，假设您拥有一个亚马逊账户并且想要查看订单，那么在未登录账户之前是不可能检查订单的。因此，事件流程如下...

扩展关系用于在用例的流程中添加额外步骤，通常是可选步骤...

假设我们仍在讨论您的亚马逊账户。基本情况是“订单”，扩展用例是“亚马逊Prime”。用户可以选择正常下单，或者选择亚马逊Prime，以更高的费用确保订单更快地到达。
请注意，用户不必选择亚马逊Prime，这只是一个选项，他们可以选择忽略此用例。

这是一个很好的资源，有很好的解释：

用例中包含什么？ 用例中的扩展是什么？

扩展用例通常定义可选行为。它与扩展用例无关

包含用于提取两个或多个用例的行为的共同部分

图表元素

• 角色：也称为角色。可以在其属性选项卡中更改角色的名称和类型。

• 继承：角色之间的精化关系。此关系可以携带名称和类型。

• 用例：这些可以有扩展点。

• 扩展点：这定义了可以添加扩展的位置。

• 关联：角色和用例之间的关联。给关联赋予易于理解的名称非常有用。

• 依赖：用例之间的依赖关系。依赖关系通常具有类型以更好地定义依赖关系的角色。要选择类型，请从图表或导航窗格中选择依赖关系，然后在属性选项卡中更改类型。有两种特殊类型的依赖关系：<<extend>> 和 <<include>>，Poseidon 提供了自己的按钮（见下文）。

• 扩展关系：两个用例之间的单向关系。用例 B 和用例 A 之间的扩展关系表示 B 的行为可以包含在 A 中。

• 包含关系：两个用例之间的单向关系。用例 A 和用例 B 之间的这种关系意味着 B 的行为始终包含在 A 中。

• 系统边框：系统边框实际上未在 Poseidon for UML 中作为模型元素实现。您可以简单地绘制一个矩形，将其发送到后台，并将其用作系统边框，将所有对应的用例放置在矩形内。

在IT技术领域，当你意识到你的用例变得过于复杂时，你可以使用“扩展（Extends）”来将复杂步骤提取出来作为自己的“扩展”用例。
当你在两个用例中看到相同的行为时，你可以使用“包含（Includes）”将这些公共行为抽象成一个单独的“抽象（Abstract）”用例。
（参考文献：Jeffrey L. Whitten，Lonnie D. Bentley，《系统分析与设计方法》，麦格劳-希尔/欧文出版社，2007年）

我喜欢把“包含”看作是基本用例的必要前提和附加条件。这意味着，在没有包含的用例的情况下，基本用例不能被视为完整。以电子商务网站销售商品为例，您无法在未选择商品并将其放入购物车之前支付商品。这意味着“支付商品”的用例包括“选择商品”。
“扩展”有不同的用途，但我喜欢把它看作是可选的替代方案。例如，在电子商务网站上，当支付商品时，您可以选择货到付款、使用Paypal付款或使用信用卡付款。这些都是“支付商品”用例的替代方案。我可以根据自己的喜好选择任何一种选项。
有关用例及其规则的更多详细信息，请参阅我的文章：

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

我记忆中的一种方法是通过视频游戏。例如，（以下不适用于所有情况，仅为用例示例）
扩展：主菜单扩展了一些功能，这意味着它们具有某些功能，但不一定需要按下。
包括：在视频游戏中开火必须先拥有武器。