UML用例图参与者

X公司想要一个基于网络的系统，作为创意的市场。用户应该能够登录并发布新想法。其他用户可以对其进行评论并“投票表决”。管理员可以登录并标记创意已经实现，并可以奖励发布创意的员工。 以下是要求：

Users should be able to login.
Users should be able to post a new idea.
Users should be able to search for and view other ideas
Users should be able to comment on ideas
Users should be able to upvote ideas
Administrators should be able to mark ideas as implemented
Administrators should be able to delete unwanted comments

你们认为我的图表正确吗？我是UML新手，所以你们可以开玩笑

---

这是一个不错的开始。仅：

• 管理员也是用户。它们是从它们身上下来的。因此，从管理员到用户，他们应该有一个

  泛化
  连接-空三角形箭头。或其他用户（请看下面）
  

• 更自然的是，有一个代理示例的图片和名称。所以，用户，管理员-用单数

• 只有当用户具有不同的定义时，才可以将用户与其他用户分开，并且从文档中也可以看到这种差异。事实并非如此。我将只使用用户。 当然，如果某些用户确实拥有不同的权限，这是可以的，但是：
  • 这个名字不好，伊姆霍
  • 他们有用户的所有选择，不是吗？因此，他们必须从用户的角度出发

---

• 您应该继续添加未来系统的部分，这些部分将在这些用例上与人工代理协作。现在您只完成了前一半的工作

---

编辑：

• 您的管理员仍然没有从管理员到用户的泛化错误。管理员可以做用户可以做的所有活动，不是吗
• 图上仍然没有子系统
• 通过旧想法进行搜索应该是直接连接到用户的用例。它不会在图上扩展任何内容
• 记住-仅在UC图创建的最后阶段使用Include和Extends。当你已经有了主画面并且正在完善它的时候。通常，它们应该只用于更深入、更彻底的图表。从一开始就使用Include和Extend意味着您还没有找到主要概念

---

+1，用于从正确的问题开始。（作业做完了，你真的要求咨询）。欢迎光临，祝你好运。别忘了标记答案！：-）我之所以将用户和其他用户分开，是因为其他用户可以对想法发表评论并对其进行投票，而用户（实际上是想法的作者）却不能这样做。我是不是想得太多了？他们也是根据其他人的想法写的。当然，他们可以对评论发表评论，不是吗？你试图为一个想法而不是想法设定权利规则。这不是普通UC图的任务。如果这些权利很复杂，也许你可以为它写一些特殊的用例。不，建模时不能考虑太多，但可以在一个图表中放入太多信息。而且它变得复杂了。