让我们说清楚一点。每当我们想表达一种情况的存在依赖于另一种情况的存在时，我们就用包含。

例子:

用户只有登录账号后才能在网上购物。换句话说，在他登录自己的账户之前，他不能购物。

在材料被上传之前，用户不能从网站上下载。 所以，如果什么都没有上传，我就无法下载。

你明白了吗?

这是关于条件后果的。如果之前我没有这样做，我就不能这样做。

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

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

我的用例:我要去城市。

包括->驾驶汽车

Extends ->填充汽油

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

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

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

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

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

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

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

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

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

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

我记得是通过电子游戏。例如, (下面不是100%的用例，只是一个用例的例子)

扩展:主菜单扩展了一些功能，这意味着它们有一些功能，但不需要按下

包括:为了在电子游戏中开火，你必须先有一个武器。

我认为理解includes和extends的意图很重要:

“包含关系旨在重用已建模的行为 通过另一个用例，而扩展关系是为 向现有的用例中添加部件，以及为可选的系统服务建模”(Overgaard和Palmkvist，用例:模式和蓝图。addison - wesley, 2004)。

在我看来，这是:

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

Extends =添加(而不是重用)功能和任何可选功能。因此，Extends可以表示以下两种情况之一: 1. 向用例中添加新特性/功能(可选或非可选) 2. 任何可选的用例(是否存在)。

简介: 包含=功能的重用 Extends =新的和/或可选的功能

您将经常发现扩展的第二种用法(即可选功能)，因为如果功能不是可选的，那么大多数情况下它被内置到用例本身，而不是作为一个扩展。至少这是我的经验。(Julian C指出，当项目进入第二阶段时，你有时会看到扩展的第一次使用(即添加新功能)。