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

Question

8

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

- 查看帖子。 - 如果未登录，则仅使用常规或Facebook注册。 - 如果使用Facebook注册，则仅使用Facebook登录。 - 如果以常规方式注册，则仅使用常规登录或重置密码。 - 如果已经通过身份验证，则仅创建帖子或取消注册。

我不明白如何为访问者建模不同的用例。由于未注册的访问者可以成为注册访问者，而注册访问者也可以成为未注册访问者，在网站上他们可以做相同的事情，只是采取不同的路径。

这些条件是否对用例图很重要？说普通注册需要填写很多字段，而Facebook注册只需要访问者选择用户名太具体了吗？

用例能否自我扩展？例如，如果注册失败，访问者会再次重复注册。

编辑：我猜测如何制作图表：

编辑2：还是像这样简单？

- user1989781

如果您也能画一个用例图的话，我会非常感激！ :) - user1989781

3个回答

2

您的第二个模型更好。在规范中，使用案例泛化并不经常使用，提供了一个例子。

。

由于用户应该能够注册，因此演员“未注册用户”可以被删除。是吗？

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

- granier

无论是注册用户还是非注册用户都可以查看帖子。基本上我想表达的是，注册不是查看帖子的必要条件，我可以这样做吗？ - user1989781

你的架构从UML的角度来看是正确的，所以你可以这样做。但是如果用户可以在注册之前激活“用例视图”并查看帖子，那么对我来说，“未注册用户”就没有必要存在了。 - granier

0

像您所做的那样展示约束没有任何问题。我通常会创建一个概述图，就像您的#2一样。然后专注于单个用例，仅显示它们与参与者和需求的关系 - 最终从后者推导出的约束。

不要陷入功能分解的陷阱，避免使用<<include>>/<<extend>>或更糟糕的泛化。用例不用于分解功能部件，而是综合它们。用例显示系统考虑下向其参与者提供的单个附加值。

登录不是用例，因为它没有附加值。它是一个约束，您可以将其附加到用例上。

像往常一样：UML规范并不适合理解用例综合。它是由具有少量业务背景的专家编写的。相反，请查看Bittner/Spence。

- qwerty_so

假设我有一个名为“创建帖子”的用例，并且帖子的创建者也可以“更改帖子”。在这里扩展是否有意义，还是应该拆分成两个不同的用例？ - user1989781

这是否有意义？它看起来非常臃肿，也许其中一些不是有效的用例？ - user1989781

您可以根据业务领域将其简单地分成几个图表（例如，一个用于管理，一个用于用户交互）。或者您可以使用边界来显示这些领域。 - qwerty_so

关于"extend"：CRUD 是一个边缘情况，你可以从两个方面看待它。你可以有一个单一的"管理<X>"或单一的"C <X>", "R <X>",等等。如果其中一个更为突出，则最好将其作为独立的用例。否则，一个单一的 CRUD 用例会更好。你的情况可能会有所不同。 - qwerty_so

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Gholamali Irani · Accepted Answer

正如 @granier 所说，你的第二个模型要好得多，@Thomas Kilian 的观点也很重要。

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

请考虑我提供的用例图：

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