用例图include中和extend有什么区别？
问问题
744929 次
19 回答
294
当一个用例向另一个一流的用例添加步骤时使用 扩展。
例如，假设“提取现金”是自动柜员机 (ATM) 的一个用例。“Assess Fee”将扩展 Withdraw Cash 并描述当 ATM 用户不在 ATM 所属机构银行时实例化的条件“扩展点”。请注意，基本的“提取现金”用例独立存在，没有扩展。
包含用于提取在多个用例中重复的用例片段。包含的用例不能独立存在，没有包含的用例是不完整的。这应该谨慎使用，并且仅在重复很重要并且设计存在（而不是巧合）的情况下使用。
例如，在每个 ATM 用例开始时发生的事件流（当用户放入他们的 ATM 卡、输入他们的 PIN 并显示主菜单时）将是包含的一个很好的候选者。
于 2009-11-15T18:48:25.667 回答
131
这可能是有争议的，但“includes always and extends are”是一个非常普遍的误解，现在几乎已经成为事实上的含义。这是一个正确的方法（在我看来，并检查了 Jacobson、Fowler、Larmen 和其他 10 个参考资料）。
关系是依赖关系
包含和扩展用例关系的关键是要认识到，与 UML 的其余部分一样，用例之间的虚线箭头是依赖关系。我将使用术语“基础”、“包含”和“扩展”来指代用例角色。
包括
基本用例取决于包含的用例；没有它/它们，基本用例是不完整的，因为包含的用例代表了可能总是或有时发生的交互的子序列。（这与对此的普遍误解相反，您的用例建议总是发生在主要场景中，有时会发生在备用流程中，这完全取决于您选择的主要场景；用例可以轻松重组以表示不同的流程作为主要场景，这无关紧要）。
在单向依赖的最佳实践中，基本用例知道（并引用）包含的用例，但包含的用例不应该“知道”基本用例。这就是为什么包含的用例可以是：a）它们自己的基本用例和b）由许多基本用例共享。
延长
扩展用例依赖于基本用例；它从字面上扩展了基本用例描述的行为。基本用例本身应该是一个功能齐全的用例（当然包括“包含”），而没有扩展用例的附加功能。
扩展用例可用于多种情况：
- 基本用例代表项目的“必须具备”功能，而扩展用例代表可选（应该/可以/想要）行为。这就是术语 optional 相关的地方——是否构建/交付是可选的，而不是它是否有时作为基本用例序列的一部分运行是可选的。
- 在第 1 阶段，您可以交付满足当时要求的基本用例，第 2 阶段将添加扩展用例描述的附加功能。这可以包含在第 2 阶段交付之后总是或有时执行的序列（再次与流行的误解相反）。
- 它可用于提取基本用例的子序列，尤其是当它们用自己的替代流程表示“异常”复杂行为时。
需要考虑的一个重要方面是扩展用例可以在基本用例流程的多个位置“插入”行为，而不仅仅是在一个包含用例的地方。因此，扩展用例不太可能适合扩展多个基本用例。
至于依赖关系，扩展用例依赖于基本用例并且又是一种单向依赖，即基本用例不需要在序列中对扩展用例的任何引用。这并不意味着您不能演示扩展点或向模板中其他地方的扩展用例添加外部参照，但基本用例必须能够在没有扩展用例的情况下工作。
概括
我希望我已经证明了“包含总是，扩展有时是”的常见误解要么是错误的，要么充其量是简单化的。如果您考虑所有关于错误概念所呈现的箭头方向性的问题，这个版本实际上更有意义——在正确的模型中，它只是依赖关系，如果您重构用例内容，它不会潜在地改变。
于 2010-12-17T16:46:00.430 回答
101
我经常用这个来记住这两个：
我的用例：我要去城市。
包括 -> 开车
扩展 -> 加油
“加油”可能并不总是需要，但可以根据车内剩余的汽油量来选择需要。“开车”是先决条件，因此我也包括在内。
于 2013-07-03T13:01:29.253 回答
71
用例用于记录行为，例如回答这个问题。
如果一个行为是该行为的补充但不一定是该行为的一部分，则该行为会扩展另一个行为，例如研究答案。
另请注意，如果您不尝试回答问题，则研究答案没有多大意义。
如果一个行为是包含行为的一部分，则该行为被包含在另一个行为中，例如登录到堆栈交换。
澄清一下，只有当您想在堆栈溢出中回答时，该插图才是正确的:)。
这些是来自UML 2.5第 671-672 页的技术定义。
我强调了我认为重要的点。
扩展
扩展是从扩展用例（扩展）到扩展用例（扩展用例）的关系，它指定扩展用例中定义的行为如何以及何时可以插入到扩展用例中定义的行为中。扩展发生在扩展用例中定义的一个或多个特定扩展点。
当有一些额外的行为可能有条件地添加到一个或多个用例中定义的行为时，应使用扩展。
扩展的UseCase是独立于扩展的 UseCase 定义的，并且独立于扩展的 UseCase是有意义的。另一方面，扩展的 UseCase通常定义本身不一定有意义的行为。相反，扩展用例定义了一组模块化行为增量，这些增量在特定条件下增强了扩展用例的执行。
...
包括
Include是两个UseCase之间的DirectedRelationship，表示将被包含UseCase（加法）的行为插入到包含UseCase（includeCase）的行为中。它也是一种 NamedElement，因此它可以在其拥有的 UseCase（包括Case）的上下文中具有名称。包含用例可能取决于执行包含用例所产生的更改。包含的 UseCase 必须可用于包含 UseCase 的行为才能被完整描述。
当两个或多个 UseCases 的行为有共同部分时，应使用 Include 关系。然后将这个 公共部分提取到一个单独的 UseCase 中，以包含在所有具有该公共部分的基本 UseCases 中。由于 Include 关系的主要用途是重用公共部分，因此基本 UseCase 中剩余的内容通常本身并不完整，而是依赖于包含的部分才有意义。这反映在关系的方向上，表明基础 UseCase 依赖于加法，反之则不然。
...
于 2015-08-06T01:43:50.267 回答
49
为了简化，
为了include
- 执行基本用例时，包含的用例会执行EVERYTIME。
- 基本用例需要完成包含的用例才能完成。
一个典型的例子：登录和验证密码之间
(登录) --- << 包括 >> --- > (验证密码)
要使登录过程成功，“验证密码”也必须成功。
为了extend
- 执行基本用例时，仅执行扩展用例有时
- 仅当满足某些条件时才会发生扩展用例。
一个典型的例子：在登录和显示错误信息之间（只是有时会发生）
(登录) < --- << 扩展 >> --- (显示错误信息)
“显示错误消息”仅在登录过程失败时才会发生。
于 2018-07-16T18:21:14.440 回答
30
我认为了解包含和扩展的意图很重要：
“包含关系旨在重用由另一个用例建模的行为，而扩展关系旨在 将部分添加到现有用例以及为可选系统服务建模”（Overgaard 和 Palmkvist，用例：模式和蓝图。Addison -韦斯利，2004）。
这对我来说是：
Include =功能的重用（即所包含的功能已被使用或可以在系统的其他地方使用）。因此，包含表示对另一个用例的依赖。
扩展 =添加（不重用）功能以及任何可选功能。因此，扩展可以表示以下两种情况之一：
1. 向用例添加新特性/功能（可选与否）
2. 任何可选用例（现有与否）。
总结：
包括 = 功能的重用
扩展 = 新的和/或可选的功能
您通常会发现扩展的第二种用法（即可选功能），因为如果功能不是可选的，那么大多数情况下它是内置在用例本身中的，而不是作为扩展。至少这是我的经验。（Julian C 指出，当项目进入第二阶段时，您有时会看到扩展的第一次使用（即添加新功能）。）
于 2012-04-14T08:25:59.990 回答
19
我认为msdn在这里解释的很容易理解。
包括[5]
包含用例调用或调用包含的用例。包含用于显示用例如何分解为更小的步骤。包含的用例位于箭头末端。
扩展[6]
同时，扩展用例为扩展用例增加了目标和步骤。扩展仅在特定条件下运行。扩展用例位于箭头端。
于 2016-10-27T09:01:45.610 回答
15
让我们更清楚地说明这一点。我们include每次想表达一个案例的存在取决于另一个案例的存在这一事实时使用。
例子：
用户只有在登录帐户后才能在线购物。换句话说，在他登录他的帐户之前，他不能进行任何购物。
在材料上传之前，用户无法从站点下载。因此，如果没有上传任何内容，我将无法下载。
你明白吗？
这是关于条件后果的。如果以前我没有这样做，我就不能这样做。
至少，我认为这是我们使用Include. 我倾向于认为上面的笔记本电脑和保修的例子是最有说服力的！
于 2012-11-27T13:36:26.797 回答
9
每当有一个用例的先决条件时，就去包含。
对于具有身份验证的用例，最坏的情况，或者是可选的然后去扩展..
示例：对于寻求入场、预约、订票的用例，您必须填写表格（注册或反馈表）......这就是 include 的来源......
示例：对于验证登录或登录您的帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。比如罚款退回书..没有得到预订..在到期日之后支付账单..这是扩展在哪里发挥...
不要过度使用图表中的包含和扩展。
保持简单愚蠢！
于 2011-05-01T19:53:46.793 回答
8
两者<include>和<extend>都依赖于基类，但是<extend>是可选的，即它是从基类派生的，但从用户的角度来看，它可以使用也可以不使用。
<include>包含在基类中，即<include>在您的用例中强制使用，否则将被视为不完整。
例如：
在ATM机器构造中（根据用户的观点）：
1：提现、存入现金和查账属于提款、存入或查账，<extend>取决于用户取款、存入或查账。这些是用户做的可选的事情。
2：“输入密码，放置卡片，取出卡片”这些是<include>因为用户必须并且应该放置卡片并输入有效密码以进行验证的事情。
于 2013-05-05T02:31:20.460 回答
7
还要注意 UML 版本：很长时间以来，<<uses >> 和 << includes >> 已被 << include >> 取代，并且 << extends >> 被<< extend >> AND 泛化取代。
对我来说，这通常是误导点：例如，斯蒂芬妮的帖子和链接是关于旧版本的：
付款时，您可以选择货到付款、使用贝宝付款或刷卡付款。这些都是“为项目付费”用例的替代方案。我可以根据自己的喜好选择这些选项中的任何一个。
事实上，除了“支付项目”之外，别无选择！在当今的 UML 中，“货到付款”是一种扩展，而“使用贝宝付款”/“通过卡付款”是专门化的。
于 2013-03-21T14:02:14.363 回答
7
“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行才能完成基本使用。
例如，考虑一个电子邮件服务的案例，这里“登录”是一个包含的用例，必须运行它才能发送电子邮件（基本用例）
另一方面，“排除”是扩展基本用例的可选用例，即使不调用/调用扩展用例，基本用例也可以成功运行。
例如，将“笔记本电脑购买”作为基本用例，将“附加保修”作为扩展用例，在这里您可以运行基本用例“笔记本电脑购买”，即使没有额外保修。
于 2012-10-24T10:29:17.433 回答
4
图表元素
演员：也称为角色。演员的名称和原型可以在其属性选项卡中更改。
继承：细化参与者之间的关系。这种关系可以带有名称和刻板印象。
用例：这些可以有扩展点。
扩展点：这定义了可以添加扩展的位置。
关联：角色和用例之间。给协会命名是很有用的。
依赖关系：用例之间。依赖关系通常有一个刻板印象来更好地定义依赖关系的角色。要选择构造型，请从图表或导航窗格中选择依赖项，然后在“属性”选项卡中更改构造型。有两种特殊的依赖关系：
<<extend>>和<<include>>，波塞冬为此提供了自己的按钮（见下文）。扩展关系：两个用例之间的单向关系。用例 B 和用例 A 之间的扩展关系意味着 B 的行为可以包含在 A 中。
包含关系：两个用例之间的单向关系。用例 A 和 B 之间的这种关系意味着 B 的行为总是包含在 A 中。
系统边框：系统边框在 Poseidon for UML 中实际上并没有作为模型元素实现。您可以简单地绘制一个矩形，将其发送到背景并将其用作系统边框，方法是将所有相应的用例放在矩形内。
于 2012-01-19T06:19:06.450 回答
3
包含关系允许一个用例包含另一个用例的步骤。
例如，假设您有一个亚马逊账户并且想要查看订单，那么如果不先登录您的账户就不可能查看订单。所以事件的流程会这样......
扩展关系用于向用例流程添加一个额外的步骤，这通常是一个可选步骤...
想象一下，我们仍在谈论您的亚马逊帐户。让我们假设基本案例是Order而扩展用例是Amazon Prime。用户可以选择定期订购商品，或者用户可以选择亚马逊 Prime，以确保他的订单以更高的成本更快到达。
但是，请注意，用户不必选择 Amazon Prime，这只是一个选项，他们可以选择忽略此用例。
于 2017-04-15T00:46:32.613 回答
3
当您了解您的用例过于复杂时，会使用Extends 。因此，您将复杂的步骤提取到他们自己的“扩展”用例中。
当您在两个用例中看到常见行为时，使用包含。因此，您将常见行为抽象为一个单独的“抽象”用例。
（参考：Jeffrey L. Whitten、Lonnie D. Bentley，系统分析与设计方法，McGraw-Hill/Irwin，2007）
于 2015-12-11T15:39:08.063 回答
3
我不推荐使用这个来记住这两个：
我的用例：我要去城市。
包括 -> 开车
扩展 -> 加油
我宁愿你用：我的用例：我要去城里。
扩展 -> 驾驶汽车
包括 -> 加油
被教导扩展关系延续了基类的行为。基类功能必须在那里。另一方面，包含关系类似于可以调用的函数。五月是粗体。
这可以从 用例模型中的敏捷建模重用中看出
于 2015-07-23T06:38:34.810 回答
3
这里已经解释了两者之间的区别。但是没有解释的是根本不应该使用<<include>>的事实。<<extend>>
如果您阅读 Bittner/Spence，您就会知道用例是关于综合，而不是分析。重用用例是无稽之谈。它清楚地表明您错误地剪切了您的域。附加值本身必须是唯一的。我所知道的唯一对附加值的再利用是特许经营权。因此，如果您从事汉堡业务，那就太好了。但在其他任何地方，您作为 BA 的任务是尝试找到 USP。这必须在良好的用例中呈现。
每当我看到人们使用其中一种关系时，就是在他们尝试进行功能分解时。这是完全错误的。
简而言之：如果您可以毫不犹豫地回答您的老板“我已经完成...”，那么“...”就是您的用例，因为您有钱去做。（这也表明“登录”根本不是用例。）
在这方面，很难找到包含或扩展其他用例的独立用例。最终，您可以使用<<extend>>来显示系统的可选性，即一些许可模式，它允许包含某些许可的用例或省略它们。但除此之外 - 只是避免他们。
于 2015-10-23T20:13:10.473 回答
0
我喜欢将“包含”视为基本用例的必要先决条件/伴随。这意味着如果没有它包含的用例，基本用例就不能被认为是完整的。我将举一个向客户销售商品的电子商务网站的示例。如果不先选择该商品并将其放入购物车，您就无法为该商品付款。这意味着用例“支付项目”包括“选择项目”。
扩展有多种用途，但我喜欢将其视为可能使用或不使用的替代方案。例如 - 仍然在电子商务网站上。付款时，您可以选择货到付款、使用贝宝付款或刷卡付款。这些都是“为项目付费”用例的替代方案。我可以根据自己的喜好选择这些选项中的任何一个。
为了更清楚和围绕用例的规则，请在此处阅读我的文章：
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
于 2013-02-23T09:42:07.237 回答