UML 用例图，查看者的不同参与者？
UML use case diagram, different actor for viewer?
我想知道我的用例图是否正确，如果不正确，是否有人可以给我一些指示。
它用于用户可以登录的应用程序（始终需要）。当他们登录时，他们会看到一个包含 posts 的列表，他们可以对该列表进行投票（如 reddit）。选择 post 时，他们可以放置和删除（仅限他们自己的）评论。
登录的用户可以在登录时放置 posts，但也有一个按钮可以查看 posts 他们已经放置在可以编辑和删除的地方。
终于有一个管理员可以删除不适当的 post 和评论。
我是否应该定义用户只能编辑和删除他们自己的 post 和评论？如果是这样，我该怎么做？也许换个演员？
提前致谢！
你的 UC 有几个缺陷。
- 登录根本不是UC（它不会为演员增加任何价值）。这是您可以应用于 UC 的约束。
- 错 username/pw当然是没有UC了。这是一些会在某处弹出的消息。
- 注册本身就是一个 UC。直接连接到用户。
- 在 UC 中使用泛化不是一个好主意，因为它会带来很多讨论的内容。将其保留在
Manage 级别并在 UC 内部描述这意味着什么。
<<include>> 通常使用错误的方式（即用于功能分解）。你也在这样做。所以抛开它，专注于基本的 UC Manage comments 并将其直接与演员联系起来。
如果出于某种原因您需要为 UC 描述一些顺序，您可以在 UC 内使用前置条件。
请记住，您无法使用用例图对所有事物进行建模。单个 UC 是一组提供特定业务结果的操作流。您可以在 UC 的描述中提供有关限制的详细信息（例如，您只能管理自己的评论的条件）（通过 activity 或序列图建模或仅在书面描述中）但 不 在 UC 图上。
由于评论在您的系统中是可选的，因此您肯定使用了不正确的关系。 include表示include UC执行时always执行include UC。在您的情况下，这取决于用户的决定，这意味着您应该改用 extends （当然在这种情况下，关系是相反的）。见 18.1.3.2（第二段）和 18.1.3.3（第一段）。您还可以在几乎所有关于基于 UML 的分析的书中找到对这一点的确认（例如 Howard Podeswa 的 "UML for the business analyst" 仅举一例）
此外，我同意 Thomas Kilian 给出的缺陷列表。
我想知道我的用例图是否正确，如果不正确，是否有人可以给我一些指示。
它用于用户可以登录的应用程序（始终需要）。当他们登录时，他们会看到一个包含 posts 的列表，他们可以对该列表进行投票（如 reddit）。选择 post 时，他们可以放置和删除（仅限他们自己的）评论。
登录的用户可以在登录时放置 posts，但也有一个按钮可以查看 posts 他们已经放置在可以编辑和删除的地方。
终于有一个管理员可以删除不适当的 post 和评论。
我是否应该定义用户只能编辑和删除他们自己的 post 和评论？如果是这样，我该怎么做？也许换个演员？
提前致谢！
你的 UC 有几个缺陷。
- 登录根本不是UC（它不会为演员增加任何价值）。这是您可以应用于 UC 的约束。
- 错 username/pw当然是没有UC了。这是一些会在某处弹出的消息。
- 注册本身就是一个 UC。直接连接到用户。
- 在 UC 中使用泛化不是一个好主意，因为它会带来很多讨论的内容。将其保留在
Manage级别并在 UC 内部描述这意味着什么。 <<include>>通常使用错误的方式（即用于功能分解）。你也在这样做。所以抛开它，专注于基本的 UCManage comments并将其直接与演员联系起来。
如果出于某种原因您需要为 UC 描述一些顺序，您可以在 UC 内使用前置条件。
请记住，您无法使用用例图对所有事物进行建模。单个 UC 是一组提供特定业务结果的操作流。您可以在 UC 的描述中提供有关限制的详细信息（例如，您只能管理自己的评论的条件）（通过 activity 或序列图建模或仅在书面描述中）但 不 在 UC 图上。
由于评论在您的系统中是可选的，因此您肯定使用了不正确的关系。 include表示include UC执行时always执行include UC。在您的情况下，这取决于用户的决定，这意味着您应该改用 extends （当然在这种情况下，关系是相反的）。见 18.1.3.2（第二段）和 18.1.3.3（第一段）。您还可以在几乎所有关于基于 UML 的分析的书中找到对这一点的确认（例如 Howard Podeswa 的 "UML for the business analyst" 仅举一例）
此外，我同意 Thomas Kilian 给出的缺陷列表。