State Machine Diagram - Two States for same object

Question

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:

Answer 1

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:

• region 1: Undedited, Edited and region 2: Staged, Unstaged, which gives 4 potential configurations: Undedited/Staged, Edited/Staged, Undedited/Unstaged, and Edited/Unstaged.
• if some combinations are not possible (e.g. Undedited/Staged) youd could think of Unedited (implicitely always unstaged) and Edited as composite state with substates Staged, Unstaged, which gives the potential configurations Edited.Unstaged and Edited.Staged
• Or maybe there are some missing states: e.g. new (always implicitely unstaged) committed-a-first-time, which could have 2 reagions (as in the first bullet above)
• etc...

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.

Answer 2

I believe your problem stems from the fact that you are trying to model two different state machines as one.

The first is the Unedited/Edited State Machine, the second is to do with Staging. The File will be the subject of both State Machines, but the states in these machines are independent of one another: Whether the File is Staged or Un-staged is not dependent on the File having been Edited; it is dependent on whether you as a user have told Git to Stage the File or not. You can Stage a File that is Unedited, and you can choose not to Stage a File that is Edited.

The editor displaying a "E" or an "S" against the name of the File is a choice about how you want to communicate the states a File is in. I assume that a File that is not Edited, but is Staged, would have an "S" displayed by its name, regardless of the face that the File had not been Edited. Displaying these symbols is behavioural logic that is not dictated by the states, but by the interpretation of them and the possible combinations of them.

From the State diagram you have included, I'm not sure, but maybe are you trying to express the process of development in a State Machine? It would be common to Edit and then Stage, but you could do it the other way around. Have you thought about using an Activity Diagram instead to express the process?