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

Question

use case diagram中 include 与 extend 有什么区别？

Answer 1

当用例将步骤添加到另一个第一类用例时，将使用

Extend 。

例如，想象“Withdraw Cash”是自动柜员机（ATM）的使用案例。 “评估费用”将延长提取现金并描述当ATM用户不在ATM所属机构存款时实例化的条件“扩展点”。请注意，基本的“Withdraw Cash”用例是独立的，没有扩展名。

包含用于在多个用例中提取重复的用例片段。包含的用例不能单独使用，如果没有包含的用例，原始用例就不完整。这应该谨慎使用，并且仅在重复很重要并且存在于设计中时（而不是巧合）。

例如，在每个ATM用例开始时（当用户放入他们的ATM卡，输入他们的PIN，并显示主菜单时）发生的事件流将是包含的良好候选者。

Answer 2

这可能是有争议的，但“包括总是有时延伸”是一种非常常见的错误观念，现在几乎已经被视为事实上的意义。这是一个正确的方法（在我看来，并检查雅各布森，福勒，拉门和其他10个参考文献）。

关系是依赖关系

包含和扩展用例关系的关键是要意识到，与UML的其余部分一样，用例之间的虚线箭头是依赖关系。我将使用术语“base”，“included”和“extends”来引用用例角色。

包括

基本用例取决于所包含的用例;没有它/他们基本用例是不完整的，因为所包含的用例表示可能总是或有时发生的交互的子序列。 （这与流行的误解相反，你的用例建议总是发生在主要场景中，有时候在备用流程中发生只取决于你选择什么作为主要场景;用例可以很容易地重组以代表不同的流程作为主要场景，这应该不重要）。

在单向依赖的最佳实践中，基本用例知道（并引用）包含的用例，但包含的用例不应该“知道”基本用例。这就是为什么包含的用例可以是：a）基本用例本身和b）由许多基本用例共享。

延伸

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

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

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

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

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

概要

我希望我已经表明，“包括总是，有时延伸”的常见误解是错误的，或者至多是简单的。如果您考虑误解所呈现的箭头方向性的所有问题，这个版本实际上更有意义 - 在正确的模型中它只是依赖性，并且如果您重构用例内容则不会发生变化。

Answer 3

我经常用它来记住这两个：

我的用例：我要去城里。

包括 - ＆gt;开车吗

延伸 - ＆gt;填充汽油

“可以根本不需要”加注汽油“，但可以根据汽车中剩余的汽油量进行选择。 “驾驶汽车”是一个先决条件因此我包括在内。

Answer 4

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

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

另请注意，如果您不想回答这个问题，研究答案并没有多大意义。

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

为了澄清，只有你想在堆栈溢出中回答这个问题才能说明这一点：）。

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

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

<强>扩展

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

当有一些额外行为应该添加到行为可能有条件时，可以使用 扩展 在一个或多个UseCases中定义。

扩展的UseCase 的定义与扩展的UseCase无关，与扩展无关 用例即可。另一方面，扩展UseCase 通常定义可能不一定有意义的行为。 相反，扩展的UseCase定义了一组模块化行为增量，增加了扩展UseCase的执行 在特定条件下。

... 的

<强>含

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

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

... 的

Answer 5

我认为理解包含和扩展的意图非常重要：

  

“包含关系旨在重用行为建模   通过另一个用例，而扩展关系是用于   将部分添加到现有用例以及以建模可选系统服务“（Overgaard和Palmkvist，用例：模式和蓝图.Addison- Wesley，2004）。

这告诉我：

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

扩展= 添加（不重用）功能， 任何可选功能。因此，延伸可以表示两件事之一：
1.将新的功能/功能添加到用例（可选或不可选）
2.任何可选用例（是否存在）。

总结：
包括=重用功能
Extends =新功能和/或可选功能

您最常见的是扩展的第二种用法（即可选功能），因为如果功能不是可选的，那么大多数时候它都内置在用例本身中，而不是扩展。至少那是我的经历。 （Julian C指出，当项目进入第二阶段时，您有时会看到扩展的第一次使用（即添加新功能）。）

Answer 6

让我们更清楚一点。每当我们想要表达一个案例的存在取决于另一个案例的存在这一事实时，我们就会使用include。

实施例

用户只有在登录帐户后才能在线购物。换句话说，在他登录帐户之前，他不能购物。

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

你明白了吗？

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

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

Answer 7

我认为msdn解释here非常容易理解。

包括 [5]

  

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

延期 [6]

  

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

Answer 8

为简化起见，

include

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

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

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

要成功完成登录过程，“验证密码”也必须成功。

---

extend

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

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

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

“显示错误消息”仅在登录过程失败时才会发生。

Answer 9

每当有用例的先决条件时，请转到include。

对于具有身份验证，最坏情况或可选的用例，然后去扩展..

例如：用于寻求入场，预约，预订机票的用例 你必须填写表格（注册或反馈表格）....这是包括来的地方..

示例：对于验证登录或登录您的帐户的用例，您的身份验证是必须的。也可以考虑最坏的情况。例如返回预订的罚款..没有预订..在截止日期后支付账单。这是延伸发挥作用的地方......

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

保持简单明了！

Answer 10

还要注意UML版本：现在已经很久了＆lt;＆lt;使用＆gt;＆gt;和＆lt;＆lt;包括＆gt;＆gt;已被＆lt;＆lt;＆lt;包括＆gt;＆gt;和＆lt;＆lt; extends＆gt;＆gt;通过＆lt;＆lt;延伸＆gt;＆gt;和概括。
对我来说，这通常是误导性的一点：作为一个例子，斯蒂芬妮的帖子和链接是关于一个旧版本：

  

在支付物品时，您可以选择付款，使用PayPal付款或通过卡付款。这些都是“物品付费”用例的替代品。我可以根据自己的喜好选择其中任何一种选择。

事实上，“为物品买单”没有其他选择！在现今的UML中，“付款交付”是一种延伸，“使用paypal支付”/“按卡支付”是专业化的。

Answer 11

“Include”用于扩展基本用例，它是必须条件，即包含用例运行必须成功运行才能完成基本用法。

e.g。 考虑一个电子邮件服务的案例，这里的“登录”是一个包含的用例，必须运行才能发送电子邮件（基本用例）

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

e.g。 将“笔记本电脑购买”视为基本用例，将“附加保修”视为扩展用例，此处您可以运行基本用例“笔记本电脑购买”，即使不需要额外保修。

Answer 12

这是一个很好的资源，有很好的解释： What is include at use case? What is Extend at use case?

  

扩展用例通常定义可选行为。它是独立扩展用例

     

包括用于提取两个或多个用例行为的常见部分

Answer 13

<include>和<extend>都依赖于基类，但<extend>是可选的，即它是从基类派生的，但在用户视图中它可以被使用或者可能不会被使用。

<include>包含在基类中，即在您的用例中使用<include>是强制性的，否则它将被视为不完整。

例如：

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

1：取款，存入现金和查看帐户都在<extend>下，因为这取决于用户是要提款还是存款或支票。这些是用户可选择的事情。

2：“输入引脚，放置卡片，移除卡片”这些是<include>下的内容，因为用户必须并且应该放置一张卡并输入有效的引脚进行验证。

Answer 14

当您了解您的用例过于复杂时，会使用

扩展。因此，您将复杂的步骤提取到他们自己的＆＃34;扩展＆＃34;用例。

当您在两个用例中看到常见行为时，会使用

包含。因此，您将常见行为抽象为一个单独的＆＃34;抽象＆＃34;用例。

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

Answer 15

我不建议使用它来记住这两个：

我的用例：我要去城里。

包括 - ＆gt;开车吗

延伸 - ＆gt;填充汽油

我宁愿你用： 我的用例：我要去城市。

延伸 - ＆gt;开车吗

包括 - ＆gt;填充汽油

我教过扩展关系继续基类的行为。基类功能必须在那里。 另一方面，包含关系类似于可以调用的函数。梅是粗体。

这可以从中看出 agilemodeling Reuse in Use-Case Models

Answer 16

图表元素

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

• 继承：演员之间的细化关系。这种关系可以带有名称和刻板印象。

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

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

• 关联：角色和用例之间。给关联者说名字很有用。

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

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

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

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

Answer 17

include 关系允许一个用例包含另一个用例的步骤。

例如，假设您拥有亚马逊帐户并且想要查看订单，那么在没有先登录您的帐户的情况下无法检查订单。所以事件的流程就是这样......

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

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

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

Answer 18

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

如果您阅读Bittner / Spence，您就会知道用例是关于综合，而不是分析。重复使用用例是无稽之谈。它清楚地表明你错误地削减了你的域名。附加值本身必须是唯一的。我知道唯一重新使用附加价值的是特许经营权。所以，如果你在汉堡生意，那很好。但在任何其他地方，你作为BA的任务是试图找到一个USP。这必须以良好的用例呈现。

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

简单地说：如果你能毫不犹豫地回答你的老板，那么我已经完成了......＆＃34;那么＆＃34; ...＆＃34;是你的用例，因为你有钱做这件事。 （这也将表明＆＃34;登录＆＃34;根本不是用例。）

在这方面，找到包含或扩展其他用例的自行用例是不太可能的。最终，您可以使用<<extend>>来显示系统的可选性，即某些许可模式允许包含某些许可的用例或省略它们。但是别的 - 只是避免它们。

Answer 19

我喜欢将“包含”视为基本用例的必要先决条件/伴奏。这意味着如果没有它包含的用例，基本用例就不能被认为是完整的。我将举例说明向客户销售商品的电子商务网站。如果没有先选择该项目并将其放入购物车，就无法支付项目费用。这意味着用例“支付项目”包括“选择项目”。

扩展有不同的用途，但我喜欢将其视为可能使用或不使用的替代方法。例如 - 仍然在电子商务网站上。在支付物品时，您可以选择付款，使用paypal付款或通过卡付款。这些都是“物品付费”用例的替代品。我可以根据自己的喜好选择其中任何一种选择。

为了更清晰和围绕用例的规则，请阅读我的文章：

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