用例图中的include和extend之间的区别是什么?
include
extend
当用例将步骤添加到另一个一级用例时使用扩展。
例如，假设“提取现金”是自动柜员机(ATM)的一个用例。“评估费用”将扩展提现并描述有条件的“扩展点”，该扩展点在ATM用户不在ATM的所属机构存钱时实例化。注意，基本的“Withdraw Cash”用例独立存在，没有扩展。
包括用于提取多个用例中复制的用例片段。被包含的用例不能独立存在，没有被包含的用例原始的用例是不完整的。这应该谨慎使用，并且只在重复很明显并且是故意存在(而不是巧合)的情况下使用。
例如，在每个ATM用例开始时发生的事件流(当用户放入他们的ATM卡，输入他们的PIN，并显示主菜单时)将是一个很好的包含候选。
这可能会引起争议，但“包含总是，扩展有时是”是一个非常常见的误解，现在几乎已经取代了事实上的含义。以下是一个正确的方法(在我看来，并与雅各布森、福勒、拉尔曼和其他10个参考文献进行了对比)。
包含和扩展用例关系的关键是要认识到，与UML的其余部分一样，用例之间的虚线箭头是一种依赖关系。我将使用术语“基本”、“包含”和“扩展”来指代用例角色。
基本用例依赖于所包含的用例;没有它/它们，基本用例是不完整的，因为所包含的用例表示可能总是或有时发生的交互的子序列。(这与流行的误解相反，你的用例所建议的总是发生在主场景中，有时发生在备用流中，这仅仅取决于你选择什么作为你的主场景;用例可以很容易地重新构造，以表示不同的流作为主要场景，这并不重要)。
在单向依赖的最佳实践中，基本用例知道(并引用)被包含的用例，但被包含的用例不应该“知道”基本用例。这就是为什么包含的用例可以是:a)它们自己的基本用例和b)由许多基本用例共享。
扩展用例依赖于基本用例;它从字面上扩展了基本用例所描述的行为。基本用例本身应该是一个完全功能的用例(当然包括了)，没有扩展用例的附加功能。
扩展用例可以在以下几种情况下使用:
需要考虑的一个重要方面是，扩展用例可以在基本用例流中的几个地方“插入”行为，而不是像被包含的用例那样只在一个地方插入。由于这个原因，扩展用例不太可能适合扩展多个基本用例。
至于依赖关系，扩展用例依赖于基本用例，同样是单向依赖，即基本用例不需要序列中任何对扩展用例的引用。这并不意味着您不能演示扩展点或在模板的其他地方向扩展用例添加x-ref，而是基本用例必须能够在没有扩展用例的情况下工作。
我希望我已经说明了“包含总是，扩展有时是”的常见误解要么是错误的，要么充其量是简单的。如果你考虑到误解所呈现的箭头方向的所有问题，这个版本实际上更有意义——在正确的模型中，它只是依赖关系，如果你重构用例内容，它不会潜在地改变。
当一个用例有先决条件时，就使用include。
对于有身份验证的用例，最坏的情况，或者是可选的，然后选择extend..
example:用于寻求入场、预约、订票的用例 您必须填写一份表格(注册或反馈表)....这就是include出现的地方..
例如:对于验证登录或登录您的帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。比如按时还书，没有预定，逾期付款，这就是延期发挥作用的地方。
不要在图中过度使用include和extend。
保持简单，傻瓜!!
图元素
演员:也称为角色。参与者的名称和原型可以在其Properties选项卡中更改。
继承:参与者之间的细化关系。这种关系可以携带一个名称和一个原型。
用例:这些用例可以有扩展点。
扩展点:这定义了可以添加扩展的位置。
关联:角色和用例之间的关联。给协会起名字是有用的。
依赖关系:用例之间。依赖项通常有一个构造型来更好地定义依赖项的角色。要选择一个原型，从图表或导航窗格中选择依赖项，然后在Properties选项卡中更改原型。有两种特殊类型的依赖:<<extend>>和<<include>>, Poseidon为它们提供了自己的按钮(见下文)。
<<extend>>
<<include>>
扩展关系:两个用例之间的单向关系。用例B和用例A之间的扩展关系意味着B的行为可以包含在A中。
包含关系:两个用例之间的单向关系。用例a和用例B之间的这种关系意味着，B的行为总是包含在a中。
系统边界:系统边界实际上不是在UML的Poseidon中作为模型元素实现的。您可以简单地绘制一个矩形，将其发送到后台，并将其作为系统边界，将所有相应的用例放在矩形中。
我认为理解includes和extends的意图很重要:
include关系是为重用行为建模的 另一个用例，而扩展关系用于 将部分添加到现有用例还有中，用于建模可选系统服务”(Overgaard和Palmkvist，用例:模式和蓝图。addison - wesley, 2004)。
这在我看来是:
Include = 重用的功能(即所包含的功能被使用或可以在系统的其他地方使用)。因此Include表示对另一个用例的依赖。
Extends = 添加(不重用)功能和也 any 可选功能。因此，Extends可以表示以下两种情况之一: 1. 将新特性/功能添加到用例(可选或不可选) 2. 任何可选用例(是否存在)
摘要: Include =功能重用 Extends =新的和/或可选功能
您将经常发现扩展的第二种用法(即可选功能)，因为如果功能不是可选的，那么大多数情况下它被内置到用例本身，而不是作为一个扩展。至少这是我的经验。(Julian C指出，当项目进入第二阶段时，你有时会看到扩展的第一次使用(即添加新功能)。
“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行以完成基本使用。
另一方面，“Exclude”是扩展基本用例的可选用例，基本用例即使不调用/调用扩展用例也可以成功运行。
让我们说清楚一点。每当我们想要表达一个case的存在依赖于另一个case的存在这一事实时，我们都会使用include。
例子:
用户只有登录账号后才能在网上购物。换句话说，在他登录自己的账户之前，他不能购物。
用户不能在材料上传之前从网站下载。 因此，如果没有上传任何内容，我就无法下载
你明白了吗?
这是关于条件后果的。如果之前我没有这样做，我就不能这样做。
Include
我喜欢把“包含”看作基本用例的必要前提/伴随。这意味着如果没有基本用例所包含的用例，就不能认为基本用例是完整的。我将给出一个向客户销售商品的电子商务网站的例子。如果不先选择商品并将其放入购物车，你就无法支付商品。这意味着用例“Pay for Item”包括“select Item”。
扩展的用途多种多样，但我喜欢将其视为一种可能使用也可能不使用的替代方法。例如，仍然在电子商务网站。在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。
想要更清楚地了解用例的规则，请阅读我的文章:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
也要注意UML版本:现在已经很长时间了<<使用>>和<<包括>>已被<<包括>>和<<& lt; & lt;扩展>>和泛化扩展>> 对我来说，这经常是误导性的观点:例如Stephanie的帖子和链接是关于一个旧版本:
在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。
事实上，除了“为物品付费”，没有其他选择!在现在的UML中，“货到付款”是一个扩展，“使用paypal支付”/“刷卡支付”是专门化的。
<include>和<extend>都依赖于基类，但<extend>是可选的，也就是说，它是从基类派生出来的，但在用户的角度来看，它可以被使用，也可以不被使用。
<include>
<extend>
<include>被合并到基类中，也就是说，在你的用例中必须使用<include>，否则它将被认为是不完整的。
例如:
在ATM机构造上(根据用户角度):
1:提现，存入现金和支票账户属于<extend>，因为它取决于用户是否提现或存入或支票。这些都是用户可以选择做的事情。
2:“输入pin，放置卡片，移除卡片”这些是在<include>下的事情，因为用户必须，也应该，放置卡片并输入有效的pin进行验证。
我经常用这个来记住这两点:
我的用例:我要去城市。
包括->驾驶汽车
Extends ->填充汽油
“加油”不一定总是被要求，但也可以根据车里剩余的汽油量来选择。“开车”是一个先决条件，所以我把它包括在内。
这是一个很好的资源，有很好的解释: 在用例中包含什么?< / > 什么是扩展用例? < / p >
扩展用例通常定义可选的行为。它是扩展用例的独立的 Include用于提取两个或多个用例的行为的公共部分
扩展用例通常定义可选的行为。它是扩展用例的独立的
Include用于提取两个或多个用例的行为的公共部分
我不建议用这个来记住这两点:
我宁愿你用: 我的用例:我要去城市。
Extends ->驾驶汽车
包括->加油
用例用于记录行为，例如回答这个问题。
一种行为延伸了另一种行为，如果它是行为的补充，但不一定是行为的一部分，例如研究答案。
还要注意的是，如果你不试图回答这个问题，研究答案也没有多大意义。
如果一个行为是包含行为的一部分，则该行为被包含在另一个行为中，例如登录到堆栈交换。
为了澄清，只有当你想在堆栈溢出中回答这个问题时，这个例子才成立。
这些是UML 2.5第671-672页中的技术定义。
我强调了我认为重要的几点。
扩展
Extend用于当有一些额外的行为需要添加到行为中，可能是有条件的
.．.
包括
Include是两个用例之间的直接关系，表明包括UseCase(加法)的行为是 插入到包含UseCase的行为中(包含case)。它也是NamedElement的一种，因此它可以有 在其所属UseCase(包括case)的上下文中使用名称。所包含的用例可能取决于所产生的更改 执行包含的UseCase。所包含的UseCase必须是可用的，以使所包含的UseCase的行为可用 完全描述。< / em > < / p > 当两个或多个UseCases的行为有共同部分时，Include关系将被使用。这 然后，公共部分被提取到一个单独的UseCase，由具有此部分的所有基本UseCase所包含。随着 Include关系的主要用途是重用公共部分，基本UseCase中的剩余部分通常是不完整的 本身，但取决于所包含的部分是否有意义。这体现在关系的方向上，说明了
这里已经解释了两者之间的区别。但是没有解释的是，<<include>>和<<extend>>根本不应该被使用。
如果你读过Bittner/Spence，你就知道用例是关于综合的，而不是分析的。用例的重用是毫无意义的。它清楚地表明您已经错误地切割了您的域名。附加值本身必须是唯一的。我所知道的唯一附加值再利用方式就是特许经营。如果你是做汉堡生意的，很好。但在其他任何地方，你作为BA的任务是试图找到一个USP。这必须在良好的用例中呈现。
每当我看到人们使用其中一种关系时，都是在尝试进行功能分解的时候。这是完全错误的。
简单地说:如果你可以毫不犹豫地回答你的老板“我做了……”，那么“……”就是你的用例，因为你这样做得到了钱。(这也清楚地表明“登录”根本不是一个用例。)
在这方面，找到包含或扩展其他用例的独立用例是非常不可能的。最终，你可以使用<<extend>>来显示你的系统的可选性，即一些许可模式，它允许包含一些许可的用例或省略它们。但除此之外，就避免他们。
当你明白你的用例太复杂时，使用扩展。因此，您将复杂的步骤提取到它们自己的“扩展”用例中。
当你在两个用例中看到相同的行为时使用包括。因此，您将常见的行为抽象到一个单独的“抽象”用例中。
(参考:Jeffrey L. Whitten, Lonnie D. Bentley，系统分析&设计方法，McGraw-Hill/Irwin, 2007)
我认为msdn解释的在这里很容易理解。
包括 [5]
包含用例调用或调用包含的用例。包含用于显示用例如何分解为更小的步骤。所包含的用例位于箭头末端。
扩展 [6]
同时，扩展用例将目标和步骤添加到扩展用例中。延期只在特定条件下生效。扩展用例位于箭头末端。
包括关系允许一个用例包含另一个用例的步骤。
例如，假设你有一个亚马逊账户，你想查看订单，如果不先登录你的账户，就不可能查看订单。所以事件的发展会这样。
扩展关系用于向用例流添加一个额外的步骤，这通常是一个可选步骤…
假设我们还在谈论你的亚马逊账户。假设基本用例是订单，扩展用例是Amazon Prime。用户可以选择定期订购商品，也可以选择亚马逊Prime，以确保他的订单以更高的成本更快到达。
但是，请注意，用户不必选择Amazon Prime，这只是一个选项，他们可以选择忽略这个用例。
为了简化,
对于include
一个典型的例子:在登录和验证密码之间
(登录)——<<包括>>——>(验证密码)
为了使登录过程成功，“验证密码”也必须成功。
对于extend
一个典型的例子:在登录和显示错误消息之间(只偶尔发生)
(login) & lt;—<<扩展>>—(显示错误信息)
“show error message”只在登录过程失败时才会出现。
扩展:主菜单扩展了一些功能，这意味着它们有一些功能，但不需要按下
包括:为了在电子游戏中开火，你必须先有一个武器。
