首页/开发/系统分析与架构设计速查/状态机图(State Machine Diagram)
需求分析与建模61 条

状态机图(State Machine Diagram)

描述对象在生命周期内的状态与转换:转换由事件触发、可带守卫条件与动作,含初始伪状态与终止状态,适合订单、工单、设备等有明确状态的领域。

状态机图是什么

状态机图描述一个对象在生命周期内的状态与状态间的转换。每条转换由事件触发,可以带守卫条件与动作,图中包含初始伪状态与终止状态。它适合表达有明确生命周期的对象,例如订单、工单、支付单与设备,能把“什么状态允许什么操作”一次性讲清。状态名应使用业务语言,而不是数据库字段值或接口名。

Mermaid 示例

Mermaid 示例
stateDiagram-v2
  [*] --> 已创建
  已创建 --> 已支付 : pay()
  已创建 --> 已取消 : cancel()
  已支付 --> 已发货 : ship()
  已支付 --> 已取消 : refund() [未发货]
  已发货 --> 已完成 : confirm()
  已完成 --> [*]

基本信息

转换四要素源状态、事件[守卫]/动作、目标状态
常见动作entry/ 进入动作、exit/ 退出动作、do/ 持续活动
伪状态初始状态、终止状态、选择、汇合、历史状态
等价实现状态模式或状态机引擎,避免在业务代码里散落 if 判断
适用对象有明确生命周期与状态约束的实体

建模检查点

检查点说明常见问题
状态完整性每个状态都有进入与离开路径出现无法离开的悬挂状态
事件唯一同一状态下同一事件的结果确定同状态同事件指向两个目标
守卫条件条件互斥且可覆盖全部取值守卫重叠或存在未覆盖分支
异常路径超时、取消、失败都有出口只能前进不能回退
终态语义终止状态表示业务结束且不可再变更结束后仍被修改

典型使用场景

  • 订单状态管理:约束哪些操作在哪个状态可用,防止越权修改
  • 工单流转:审批、处理、关闭各环节的触发条件与责任人
  • 支付与退款:处理部分成功、退款中、退款失败等中间态
  • 设备管理:在线、离线、升级中、故障等状态与上报事件
  • 审批流程评审:与业务方逐条确认状态迁移与例外
  • 代码重构:把散落的 if 状态判断收敛成显式的状态机
状态机与活动图容易混用:状态机关注对象处在什么状态、什么事件让它变化;活动图关注流程步骤与并发,前者更适合生命周期,后者更适合工作流。
把接口名或数据库字段值当状态名,会让业务方无法评审,模型也难以与业务规则对齐。

易错点

  • 状态与业务动作不加约束,任意接口都能改状态,数据出现“已发货又退回已创建”这类脏值
  • 守卫条件重叠或不完整,同一事件在两个条件下都能触发,行为不确定
  • 缺少取消、超时等异常出口,异常单据卡在中间状态无法处理
  • 只在文档里画状态机,代码仍用散落的 if 判断,实现与模型长期不一致
  • 用状态机表达跨多个聚合的完整流程,边界过大导致模型无法落地

数据来源与参考

  • OMG UML 2.5.1 规范
  • David Harel 状态图相关论文(1987)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌