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

include和extend在用例图中有什么区别？

Answer 1

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

例如，想象“提取现金”是ATM机的一个用例。 “评估费用”将扩展提取现金，并描述当ATM用户没有在ATM所属机构存款时实例化的有条件 “延伸点”。 注意，基本的“Withdraw Cash”用例是独立的，没有扩展名。

包含用于提取在多个用例中复制的用例碎片。 包含的用例不能单独存在，如果没有包含用例，原始用例也不完整。 这应该谨慎使用，只有在重复是重要的情况下，才能通过devise（而不是巧合）来存在。

例如，在每个ATM使用案例（当用户放入他们的ATM卡，input他们的PIN，并显示主菜单）开始时发生的事件stream将是包括的一个很好的候选者。

Answer 2

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

关系是依赖关系

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

包括

基本用例取决于所包含的用例; 没有它/基本用例是不完整的，因为所包含的用例代表了总是或有时可能发生的交互的子序列。 （这与这种stream行的误解是相反的，你的用例暗示总是在主要场景中发生，有时在替代stream程中发生，这取决于你select什么样的主要场景;用例可以很容易地重新构build来表示不同的stream程作为主要的情况，这不应该）。

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

延伸

扩展用例依赖于基本用例; 它从字面上扩展了基本用例描述的行为。 基本用例本身应该是一个function完整的用例（当然包括include），而不需要扩展用例的附加function。

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

1. 基本用例表示项目的“必须拥有”function，而扩展用例则表示可选（应该/可能/不想要）行为。 这是术语可选的地方是相关的 – 可select是否构build/传递，而不pipe它是否有时作为基本用例序列的一部分运行。
2. 在阶段1中，您可以提供满足当前需求的基本用例，阶段2将添加扩展用例所描述的附加function。 这可以包含在阶段2交付之后总是或者有时执行的序列（再次与stream行的误解相反）。
3. 它可以用来提取基本用例的子序列，尤其是当它们用自己的替代stream来表示“特殊”的复杂行为时。

需要考虑的一个重要方面是，扩展用例可以在基本用例的stream程中的多个位置“插入”行为，而不仅仅是作为一个包含用例的单一位置。 出于这个原因，扩展用例不太适合扩展一个以上的基本用例。

对于依赖关系，扩展用例依赖于基本用例，又是单向依赖关系，即基本用例不需要引用序列中的扩展用例。 这并不意味着你不能展示扩展点或者在模板的其他地方向扩展用例添加一个x-ref，但是基本用例必须能够在没有扩展用例的情况下工作。

概要

我希望我已经表明，“包括总是，有时延伸”这个常见的错误概念或者是错的，或者说是过于简单化。 如果你考虑所有关于箭头方向性的问题，这个版本实际上是更有意义的 – 错误概念呈现在正确的模型中，它只是依赖关系，如果你重构用例的内容，它不会改变。

Answer 3

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

我的用例：我要去城市。

包括 – >开车

延伸 – >填满汽油

“填充汽油”可能并不是必需的，但是可以根据汽车中剩余的汽油量select性地要求。 “开车”是我包括的一个先决条件。

Answer 4

用例用于logging行为，例如回答这个问题。

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

另外请注意，如果你不想回答这个问题，那么研究答案就没有什么意义。

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

为了澄清，说明只是如果你想在这里堆栈溢出回答:)。

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

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

扩展

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

当有一些额外的行为应该被添加， 可能有条件地添加到在一个或多个UseCases中定义的行为时，Extend被用于使用。

扩展的UseCase是独立于扩展的UseCase定义的，并且独立于扩展的UseCase 是有意义的 。 另一方面， 扩展的UseCase通常定义的行为本身可能不一定有意义 。 相反，扩展的UseCase定义了一组模块化行为增量，在特定条件下扩展了UseCase的执行。

…

包括

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

包含关系旨在用于两个或多个UseCases行为的公共部分。 然后这个公共部分被提取到一个单独的UseCase中，被包含在所有具有这个部分的基本UseCase中 。 由于包含关系的主要用途是重用通用部分，因此留在基本UseCase中的内容通常本身并不完整，但依赖于包含的部分是有意义的。 这反映在关系的方向上，表明基础UseCase取决于添加，但反之亦然。

…

Answer 5

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

“包含关系是为了重复使用 另一个用例build模的行为，而扩展关系是为了将部件添加到现有用例以及为 可选系统服务build模”（Overgaard和Palmkvist，用例：模式和蓝图。 – 韦斯利，2004年）。

这读作为：

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

扩展= 添加 （不重复使用）function和任何可选function。 因此，扩展可以表示两件事之一：
1.向用例添加新特性/function（可选或不可选）
2.任何可选用例（是否存在）。

概要：
包括=重用function
扩展=新的和/或可选的function

你会经常发现扩展的第二个用法（即可选的function），因为如果function不是可选的，那么大多数时候它是build立在用例本身上的，而不是作为扩展。 至less这是我的经验。 （Julian C指出，当项目进入第二阶段时，您有时会看到第一个用法（即添加新function））。

Answer 6

让我们更清楚一点。 每当我们想expression一个事例的存在取决于另一个事物的存在时，我们就使用include 。

例子：

用户只有在login账户后才能在网上购物。 其他人说，他login账户之前，不能做任何购物。

用户在上传资料之前无法从网站下载。 所以，如果没有上传，我不能下载。

你明白了吗？

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

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

Answer 7

我想在这里解释的msdn很容易理解。

包括 [5]

包括用例调用或调用包含的用例。 包含用于显示用例如何分解成更小的步骤。 包含的用例在箭头结尾。

延伸 [6]

同时，扩展用例增加了扩展用例的目标和步骤。 扩展只能在一定的条件下运行。 扩展用例在箭头结尾。

Answer 8

每当有一个用例的先决条件，然后去包含。

对于有身份validation的用户，最坏的情况下，或者是可选的，然后去扩展..

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

例如：对于validationlogin或login您的帐户的用例，您的身份validation是必须的。也考虑到最糟糕的情况。像返还书罚款..没有得到一个保留..支付法案后的date..这是在哪里延伸来玩…

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

保持简单的SILLY！

Answer 9

还要提防UML版本：现在已经很长一段时间了，<<用法>>和<<包含>>已经被<< include >>和<< extends >>所取代，被<< extends' 泛化 。
对我来说，这往往是误导的一点：作为一个例子，斯蒂芬妮的post和链接是关于一个旧版本：

当支付一个项目，你可以select支付交货，支付使用贝宝或卡支付。 这些都是“支付项目”用例的替代scheme。 我可以根据自己的喜好select这些选项中的任何一个。

事实上，没有什么可以替代“支付物品”！ 在现在的UML中，“交货付款”是一种延伸，“paypal paypal”/“pay by card”是专业化的。

Answer 10

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

例如，考虑一个电子邮件服务的情况，这里“login”是一个包含的用例，为了发送一个电子邮件（基本用例）

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

例如，考虑将“笔记本电脑购买”作为基本用例，将“附加保修”作为扩展用例，在这里您可以运行基本用例“笔记本电脑购买”，即使没有额外的保修。

Answer 11

这是很好的解释： 什么是包含在用例中？ 什么是扩展用例？

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

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

Answer 12

当你理解你的用例太复杂的时候使用Extends 。 因此，您将复杂的步骤提取到自己的“扩展”用例中。

当您在两个用例中看到常见行为时，将使用包含。 所以你把普通的行为抽象成一个单独的“抽象”用例。

（参考文献：Jeffrey L. Whitten，Lonnie D.Bentley，Systems analysis＆design methods，McGraw-Hill / Irwin，2007）

Answer 13

图元素

• 演员：也被称为angular色。 演员的姓名和刻板印象可以在其属性选项卡中更改。

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

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

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

• 关联：在angular色和用例之间。 给协会说话的名字是有用的。

• 依赖关系：在用例之间。 依赖往往有一个刻板印象，以更好地定义依赖的作用。 要select一个构造型，请从图表或导航窗格中select依赖项，然后在“属性”选项卡中更改构造型。 有两种特殊的依赖关系： <<extend>>和<<include>> ，为此，波塞冬提供自己的button（见下文）。

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

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

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

Answer 14

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

我的用例：我要去城市。

包括 – >开车

延伸 – >填满汽油

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

延伸 – >驾驶汽车

包括 – >填充汽油

我教导说，扩展关系延续了基类的行为。 基类function必须在那里。 另一方面，包含关系类似于可能被调用的函数。 五月大胆。

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

Answer 15

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

例如，假设您有一个亚马逊账户，并且您想要查看订单，那么在没有首先login您的账户的情况下不可能检查订单。 所以事件的stream动会这样…

扩展关系用于向用例的stream程添加额外的步骤，通常是可选的步骤…

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

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

Answer 16

<include>和<extend>都依赖于基类，但是<extend>是可选的，即它是从基类派生出来的，但是在用户观点上它可能被使用或者可能不被使用。

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

例如：

在ATM机的build设中（根据用户的观点）：

1：提款，存款和支票存入<extend>因为取决于用户是否提取或存款或支票。 这些是用户可选的东西。

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

Answer 17

我喜欢把“包含”作为基本用例的必要前提/伴随。 这意味着如果没有包含用例，基本用例就不能被认为是完整的。 我将举一个向客户销售物品的电子商务网站的例子。 如果没有先select商品并将其放入购物车，则无法支付商品。 这意味着用例“支付项目”包括“select项目”。

扩展有各种各样的用途，但是我想把它看作是可以或不可以使用的替代scheme。 例如 – 仍然在电子商务网站上。 当支付一个项目，你可以select支付交货，支付使用贝宝或卡支付。 这些都是“支付项目”用例的替代scheme。 我可以根据自己的喜好select这些选项中的任何一个。

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

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

Answer 18

这两者之间的差异已经在这里解释。 但是没有解释的是， <<include>>和<<extend>>根本就不应该被使用。

如果你阅读Bittner / Spence，你就知道用例是关于综合的，而不是分析。 用例的再利用是无稽之谈。 这清楚地表明你错误地切断了你的域名。 附加值本身必须是唯一的。 我知道唯一重用的附加值就是特许经营。 所以，如果你在汉堡生意，很好。 但是在其他任何地方，作为学士学位的任务是尝试find一个USP。 而且必须以良好的使用情况来呈现。

每当我看到人们使用这些关系之一时，他们试图进行function分解。 而这显然是错误的。

简单来说，如果你可以毫不犹豫地回答你的老板“我已经完成了…”，那么“…”就是你的用例，因为你有钱可以做到这一点。 （这也表明“login”根本不是一个用例。）

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