在用例图中包含和扩展之间的区别是什么?
当前回答
“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行以完成基本使用。
如。 考虑一个电子邮件服务的案例，这里“Login”是一个包含的用例，必须运行它来发送电子邮件(基本用例)
另一方面，“Exclude”是扩展基本用例的可选用例，基本用例即使不调用/调用扩展用例也可以成功运行。
如。 考虑“Laptop Purchase”作为基本用例，“Additional Warranty”作为扩展用例，在这里你可以运行基本用例“Laptop Purchase”，甚至不需要额外的保证。
其他回答
让我们说清楚一点。每当我们想表达一种情况的存在依赖于另一种情况的存在时，我们就用包含。
例子:
用户只有登录账号后才能在网上购物。换句话说，在他登录自己的账户之前，他不能购物。
在材料被上传之前，用户不能从网站上下载。 所以，如果什么都没有上传，我就无法下载。
你明白了吗?
这是关于条件后果的。如果之前我没有这样做，我就不能这样做。
至少，我认为这是我们使用Include的正确方式。 我倾向于认为上面的笔记本电脑和保修的例子是最有说服力的!
当用例向另一个一级用例添加步骤时，使用Extend。
例如，假设“提取现金”是自动柜员机(ATM)的一个用例。“评估费用”将扩展提现并描述有条件的“扩展点”，该“扩展点”在ATM用户不在ATM所属机构存入银行时实例化。注意，基本的“Withdraw Cash”用例独立存在，没有扩展。
Include用于提取在多个用例中重复的用例片段。被包含的用例不能独立存在，没有被包含的用例原始的用例是不完整的。这应该谨慎使用，并且只在重复很明显并且是故意存在(而不是巧合)的情况下使用。
例如，在每个ATM用例开始时发生的事件流(当用户放入他们的ATM卡，输入他们的PIN，并显示主菜单时)将是一个很好的包含候选。
我喜欢把“包含”看作基本用例的必要前提/伴随。这意味着如果没有基本用例所包含的用例，就不能认为基本用例是完整的。我将给出一个向客户销售商品的电子商务网站的例子。如果不先选择商品并将其放入购物车，你就无法支付商品。这意味着用例“Pay for Item”包括“select Item”。
扩展的用途多种多样，但我喜欢将其视为一种可能使用也可能不使用的替代方法。例如，仍然在电子商务网站。在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。
想要更清楚地了解用例的规则，请阅读我的文章:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
还要注意UML版本:现在<<使用>>和<<包含>>已经很长时间了，已经被<<包括>>所取代，<<扩展>>由<<扩展>>和泛化。 对我来说，这往往是误导性的观点:例如Stephanie的帖子和链接是关于一个旧版本的:
在付款时，您可以选择货到付款、使用paypal付款或刷卡付款。这些都是“为物品付费”用例的替代方案。我可以根据自己的喜好选择其中任何一种。
事实上，除了“为物品付费”，没有其他选择!在现在的UML中，“货到付款”是一个扩展，“使用paypal支付”/“刷卡支付”是专门化的。
当一个用例有先决条件时，就使用include。
对于有身份验证的用例，最坏的情况，或者是可选的，然后选择extend..
示例:用于寻求入场、预约、机票预订的用例 您必须填写一份表格(注册或反馈表)....这就是包容的由来。
例如:对于验证登录或登录您的帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。比如按时还书，没有预定，逾期付款，这就是延期发挥作用的地方。
不要在图中过度使用include和extend。
保持简单，傻瓜!!
