为了简化,

为包括

当基本用例执行时，包含的用例将每次执行一次。 基本用例需要完成所包含的用例才能完成。

一个典型的例子:在登录和验证密码之间

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

为了使登录过程成功，“验证密码”也必须成功。

为扩展

当基本用例被执行时，扩展用例只是偶尔执行 扩展用例仅在满足某些条件时才会发生。

一个典型的例子:在登录和显示错误消息之间(只偶尔发生)

(登录 ) <--- << 扩展> >——(显示错误消息)

“show error message”只在登录过程失败时才会出现。

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

我的用例:我要去城市。

包括->驾驶汽车

Extends ->填充汽油

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

我不建议用这个来记住这两点:

我的用例:我要去城市。

包括->驾驶汽车

Extends ->填充汽油

我宁愿你用: 我的用例:我要去城市。

Extends ->驾驶汽车

包括->加油

扩展关系延续了基类的行为。基类功能必须在那里。 另一方面，包含关系类似于可能被调用的函数。梅是粗体字。

这可以从 用例模型中的重用

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

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

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

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

为了简化,

为包括

当基本用例执行时，包含的用例将每次执行一次。 基本用例需要完成所包含的用例才能完成。

一个典型的例子:在登录和验证密码之间

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

为了使登录过程成功，“验证密码”也必须成功。

为扩展

当基本用例被执行时，扩展用例只是偶尔执行 扩展用例仅在满足某些条件时才会发生。

一个典型的例子:在登录和显示错误消息之间(只偶尔发生)

(登录 ) <--- << 扩展> >——(显示错误消息)

“show error message”只在登录过程失败时才会出现。

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

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

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

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

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