小虾汉斯1. 用例建模基础：从电梯控制说起
我第一次接触用例建模是在2008年参与一个电梯控制系统项目时。当时需求文档写了上百页，但开发团队和客户对"如何判断电梯应该响应哪个楼层请求"的理解始终存在分歧。直到我们引入用例技术，用可视化的椭圆和火柴人厘清了所有交互场景，项目才重回正轨。
1.1 参与者的本质与识别
在电梯控制系统中，参与者（Actor）远不止按下按钮的乘客。根据我的项目经验，完整的参与者清单应该包括：
- 显性参与者：乘客（通过按钮面板交互）、维修人员（通过控制面板交互）
- 隐性参与者：重量传感器（检测超载）、红外传感器（检测门障）、电机编码器（反馈电梯位置）
- 时间参与者：定期维护提醒、空闲时的节能模式计时器
关键经验：不要被UML的"火柴人"符号限制思维。我曾见过团队争论"传感器该不该画成人形"，这完全偏离了重点。参与者本质是任何与系统产生数据或控制流交互的实体。
1.2 用例的原子性设计原则
好的用例应该像乐高积木——足够原子化且可组合。在电梯项目中，我们最初设计的"运送乘客到目标楼层"用例就犯了典型错误：
- 混合了门控制、移动控制和调度逻辑
- 隐含假设乘客会配合完成整个流程
- 没有考虑紧急停止等异常路径
重构后的用例组：
code复制[乘客部分]
- 请求电梯（无电梯在楼层时生成调度任务）
- 选择目标楼层（需验证权限卡）
- 取消请求（长按按钮）
[电梯部分]
- 执行单层移动（包含加速/匀速/减速状态）
- 处理停层请求（判断是否应该停靠）
- 紧急制动（响应消防信号或超重）
[门控制]
- 安全开门（需满足停靠且无移动条件）
- 安全关门（检查障碍物和最大等待时间）
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 需求捕获：前置/后置条件的艺术
2.1 条件表达的精确性
在医疗设备公司的合作项目中，我们曾因模糊的"系统应确保安全"需求导致FDA认证受阻。改用形式化的前置/后置条件后，审查通过率显著提升。例如：
血压监测用例：
text复制前置条件:
- 袖带压力 > 患者收缩压 + 20mmHg
- 最近30秒内无肢体移动警报
- 设备自检状态 = OK
后置条件:
- 存储的舒张压/收缩压值误差 ≤ ±3mmHg
- 生成带时间戳的测量记录
- 如检测到心律失常则