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

我正在制作一个网站，访问者可以：

• 查看帖子
• 只有在未登录的情况下才使用常规或Facebook注册
• 只有在Facebook注册的情况下才能登录Facebook
• 如果他们以常规方式注册，则仅使用常规登录或密码重置
• 只有经过身份验证的帖子才能创建或注销

我不明白我应该如何为访问者建模不同的可用用例。由于未注册的访问者可以成为注册的访问者，而注册的访问者可以成为未注册的访问者，他们可以在站点上做同样的事情，他们只是选择不同的路径

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

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

编辑：我猜了一下如何绘制图表：

编辑2：或者像这样更简单？

---

你的第二种型号要好得多。用例泛化即使在规范中也不经常使用，提供了一个示例

因为用户应该能够注册，所以可以删除参与者“未注册用户”。没有

---

我只在一种情况下使用用例泛化：当我希望多个用例获得相同的包含或扩展时。

按照您的方式显示约束没有什么错。我通常会创建一个概览图，如您的#2。然后关注单个用例，只显示它们与参与者和需求的关系，并最终从后者派生出约束

不要落入函数分解的陷阱，避免

/

或更糟糕的泛化。用例不是用来分解功能部件，而是用来合成它们。用例显示了正在考虑的系统向其参与者之一交付的单一附加值

Login

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

---

一如既往：UML规范不是很好的阅读理解用例合成。它是由没有什么商业背景的书呆子写的。看看比特纳/斯宾塞吧。

正如@granier所说，你的第二个模型要好得多，@Thomas Kilian的观点是可以改变的

我想指出您的错误，并提供一个新的用例图。我认为您的模型中存在一些错误（逻辑上和实践上都有错误）：

太详细的用例图（模型1）（请参阅我以前的帖子提示）

用户名不是用例

登录和重置密码之间没有扩展关系。（模式2）

与注册用户关联的登录名？所有用户都可以触发登录用例（即使成功与否）

错误使用包含、扩展和继承关系（模型1）

请考虑我提供的用例图：

---

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

如果你也画一张用例图，我会非常感激的！：）假设我有一个用例叫做“创建帖子”，帖子的创建者也可以“更改帖子”。在这里扩展是有意义的还是我应该把它们分成两个不同的用例？这有意义吗？它看起来非常臃肿，可能其中一些是无效的用例？您可以简单地根据业务领域将其细分为几个图表（例如，一个用于管理，一个用于用户交互）。或者使用边界来显示这些域。Re。“扩展”：CRUD是一条边界线，您可以从两个方面看到它。您可以使用单个“管理”或单个“C”、“R”等。如果其中一个占主导地位，则最好将其设置为独立的UC。否则，单个CRUD用例更好。YMMV已注册和未注册的用户都可以查看帖子。基本上，我想说明的是，注册并不是查看帖子的要求，我可以这样做吗？从UML的角度来看，您的模式是正确的，所以您可以这样做。但如果用户可以激活用例查看帖子和注册，这意味着未注册的用户可以查看帖子，对我来说，不需要未注册的用户。