UML用例图，不同的参与者？

我想知道我的用例图是否正确，如果不正确，是否有人能给我一些提示

它适用于用户可以登录的应用程序（总是必需的）。当他们登录时，他们会看到一个帖子列表，他们可以向上或向下投票（比如reddit）。当选择一篇文章时，他们可以放置和删除（只有他们自己的）评论

登录的用户可以在登录时放置帖子，但也有一个按钮可以查看他们已经放置的帖子，可以编辑和删除这些帖子

最后还有一个管理员可以删除不适当的帖子和评论

我是否应该定义用户只能编辑和删除自己的帖子和评论？如果是，我该怎么做？也许是另一个演员

提前谢谢

---

您的UCs中有几个缺陷

登录根本不是UC（它不会为参与者增加任何价值）。这是可以应用于UCs的约束

错误的用户名/pw当然不是UC。这是某个地方会弹出的信息

注册是一个独立的UC。将其直接连接到用户

在UC中使用泛化不是一个好主意，因为它会带来很多东西供讨论。将其置于

管理

级别，并在UC内部描述这意味着什么

通常使用错误的方式（即用于功能分解）。你也在这样做。因此，抛开它，专注于基本的UC

管理评论

，并将其直接与参与者联系起来

---

如果出于某种原因，您需要描述UCs的某些顺序，您可以在UCs内部使用前置条件。

UCs中有几个缺陷

登录根本不是UC（它不会为参与者增加任何价值）。这是可以应用于UCs的约束

错误的用户名/pw当然不是UC。这是某个地方会弹出的信息

注册是一个独立的UC。将其直接连接到用户

在UC中使用泛化不是一个好主意，因为它会带来很多东西供讨论。将其置于

管理

级别，并在UC内部描述这意味着什么

通常使用错误的方式（即用于功能分解）。你也在这样做。因此，抛开它，专注于基本的UC

管理评论

，并将其直接与参与者联系起来

---

如果出于某种原因，您需要描述UCs的某些顺序，您可以在UCs内部使用前置条件。

请记住，您不能使用用例图对所有内容进行建模。单个UC是一组提供特定业务结果的操作流。您可以在UC描述中提供有关限制的详细信息（例如，您只能管理自己的评论的条件）（通过活动或序列图建模，或仅在书面描述中提供），但在UC图上不提供

由于评论在您的系统中是可选的，因此您肯定使用了不正确的关系。包含意味着在执行包含UC时，将始终执行包含的UC。在您的情况下，这取决于用户的决定，这意味着您应该使用extends（当然，在这种情况下，关系是相反的）。见18.1.3.2（第二段）和18.1.3.3（第一段）。你也可以在几乎任何一本关于基于UML的分析的书中找到这一点的证明（例如Howard Podeswa的《面向业务分析师的UML》）

---

除此之外，我同意Thomas Kilian给出的缺陷列表。

请记住，您不能使用用例图对所有问题进行建模。单个UC是一组提供特定业务结果的操作流。您可以在UC描述中提供有关限制的详细信息（例如，您只能管理自己的评论的条件）（通过活动或序列图建模，或仅在书面描述中提供），但在UC图上不提供

由于评论在您的系统中是可选的，因此您肯定使用了不正确的关系。包含意味着在执行包含UC时，将始终执行包含的UC。在您的情况下，这取决于用户的决定，这意味着您应该使用extends（当然，在这种情况下，关系是相反的）。见18.1.3.2（第二段）和18.1.3.3（第一段）。你也可以在几乎任何一本关于基于UML的分析的书中找到这一点的证明（例如Howard Podeswa的《面向业务分析师的UML》）

除此之外，我同意托马斯·基利安给出的缺陷清单