我可以在我的用例中添加'system‘作为参与者吗？

Question

我正在为我的毕业设计开发一个考勤系统应用。简而言之，基本上讲师每天使用API为每个班级生成二维码，学生扫描二维码并在数据库中设置他们的出勤状态。

然而，由于API生成代码，我想知道:我是否应该添加一个名为'system‘的辅助角色来表示API？

另外，对于登录，系统应该有一个基本的2FA机制，我想知道我在这里所做的是否正确？

​

​

Answer 1

是否应该添加一个名为'system‘的辅助角色来表示应用编程接口？

按照您的建模方式，您暗示还有另一个名为"system“的软件，它为您设计的软件提供二维码。

这可能不是真的，因此删除参与者"system“。

右侧的所有用例都是功能分解。别干那事。这不是用例图的目的。

左边的用例很好(除了"login"，请看我的单独评论)

Answer 2

以下元素是成功的用例建模的关键，并且可以直接从UML2.5.1规范(p639和640)派生：

• 用例指定主体(系统)提供的一组行为，具有对参与者有价值的可观察结果，并且无需引用系统的内部结构
• 参与者位于主体(系统)之外。

如果QR码是由同一系统生成的，则不能有System执行元:系统不在其自身之外。二维码生成将只是所提供的行为集的一部分。

如果QR码是由另一个系统生成的，则取决于：

• 如果另一个系统只是系统内部结构所需的辅助系统，但与用户无关，则不应将其显示为参与者；

• 如果另一个系统是一个独立的系统，特别是如果1)它可以由人工操作员替换；或者2)它的存在与业务干系人相关(例如，天气系统、股票报价系统等)；或者3)你的系统帮助另一个系统实现它的目标；那么你可以将它显示为一个参与者(甚至应该在案例2中)。

更普遍的是，围绕登录用例存在一些争议(对相反观点的详细解释：here)。我建议不要使用它。但是，如果您删除Verify (这是系统执行的操作，而不是对用户有价值的事件)，请删除Bad password (这是一个将触发一些操作的事件，但肯定不是用户所重视的事件)。最后，如果是密码登录，SSO登录或MFA登录都无关紧要:所有的tehrse都只是实现目标的手段。让这些详细信息来描述登录场景。

还要记住，用例之间没有顺序(这是为什么使用登录用例不是一个好主意的另一个原因)。