用例图中包含和扩展之间有什么区别？

是什么区别include，并extend在用例图？

当用例将步骤添加到另一个一流的用例时，将使用Extend。

例如，假设“取现”是自动柜员机（ATM）的用例。“评估费”将扩展“提取现金”并描述有条件的 “扩展点”，该条件在ATM用户未在ATM拥有机构上银行时实例化。请注意，基本的“提取现金”用例独立存在，没有扩展名。

Include用于提取在多个用例中重复的用例片段。附带的用例不能单独存在，没有附带的原始用例是不完整的。应当谨慎使用此功能，并且仅在重复很重要并且是设计使然存在（而不是巧合）的情况下使用。

例如，在每个ATM用例开始时发生的事件流（当用户放入其ATM卡，输入其PIN并显示主菜单时）将是一个不错的选择。

这可能是有争议的，但是“包含始终是，有时是扩展”是一种非常普遍的误解，实际上已经几乎取代了事实上的含义。这是一种正确的方法（我认为，并对照Jacobson，Fowler，Larmen和其他10个参考文献进行了检查）。

关系是依赖性

包含和扩展用例关系的关键是要认识到，与其他UML一样，用例之间的虚线箭头是依赖关系。我将使用术语“基础”，“包含”和“扩展”来指代用例角色。

包括

基本用例取决于所包含的用例。没有它/它们，基本用例是不完整的，因为所包含的用例代表了可能总是发生或有时发生的交互作用的子序列。（这与对此的普遍误解相反，用例建议总是在主场景中发生，有时在备用流程中发生，这仅取决于您选择的主场景；用例可以很容易地重组以表示不同的流程作为主要方案，这无关紧要）。

在一种方式依赖的最佳实践中，基本用例了解（并引用）了所包含的用例，但是所包含的用例不应“知道”基本用例。这就是为什么包含的用例可以是：a）自身拥有基本用例，以及b）由多个基本用例共享。

延伸

扩展用例取决于基本用例。它从字面上扩展了基本用例描述的行为。基本用例应本身就是一个功能齐全的用例（当然包括“包括”），而没有扩展用例的其他功能。

扩展用例可以在几种情况下使用：

1. 基本用例表示项目的“必须具有”功能，而扩展用例表示可选的（应该/可能/想要）行为。这是与术语“可选”相关的地方–是可选的是构建/交付，而不是可选的，有时它是否作为基本用例序列的一部分运行。
2. 在阶段1中，您可以交付满足当时要求的基本用例，而阶段2将添加扩展用例描述的其他功能。它可以包含在阶段2交付后始终执行或有时执行的序列（与流行的误解相反）。
3. 它可以用于提取基本用例的子序列，尤其是当它们用其自己的替代流程表示“异常”复杂行为时。

要考虑的一个重要方面是，扩展用例可以在基本用例流程的多个位置“插入”行为，而不仅仅是包含用例在单个位置。因此，扩展用例极不可能适合于扩展多个基本用例。

关于依赖关系，扩展用例依赖于基础用例，并且还是单向依赖关系，即基础用例不需要序列中对扩展用例的任何引用。这并不意味着您无法演示扩展点，也无法在模板中其他位置的扩展用例中添加外部参照，但是基本用例必须能够在没有扩展用例的情况下工作。

摘要

我希望我已经表明，普遍的误解是“总是包含，有时是扩展”，这是错误的，或者充其量只是简单化。如果您考虑到误解所带来的箭头方向性的所有问题，则此版本实际上更有意义–在正确的模型中，它只是依赖关系，如果重构用例内容则不会改变。

我经常用它来记住两个：

我的用例：我要去城市。

包括->开车

扩展->加油

并非始终需要“填充汽油”，但根据车内剩余的汽油量，可以选择“填充汽油”。因此，“驾车”是前提条件。

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

如果行为是行为的补充，但又不一定是行为的一部分，则它会扩展另一行为，例如研究答案。

还要注意，如果您不尝试回答问题，那么研究答案就没有多大意义。

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

为了澄清起见，仅当您想在堆栈溢出:)中回答时，插图才是正确的。

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

我强调了我认为的重点。

延伸

延伸是一种关系 从扩展UseCase（扩展）到扩展UseCase（扩展Case）的关系，它指定如何以及何时将扩展UseCase中定义的行为插入扩展UseCase中定义的行为。扩展发生在扩展UseCase中定义的一个或多个特定扩展点。

当需要在一个或多个UseCases中定义的行为中添加某些其他行为（可能有条件）时，可以使用Extend 。

所述扩展用例被独立地定义的延伸的用例，并且是独立地有意义延伸用例的。另一方面，扩展的UseCase通常定义本身不一定有意义的行为。而是，扩展UseCase定义了一组模块化行为增量，以增加在特定条件下扩展UseCase的执行。

...

包括

Include是两个UseCases之间的DirectedRelationship，指示将包含的UseCase（添加项）的行为插入到包含UseCase的行为中。它也是NamedElement的一种，因此它可以在其拥有的UseCase（包括includeCase）的上下文中具有名称。包含的UseCase可能取决于执行包含的UseCase所产生的更改。随附的UseCase必须是可用的，以便完整描述包含的UseCase的行为。

当两个或多个UseCases的行为存在共同部分时，可以使用Include关系。然后，将此 公共部分提取到一个单独的UseCase中，以供具有该部分公共的所有基本UseCases所包括。因为Include关系的主要用途是重用公共部分，所以基本UseCase所剩下的内容通常本身并不完整，而是取决于所包含的部分是否有意义。这反映在关系的方向上，表明基本UseCase依赖于添加项，反之亦然。

...

我认为了解包含和扩展的意图很重要：

“包含关系用于重用由另一个用例建模的行为，而扩展关系用于 向现有用例添加部件以及对可选系统服务进行建模”（Overgaard和Palmkvist，用例：模式和蓝图。Addison -Wesley，2004年。

这对我来说是：

包含= 功能的重用（即，所包含的功能已在系统中的其他地方使用或可以使用）。因此，包含表示对另一个用例的依赖。

延伸= 加入（未重用）功能和也任何可选功能。因此，扩展可以表示两件事之一：
1. 在用例中添加新功能（可选或不可选）
2.任何可选选用例（现有或不存在）。

摘要：
包含=功能重用
扩展=新功能和/或可选功能

您通常会发现扩展的第二种用法（即可选功能），因为如果功能不是可选的，那么大多数情况下它是内置在用例本身中的，而不是扩展。至少那是我的经验。（朱利安C指出，当项目进入第二阶段时，您有时会看到扩展的第一用法（即添加新功能））。

为了简化，

对于 include

1. 当执行基本用例时，包含的用例将在EVERYTIME执行。
2. 基本用例需要完成所包含的用例才能完成。

一个典型的例子：在登录和验证密码之间

（登录）--- <<包括>> --- >（验证密码）

为了使登录过程成功，“验证密码”也必须成功。

对于 extend

1. 当执行基本用例时，仅在某些时候执行扩展用例
2. 仅当满足某些条件时，才会发生扩展用例。

一个典型的示例：在登录和显示错误消息之间（仅有时发生）

（登录）< --- <<扩展>> ---（显示错误消息）

仅在登录过程失败时才出现“显示错误消息”。

我认为msdn 在这里解释的内容很容易理解。

包括 [5]

包含用例调用或调用包含的用例。包含用于显示用例如何分解为较小的步骤。随附的用例位于箭头末端。

扩展 [6]

同时，扩展用例为扩展用例增加了目标和步骤。这些扩展仅在某些条件下运行。扩展用例位于箭头末端。

让我们更清楚一点。我们include每次都想表达一个案例的存在取决于另一案例的存在这一事实。

例子：

用户只有登录帐户才能进行在线购物。换句话说，他必须先登录帐户才能购物。

在上载资料之前，用户无法从网站下载。因此，如果没有任何上传，我将无法下载。

你明白了吗？

这是关于条件后果的。如果我以前没做过我不能做这个。

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

只要有用例的先决条件，就可以包含。

对于具有身份验证的用例，最坏的情况，或者是可选的，然后进行扩展。

例如：对于寻求入场，预约，机票预订的用例，您必须填写一张表格（注册或反馈表格）。

例如：对于一个用于验证登录或登录帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。例如可以很好地退还书本。不能得到预订。延伸发挥作用的地方...

不要过度使用图中的包含和扩展。

保持简单愚蠢！

还要提防UML版本：很长一段时间以来，<<使用>>和<<包含>>被替换为<<包含>>，而<<扩展>>被<<扩展>>和泛化取代了。
对我来说，这通常是一个误导点：例如，斯蒂芬妮的帖子和链接是关于一个旧版本的：

付款时，您可以选择货到付款，使用贝宝（paypal）付款或通过卡付款。这些都是“按需购买”用例的替代方案。我可以根据自己的喜好选择任何这些选项。

实际上，除了“支付商品”之外，没有其他选择！在当今的UML中，“货到付款”是一种扩展，“用贝宝付款” /“用卡付款”是专业化的。

“包含”用于扩展基本用例，这是必须满足的条件，即必须成功运行包含用例才能完成基本用例。

例如，考虑电子邮件服务的情况，此处“登录”是包含的用例，必须运行该情况才能发送电子邮件（基本用例）

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

例如，以“笔记本电脑购买”为基本用例，以“附加保修”为扩展用例，在这里您可以运行基本用例“笔记本电脑购买”，甚至无需额外的保修。

这是一个很好的资源，并提供了很好的解释： 用例包括什么？ 什么是用例扩展？

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

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

图元素

• 演员：也称为角色。演员的名称和构造型可以在其“属性”选项卡中更改。

• 继承：演员之间的提炼关系。此关系可以带有名称和构造型。

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

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

• 关联：角色和用例之间。给协会讲名字很有用。

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

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

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

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

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

<include>包含在基类中，即<include>在您的用例中必须使用，否则将被认为是不完整的。

例如：

在ATM机构造中（根据用户的观点）：

1：提款，现金入金和支票帐户<extend>之所以出现，是因为它取决于用户是否要提取，存入或支票。这些是用户执行的可选操作。

2：“输入图钉，放置卡，取出卡”是发生这些事情的原因，<include>因为用户必须并且应该放置卡并输入有效的图钉进行验证。

我不建议使用此方法来记住两个：

我的用例：我要去城市。

包括->开车

扩展->加油

我希望您使用：我的用例：我要去城市。

延伸->开车

包括->加油

有人教导说扩展关系会延续基类的行为。基类功能必须存在。另一方面，包含关系类似于可以调用的功能。May以粗体显示。

这可以从用例模型中的敏捷建模重用中看出

两者之间的区别已在此处说明。但是没有解释的是根本不应该使用<<include>>并且<<extend>>根本不使用的事实。

如果您读过Bittner / Spence，就会知道用例是关于综合的，而不是分析。重用用例是胡说八道。它清楚地表明您错误地削减了域名。增值本身必须是唯一的。我所知道的唯一增值用途是特许经营。因此，如果您从事汉堡生意，那就太好了。但是，作为学士学位的其他任务是尝试找到USP。这必须在好的用例中提出。

每当我看到人们使用这些关系之一时，就是他们尝试进行功能分解的时候。这是完全错误的。

简而言之：如果您可以毫不犹豫地回答老板“我已经完成了……”，那么“ ...”就是您的用例，因为您有这样做的钱。（这也将清楚表明“登录”根本不是用例。）

在这方面，很难找到包含或扩展其他用例的独立用例。最终，您可以<<extend>>用来显示系统的可选性，即某些许可模式，该许可模式可以包括某些许可的用例，也可以忽略它们。但除此之外-避免它们。

当您了解用例过于复杂时，可以使用扩展。因此，您将复杂的步骤提取到自己的“扩展”用例中。

当您在两个用例中看到常见行为时，将使用Includes。因此，您可以将常见行为抽象为一个单独的“抽象”用例。

（参考：Jeffrey L. Whitten，Lonnie D. Bentley，系统分析与设计方法，McGraw-Hill / Irwin，2007年）

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

例如，假设您有一个亚马逊帐户，并且想要检查订单，那么如果不先登录帐户就无法检查订单。因此，事件的流向如此……

的延伸关系用于添加一个额外的步骤，以一个用例的流动，这通常是可选的步骤...

想象一下，我们仍在谈论您的亚马逊帐户。让我们假设基本情况是Order，扩展用例是Amazon Prime。用户可以选择仅定期订购商品，或者用户可以选择Amazon Prime，以确保其订单以更高的成本更快到达。

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

我喜欢将“包含”视为基本用例的必要前提条件。这意味着没有包含的用例就不能认为基本用例是完整的。我将举一个电子商务网站向客户出售商品的示例。如果没有先选择该项目并将其放入购物车，就无法为该项目付款。这意味着用例“为项目付款”包括“选择项目”。

扩展有多种用法，但我想将其视为可能会或可能不会使用的替代方法。例如-仍在电子商务网站上。付款时，您可以选择货到付款，使用贝宝（paypal）付款或通过卡付款。这些都是“按需购买”用例的替代方案。我可以根据自己的喜好选择任何这些选项。

为了更清楚地了解用例的规则，请在此处阅读我的文章：

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