4、实时需求捕获：利益相关者分析、场景建模、用例图（UML）
好，咱们进入第四章。实时需求捕获。
说实话，很多做实时系统的工程师，一上来就画时序图、写状态机。这其实是个坑。你连谁在用这个系统、系统要处理什么场景都没搞清楚，画出来的时序图大概率是空中楼阁。我早年吃过这个亏，一个航空电子的项目，需求文档写了三百页，结果到集成测试才发现，飞行员的操作习惯跟我们的设计完全对不上。嗯，从那以后，我养成了一个习惯：先做利益相关者分析，再做场景建模，最后才画用例图。
4.1 利益相关者分析：谁在跟你的系统打交道？
实时系统不是孤立的。它一定存在于某个更大的系统里，跟人、跟其他设备、跟环境交互。利益相关者分析，说白了就是搞清楚：谁在乎这个系统？谁会被这个系统影响？
我个人习惯把利益相关者分成三类：
- 直接操作者：比如飞行员、手术医生、工厂操作员。他们直接跟系统交互，对响应时间、操作手感有最直观的感受。
- 间接影响者：比如乘客、患者、生产线上的下一道工序。他们不直接操作，但系统的实时行为会直接影响他们的体验或安全。
- 系统维护者：比如诊断工程师、系统管理员。他们关心的是系统的可观测性、可调试性，以及故障时的恢复能力。
一个真实的教训：我曾经参与一个汽车刹车控制系统的项目。我们花了大量精力分析驾驶员的踩刹车行为，却忽略了维修技师的需求。结果系统上线后，维修技师发现无法通过诊断接口读取刹车踏板的实时位置数据，导致故障排查极其困难。最后不得不紧急打补丁，增加了诊断数据通道。
你看，利益相关者分析如果漏了人，后面所有的工作都可能要返工。我的建议是：在项目启动阶段，拉一个清单，把能想到的所有利益相关者都列出来，然后逐一分析他们的关注点。
4.2 场景建模：把需求变成故事
利益相关者分析完了，接下来做什么？我个人习惯是写场景。场景是什么？就是一段故事，描述某个利益相关者在特定环境下，跟系统交互完成某个目标的过程。
为什么要写场景？因为场景能帮你发现那些藏在字里行间的隐含需求。你想想看，需求文档里写「系统应在100ms内响应刹车指令」，这很清晰对吧？但场景会告诉你：如果刹车指令和方向盘转向指令同时到达，系统该怎么处理？如果刹车指令在系统刚启动时到达，又该怎么处理？
场景建模我一般用三步走：
- 定义触发条件：什么事件启动了这次交互？比如「驾驶员踩下刹车踏板」。
- 描述交互流程：系统感知到什么？做出什么反应？利益相关者又有什么反馈？
- 明确结束状态：交互完成后，系统处于什么状态？利益相关者得到了什么结果？
举个例子，一个简单的场景：
场景名称：紧急刹车
触发条件：驾驶员以超过50N的力踩下刹车踏板
交互流程：
1. 系统在5ms内检测到踏板力超过阈值
2. 系统在10ms内激活制动主缸
3. 系统在20ms内将制动压力提升至目标值的90%
4. 系统在50ms内点亮刹车灯
5. 系统在100ms内完成ABS预充油
结束状态：车辆以最大减速度制动，刹车灯亮起，ABS系统就绪你看，这个场景里隐含了多少实时需求？每个步骤都有明确的时间约束。这些约束如果只写在需求文档里，很容易被忽略。但放在场景里，它就变成了一个完整的故事，所有人都能看懂。
我的一个小技巧：写场景的时候，尽量用「普通人能看懂的语言」。别一上来就写「ECU通过CAN总线接收制动信号」，而是写「驾驶员踩下刹车」。等场景确认了，再细化成技术语言。这样能确保非技术背景的利益相关者也能参与评审。
4.3 用例图（UML）：把场景画出来
场景写好了，接下来就是画用例图。用例图是UML里最简单、也最容易被低估的图。说白了，它就是一张图，告诉你：谁（角色）能用系统做什么（用例）。
画用例图，我一般遵循几个原则：
- 角色用小人表示：每个角色对应一个利益相关者。注意，角色可以是人，也可以是外部系统。比如「ABS控制器」就是一个角色，它跟你的刹车系统交互。
- 用例用椭圆表示：每个用例对应一个完整的交互场景。用例的名字要动词+名词，比如「执行紧急刹车」、「诊断系统状态」。
- 关系用线条表示：角色和用例之间用实线连接，表示「谁发起什么用例」。用例之间可以用虚线箭头表示包含（include）或扩展（extend）关系。
举个例子，一个刹车控制系统的用例图可能包含：
| 角色 | 用例 | 说明 |
|---|---|---|
| 驾驶员 | 执行正常刹车 | 常规减速操作 |
| 驾驶员 | 执行紧急刹车 | 全力制动，触发ABS |
| 维修技师 | 诊断系统状态 | 读取实时数据、故障码 |
| ABS控制器 | 执行防抱死控制 | 在紧急刹车时介入 |
注意，用例图不是流程图。它不描述步骤顺序，只描述功能边界。你想想看，用例图的作用是什么？是让所有利益相关者达成共识：系统到底要做什么，不做什么。边界清晰了，后面的设计才不会跑偏。
我曾经踩过的坑：有一次，我把用例图画得太细了，把每个步骤都画成了用例。结果图变得极其复杂，谁也看不懂。后来我明白了，用例图要保持在「业务功能」层面，不要深入到「技术实现」层面。一个用例应该对应一个完整的、有意义的业务目标，而不是一个技术操作。
4.4 三者如何配合？
利益相关者分析、场景建模、用例图，这三者不是孤立的。我个人习惯的工作流是这样的：
- 先做利益相关者分析，列出所有角色。
- 针对每个角色，写几个关键场景。
- 把场景提炼成用例，画用例图。
- 用用例图跟利益相关者确认，看有没有遗漏。
- 确认后，把场景里的时间约束提取出来，作为后续时序分析的输入。
你看，这个流程走下来，需求捕获就不是拍脑袋了，而是有根有据的。每个需求都能追溯到某个利益相关者的某个场景。这对后续的验证和变更管理，帮助非常大。
嗯，这一章就到这里。下一章，我们会进入时序规格定义的核心——如何用时间约束来描述实时行为。到时候，我会分享一些我在实际项目中用过的模板和工具。