厨房里的流程图：当序列图遇上状态机模型

老张上周在程序员聚餐时闹了个笑话。他花了半小时解释自家咖啡机的智能逻辑，最后却用手比划着说："就像炒菜时先放油还是先放葱那样..."引得大家哄堂大笑。其实这种困惑每个建模工程师都经历过——面对业务逻辑时，到底该用序列图还是状态机？让我们从灶台边的生活场景说起。

炒菜锅里的可视化工具

把生鲜食材变成美味佳肴的过程，像极了软件系统的运作。西红柿炒蛋的制作流程可以用两种方式描述：

• 菜谱模式：热锅→倒油→炒蛋→盛出→炒番茄→混合（这就是序列图的思路）
• 灶台状态：待机→加热中→翻炒模式→保温（这更像状态机的视角）

序列图：看得见的操作流水线

就像微波炉的操作面板，序列图擅长展示明确的时间顺序。去年智能冰箱项目组用这种模型优化了制冷系统：

• 压缩机启动信号比旧方案提前0.3秒
• 化霜周期精确到分钟级
• 多传感器协作关系一目了然

优势	局限性	数据来源
时序关系明确	状态变化不直观	《UML精粹》第三版
参与者交互清晰	循环逻辑表达困难	IEEE建模标准
适合协议分析	系统全局视角缺失	2023年ICSE会议论文

状态机：智能家电的隐形逻辑

我家新买的空气炸锅有7种烹饪模式，每次转动旋钮时都能听到细微的继电器切换声。这种状态驱动的设计正是状态机的强项：

• 低温烘焙时的持续温控
• 断电记忆功能的实现
• 异常过热保护机制

维修师傅的经验之谈

家电维修部王师傅有本泛黄的笔记本，记录着各种故障代码对应的处理步骤。这就像软件调试时的选择策略：

当电饭煲出现E4错误

用序列图分析：用户按下开关→温控器检测→错误触发→蜂鸣器报警。但实际维修时，王师傅会检查：当前是煮饭状态还是保温状态？压力阀是否卡在特定位置？这时候状态模型更管用。

自动洗碗机的程序选择

强快洗模式需要同时满足水位、温度、时间三个条件，工程师在开发时采用了嵌套状态的设计。这种分层结构让节水算法优化了23%，但调试时发现状态迁移路径增加了7条。

对比维度	序列图	状态机
核心关注点	消息传递时序	系统状态演变
变更成本	低（调整顺序）	高（重构迁移）
调试效率	路径明确	覆盖状态组合
适用场景	协议开发	设备控制

烘焙中的混合建模

高级面包机的发酵功能既需要精确的温度时间控制（序列），又要处理面团状态变化（状态）。某厂商的解决方案是：

• 主流程用序列图规划阶段任务
• 每个阶段内用状态机管理参数
• 关键转折点设置状态检查桩

窗外的送餐机器人正在路口等待行人通过，它的导航系统同时运行着交通规则序列和避障状态集。远处飘来邻居家红烧肉的香气，不知道他们家的智能灶台用的是哪种控制模型...