状态机图 - 同一对象的两个状态
State Machine Diagram - Two States for same object
我正在绘制类似于 Git 的情况，其中您可以同时拥有多个状态的单个文件（即具有暂存更改和未暂存更改的文件）。在这种情况下，我有三个主要状态：
- 未经编辑的文件
- Edited/unstaged 文件
- 暂存文件
是否可以显示单个文件同时处于状态 2 和状态 3 而无需将所有状态信息复制到另一个状态（即状态 4。暂存和 edited/unstaged 文件）。这是一个简化的图表：
我认为您的问题源于您试图将两个不同的状态机建模为一个。
第一个是Unedited/Edited State Machine，第二个是Staging。文件将成为两个状态机的主题，但这些状态机中的状态相互独立：文件是已暂存还是未暂存 不依赖于 文件已被暂存编辑； 取决于 您作为用户 是否告诉 Git 暂存文件。您可以暂存未编辑的文件，也可以选择不暂存已编辑的文件。
编辑器在文件名称上显示 "E" 或 "S" 是关于您希望如何传达文件所处状态的选择。我假设文件是未编辑但已上演，其名称将显示 "S"，而不管文件未被编辑的面貌如何。显示这些符号是行为逻辑，不是由状态决定的，而是由对它们的解释和它们的可能组合决定的。
根据你提供的状态图，我不确定，但也许你想用状态机来表达开发过程？先编辑然后上舞台很常见，但您也可以反过来做。您是否考虑过使用 Activity 图来表达流程？
状态机基础知识
在你的SM中，没有区域，没有合成状态，也没有子机。因此，在给定时间 最多只能有一个状态处于活动状态 。它不是完全那样写的，但它来自 UML 规范中 SM 的语义，尤其是：
A behavior StateMachine comprises one or more Regions, each Region containing a graph (possibly hierarchical) (...). A particular execution of a StateMachine is represented by a set of valid path traversals through one or more Region graphs, triggered by the dispatching of an Event occurrence (...). Due to its event-driven nature, a StateMachine execution is either in transit or in state, alternating between the two. It is in transit when an event is dispatched that matches at least one of its associated Triggers.
通过转换和状态的图遍历机制明确了两个状态不能同时处于活动状态。
更复杂的状态机
状态机可能要复杂得多。首先，一个SM可以由Regions组成：
A Region denotes a behavior fragment that may execute concurrently with its orthogonal Regions. Two or more Regions are orthogonal to each other if they are either owned by the same State or, at the topmost level, by the same StateMachine.
此外 复合状态 可能有子状态：所以如果这个状态是活跃的，它的子状态也可能会活跃。 submachine 可能指的是更复杂的情况。
在这样复杂的 SM 中，机器的当前状态实际上是跨活动区域的状态层次结构中几个兼容活动状态的 配置。
你有什么要求？
每当你觉得几个状态可能同时相关时，你必须进一步分解你的状态，并识别那些相关的（例如：潜在的子状态）和那些独立的（正交区域）。
换句话说，如果Unedited file、Edited/unstaged file和Staged file不充分，独立于GIT语义，你可以想到：
- 区域 1：
Undedited、Edited 和区域 2：Staged、Unstaged，这给出了 4 种可能的配置：Undedited/Staged、Edited/Staged、Undedited/Unstaged 和 Edited/Unstaged。
- 如果某些组合是不可能的（例如
Undedited/Staged），您可以将 Unedited（隐含地始终未分级）和 Edited 视为具有子状态的复合状态Staged、Unstaged，给出了潜在的配置 Edited.Unstaged 和 Edited.Staged
- 或者可能缺少一些状态：例如
new（总是隐含地未分阶段）committed-a-first-time，它可能有 2 个区域（如上面的第一个项目符号）
- 等...
可以指导您的状态分析的是找到一个最能以独特且明确的方式描述状态的不变条件。
历史
SM 历史记录无法解决您的并发状态问题：
The concept of State history (...) is a convenience concept associated with Regions of composite States whereby a Region keeps track of the state configuration it was in when it was last exited. This allows easy return to that same state configuration, if desired, the next time the Region becomes active (...), or if there is a local Transition that returns to its history.
结论
你的问题的解决方案可能在SM之外。例如，一个被编辑然后暂存的文件有两个版本：本地驱动器上的当前版本是可编辑的，以及暂存的不可变版本在 GIT 存储库中。在这种情况下，您确实拥有已编辑的暂存版本和未编辑的（与暂存版本相比）版本。这两个并发状态与不同的对象相关，每个对象都有自己的 SM。
我正在绘制类似于 Git 的情况，其中您可以同时拥有多个状态的单个文件（即具有暂存更改和未暂存更改的文件）。在这种情况下，我有三个主要状态：
- 未经编辑的文件
- Edited/unstaged 文件
- 暂存文件
是否可以显示单个文件同时处于状态 2 和状态 3 而无需将所有状态信息复制到另一个状态（即状态 4。暂存和 edited/unstaged 文件）。这是一个简化的图表：
我认为您的问题源于您试图将两个不同的状态机建模为一个。
第一个是Unedited/Edited State Machine，第二个是Staging。文件将成为两个状态机的主题，但这些状态机中的状态相互独立：文件是已暂存还是未暂存 不依赖于 文件已被暂存编辑； 取决于 您作为用户 是否告诉 Git 暂存文件。您可以暂存未编辑的文件，也可以选择不暂存已编辑的文件。
编辑器在文件名称上显示 "E" 或 "S" 是关于您希望如何传达文件所处状态的选择。我假设文件是未编辑但已上演，其名称将显示 "S"，而不管文件未被编辑的面貌如何。显示这些符号是行为逻辑，不是由状态决定的，而是由对它们的解释和它们的可能组合决定的。
根据你提供的状态图，我不确定，但也许你想用状态机来表达开发过程？先编辑然后上舞台很常见，但您也可以反过来做。您是否考虑过使用 Activity 图来表达流程？
状态机基础知识
在你的SM中，没有区域，没有合成状态，也没有子机。因此，在给定时间 最多只能有一个状态处于活动状态 。它不是完全那样写的，但它来自 UML 规范中 SM 的语义，尤其是：
A behavior StateMachine comprises one or more Regions, each Region containing a graph (possibly hierarchical) (...). A particular execution of a StateMachine is represented by a set of valid path traversals through one or more Region graphs, triggered by the dispatching of an Event occurrence (...). Due to its event-driven nature, a StateMachine execution is either in transit or in state, alternating between the two. It is in transit when an event is dispatched that matches at least one of its associated Triggers.
通过转换和状态的图遍历机制明确了两个状态不能同时处于活动状态。
更复杂的状态机
状态机可能要复杂得多。首先，一个SM可以由Regions组成：
A Region denotes a behavior fragment that may execute concurrently with its orthogonal Regions. Two or more Regions are orthogonal to each other if they are either owned by the same State or, at the topmost level, by the same StateMachine.
此外 复合状态 可能有子状态：所以如果这个状态是活跃的，它的子状态也可能会活跃。 submachine 可能指的是更复杂的情况。
在这样复杂的 SM 中，机器的当前状态实际上是跨活动区域的状态层次结构中几个兼容活动状态的 配置。
你有什么要求？
每当你觉得几个状态可能同时相关时，你必须进一步分解你的状态，并识别那些相关的（例如：潜在的子状态）和那些独立的（正交区域）。
换句话说，如果Unedited file、Edited/unstaged file和Staged file不充分，独立于GIT语义，你可以想到：
- 区域 1：
Undedited、Edited和区域 2：Staged、Unstaged，这给出了 4 种可能的配置：Undedited/Staged、Edited/Staged、Undedited/Unstaged和Edited/Unstaged。 - 如果某些组合是不可能的（例如
Undedited/Staged），您可以将Unedited（隐含地始终未分级）和Edited视为具有子状态的复合状态Staged、Unstaged，给出了潜在的配置Edited.Unstaged和Edited.Staged - 或者可能缺少一些状态：例如
new（总是隐含地未分阶段）committed-a-first-time，它可能有 2 个区域（如上面的第一个项目符号） - 等...
可以指导您的状态分析的是找到一个最能以独特且明确的方式描述状态的不变条件。
历史
SM 历史记录无法解决您的并发状态问题：
The concept of State history (...) is a convenience concept associated with Regions of composite States whereby a Region keeps track of the state configuration it was in when it was last exited. This allows easy return to that same state configuration, if desired, the next time the Region becomes active (...), or if there is a local Transition that returns to its history.
结论
你的问题的解决方案可能在SM之外。例如，一个被编辑然后暂存的文件有两个版本：本地驱动器上的当前版本是可编辑的，以及暂存的不可变版本在 GIT 存储库中。在这种情况下，您确实拥有已编辑的暂存版本和未编辑的（与暂存版本相比）版本。这两个并发状态与不同的对象相关，每个对象都有自己的 SM。