登录模块的用例图
Use Case Diagram for Login Module
我为我正在处理的登录模块制作了一个简单的用例。
在那里我有三种登录方式，我想知道这是否是正确的方式。
或者如果我有一个登录过程并且 Facebook、电子邮件和 Google 扩展到它是否更好。
感谢您的帮助。
您的图表中没有任何语法错误。
不过有几点要说：
Check suspended 和 Send reset email 似乎是动作而不是用例。要成为一个用例，它们至少应该暗示与参与者的交互。- 用户专业化并不是真正需要的，因为图表没有显示用例级别的细节。它的好处是提醒有不同类型的用户，但您可以通过其他方式传达此信息。
- 如果您选择保留它，因为从大局来看，参与者应该与系统交互中的角色相对应。如果系统是关于
volunteers协助blind and visually impaired people，谁能求助，就可以了。如果不是，它可能显得模棱两可。因为 accessibility requirements 应该是每个系统中每个用例的隐式要求，而不应该在用例图中需要明确的参与者专门化。
还有一些建议：
- 原则上，用例应该对参与者有价值并且对应于他们的一些目标。它旨在保持大局观，而不是分解系统将如何进行的细节。因此，保持简单。单个登录用例和最终重置密码用例似乎绰绰有余。
- 为了宣传大局，尽量让你的副演员一般化：
使用
Identity provider。这将帮助您设计一个具有合理分离关注点的未来证明系统：每当 new identity provider 出现时，您可以只实现一些 类 的新特化。无需更改您的用例，也无需从根本上审查您的设计。
我为我正在处理的登录模块制作了一个简单的用例。
在那里我有三种登录方式，我想知道这是否是正确的方式。
或者如果我有一个登录过程并且 Facebook、电子邮件和 Google 扩展到它是否更好。
感谢您的帮助。
您的图表中没有任何语法错误。
不过有几点要说：
Check suspended和Send reset email似乎是动作而不是用例。要成为一个用例，它们至少应该暗示与参与者的交互。- 用户专业化并不是真正需要的，因为图表没有显示用例级别的细节。它的好处是提醒有不同类型的用户，但您可以通过其他方式传达此信息。
- 如果您选择保留它，因为从大局来看，参与者应该与系统交互中的角色相对应。如果系统是关于
volunteers协助blind and visually impaired people，谁能求助，就可以了。如果不是，它可能显得模棱两可。因为 accessibility requirements 应该是每个系统中每个用例的隐式要求，而不应该在用例图中需要明确的参与者专门化。
还有一些建议：
- 原则上，用例应该对参与者有价值并且对应于他们的一些目标。它旨在保持大局观，而不是分解系统将如何进行的细节。因此，保持简单。单个登录用例和最终重置密码用例似乎绰绰有余。
- 为了宣传大局，尽量让你的副演员一般化：
使用
Identity provider。这将帮助您设计一个具有合理分离关注点的未来证明系统：每当 new identity provider 出现时，您可以只实现一些 类 的新特化。无需更改您的用例，也无需从根本上审查您的设计。