我正在为我的毕业项目开发一个考勤系统应用程序。 简而言之，基本上教师每天都会使用 API 为每个班级生成二维码，学生扫描二维码，他们的出勤状态将被设置在数据库中。
但是，由于 API 生成代码，我想知道：我是否应该添加一个名为“system”的辅助角色来表示 API？
同样对于登录，系统应该有一个基本的 2FA 机制，我想知道我在这里所做的是否正确？
【问题讨论】：
标签： uml use-case use-case-diagram
我是否应该添加一个名为“system”的辅助角色来表示 API？
按照您对其建模的方式，您暗示还有另一个名为“系统”的软件为您设计的软件提供二维码。
这可能是不真实的，因此删除演员“系统”。
右侧的所有用例都是功能分解。不要那样做。这不是用例图的目的。
左侧的用例很好（“登录”除外，见我的单独评论）
【讨论】：
以下元素是成功用例建模的关键，可以直接从 UML 2.5.1 规范（p639 和 640）派生：
如果二维码是由同一系统生成的，则您不得有System 演员：系统不在其自身之外。 QR 码生成只是所提供的一系列行为的一部分。
如果二维码是由其他系统生成的，则取决于：
如果其他系统只是系统内部结构所需的辅助系统，但与用户无关，则不应将其显示为演员；
如果另一个系统是一个独立的系统，特别是如果 1) 它可以由人工操作员替换；或 2) 它的存在与业务利益相关者相关（例如天气系统、股票报价系统……）；或 3) 您的系统帮助其他系统实现其目标；那么您可以将其展示为演员（甚至应该在案例 2 中）。
更一般地，关于登录用例存在一些争议（对立观点的详细解释：here）。我建议不要使用它。但是，如果您删除Verify（这是系统执行的操作，而不是对用户有价值的操作），请删除Bad password（这是一个将触发某些操作的事件，但绝对不是用户的价值）。最后，如果是密码登录，SSO 登录或 MFA 登录都无所谓：所有这些都只是实现目标的手段。让这些细节用于登录场景的描述。
还要记住，用例之间没有顺序（这也是为什么使用登录用例不是一个好主意的另一个原因）。
【讨论】：