在用例图中，包括和扩展之间有什么区别？
包括
扩展
当一个用例为另一个第一类用例增加步骤时，就使用扩展。
例如，假设"Withdraw Cash"是自动取款机（ATM）的用例。"Assess Fee"将扩展Withdraw Cash并描述条件"扩展点"，当ATM用户不在ATM所属机构办理银行业务时，它将被实例化。 请注意，基本的"Withdraw Cash"用例是独立的，不需要扩展。
包含是用来提取多个用例中*重复的用例片段的。 包含的用例不能独立存在，没有包含的用例，原用例就不完整。 这个方法应该少用，而且只在重复很严重并且是设计的（而不是巧合）的情况下使用。
例如，在每个ATM用例开始时发生的事件流（当用户放入他们的ATM卡，输入他们的密码，并显示主菜单时）将是一个很好的包含候选者。
这可能是有争议的，但 "包括总是，扩展有时 "是一个非常普遍的误解，现在几乎已经成为事实上的意思。 这里有一个正确的方法（在我看来，并与Jacobson、Fowler、Larmen和其他10个参考文献进行了核对）。
包含和扩展用例关系的关键是要认识到，与UML的其他部分相同，用例之间的虚线箭头是一种依赖关系。 我将使用术语 "基础"、"包括 "和 "扩展 "来指代用例的角色。
一个基本用例依赖于所包含的用例；没有它/它们，基本用例是不完整的，因为所包含的用例代表了交互的子序列，可能总是发生，也可能有时发生。(这与一个流行的误解相反，你的用例所建议的总是发生在主要场景中，有时发生在备用流程中，这仅仅取决于你选择什么作为你的主要场景；用例可以很容易地被重组，以代表一个不同的流程作为主要场景，这应该不重要）。)
在单向依赖的最佳实践中，基本用例知道（并引用）所包含的用例，但所包含的用例不应该 "知道 "基本用例。这就是为什么包含的用例可以是：a）本身就是基础用例，b）由一些基础用例共享。
扩展用例依赖于基础用例；它从字面上扩展了基础用例所描述的行为。 基础用例本身应该是一个功能齐全的用例（当然包括'include'），而不包括扩展用例的额外功能。
扩展用例可以在几种情况下使用。
1.基础用例代表了项目的 "必须 "功能，而扩展用例代表了可选的（应该/可能/想要）行为。 这就是术语optional的意义所在--optional是否构建/交付，而不是optional是否有时作为基本用例序列的一部分运行。 2.2.在第一阶段，你可以交付基本用例，满足当时的要求，第二阶段将增加扩展用例所描述的额外功能。这可以包含在第2阶段交付后总是或有时执行的序列（再次与流行的误解相反）。 3.它可以用来提取出基本用例的子序列，特别是当它们代表了具有其自身替代流程的 "特殊 "复杂行为时。
需要考虑的一个重要方面是，扩展用例可以在基本用例的流程中的几个地方 "插入 "行为，而不是像内含用例那样只在一个地方。 由于这个原因，一个扩展用例很可能不适合扩展一个以上的基础用例。
至于依赖性，扩展用例是依赖于基础用例的，而且还是单向依赖，即基础用例不需要在序列中对扩展用例进行任何引用。 这并不意味着你不能展示扩展点或在模板的其他地方添加扩展用例的X-ref，但基础用例必须能够在没有扩展用例的情况下工作。
我希望我已经表明，"包含总是，扩展有时 "的常见误解要么是错误的，要么充其量是简单化的。 如果你考虑到这个误解所带来的关于箭头方向性的所有问题，这个版本实际上更有意义--在正确的模型中，它只是依赖关系，如果你重构用例内容，它不会有潜在的变化。
我经常用这个来记住这两个人。
我的用例： 我要去城市。
包括-> 开车
伸出-> 加油
"加满汽油"。 并非在任何时候都需要，但可根据车内剩余的汽油量选择是否需要。 "驾驶汽车"。 是一个前提条件，因此我包括。
用例是用来记录行为的，如 回答这个问题。
[！[回答问题用例][1]][1]。
一个行为扩展了另一个行为，如果它是行为之外但不一定是行为的一部分，如 研究答案。
还要注意，如果你不是想回答问题，研究答案就没有多大意义。
[！[研究答案延伸][2]][2]。
如果一个行为是包括行为的一部分，那么它就被包含在另一个行为中，例如 登录到堆栈交换。
[！[登录堆栈交换包括][3]][3]。
澄清一下，只有当你想在这里用堆栈溢出回答时，这个说明才是正确的：）。)
这些是[UML 2.5][4]第671-672页的技术定义。
我强调了我认为重要的几点。
**我强调了我认为重要的几点。
*扩展是指从一个扩展的用例（扩展）到一个扩展的用例**（扩展的用例）的关系，该关系指定了 扩展用例中定义的行为如何以及何时可以插入到扩展用例中定义的行为中。 扩展发生在扩展的UseCase中定义的一个或多个特定扩展点。
*当有一些额外的行为应被添加到行为中时，可能是有条件地时，可以使用扩展。 在一个或多个用例中定义。
*扩展的用例独立于扩展的用例而定义，并且独立于扩展的用例而有意义。 UseCase。 另一方面，扩展的UseCase通常定义了本身不一定有意义的行为*。 相反，扩展的 UseCase 定义了一组模块化行为增量，这些行为增量增强了扩展的 UseCase 的执行。 在特定条件下
...
包括。
*包含是两个用例之间的定向关系，表明包含的用例（添加）的行为是的。 插入到包括UseCase（the includingCase）的行为中。 它也是一种NamedElement，所以它可以有一个 的上下文中的名称（includingCase）。 包含的 UseCase 可能取决于由以下原因产生的更改： 1. 执行所包含的UseCase。 包含的UseCase必须是可用的，以使包含的UseCase的行为能够被执行。 完全描述。
*当两个或多个 UseCases 的行为有共同部分时，可使用 Include 关系。 这种 然后，共同部分被提取到一个单独的UseCase中，以便被具有该共同部分的所有基本UseCase所包含。 由于 Include关系的主要用途是对通用部分的重用，在基UseCase中留下的内容通常不完整，在 本身是的，但依赖于所包含的部分才有意义。 这体现在关系的方向上，表明了 基准用例取决于加法，而不是反之。
[1]: http://i.stack.imgur.com/AJg4b.png [2]: http://i.stack.imgur.com/vvgPm.png [3]: http://i.stack.imgur.com/n2uqf.png [4]: http://www.omg.org/spec/UML/2.5/
我认为理解包括和延伸的意图很重要。
包含关系的目的是为了重用行为的模型。 由另一个用例，而扩展关系的目的是为了另一个用例。 将部分添加到现有的用例中以及用于模拟可选的系统服务"。 (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley，2004）。)
包含关系的目的是为了重用行为的模型。
由另一个用例，而扩展关系的目的是为了另一个用例。
将部分添加到现有的用例中以及用于模拟可选的系统服务"。 (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley，2004）。)
这在我看来是这样的。
Include = *重用功能（即： 包含的功能在系统的其他地方被使用或可以被使用）。) 因此，Include表示对另一个用例的依赖。<br />。
扩展=添加（而不是重用）功能和任何可选的功能。 因此，Extends可以表示两种情况之一。 <br />。
任何可选的用例（现有或没有）。
小结。 Include = 重用功能<br />。 扩展 = 新的和/或可选的功能
你最常看到的是extends的第2种用法（即 可选功能），因为如果功能不是可选的，那么大多数情况下，它是内置于用例本身的，而不是扩展。 至少我的经验是这样的'。 (Julian C指出，有时你会看到extends的第1种用法（即 (Julian C指出，有时你会看到extends的第1种用法(即添加新功能)，当一个项目进入它的第2个阶段)。
让我们把这个问题说得更清楚。 我们每次想表达一个案例的存在取决于另一个案例的存在时，都会使用include。
include
例子。
一个用户只有在登录了他的账户之后才能进行在线购物。 换句话说，他在登录账户之前不能进行任何购物。
在资料还没有上传之前，用户不能从网站下载。 所以，如果没有上传任何东西，我就不能下载。
你明白了吗？
这就是条件性的后果。 如果之前我没有'不做那件事，我就不能做这个。
至少，我认为这是我们使用Include的正确方式。 我倾向于认为上面右边的Laptop和保修的例子是最有说服力的!
Include
为了简化：
对于 "include"，
基础用例需要完成包含的用例才能完成。
一个典型的例子。 在登录和验证密码之间
(登录) --- << 包括>>。 ---> (验证密码)
为了使登录过程成功，"验证密码"。 也必须成功。
为 "延长"。
只有满足某些标准时，扩展用例才会发生。
一个典型的例子。 在登录和显示错误信息之间(有时才会发生)
登录）<------<< 延长<>>.--（显示错误信息）。 --- (显示错误信息)
"显示错误信息"。 只有在登录过程失败时才会发生。
我认为msdn所解释的[这里][1]很容易理解。
包括[5]
包含的用例调用或调用包含的用例。 包含用于显示用例如何分解成更小的步骤。 包含的用例位于箭头末端。
扩展 [6]
同时，扩展用例为扩展用例增加了目标和步骤。 扩展用例只在一定条件下运行。 扩展用例在箭头端。
[！[在此输入图像描述][2]][2] 。
[1]: https://msdn.microsoft.com/en-us/library/dd409427.aspx [2]: https://i.stack.imgur.com/FDKqy.png
只要是有前提条件的用例，就可以选择包含。
对于有认证的用例，最坏的情况下，或者是可选的用例，则选择扩展。
例子：对于一个寻求入学、预约、订票的用例来说 你必须填写一个表格（注册或反馈表）....，这就是include的作用。
例如：对于一个验证登录或登录你的帐户的用例，你的认证是必须的。也要考虑最坏的情况，如退书时有罚款。
在图表中不要过度使用include和extend。
不要在图表中过多地使用include和extend，保持简单就好！！！。
另外，还要小心UML版本。 它'已经有很长一段时间了，<< 使用了>>.和<<。 和<< 包括>>.和<<。 已经被<<取代。 包括>>，以及<<。 扩展了>>。 改为<<。 extend >> 和泛化。 对我来说，那'往往是误导人的一点 。 作为一个例子Stephanie'的帖子和链接是关于一个旧版本 。 ＆gt。 当支付一个项目时，你可以选择货到付款，使用paypal支付或用卡支付。 这些都是"为商品付款".的替代方案。 用例的替代方案。 我可以根据自己的喜好选择其中任何一种方案。
事实上，并没有真正的替代品来代替"支付项目"。 ! 在现在的 UML 中，"pay on delivery" 是一个扩展，而"paypal"/"pay by card" 是专门化。
"Include"。 用于扩展基本用例，它是一个必须条件，即 包含的用例运行必须成功运行才能完成基础用例。
例如 考虑一个电子邮件服务的案例，这里"Login" 是一个包含的用例，必须运行它才能发送电子邮件（基础用例）。
"Exclude"。 另一方面是扩展基本用例的可选用例，即使不调用扩展用例，基本用例也可以成功运行。
例如 将"Laptop Purchase" 作为基础用例，并将"附加保修" 作为扩展用例，这里你可以运行基本用例"Laptop Purchase"。 即使不使用额外的保修服务，也可以运行基本用例"Laptop Purchase"。
这是一个很好的资源，有很好的解释。 [什么是包括在用例中？][1] [什么是用例的Extend？][2]
扩展用例通常定义了可选的行为。 它与扩展用例**无关。
包含用于提取两个或多个用例的行为的共同部分。
[1]: http://www.uml-diagrams.org/use-case-include.html [2]: http://www.uml-diagrams.org/use-case-extend.html
图表元素
演员。 也称为角色。 角色的名称和定型可以在属性标签中更改。
继承。 演员之间的细化关系。 这种关系可以携带一个名称和一个定型。
用例：可以有扩展点。 这些用例可以有扩展点。
扩展点：定义了可以添加扩展的位置。 这定义了可以添加扩展点的位置。
关联：在角色和用例之间。 角色和用例之间的关联。 给关联命名是很有用的。
依赖关系：在用例之间。 在用例之间。 依赖关系通常有一个定型，以更好地定义依赖关系的角色。 要选择一个定型，从图或导航窗格中选择依赖，然后在属性选项卡中更改定型。 有两种特殊类型的依赖关系。 <<extend>>和<<include>>，Poseidon为其提供了自己的按钮（见下文）。
<<extend>>
<<include>>
扩展关系。 扩展关系：两个用例之间的单向关系。 用例 B 和用例 A 之间的扩展关系意味着 B 的行为可以包含在 A 中。
包含关系：两个用例之间的单向关系。 包含关系：两个用例之间的单向关系。 用例 A 和 B 之间的这种关系意味着 B 的行为总是包含在 A 中。
系统边界。 系统边框：其实在 Poseidon for UML 中，系统边框并不是作为模型元素实现的。 你可以简单地画一个矩形，把它送到后台，并通过把所有对应的用例放在矩形内作为系统边界。
<include>和<extension>都依赖于基类，但<extension>是可选的，也就是说，它是从基类中派生出来的，但从用户的角度来看，它可以被使用，也可以不被使用。
<include>
<extension>
<include>是包含在基类中的，也就是说，在你的用例中必须使用<include>，否则会被认为是不完整的。
eg:
在ATM机建设中（根据用户的角度）。
1: 取款、存钱、查账属于""，因为取款、存钱还是查账取决于用户。 这些都是用户可选择的事情。
2: "输入密码，放卡，取卡"。 这些都是属于<include>的事情，因为用户必须，也应该放置卡片，并输入有效的pin进行验证。
当你了解到你的用例过于复杂时，就会使用扩展。 所以你将复杂的步骤提取到自己的"扩展"。 的用例中。
包含用于在两个用例中看到共同行为时。 所以你把共同的行为抽象成一个单独的"abstract".用例。 用例中。
(参考文献：Jeffrey L． Jeffrey L. Whitten, Lonnie D. Whitten，Lonnie D． Bentley，系统分析&。 设计方法，McGraw-Hill/Irwin，2007）。)
我不建议用这个来记住这两个人。
我的用例： 我要去这个城市。
我宁愿你用。 我的用例。 我要去城里。
延伸出-> 开车
包括-> 加油
据悉，扩展关系延续了基类的行为。 基类的功能必须存在。 而include关系则类似于可以调用的函数。 May是用粗体字表示的。
这可以从 敏捷建模在用例模型中的重用</a>。
include关系允许一个用例包含另一个用例的步骤。
例如，假设你有一个亚马逊账户，你想检查一个订单，好吧，如果不先登录你的账户，是不可能检查订单的。 所以事件的流程是这样的......
！[在此输入图片描述][1]。
extend关系用于在用例的流程中增加一个额外的步骤，这通常是一个可选的步骤......。
想象一下，我们仍然在谈论你的亚马逊账户。 让我们假设基础案例是Order，扩展用例是Amazon Prime。 用户可以选择只是定期订购商品，或者，用户可以选择选择Amazon Prime，以确保他的订单以更高的成本更快地到达。
但是，请注意，用户不必选择Amazon Prime，这只是一个选项，他们可以选择忽略这个用例。
1:
[2]: https://i.stack.imgur.com/CI6Ll.jpg
这里已经解释了两者之间的区别。 但没有解释的是，<<include>>和<<extension>>根本就不应该使用。
<<extension>>
如果你读过Bittner/Spence，你就知道用例是关于综合的，而不是分析的。 重用用例是无稽之谈。 它清楚地表明，你已经错误地切割了你的领域。 附加价值本身必须是独一无二的。 我所知道的唯一重复使用附加价值的是特许经营。 所以如果你是做汉堡生意的，不错。 但在其他地方，作为BA，你的任务是尽量找到一个USP。 而这必须用好的用例来呈现。
每当我看到人们使用这些关系之一时，就是他们试图做功能分解的时候。 而这'是完全错误的。
说得简单点。 如果你能毫不犹豫地回答你的老板"我已经做了... " 那么"..."。 就是你的用例，因为你做了就有了钱。 (这样也能明确"登录"。 根本就不是一个用例）。)
在这方面，找到自立的用例，包含或扩展其他用例的可能性很小。 最终你可以使用<<扩展>>来显示你的系统的可选性，即 一些许可模式允许包含一些许可的用例或省略它们。 但是，其他的--只是避免使用它们。
<<扩展>>
我喜欢把"包括"。 作为基本用例的必要前提/补充。 这意味着，如果没有它所包含的用例，基础用例就不能被认为是完整的。 我举一个向客户销售商品的电子商务网站的例子。 如果不先选择一个商品并将其放入购物车，就无法为该商品付款。 这意味着用例"为项目付款"。 包括"选择项目"。
扩展有不同的用法，但我喜欢把它看作是一种可能使用也可能不使用的替代方案。 例如--还是在电子商务网站上。 当为一个项目付款时，你可以选择货到付款，使用paypal付款或用卡付款。 这些都是"为商品付款"的替代方案。 用例的替代方案。 我可以根据自己的喜好选择这些选项中的任何一个。
要了解更多关于用例的规则，请阅读我在这里的文章。
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
当一个用例为另一个第一类用例增加步骤时，就使用扩展。
例如，假设"Withdraw Cash"是自动取款机（ATM）的用例。"Assess Fee"将扩展Withdraw Cash并描述条件"扩展点"，当ATM用户不在ATM所属机构办理银行业务时，它将被实例化。 请注意，基本的"Withdraw Cash"用例是独立的，不需要扩展。
包含是用来提取多个用例中*重复的用例片段的。 包含的用例不能独立存在，没有包含的用例，原用例就不完整。 这个方法应该少用，而且只在重复很严重并且是设计的（而不是巧合）的情况下使用。
例如，在每个ATM用例开始时发生的事件流（当用户放入他们的ATM卡，输入他们的密码，并显示主菜单时）将是一个很好的包含候选者。
这可能是有争议的，但 "包括总是，扩展有时 "是一个非常普遍的误解，现在几乎已经成为事实上的意思。 这里有一个正确的方法（在我看来，并与Jacobson、Fowler、Larmen和其他10个参考文献进行了核对）。
关系是依赖关系
包含和扩展用例关系的关键是要认识到，与UML的其他部分相同，用例之间的虚线箭头是一种依赖关系。 我将使用术语 "基础"、"包括 "和 "扩展 "来指代用例的角色。
包括
一个基本用例依赖于所包含的用例；没有它/它们，基本用例是不完整的，因为所包含的用例代表了交互的子序列，可能总是发生，也可能有时发生。(这与一个流行的误解相反，你的用例所建议的总是发生在主要场景中，有时发生在备用流程中，这仅仅取决于你选择什么作为你的主要场景；用例可以很容易地被重组，以代表一个不同的流程作为主要场景，这应该不重要）。)
在单向依赖的最佳实践中，基本用例知道（并引用）所包含的用例，但所包含的用例不应该 "知道 "基本用例。这就是为什么包含的用例可以是：a）本身就是基础用例，b）由一些基础用例共享。
扩展
扩展用例依赖于基础用例；它从字面上扩展了基础用例所描述的行为。 基础用例本身应该是一个功能齐全的用例（当然包括'include'），而不包括扩展用例的额外功能。
扩展用例可以在几种情况下使用。
1.基础用例代表了项目的 "必须 "功能，而扩展用例代表了可选的（应该/可能/想要）行为。 这就是术语optional的意义所在--optional是否构建/交付，而不是optional是否有时作为基本用例序列的一部分运行。 2.2.在第一阶段，你可以交付基本用例，满足当时的要求，第二阶段将增加扩展用例所描述的额外功能。这可以包含在第2阶段交付后总是或有时执行的序列（再次与流行的误解相反）。 3.它可以用来提取出基本用例的子序列，特别是当它们代表了具有其自身替代流程的 "特殊 "复杂行为时。
需要考虑的一个重要方面是，扩展用例可以在基本用例的流程中的几个地方 "插入 "行为，而不是像内含用例那样只在一个地方。 由于这个原因，一个扩展用例很可能不适合扩展一个以上的基础用例。
至于依赖性，扩展用例是依赖于基础用例的，而且还是单向依赖，即基础用例不需要在序列中对扩展用例进行任何引用。 这并不意味着你不能展示扩展点或在模板的其他地方添加扩展用例的X-ref，但基础用例必须能够在没有扩展用例的情况下工作。
SUMMARY
我希望我已经表明，"包含总是，扩展有时 "的常见误解要么是错误的，要么充其量是简单化的。 如果你考虑到这个误解所带来的关于箭头方向性的所有问题，这个版本实际上更有意义--在正确的模型中，它只是依赖关系，如果你重构用例内容，它不会有潜在的变化。
我经常用这个来记住这两个人。
我的用例： 我要去城市。
包括-> 开车
伸出-> 加油
"加满汽油"。 并非在任何时候都需要，但可根据车内剩余的汽油量选择是否需要。 "驾驶汽车"。 是一个前提条件，因此我包括。
用例是用来记录行为的，如 回答这个问题。
[！[回答问题用例][1]][1]。
一个行为扩展了另一个行为，如果它是行为之外但不一定是行为的一部分，如 研究答案。
还要注意，如果你不是想回答问题，研究答案就没有多大意义。
[！[研究答案延伸][2]][2]。
如果一个行为是包括行为的一部分，那么它就被包含在另一个行为中，例如 登录到堆栈交换。
[！[登录堆栈交换包括][3]][3]。
澄清一下，只有当你想在这里用堆栈溢出回答时，这个说明才是正确的：）。)
这些是[UML 2.5][4]第671-672页的技术定义。
我强调了我认为重要的几点。
**我强调了我认为重要的几点。
*扩展是指从一个扩展的用例（扩展）到一个扩展的用例**（扩展的用例）的关系，该关系指定了 扩展用例中定义的行为如何以及何时可以插入到扩展用例中定义的行为中。 扩展发生在扩展的UseCase中定义的一个或多个特定扩展点。
*当有一些额外的行为应被添加到行为中时，可能是有条件地时，可以使用扩展。 在一个或多个用例中定义。
*扩展的用例独立于扩展的用例而定义，并且独立于扩展的用例而有意义。 UseCase。 另一方面，扩展的UseCase通常定义了本身不一定有意义的行为*。 相反，扩展的 UseCase 定义了一组模块化行为增量，这些行为增量增强了扩展的 UseCase 的执行。 在特定条件下
...
包括。
*包含是两个用例之间的定向关系，表明包含的用例（添加）的行为是的。 插入到包括UseCase（the includingCase）的行为中。 它也是一种NamedElement，所以它可以有一个 的上下文中的名称（includingCase）。 包含的 UseCase 可能取决于由以下原因产生的更改： 1. 执行所包含的UseCase。 包含的UseCase必须是可用的，以使包含的UseCase的行为能够被执行。 完全描述。
*当两个或多个 UseCases 的行为有共同部分时，可使用 Include 关系。 这种 然后，共同部分被提取到一个单独的UseCase中，以便被具有该共同部分的所有基本UseCase所包含。 由于 Include关系的主要用途是对通用部分的重用，在基UseCase中留下的内容通常不完整，在 本身是的，但依赖于所包含的部分才有意义。 这体现在关系的方向上，表明了 基准用例取决于加法，而不是反之。
...
[1]: http://i.stack.imgur.com/AJg4b.png [2]: http://i.stack.imgur.com/vvgPm.png [3]: http://i.stack.imgur.com/n2uqf.png [4]: http://www.omg.org/spec/UML/2.5/
我认为理解包括和延伸的意图很重要。
这在我看来是这样的。
Include = *重用功能（即： 包含的功能在系统的其他地方被使用或可以被使用）。) 因此，Include表示对另一个用例的依赖。<br />。
扩展=添加（而不是重用）功能和任何可选的功能。 因此，Extends可以表示两种情况之一。 <br />。
任何可选的用例（现有或没有）。
小结。
Include = 重用功能<br />。 扩展 = 新的和/或可选的功能
你最常看到的是extends的第2种用法（即 可选功能），因为如果功能不是可选的，那么大多数情况下，它是内置于用例本身的，而不是扩展。 至少我的经验是这样的'。 (Julian C指出，有时你会看到extends的第1种用法（即 (Julian C指出，有时你会看到extends的第1种用法(即添加新功能)，当一个项目进入它的第2个阶段)。
让我们把这个问题说得更清楚。 我们每次想表达一个案例的存在取决于另一个案例的存在时，都会使用
include。例子。
一个用户只有在登录了他的账户之后才能进行在线购物。 换句话说，他在登录账户之前不能进行任何购物。
在资料还没有上传之前，用户不能从网站下载。 所以，如果没有上传任何东西，我就不能下载。
你明白了吗？
这就是条件性的后果。 如果之前我没有'不做那件事，我就不能做这个。
至少，我认为这是我们使用
Include的正确方式。 我倾向于认为上面右边的Laptop和保修的例子是最有说服力的!为了简化：
对于 "include"，
基础用例需要完成包含的用例才能完成。
一个典型的例子。 在登录和验证密码之间
(登录) --- << 包括>>。 ---> (验证密码)
为了使登录过程成功，"验证密码"。 也必须成功。
为 "延长"。
只有满足某些标准时，扩展用例才会发生。
一个典型的例子。 在登录和显示错误信息之间(有时才会发生)
登录）<------<< 延长<>>.--（显示错误信息）。 --- (显示错误信息)
"显示错误信息"。 只有在登录过程失败时才会发生。
我认为msdn所解释的[这里][1]很容易理解。
包括[5]
扩展 [6]
[！[在此输入图像描述][2]][2] 。
[1]: https://msdn.microsoft.com/en-us/library/dd409427.aspx [2]: https://i.stack.imgur.com/FDKqy.png
只要是有前提条件的用例，就可以选择包含。
对于有认证的用例，最坏的情况下，或者是可选的用例，则选择扩展。
例子：对于一个寻求入学、预约、订票的用例来说 你必须填写一个表格（注册或反馈表）....，这就是include的作用。
例如：对于一个验证登录或登录你的帐户的用例，你的认证是必须的。也要考虑最坏的情况，如退书时有罚款。
在图表中不要过度使用include和extend。
不要在图表中过多地使用include和extend，保持简单就好！！！。
另外，还要小心UML版本。 它'已经有很长一段时间了，<< 使用了>>.和<<。 和<< 包括>>.和<<。 已经被<<取代。 包括>>，以及<<。 扩展了>>。 改为<<。 extend >> 和泛化。 对我来说，那'往往是误导人的一点 。 作为一个例子Stephanie'的帖子和链接是关于一个旧版本 。 ＆gt。 当支付一个项目时，你可以选择货到付款，使用paypal支付或用卡支付。 这些都是"为商品付款".的替代方案。 用例的替代方案。 我可以根据自己的喜好选择其中任何一种方案。
事实上，并没有真正的替代品来代替"支付项目"。 ! 在现在的 UML 中，"pay on delivery" 是一个扩展，而"paypal"/"pay by card" 是专门化。
"Include"。 用于扩展基本用例，它是一个必须条件，即 包含的用例运行必须成功运行才能完成基础用例。
例如 考虑一个电子邮件服务的案例，这里"Login" 是一个包含的用例，必须运行它才能发送电子邮件（基础用例）。
"Exclude"。 另一方面是扩展基本用例的可选用例，即使不调用扩展用例，基本用例也可以成功运行。
例如 将"Laptop Purchase" 作为基础用例，并将"附加保修" 作为扩展用例，这里你可以运行基本用例"Laptop Purchase"。 即使不使用额外的保修服务，也可以运行基本用例"Laptop Purchase"。
这是一个很好的资源，有很好的解释。 [什么是包括在用例中？][1] [什么是用例的Extend？][2]
[1]: http://www.uml-diagrams.org/use-case-include.html [2]: http://www.uml-diagrams.org/use-case-extend.html
图表元素
演员。 也称为角色。 角色的名称和定型可以在属性标签中更改。
继承。 演员之间的细化关系。 这种关系可以携带一个名称和一个定型。
用例：可以有扩展点。 这些用例可以有扩展点。
扩展点：定义了可以添加扩展的位置。 这定义了可以添加扩展点的位置。
关联：在角色和用例之间。 角色和用例之间的关联。 给关联命名是很有用的。
依赖关系：在用例之间。 在用例之间。 依赖关系通常有一个定型，以更好地定义依赖关系的角色。 要选择一个定型，从图或导航窗格中选择依赖，然后在属性选项卡中更改定型。 有两种特殊类型的依赖关系。
<<extend>>和<<include>>，Poseidon为其提供了自己的按钮（见下文）。扩展关系。 扩展关系：两个用例之间的单向关系。 用例 B 和用例 A 之间的扩展关系意味着 B 的行为可以包含在 A 中。
包含关系：两个用例之间的单向关系。 包含关系：两个用例之间的单向关系。 用例 A 和 B 之间的这种关系意味着 B 的行为总是包含在 A 中。
系统边界。 系统边框：其实在 Poseidon for UML 中，系统边框并不是作为模型元素实现的。 你可以简单地画一个矩形，把它送到后台，并通过把所有对应的用例放在矩形内作为系统边界。
<include>和<extension>都依赖于基类，但<extension>是可选的，也就是说，它是从基类中派生出来的，但从用户的角度来看，它可以被使用，也可以不被使用。<include>是包含在基类中的，也就是说，在你的用例中必须使用<include>，否则会被认为是不完整的。eg:
在ATM机建设中（根据用户的角度）。
1: 取款、存钱、查账属于""，因为取款、存钱还是查账取决于用户。 这些都是用户可选择的事情。
2: "输入密码，放卡，取卡"。 这些都是属于
<include>的事情，因为用户必须，也应该放置卡片，并输入有效的pin进行验证。当你了解到你的用例过于复杂时，就会使用扩展。 所以你将复杂的步骤提取到自己的"扩展"。 的用例中。
包含用于在两个用例中看到共同行为时。 所以你把共同的行为抽象成一个单独的"abstract".用例。 用例中。
(参考文献：Jeffrey L． Jeffrey L. Whitten, Lonnie D. Whitten，Lonnie D． Bentley，系统分析&。 设计方法，McGraw-Hill/Irwin，2007）。)
我不建议用这个来记住这两个人。
我的用例： 我要去这个城市。
包括-> 开车
伸出-> 加油
我宁愿你用。 我的用例。 我要去城里。
延伸出-> 开车
包括-> 加油
据悉，扩展关系延续了基类的行为。 基类的功能必须存在。 而include关系则类似于可以调用的函数。 May是用粗体字表示的。
这可以从 敏捷建模在用例模型中的重用</a>。
include关系允许一个用例包含另一个用例的步骤。
例如，假设你有一个亚马逊账户，你想检查一个订单，好吧，如果不先登录你的账户，是不可能检查订单的。 所以事件的流程是这样的......
！[在此输入图片描述][1]。
extend关系用于在用例的流程中增加一个额外的步骤，这通常是一个可选的步骤......。
[！[在此输入图像描述][2]][2] 。
想象一下，我们仍然在谈论你的亚马逊账户。 让我们假设基础案例是Order，扩展用例是Amazon Prime。 用户可以选择只是定期订购商品，或者，用户可以选择选择Amazon Prime，以确保他的订单以更高的成本更快地到达。
但是，请注意，用户不必选择Amazon Prime，这只是一个选项，他们可以选择忽略这个用例。
1:
[2]: https://i.stack.imgur.com/CI6Ll.jpg
这里已经解释了两者之间的区别。 但没有解释的是，
<<include>>和<<extension>>根本就不应该使用。如果你读过Bittner/Spence，你就知道用例是关于综合的，而不是分析的。 重用用例是无稽之谈。 它清楚地表明，你已经错误地切割了你的领域。 附加价值本身必须是独一无二的。 我所知道的唯一重复使用附加价值的是特许经营。 所以如果你是做汉堡生意的，不错。 但在其他地方，作为BA，你的任务是尽量找到一个USP。 而这必须用好的用例来呈现。
每当我看到人们使用这些关系之一时，就是他们试图做功能分解的时候。 而这'是完全错误的。
说得简单点。 如果你能毫不犹豫地回答你的老板"我已经做了... " 那么"..."。 就是你的用例，因为你做了就有了钱。 (这样也能明确"登录"。 根本就不是一个用例）。)
在这方面，找到自立的用例，包含或扩展其他用例的可能性很小。 最终你可以使用
<<扩展>>来显示你的系统的可选性，即 一些许可模式允许包含一些许可的用例或省略它们。 但是，其他的--只是避免使用它们。我喜欢把"包括"。 作为基本用例的必要前提/补充。 这意味着，如果没有它所包含的用例，基础用例就不能被认为是完整的。 我举一个向客户销售商品的电子商务网站的例子。 如果不先选择一个商品并将其放入购物车，就无法为该商品付款。 这意味着用例"为项目付款"。 包括"选择项目"。
扩展有不同的用法，但我喜欢把它看作是一种可能使用也可能不使用的替代方案。 例如--还是在电子商务网站上。 当为一个项目付款时，你可以选择货到付款，使用paypal付款或用卡付款。 这些都是"为商品付款"的替代方案。 用例的替代方案。 我可以根据自己的喜好选择这些选项中的任何一个。
要了解更多关于用例的规则，请阅读我在这里的文章。
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics