umlstate-diagram

State Machine Diagram - Two States for same object

I am diagramming a situation similar to Git, where you can have a single file in multiple states at once (i.e. a file with staged changes and unstaged changes). In this scenario, I have three main states:

  1. Unedited file
  2. Edited/unstaged file
  3. Staged file

Is it possible to show that a single file is in both state 2 and 3 without duplicating all the state information into another state (i.e. State 4. Staged and edited/unstaged file). Here is a simplified diagram:

enter image description here

Solution

  • State machine basics

    In your SM , there is no region, no composite state, nor submachines. There can therefore only be at most one state active at a given time. It's not written exactly like that, but it emerges from the semantics of the SM in the UML specs, inter alia:

    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.

    The graph traversal mechanism through transitions and states make it clear that two states cannot be active at the same time.

    More complex state machines

    State machines can be much more complex. First of all, a SM can be made of 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.

    Furthermore composite states may have sub-states: so if this state is active, a substate of it may get active as well. And submachines may refer to even more complex situations.

    In such comple SM, the curent state of the machine is in reality a configuration of several compatible active states in the hierarchy of states across the active regions.

    What are your requirements?

    Whenever, you feel that several states could be relevant at the same time, you must therefore decompose your states further, and identifying those who are related (e.g.: potential substates) and those who are independent (orthogonal regions).

    In other words, if Unedited file, Edited/unstaged file and Staged file are not sufficient, independently of GIT semantic, you could think of:

    What could guide your state analysis is to find an invariant condition that best describes the state in a unique and unambiguous way.

    History

    SM history will not resolve your concurrent state issue:

    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.

    Conclusions

    The solution to your problem may be outside theSM. For instance, a file which is edited and then staged, has two versions: the current version on the local drive that is editable, and the staged unmutable version in the GIT repository. In this case you have indeed the edited staged version active and the unedited (in comparison to the staged) version. The two concurent states relate to different objects, each having its own SM.