在用例图中包含和扩展之间的区别是什么?
当前回答
这里已经解释了两者之间的区别。但没有解释的是，<<include>>和<<extend>>根本不应该被使用。
如果你读过Bittner/Spence，你就知道用例是关于综合的，而不是分析的。用例的重用是毫无意义的。它清楚地表明您已经错误地切割了您的域名。附加值本身必须是唯一的。我所知道的唯一附加值再利用方式就是特许经营。如果你是做汉堡生意的，很好。但在其他任何地方，你作为BA的任务是试图找到一个USP。这必须在良好的用例中呈现。
每当我看到人们使用其中一种关系时，都是在尝试进行功能分解的时候。这是完全错误的。
简单地说:如果你可以毫不犹豫地回答你的老板“我做了……”，那么“……”就是你的用例，因为你这样做得到了钱。(这也清楚地表明“登录”根本不是一个用例。)
在这方面，找到包含或扩展其他用例的独立用例是非常不可能的。最终，您可以使用<<extend>>来显示您的系统的可选性，即一些许可模式，它允许包含某些许可的用例或省略它们。但除此之外，就避免他们。
其他回答
这里已经解释了两者之间的区别。但没有解释的是，<<include>>和<<extend>>根本不应该被使用。
如果你读过Bittner/Spence，你就知道用例是关于综合的，而不是分析的。用例的重用是毫无意义的。它清楚地表明您已经错误地切割了您的域名。附加值本身必须是唯一的。我所知道的唯一附加值再利用方式就是特许经营。如果你是做汉堡生意的，很好。但在其他任何地方，你作为BA的任务是试图找到一个USP。这必须在良好的用例中呈现。
每当我看到人们使用其中一种关系时，都是在尝试进行功能分解的时候。这是完全错误的。
简单地说:如果你可以毫不犹豫地回答你的老板“我做了……”，那么“……”就是你的用例，因为你这样做得到了钱。(这也清楚地表明“登录”根本不是一个用例。)
在这方面，找到包含或扩展其他用例的独立用例是非常不可能的。最终，您可以使用<<extend>>来显示您的系统的可选性，即一些许可模式，它允许包含某些许可的用例或省略它们。但除此之外，就避免他们。
当您理解您的用例过于复杂时，可以使用Extends。因此，您将复杂的步骤提取到它们自己的“扩展”用例中。
Includes用于在两个用例中看到相同的行为。因此，您将常见的行为抽象到一个单独的“抽象”用例中。
(参考:Jeffrey L. Whitten, Lonnie D. Bentley，系统分析与设计方法，McGraw-Hill/Irwin, 2007)
让我们说清楚一点。每当我们想表达一种情况的存在依赖于另一种情况的存在时，我们就用包含。
例子:
用户只有登录账号后才能在网上购物。换句话说，在他登录自己的账户之前，他不能购物。
在材料被上传之前，用户不能从网站上下载。 所以，如果什么都没有上传，我就无法下载。
你明白了吗?
这是关于条件后果的。如果之前我没有这样做，我就不能这样做。
至少，我认为这是我们使用Include的正确方式。 我倾向于认为上面的笔记本电脑和保修的例子是最有说服力的!
“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行以完成基本使用。
如。 考虑一个电子邮件服务的案例，这里“Login”是一个包含的用例，必须运行它来发送电子邮件(基本用例)
另一方面，“Exclude”是扩展基本用例的可选用例，基本用例即使不调用/调用扩展用例也可以成功运行。
如。 考虑“Laptop Purchase”作为基本用例，“Additional Warranty”作为扩展用例，在这里你可以运行基本用例“Laptop Purchase”，甚至不需要额外的保证。
包含关系允许一个用例包含另一个用例的步骤。
例如，假设你有一个亚马逊账户，你想查看订单，如果不先登录你的账户，就不可能查看订单。所以事件的发展会这样。
扩展关系用于向用例流添加一个额外的步骤，这通常是一个可选的步骤…
假设我们还在谈论你的亚马逊账户。让我们假设基本用例是Order，扩展用例是Amazon Prime。用户可以选择定期订购商品，也可以选择亚马逊Prime，以确保他的订单以更高的成本更快到达。
但是，请注意，用户不必选择Amazon Prime，这只是一个选项，他们可以选择忽略这个用例。
