系统建模常常让人感觉像是在一堆方框和箭头构成的迷宫中穿行。虽然结构图定义了系统由什么组成，而行为图则定义了系统做什么。在这些图中，状态机图尤为突出，是捕捉系统动态行为的主要工具。它不仅仅是流程图，更是一个逻辑引擎，决定了系统如何随时间对事件作出响应。理解这些图中的隐藏逻辑，对于确保系统设计的稳健性至关重要。
本指南探讨了SysML状态机的机制。我们将超越基本语法，深入分析决定系统可靠性的架构决策。从嵌套层次结构到并发区域，每一个细节都至关重要。建模的精确性会直接转化为实现的精确性。
为何状态机定义了系统完整性 🔒
现代系统很少是线性的。它们在不同模式下运行，处理异常，并保留对过去事件的记忆。简单的步骤序列无法捕捉到一个系统在需要暂停、恢复或根据当前状态做出不同反应时的复杂性。状态机提供了描述这些条件的形式化方法。
在建模复杂系统时，仅依赖活动图会导致歧义。活动图展示流程，但它们本身并不追踪状态。状态机通过明确地定义系统在任何时刻的状态来弥补这一空白。这一区别对于安全关键系统、嵌入式控制器和分布式架构至关重要。
使用状态机的主要优势包括：
- 明确的状态定义： 系统可能存在的每一种状态都以可视化方式呈现。
- 事件驱动的逻辑： 变化的触发条件与状态转换之间有明确的关联。
- 历史状态保留： 在进入状态时能够记住先前的配置。
- 并发性： 建模多个同时发生的独立行为。
SysML 状态机的核心结构 🏗️
要解析其逻辑，必须理解基本的构成要素。状态机由状态和转换组成。这些元素通过事件和守卫进行交互。对每个组件的清晰理解可以防止建模错误在设计阶段蔓延。
状态与初始点
状态表示系统在满足不变式、等待事件或执行活动期间所处的条件。旅程始于初始点。这是一个实心黑圆圈，表示系统的起始状态。从这里出发，必须产生第一条转换，以定义进入行为。
转换与事件
转换连接一个状态到另一个状态。它代表状态的改变。要发生转换，通常需要满足三个条件：
- 事件： 必须发生某些事情（例如，信号到达、计时器超时）。
- 守卫条件： 必须求值为真的布尔表达式。
- 效果： 转换过程中执行的动作（例如，记录数据、发送消息）。
进入与退出动作
状态在进入或离开时通常需要特定的行为。这些行为被定义为进入和退出动作。
- 进入动作 (/entry)： 状态变为激活状态时立即执行。
- 退出动作（/exit）： 离开状态前立即执行。
- 执行活动： 系统处于该状态期间持续执行的动作。
考虑一个系统进入“校准”状态的场景。入口动作可能用于初始化传感器。执行活动可能运行持续检查。退出动作可能保存校准数据。如果没有这些区分，操作的时序将变得不明确。
精准管理状态历史 🕰️
SysML 最强大的功能之一是能够追踪历史。当系统离开一个复杂状态并稍后返回时，它是从头开始重启，还是从中断处继续？这一决定定义了系统在间歇性运行下的行为。
浅层历史与深层历史
历史状态使系统能够记住其过去的配置。有两种不同的类型：
- 浅层历史： 记住复合状态中的顶层状态。如果系统返回，它将进入最后的顶层子状态，忽略更深层的结构。
- 深层历史： 记住整个嵌套路径。如果系统返回，它将重新进入其之前所在的精确子状态，包括所有嵌套层级。
这种区分对经历复杂模式切换的系统至关重要。深层历史状态确保操作上下文得以保留，从而减少重新初始化流程的需求。
历史状态的实现
在图中，历史状态用一个内部带有‘H’的圆圈表示。它通常通过由事件触发的转换与状态相连。浅层历史与深层历史的选择必须明确记录，因为它会影响系统的恢复逻辑。
通过正交区域实现并发 ⚡
系统很少在单一维度上运行。例如，车辆系统会同时管理推进、制动和导航。这些行为通常相互独立，但又在同一系统实例中发生。SysML 通过正交区域来处理这种情况。
拆分与合并状态
为了建模并发，一个状态被厚条分隔成多个区域。该条作为拆分点。当系统进入复合状态时，所有区域会同时激活。合并条表示这些区域同步的位置。
正交建模的优势
- 解耦： 不同的关注点被分别建模。
- 清晰性： 降低了单一庞大状态机的复杂性。
- 可扩展性： 可以在不破坏现有逻辑的情况下添加新的并发行为。
然而，并发会引入同步风险。设计者必须确保跨区域的共享资源得到正确管理，以防止竞争条件。
何时使用状态机与活动图 ⚖️
状态机图和活动图之间常常会产生混淆。两者都描述行为，但它们的范围不同。选择正确的工具取决于所建模逻辑的性质。
| 特性 | 状态机图 | 活动图 |
|---|---|---|
| 主要关注点 | 系统模式和条件 | 流程流和算法 |
| 状态保持 | 显式（当前状态的记忆） | 隐式（变量保存数据） |
| 事件处理 | 反应式（由外部触发驱动） | 主动式（由数据流驱动） |
| 并发性 | 通过区域原生支持 | 通过分叉/汇合支持 |
| 最适合 | 控制逻辑、模式、状态 | 工作流、数据处理 |
当系统必须等待事件或维持特定模式时，使用状态机。当重点在于操作序列或数据转换时，使用活动图。通常需要采用混合方法，即一个活动触发状态机的转换。
常见的建模陷阱，应避免 ⚠️
即使是经验丰富的建模者也可能引入歧义。避免常见错误可确保模型保持可靠的规范性。
1. 状态过于细粒度
为每个微小的变量变化创建状态会导致图示过于密集，难以阅读。状态应代表系统的重大条件，而非每一个中间数据点。
2. 缺少默认转换
每个状态都应考虑意外事件。如果某个状态未定义特定事件，系统行为将未定义。应实现默认转换或通用状态处理机制来管理异常。
3. 循环依赖
在没有保护条件的情况下创建立即循环的转换可能导致无限执行。确保循环具有明确的退出条件或保护条款。
4. 忽略入口/出口效应
在状态中放置逻辑但未定义入口或出口效应，可能会隐藏副作用。务必明确说明状态激活或停用时会发生什么。
5. 控制与数据流的混合
状态机不是数据流图。虽然它们可以触发数据操作，但主要逻辑应以控制为导向。将数据操作保留在活动图或顺序图中。
将状态逻辑与结构模型集成 🔗
状态机并非孤立存在。它与系统的结构模型相互作用。状态机必须引用其他图中定义的部件、端口和信号。
与部件的关联
转换通常会调用系统特定部件上的操作。例如，“启动发动机”转换可能会调用“发动机控制器”部件上的操作。这种关联确保行为建立在物理或逻辑架构之上。
信号传播
状态机中的事件通常是信号。这些信号必须定义为消息流或接口规范。确保信号定义与接收方的预期一致，对于互操作性至关重要。
清晰系统行为的最佳实践 📝
为保持模型的清晰性和权威性，请遵循以下准则。
- 命名一致性：为转换使用动作动词（例如，“请求启动”、“中止过程”），为状态使用名词（例如，“空闲”、“处理中”）。
- 视觉层次：使用复合状态来分组相关逻辑。不要在顶层添加过多的转换，以免造成混乱。
- 守卫条件清晰性：保持守卫条件简单。如果条件复杂，应将其定义为其他位置的属性或函数。
- 文档化：为复杂状态添加注释，解释特定配置背后的原理。
- 评审循环：定期与利益相关者一起评审状态机，以确保逻辑符合操作需求。
复杂逻辑的高级模式 🚀
超越基础内容，SysML允许使用模式来处理复杂场景。
虚拟状态
虚拟状态用于在不增加新层级的情况下对状态进行分组。它们有助于在不影响逻辑转换的前提下，从视觉上组织图示。这使得图示保持整洁，同时维持逻辑分组。
宏状态
宏状态是作为父机器中单一状态的复合状态。它们适用于抽象。你可以将一个复杂的状态机定义为宏状态，并从更高级别的图中引用它。
子机状态
子机状态允许你引用整个外部状态机。这促进了复用。如果多个系统共享相同的认证逻辑，只需将其建模一次作为子机状态，并在需要的地方引用它。
关于实现原则的结论 📊
系统的逻辑嵌入在其行为之中。通过掌握状态机的细微差别，建模者可以创建出稳健、可维护且清晰的规范。从抽象需求到具体实现的过渡，正是通过这些图示得以实现的。
注重清晰性而非复杂性。使用层次结构来管理深度。使用历史记录来管理记忆。使用并发性来管理并行性。当这些原则得到一致应用时，系统的运行行为就变得可预测且可靠。图表成为一份动态文档，指导开发和测试。
随着系统的发展，持续优化模型。静态模型会很快过时。动态建模过程可确保系统逻辑始终与实际运行情况保持一致。