用例图的条件路径应该如何建模？

Question

我正在创建一个访问者可以访问的网站：

• 查看帖子。
• 如果他们没有登录，则只能使用常规或Facebook注册。
• 如果他们已在Facebook注册，则只能使用Facebook登录。
• 如果他们以常规方式注册，则仅使用常规登录或密码重置。
• 如果经过身份验证，则只创建帖子或取消注册。

我不明白我应该如何为访客提供不同的用例模型。由于未注册的访客可以成为注册访客，注册访客可以成为未注册的访客，他们可以在网站上做同样的事情，他们只是采取不同的路径。

这些条件对于用例图是否重要？是否过于具体，不能说定期注册需要填写许多字段，而Facebook注册只要求访问者选择用户名？

用例可以扩展吗？就像注册失败一样，访问者再次重复注册。

编辑：我猜了怎么做图：

编辑2：或者可能更简单？

Answer 1

正如@granier所说，你的第二个模型要好得多，而且@Thomas Kilian的分数是可以重新制作的。

我想说出你的错误并提供一个新的用例图。我认为您的模型中存在一些错误（逻辑和实际）：

1. 详细的用例图（型号1）（请参阅我之前的帖子提示 here）
2. 用户名不是用例。
3. 登录和重置密码之间没有扩展关系。 （模型2）
4. 与注册用户相关联的登录？所有用户都可以触发登录用例（甚至是否成功）。
5. 错误使用include和扩展和继承关系（模型1）。

请考虑我提供的用例图：



此外，您可以在用例文档中添加前置条件和后置条件。但是，他们不会改变用例。

Answer 2

你的第二个模型要好得多。即使在规范中提供了例子，也不经常使用用例概括。 https://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

由于用户应该能够注册，所以演员＆＃34;未注册用户＆＃34;可以删除。不是吗？

我仅在一种情况下使用用例概括：当我想要几个用例获得相同的包含或扩展时。

Answer 3

显示约束时没有任何问题。我所做的通常是创建像＃2这样的概览图。然后专注于单个用例，显示他们与参与者和要求的关系 - 并最终从后者获得约束。

不要陷入功能分解的陷阱，避免<<include>>/<<extend>>甚至更糟的概括。用例不用于分解功能部件，而是合成它们。用例显示正在考虑的系统向其中一个参与者提供的单个附加值。

Login不是用例，因为它没有附加价值。这是一个可以附加到用例的约束。

一如既往：UML规范无法理解用例合成。它由没有商业背景的eggheads编写。再看看Bittner / Spence。