移动端应用用例图参与者识别及设计合理性咨询

你的设计方向没问题，但可以针对核心需求做简化，让图更清晰直观，具体调整点如下：

1. 聚焦核心用例，合并非必要分支 #

你的核心需求是更改智能镜状态，所以不用把登录、注册这类前置操作拆成独立用例——除非账号体系是系统核心功能。可以把「用户登录/注册」作为核心用例的前置条件，只保留最核心的用例：「通过移动端App修改智能镜模块设置」。

2. 简化参与者设定 #

• 主参与者只保留User（通过移动端App完成交互即可，无需把App单独作为参与者）；
• Firebase和REST API属于系统内部依赖的组件，不用设为次要参与者。用例图的核心是展示用户与系统功能的交互，内部服务/接口可以用注释说明，或者包含在系统边界内；
• 如果需要体现智能镜的独立行为（比如显示配对二维码），可以把「智能镜设备」设为次要参与者，对应「显示配对二维码」的辅助用例。

3. 简化后的用例结构参考 #

• 主用例：修改智能镜模块设置
  • 前置条件：用户已完成身份验证，且移动端App已与智能镜配对
  • 交互流程：用户在App调整设置 → 设置同步至Firebase → REST API读取配置并更新智能镜状态
• 辅助用例：配对智能镜
  • 触发条件：智能镜未关联用户
  • 交互流程：智能镜显示配对二维码 → 用户用App扫码 → 绑定用户与智能镜设备

这样调整后，用例图会更贴合你的核心需求，结构也更简洁，符合UML用例图聚焦用户核心交互的设计原则。

内容的提问来源于stack exchange，提问作者Adem Othman