4. 需求分析与建模：用例图与活动图在嵌入式系统中的应用
说到需求分析，很多嵌入式工程师第一反应是「写文档太虚了，不如直接开干」。我以前也这么想，直到有一次项目做到一半，客户突然说「我要的不是这个功能」——嗯，那感觉，真叫一个酸爽。
其实需求分析不是让你当作家，而是让你把脑子里的想法画出来。画出来，大家才能对齐。今天我就聊聊两个最实用的工具：用例图和活动图。
4.1 为什么嵌入式系统需要用例图？
用例图（Use Case Diagram）说白了就是回答三个问题：
- 谁在用这个系统？
- 他要干什么？
- 系统给他什么结果？
在嵌入式领域，这个「谁」不一定是人。可能是另一个MCU、一个传感器、一个云平台。我习惯把外部交互者统称为「Actor」——参与者。
核心原则：用例图只关注「做什么」，不关注「怎么做」。别在用例图里画流程图，那是活动图的事。
4.2 用例图的核心元素
| 元素 | 符号 | 嵌入式示例 |
|---|---|---|
| 参与者（Actor） | 小人图标 | 用户、传感器、上位机、云服务器 |
| 用例（Use Case） | 椭圆 | 读取温度、发送报警、校准零点 |
| 系统边界 | 矩形框 | 智能温控器系统 |
| 关系 | 连线 + 箭头 | 包含（include）、扩展（extend）、泛化 |
我的习惯：画用例图时，先把所有参与者列出来，再给每个参与者列他关心的功能。别贪多，一张图控制在8-12个用例以内，多了就拆子系统。
4.3 实战案例：智能灌溉控制器
假设我们要做一个智能灌溉系统。我带着团队做需求分析时，第一版用例图是这样的：
避坑指南：我曾经在一个项目里把「读取温度」和「计算平均值」画成两个用例，结果评审时被怼了——用例是给用户看的，不是给程序员看的。用户只关心「读取温度」，至于怎么算平均值，那是设计阶段的事。
4.4 活动图：把用例展开成流程
用例图画完了，大家知道「要做什么」了。但具体怎么做？这时候活动图（Activity Diagram）就派上用场了。
活动图本质上就是流程图，但它比普通流程图多了几个好东西：
- 泳道（Swimlane）：谁负责哪一步，一目了然
- 并发分叉（Fork）：多个任务同时跑
- 事件流：带触发条件的动作
我习惯把活动图用在两个地方：一是描述一个用例的内部流程，二是描述多个Actor之间的交互流程。
4.5 实战：自动灌溉决策的活动图
拿刚才的「自动灌溉决策」用例来说，我们把它展开成活动图：
我的经验：活动图里的并发分叉特别适合嵌入式系统。比如这个例子，采集数据和写日志可以同时做，不用等一个完了再做另一个。我在做低功耗设备时，经常用并发分叉来优化任务调度——能并行就别串行，省时间就是省电。
4.6 用例图 vs 活动图：什么时候用哪个？
| 维度 | 用例图 | 活动图 |
|---|---|---|
| 关注点 | 系统功能边界 | 业务流程细节 |
| 使用阶段 | 需求分析初期 | 需求细化阶段 |
| 读者 | 客户、产品经理 | 开发、测试人员 |
| 粒度 | 粗粒度 | 细粒度 |
| 嵌入式典型场景 | 定义系统与外部的交互 | 描述中断处理、状态机流转 |
4.7 嵌入式需求建模的常见坑
做了这么多年项目，我踩过不少坑。挑几个典型的说说：
- 坑一：用例图里画了太多技术细节。 比如把「I2C通信」「SPI配置」画成用例。记住，用例是给业务看的，不是给驱动工程师看的。
- 坑二：活动图没有泳道。 没有泳道的活动图，你根本分不清哪个动作是谁干的。嵌入式系统里Actor多（MCU、传感器、上位机），泳道是刚需。
- 坑三：忽略了异常流程。 我曾经画了一个完美的灌溉流程，结果没考虑传感器断线的情况。现场跑起来，传感器一掉线，系统直接死循环。从那以后，我每个活动图都加一个「异常分支」。
避坑指南：画活动图时，一定要把「超时处理」「通信失败」「数据异常」这些分支画出来。嵌入式系统不像App，崩溃了可以重启——设备在现场，重启可能意味着停产。
4.8 小结：两张图，一个框架
用例图和活动图，一个管「做什么」，一个管「怎么做」。两者配合，基本能把嵌入式系统的需求说清楚。
我个人习惯的做法是：先画用例图，和客户确认功能边界；再针对核心用例画活动图，和团队对齐实现流程。两张图加起来，需求文档的骨架就有了。