UML用例图问题

Question

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

• 如果我的系统有guest的注册/登录用例，是否应该为admin，user启用（我只想澄清，如果我有登录系统，我是否认为管理员，用户等是人谁已经登录到系统，所以我跳过它们与记录事物）？

• 如果我的系统有一个学生演员，即签署个人研讨会/课程，我是否（或我被允许）制作用例，参加课程＆＃39;＆＃39;为他们歌唱后，应该和那些人之间有关系

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

• 我的付款设置是否正确？

Answer 1

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

另一个建议。您在Actors和Use Cases之间的黑色箭头（通常表示UML中的“依赖关系”）应该是双向的，非箭头的，行（这通常称为“关联”）至少这是UML标准所说的

Answer 2

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

请记住，除非您在大多数时间生成代码，因此UML是关于沟通的，因此了解您的受众。不要害怕使用注释或约束，如果这是家庭作业，使用约束并获得一些真实点。甚至可能对标志设置约束并支付课程用例。