毕业设计考勤系统用例中能否将'system'作为参与者添加？

问题1：是否需要添加system次要参与者代表生成二维码的API #

• 先明确UML用例图的参与者核心定义：所有参与者都必须是考勤系统边界之外的交互实体，系统内部的接口、模块不属于参与者范畴
• 如果生成二维码的API是考勤系统自身封装的内部接口：完全不需要额外添加次要参与者，生成二维码的逻辑属于「教师创建考勤二维码」用例的内部实现步骤，无需暴露在用例的参与者层
• 如果二维码生成能力调用的是第三方独立服务：可以添加名为「二维码生成服务」的次要参与者，不要命名为system，该名称通常指代你开发的考勤系统本体，命名混淆会大幅降低用例图可读性

问题2：带2FA机制的登录用例设计合理性 #

参考用例图如下：

• 核心设计逻辑正确：将2FA作为登录环节的补充校验用例，符合用例设计的分层原则
• 可根据实际业务规则调整用例关系：
  • 若所有角色（教师、学生）登录都强制要求2FA：将「双因素验证」和「用户登录」用例设置为*包含（include）*关系，代表2FA是登录流程的必执行步骤
  • 若仅指定角色强制2FA、或用户可自主选择是否开启2FA：将二者设置为*扩展（extend）*关系，触发条件标注为「需要执行2FA校验」即可
• 优化建议：不要将2FA的内部实现步骤（如发送验证码、校验验证码）拆分为独立用例，用例是面向用户的可感知价值点，内部实现步骤无需单独列示

内容的提问来源于stack exchange，提问作者Sam Nakity