还要注意UML版本:现在<<使用>>和<<包含>>已经很长时间了，已经被<<包括>>所取代，<<扩展>>由<<扩展>>和泛化。 对我来说，这往往是误导性的观点:例如Stephanie的帖子和链接是关于一个旧版本的:

在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。

事实上，除了“为物品付费”，没有其他选择!在现在的UML中，“货到付款”是一个扩展，“使用paypal支付”/“刷卡支付”是专门化的。

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

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

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

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

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

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

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

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

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

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

例子:

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

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

你明白了吗?

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

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

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

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

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

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

为了简化,

为包括

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

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

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

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

为扩展

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

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

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

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