UML 用例图问题

Question

我有一些关于用例图的问题：

• 如果我的系统有访客注册/登录用例，是否应该为管理员、用户启用它（我只是想澄清一下，如果我有登录系统，我是否假设管理员、用户等是已经登录到系统的人，所以我通过日志记录跳过他们）？

• 如果我的系统有一个学生演员，正在为个人研讨会/课程签名，我是否有（或我被允许）在为他们唱歌后为“上课”制作用例，并且应该有这些之间的关系 2

• 我的老师应该继承学生演员吗，因为他也可以浏览课程？ （等等管理员？）

• 我的付款设置正确吗？

Answer 1

1. 请记住，这些是角色而不是人。管理员可以是访客，只要他们的行为完全像猜测一样，没有特殊的功能或规则。但是，在登录过程中，用户角色可能会更改，成为管理员。请注意，您在某种意义上缺少验证用户，每个需要安全性的用例都应该包含它，通常不扩展。
2. 仅当它与系统交互时，例如触发自动完成或以某种方式进行跟踪。通常不需要关系，关联可以帮助传达一些不明确的内容，但我不确定在这种情况下会是什么。
3. 不，实际上，角色是任何用户在经过身份验证后都可以浏览课程。您可以让学生、管理员和教师成为经过身份验证的人员或关联人员等的子类型
4. 。具体取决于情况。首先，你永远不会同时付款和注册，因此从用户的角度来看这是不可行的。 UML 中还有其他方法来连接支付课程费用的约束。流程图、状态图等。因为支付实际上是一项长期运行的交易，很难确定。我将亲自向学生展示外部支付系统与“支付”用例的交互。

请记住，除非您在大多数情况下生成代码，否则 UML 是关于沟通的，因此了解您的受众。不要害怕使用注释或约束，如果这是家庭作业，请使用约束并获得一些真正的分数。甚至可能对标志和付费课程用例施加限制。

Answer 2

1. 如果您希望管理员能够登录，那么他会有一个用例。我同意他很可能不会注册，所以也许您想将注册/登录分成两个用例？
2. 您不必制作“上课”用例。仅当用户与系统交互时才这样做。我的猜测是，他不会用系统“上课”，在这种情况下，它不会成为系统的用例。
3. 我认为你不会想从学生那里继承。首先，从现实的角度来看，这是没有意义的。这意味着老师是学生。您可以将该行为提取到另一个父类，但这可能会使层次结构太大且令人困惑。
4. 如果您询问“签署课程”是否包含“付费课程”是否正确，那么也许最好使用扩展。

另一个建议。 Actor 和用例之间的黑色箭头（通常在 UML 中表示“依赖关系”）应该是双向的、无箭头的线（这通常称为“关联”）至少 UML 标准是这么说的。