use case diagram 中的 include 和 extend 有什么区别？
【问题讨论】：
标签： uml use-case rational-unified-process
Extend 在一个用例向另一个一流用例添加步骤时使用。
例如，假设“取款”是自动柜员机 (ATM) 的一个用例。 “Assess Fee”将扩展 Withdraw Cash 并描述当 ATM 用户不在 ATM 所属机构银行时实例化的条件“扩展点”。请注意，基本的“提取现金”用例独立存在，没有扩展。
Include 用于提取在多个用例中重复的用例片段。包含的用例不能独立存在，如果没有包含的用例，原始用例是不完整的。这应该谨慎使用，并且只有在重复很重要并且是设计（而不是巧合）存在的情况下才使用。
例如，在每个 ATM 用例开始时发生的事件流（当用户放入他们的 ATM 卡、输入他们的 PIN 并显示主菜单时）将是包含的一个很好的候选者。
【讨论】：
Include is used to extract use case fragments that are duplicated in multiple use cases，在这些步骤中提取了什么：puts in their ATM card, enters their PIN, and is shown the main menu？谢谢
这可能是有争议的，但“includes always are 并且 extends are有时”是一个非常普遍的误解，现在几乎已经成为事实上的含义。这是一个正确的方法（在我看来，并与 Jacobson、Fowler、Larmen 和其他 10 个参考文献进行了核对）。
包含和扩展用例关系的关键是要认识到，与 UML 的其余部分一样，用例之间的虚线箭头是依赖关系。我将使用术语“基础”、“包含”和“扩展”来指代用例角色。
基本用例取决于包含的用例；没有它/他们，基本用例是不完整的，因为包含的用例代表可能总是或有时发生的交互的子序列。 （这与对此的普遍误解相反，您的用例建议总是发生在主要场景中，有时会发生在备用流程中，这完全取决于您选择的主要场景；用例可以轻松重组以表示不同的流程作为主要场景，这无关紧要）。
在单向依赖的最佳实践中，基本用例知道（并引用）包含的用例，但包含的用例不应该“知道”基本用例。这就是为什么包含的用例可以是：a) 基本用例本身，b) 由多个基本用例共享。
扩展用例依赖于基本用例；它从字面上扩展了基本用例描述的行为。基本用例本身应该是一个功能齐全的用例（当然包括“包含”），而没有扩展用例的附加功能。
可在多种情况下使用扩展用例：
需要考虑的一个重要方面是，扩展用例可以在基本用例流程的多个位置“插入”行为，而不仅仅是包含用例那样的单个位置。因此，扩展用例不太可能适用于扩展多个基本用例。
关于依赖，扩展用例依赖于基本用例，又是一种单向依赖，即基本用例在序列中不需要对扩展用例的任何引用。这并不意味着您不能演示扩展点或向模板中其他地方的扩展用例添加外部参照，但基本用例必须能够在没有扩展用例的情况下工作。
我希望我已经证明了“包含总是，扩展有时是”的常见误解要么是错误的，要么充其量是简单化的。如果您考虑到误解所带来的所有关于箭头方向性的问题，这个版本实际上更有意义——在正确的模型中，它只是依赖关系，如果您重构用例内容，它不会潜在地改变。
【讨论】：
我经常用这个来记住这两个：
我的用例：我要去城市。
包括 -> 开车
延长 -> 加油
“加油”可能并非始终需要，但可以根据车内剩余的汽油量选择需要。 “开车”是先决条件，因此我也包括在内。
【讨论】：
用例用于记录行为，例如回答这个问题。
如果一个行为是该行为的补充但不一定是该行为的一部分，则该行为会扩展另一个行为，例如研究答案。
另请注意，如果您不尝试回答问题，则研究答案没有多大意义。
如果一个行为是包含行为的一部分，则该行为被包含在另一个行为中，例如登录堆栈交换。
为了澄清，只有当你想在这里回答堆栈溢出时，插图才成立:)。
这些是来自UML 2.5 第 671-672 页的技术定义。
我强调了我认为的重点。
扩展
扩展是从扩展用例（扩展）到扩展用例（扩展用例）的关系，它指定 扩展用例中定义的行为如何以及何时可以插入到扩展用例中定义的行为中。 扩展发生在扩展用例中定义的一个或多个特定扩展点。
Extend 旨在用于当有一些额外的行为可能有条件地添加到行为中时 在一个或多个用例中定义。
extended UseCase 独立于扩展 UseCase 定义，独立于扩展有意义 用例。另一方面，扩展用例通常定义本身不一定有意义的行为。 相反，扩展 UseCase 定义了一组模块化行为增量，这些增量增加了扩展 UseCase 的执行 在特定条件下。
...
包括
Include是两个UseCase之间的DirectedRelationship，表示被包含的UseCase（加法）的行为是 插入到包含UseCase（includeCase）的行为中。它也是一种 NamedElement，因此它可以有一个 在其拥有的用例（包括用例）的上下文中命名。包括 UseCase 可能取决于 执行包含的用例。包含的 UseCase 必须可用于包含 UseCase 的行为 完全描述。
包含关系旨在用于两个或多个用例的行为有共同部分的情况。这 然后将公共部分提取到一个单独的用例中，以包含在所有具有该部分共同的基本用例中。作为 Include 关系的主要用途是重用公共部分，基本 UseCase 中剩余的内容通常不完整 本身，但依赖于包含的部分才有意义。这反映在关系的方向上，表明 base UseCase 依赖于加法，反之则不然。
...
【讨论】：
为了简化，
为include
一个典型的例子：登录和验证密码之间
（登录）--- > --->（验证密码）
要使登录过程成功，“验证密码”也必须成功。
为extend
一个典型的例子：在登录和显示错误信息之间（只是偶尔发生）
（登录）--- > ---（显示错误信息）
“显示错误消息”仅在登录过程失败时才会出现。
【讨论】：
include 代表“需要”，而extend 代表“可能”
我认为理解包含和扩展的意图很重要：
“包含关系旨在重用行为建模 另一个用例，而扩展关系旨在 添加部分到现有用例以及用于建模可选系统服务”（Overgaard 和 Palmkvist，用例：模式和蓝图。Addison-韦斯利，2004）。
这对我来说是：
Include = 重用功能（即包含的功能已被使用或可以在系统的其他地方使用）。因此，包含表示对另一个用例的依赖。
扩展 = 添加（不重用）功能和也任何可选功能。因此，扩展可以表示以下两种情况之一：
1. 向用例添加新特性/功能（可选或不可选）
2. 任何可选用例（存在与否）。
总结：
包括 = 重用功能
扩展 = 新的和/或可选的功能
您通常会发现扩展的第二种用法（即可选功能），因为如果功能不是可选的，那么大多数情况下它是内置在用例本身中的，而不是作为扩展。至少这是我的经验。 （Julian C 指出，当项目进入第二阶段时，您有时会看到 extends 的第一个用法（即添加新功能）。
【讨论】：
我觉得msdn对here的解释很容易理解。
包括 [5]
包含用例调用或调用包含的用例。包含用于显示用例如何分解为更小的步骤。包含的用例位于箭头末端。
扩展 [6]
同时，扩展用例会为扩展用例添加目标和步骤。扩展仅在特定条件下运行。扩展用例在箭头末端。
【讨论】：
让我们更清楚地说明这一点。每当我们想表达一个案例的存在取决于另一个案例的存在这一事实时，我们都会使用include。
示例：
用户只有在登录帐户后才能在线购物。换句话说，在他登录帐户之前，他不能进行任何购物。
在材料上传之前，用户无法从网站下载。 因此，如果没有上传任何内容，我将无法下载。
你明白了吗？
这是关于条件结果的。 如果以前我没有这样做，我将无法这样做。
至少，我认为这是我们使用Include 的正确方式。
我倾向于认为上面的笔记本电脑和保修的例子是最有说服力的！
【讨论】：
只要有一个用例的先决条件，就去包含。
对于具有身份验证的用例，最坏的情况，或者是可选的然后去扩展..
示例：用于寻求入场、预约、订票的用例 您必须填写表格（注册表或反馈表）......这就是 include 的来源......
示例：对于验证登录或登录您的帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。例如罚款退还书..未获得预订..在到期日之后支付账单。 .这就是extend发挥作用的地方...
不要在图中过度使用包含和扩展。
保持简单愚蠢！！！
【讨论】：
<include> 和<extend> 都依赖于基类，但<extend> 是可选的，即它是从基类派生的，但从用户的角度来看，它可以使用也可以不使用。
<include> 包含在基类中，即在您的用例中必须使用<include>，否则将被视为不完整。
例如：
在ATM机构造中（根据用户的观点）：
1：提现、存入现金和查看账户都在<extend>下，因为这取决于用户是提现还是存款还是检查。这些是用户做的可选的事情。
2：“输入密码，放置卡片，取出卡片”这些是<include> 下的内容，因为用户必须并且应该放置卡片并输入有效密码以进行验证。
【讨论】：
“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行才能完成基本使用。
例如 考虑一个电子邮件服务的案例，这里的“登录”是一个包含的用例，必须运行它才能发送电子邮件（基本用例）
另一方面，“排除”是扩展基本用例的可选用例，即使不调用/调用扩展用例，基本用例也可以成功运行。
例如 考虑将“笔记本电脑购买”作为基本用例，将“附加保修”作为扩展用例，您可以在此处运行基本用例“笔记本电脑购买”，即使没有额外保修。
【讨论】：
Login 根本不是一个用例。这是为满足先决条件而执行的功能。
还要注意 UML 版本：很长时间以来，> 和 > 已被 > 取代，> 已被 > AND 泛化。
对我来说，这通常是一个误导点：例如，斯蒂芬妮的帖子和链接是关于旧版本的：
在为商品付款时，您可以选择货到付款、使用贝宝付款或刷卡付款。这些都是“为项目付费”用例的替代方案。我可以根据自己的喜好选择这些选项中的任何一个。
事实上，除了“为项目付费”之外，别无选择！在现在的UML中，“货到付款”是一种延伸，“paypal”/“pay by card”是专门化的。
【讨论】：
这是一个很好的资源，有很好的解释： What is include at use case? What is Extend at use case?
扩展用例通常定义可选行为。它独立于扩展用例
Include 用于提取两个或多个用例的行为的共同部分
【讨论】：
图表元素
演员：也称为角色。演员的名称和原型可以在其属性选项卡中更改。
继承：细化参与者之间的关系。这种关系可以带有名称和原型。
用例：这些可以有扩展点。
扩展点：这定义了可以添加扩展的位置。
关联：在角色和用例之间。给协会起名字很有用。
依赖关系：用例之间。依赖关系通常有一个刻板印象来更好地定义依赖关系的角色。要选择构造型，请从图表或导航窗格中选择依赖项，然后在“属性”选项卡中更改构造型。有两种特殊的依赖关系：<<extend>> 和 <<include>>，波塞冬为此提供了自己的按钮（见下文）。
扩展关系：两个用例之间的单向关系。用例 B 和用例 A 之间的扩展关系意味着 B 的行为可以包含在 A 中。
包含关系：两个用例之间的单向关系。用例 A 和 B 之间的这种关系意味着，B 的行为总是包含在 A 中。
系统边框：系统边框实际上并未作为 UML 的 Poseidon 中的模型元素实现。您可以简单地绘制一个矩形，将其发送到背景并将其用作系统边框，方法是将所有相应的用例放在矩形内。
【讨论】：
我不建议用这个来记住两者：
我的用例：我要去城市。
包括 -> 开车
延长 -> 加油
我宁愿你使用： 我的用例：我要去城市。
延伸 -> 驾驶汽车
包括 -> 加油
被教导扩展关系延续了基类的行为。基类功能必须在那里。 另一方面，包含关系类似于可以调用的函数。 May 为粗体。
【讨论】：
这里已经解释了两者之间的区别。但是没有解释的是<<include>>和<<extend>>根本不应该被使用。
如果您阅读 Bittner/Spence，您就会知道用例是关于综合，而不是分析。重用用例是无稽之谈。它清楚地表明您错误地剪切了您的域。附加值本身必须是唯一的。我所知道的唯一对附加值的再利用是特许经营权。因此，如果您从事汉堡业务，那就太好了。但在其他任何地方，您作为 BA 的任务是尝试找到 USP。这必须在良好的用例中呈现。
每当我看到人们使用其中一种关系时，就是在他们尝试进行功能分解时。这是完全错误的。
简单地说：如果你可以毫不犹豫地回答你的老板“我已经完成了......”，那么“......”就是你的用例，因为你有钱去做。 （这也表明“登录”根本不是用例。）
在这方面，很难找到包含或扩展其他用例的独立用例。最终，您可以使用<<extend>> 来显示系统的可选性，即允许包含某些许可证的用例或省略它们的一些许可模式。但除此之外 - 避免它们。
【讨论】：
Extends 在您了解您的用例过于复杂时使用。因此，您将复杂的步骤提取到它们自己的“扩展”用例中。
包含用于您在两个用例中看到常见行为。因此，您将常见行为抽象为一个单独的“抽象”用例。
（参考：Jeffrey L. Whitten、Lonnie D. Bentley，系统分析和设计方法，McGraw-Hill/Irwin，2007 年）
【讨论】：
【讨论】：
Amazon Prime 应该是什么样的用例？它甚至不包含动词。
我喜欢将“包含”视为基本用例的必要先决条件/伴随。这意味着如果没有它包含的用例，基本用例就不能被认为是完整的。我将举一个向客户销售商品的电子商务网站的示例。如果不先选择该商品并将其放入购物车，您就无法为该商品付款。这意味着用例“支付项目”包括“选择项目”。
extends 有多种用途，但我喜欢将其视为可能使用或不使用的替代方案。例如 - 仍然在电子商务网站上。付款时，您可以选择货到付款、使用贝宝付款或刷卡付款。这些都是“为项目付费”用例的替代方案。我可以根据自己的喜好选择这些选项中的任何一个。
为了更清楚和围绕用例的规则，请阅读我的文章：
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
【讨论】：
login 和 create 帐户都不是用例。两者都是函数。因此-1