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

Question

是什么区别include,并extend在用例图？

Answer 1

当用例将步骤添加到另一个一等用例时,使用Extend.

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

Include用于提取在多个用例中重复的用例片段.包含的用例不能单独使用,如果没有包含的用例,原始用例就不完整.这应该谨慎使用,并且仅在重复很重要并且存在于设计(而不是巧合)的情况下使用.

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

Answer 2

这可能是有争议的,但"包括总是和延伸有时"是一种非常常见的误解,现在几乎已经被视为事实上的意义.这是一个正确的方法(在我看来,并检查雅各布森,福勒,拉门和其他10个参考).

关系是依赖关系

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

包括

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

在依赖基本用例的一种方法最好的做法知道(并指)所包含的用例,但包括用例不应该"知道"关于基本用例.这就是为什么包含的用例可以是:a)基本用例本身和b)由许多基本用例共享.

延伸

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

扩展用例可用于以下几种情况:

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

要考虑的一个重要方面是延长使用的情况下可以在基本用例流程的几个地方,不只是作为一个包含用例做了一个地方"插入"行为.因此,扩展用例极不可能适用于扩展多个基本用例.

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

摘要

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

Answer 3

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

我的用例:我要去城里.

包括 - >开车

延伸 - >填充汽油

可能根本不需要"填充汽油",但可以根据汽车中剩余的汽油量来选择."驾驶汽车"是一个先决条件因此我包括在内.

Answer 4

用例用于记录行为,例如回答这个问题.

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

另请注意,如果您不想回答问题,研究答案就没有多大意义.

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

为了澄清,只有你想在堆栈溢出:)这里回答这个例子才是真的.

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

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

扩展

Extend是从扩展UseCase(扩展)到扩展UseCase(extendedCase)的关系,它指定如何以及何时将扩展UseCase中定义的行为插入到扩展UseCase中定义的行为中.扩展发生在扩展的UseCase中定义的一个或多个特定扩展点上.

当存在一些额外的行为(可能是有条件地)添加到一个或多个UseCases中定义的行为时,可以使用Extend .

所述扩展用例被独立地定义的延伸的用例,并且是独立地有意义延伸用例的.另一方面,扩展的UseCase通常定义可能不一定有意义的行为.相反,扩展的UseCase定义了一组模块化行为增量,这些增量在特定条件下增加了扩展UseCase的执行.

...

包括

Include是两个UseCases之间的DirectedRelationship,表示包含的UseCase(添加)的行为被插入到包含UseCase(includesCase)的行为中.它也是一种NamedElement,因此它可以在其拥有的UseCase(includesCase)的上下文中具有名称.包含UseCase可能取决于执行包含的UseCase所产生的更改.包含的UseCase必须可用于完整描述包含UseCase的行为.

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

...

Answer 5

我认为了解包含和扩展的意图很重要:

"包含关系旨在重用由另一个用例建模的行为,而扩展关系旨在为 现有用例添加部分以及为可选系统服务建模"(Overgaard和Palmkvist,用例:模式和蓝图.Addison -Wesley,2004).

这告诉我:

包括= 重用功能(即使用所包含的功能或可以在系统的其他地方使用).因此,Include表示依赖于另一个用例.

延伸= 加入(未重用)功能和也任何可选功能.因此,扩展可以表示以下两种情况之一:
1.向用例添加新特性/功能(可选或不可选)
2.任何可选用例(现有或未存在).

摘要:
Include =重用功能
Extends =新功能和/或可选功能

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

Answer 6

让我们更清楚一点.我们include每次想要表达一个案例的存在取决于另一个案例的存在这一事实.

例子:

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

在上传材料之前,用户无法从网站下载.所以,如果没有上传任何内容,我无法下载.

你明白了吗？

这是关于条件后果的.如果以前我不这样做,我不能这样做.

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

Answer 7

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

包括 [5]

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

延伸 [6]

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

Answer 8

为了简化,

对于 include

1. 当执行基本用例时,包含的用例每隔一段时间执行一次.
2. 基本用例需要完成包含的用例才能完成.

典型示例:登录和验证密码之间

(登录)--- << include >> --- >(验证密码)

要使登录过程成功,"验证密码"也必须成功.

对于 extend

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

典型示例:登录和显示错误消息之间(有时仅发生)

(登录)< --- << extend >> ---(显示错误信息)

只有在登录过程失败时才会出现"显示错误消息".

Answer 9

每当有用例的先决条件时,请转到include.

对于具有身份验证,最坏情况场景或可选的用户,请进行扩展..

例如:对于寻求入场,预约,机票预订的用例,您必须填写表格(注册或反馈表格)....这是包括来的地方..

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

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

保持简单!

Answer 10

"Include"用于扩展基本用例,它是必须条件,即包含用例运行必须成功运行才能完成基本使用.

例如,考虑一个电子邮件服务案例,这里"登录"是一个包含的用例,必须运行才能发送电子邮件(基本用例)

另一方面,"排除"是扩展基本用例的可选用例,即使不调用/调用扩展用例,基本用例也可以成功运行.

例如,将"笔记本电脑购买"视为基本用例,将"附加保修"视为扩展用例,即使不进行额外保修,也可以在此处运行基本用例"笔记本电脑购买".

Answer 11

还要注意UML版本:现在很久以来<< uses >>和<< includes >>已被<< include >>取代,<< extends >>被<< extend >>和泛化所取代.
对我而言,这通常是误导性的一点:作为一个例子,斯蒂芬妮的帖子和链接是关于一个旧版本:

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

事实上,"物品付款"没有其他替代品!在现今的UML中,"付款交付"是一种延伸,"使用paypal支付"/"按卡支付"是专业化.

Answer 12

二者<include>并<extend>依赖于基类，但<extend>是可选的，即，它从基类，但在用户点导出查看它可以使用或可以不使用。

<include>包含在基类中，即，必须<include>在您的用例中使用，否则将被视为不完整。

例如：

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

1：提现、存入现金、查账，<extend>因用户取现、存入、查账而定。这些是用户做的可选的事情。

2：“输入密码，放置卡片，取出卡片”这些是<include>用户必须并且应该放置卡片并输入有效密码以进行验证的事情。

Answer 13

这是一个很好的资源,有很好的解释: 用例包括什么？ 什么是用例扩展？

扩展用例通常定义可选行为.它独立于扩展用例

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