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


当前回答

我喜欢把“包含”看作基本用例的必要前提/伴随。这意味着如果没有基本用例所包含的用例,就不能认为基本用例是完整的。我将给出一个向客户销售商品的电子商务网站的例子。如果不先选择商品并将其放入购物车,你就无法支付商品。这意味着用例“Pay for Item”包括“select Item”。

扩展的用途多种多样,但我喜欢将其视为一种可能使用也可能不使用的替代方法。例如,仍然在电子商务网站。在付款时,您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。

想要更清楚地了解用例的规则,请阅读我的文章:

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

其他回答

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

我的用例:我要去城市。

包括->驾驶汽车

Extends ->填充汽油

“加油”不一定总是被要求,但也可以根据车里剩余的汽油量来选择。“开车”是一个先决条件,所以我把它包括在内。

当一个用例有先决条件时,就使用include。

对于有身份验证的用例,最坏的情况,或者是可选的,然后选择extend..

示例:用于寻求入场、预约、机票预订的用例 您必须填写一份表格(注册或反馈表)....这就是包容的由来。

例如:对于验证登录或登录您的帐户的用例,您的身份验证是必须的。还要考虑最坏的情况。比如按时还书,没有预定,逾期付款,这就是延期发挥作用的地方。

不要在图中过度使用include和extend。

保持简单,傻瓜!!

这里已经解释了两者之间的区别。但没有解释的是,<<include>>和<<extend>>根本不应该被使用。

如果你读过Bittner/Spence,你就知道用例是关于综合的,而不是分析的。用例的重用是毫无意义的。它清楚地表明您已经错误地切割了您的域名。附加值本身必须是唯一的。我所知道的唯一附加值再利用方式就是特许经营。如果你是做汉堡生意的,很好。但在其他任何地方,你作为BA的任务是试图找到一个USP。这必须在良好的用例中呈现。

每当我看到人们使用其中一种关系时,都是在尝试进行功能分解的时候。这是完全错误的。

简单地说:如果你可以毫不犹豫地回答你的老板“我做了……”,那么“……”就是你的用例,因为你这样做得到了钱。(这也清楚地表明“登录”根本不是一个用例。)

在这方面,找到包含或扩展其他用例的独立用例是非常不可能的。最终,您可以使用<<extend>>来显示您的系统的可选性,即一些许可模式,它允许包含某些许可的用例或省略它们。但除此之外,就避免他们。

当用例向另一个一级用例添加步骤时,使用Extend。

例如,假设“提取现金”是自动柜员机(ATM)的一个用例。“评估费用”将扩展提现并描述有条件的“扩展点”,该“扩展点”在ATM用户不在ATM所属机构存入银行时实例化。注意,基本的“Withdraw Cash”用例独立存在,没有扩展。

Include用于提取在多个用例中重复的用例片段。被包含的用例不能独立存在,没有被包含的用例原始的用例是不完整的。这应该谨慎使用,并且只在重复很明显并且是故意存在(而不是巧合)的情况下使用。

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

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

例如,假设你有一个亚马逊账户,你想查看订单,如果不先登录你的账户,就不可能查看订单。所以事件的发展会这样。

扩展关系用于向用例流添加一个额外的步骤,这通常是一个可选的步骤…

假设我们还在谈论你的亚马逊账户。让我们假设基本用例是Order,扩展用例是Amazon Prime。用户可以选择定期订购商品,也可以选择亚马逊Prime,以确保他的订单以更高的成本更快到达。

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