13.2. State Machines

A finite-state machine (FSM) is an abstract mathematical model of computation (with less computational power than a Turing machine), representing a special case of the more general concept of state transition systems. FSMs have been extended in various ways. In particular, David Harel's (1987) State Chart formalism and diagram language has heavily influenced the use of state machines in Object-Oriented modeling resulting in UML's state machine diagrams.

Since they provide a way to capture how objects change state in response to events, state machines are used in computer science for describing object lifecycles and in systems engineering for modeling simple reactive systems, such as vending machines or elevators.

An example of a simple mechanism that can be modeled by a state machine is a turnstile, a gate with three rotating arms, one across the entryway, as used to control access to subways. Initially the arms are locked, blocking the entry, preventing patrons from passing through. Depositing a coin in a slot on the turnstile unlocks the arms, allowing a single customer to push through. After the customer passes through, the arms are locked again until another coin is inserted.

This state machine diagram can be expressed in SysML2 in the following way:

tem def Coin;
item def Push;
state TurnstileStateMachine {
  entry; then Locked;
  state Locked;
  accept Coin then Unlocked;
  accept Push then Locked;
  state Unlocked;
  accept Coin then Unlocked;
  accept Push then Locked;
}

In SysML2, the states of a state machine are modeled as special kinds of actions called state actions. Thus, in a SysML2 model, we can declare state types (and state properties) that may include all kinds of action type elements, such as succession properties as well as merge, decision, fork and join action properties.

Considering a state as an action is incompatible both with the commonsense understanding of the term "state" and with its treatment in philosophy.

The possible transitions between the states of a state machine are modeled as transition properties, which are implicitly typed by the action type States::StateTransitionAction. A transition property relates a source state property to a target state property, declaring that it is possible to transition from a source state action performance to a new target state action performance.

A SysML2 state machine can be modeled as a single-valued state property of a part type, as in the following example:

item def DataPacket;
item def Exit;
part def Relay {
  port incoming;
  port outgoing;
  state relay_behavior[1] {
    transition first start then waiting;
    state waiting;
       
    transition
      first waiting
      accept Exit via incoming
      then done;
         
    transition receiveData
      first waiting
      accept packet : DataPacket via incoming
      then sending;
         
    state sending {
      entry send receiveData.packet via outgoing;
    }
    transition first sending then waiting;
  }
}

A transition is triggered under the following conditions:

1. A transition can only be triggered during a performance of its source state.
2. If a transition property has a guard expression, a transition can only be triggered if the guard expression evaluates to true.
3. If a transition property has an accept action property, then a transition is triggered if the accept action can accept an incoming transfer via its receiver parameter and the above conditions are met.

If a transition is triggered, then it establishes a succession relationship between the source state performance and a new target state performance, and the transition is performed as follows:

1. If the source state has a do action that is still being performed, that is interrupted.
2. Then, if the source state has an exit action, that is performed.
3. Once that completes, if the transition has an effect action, that is performed.
4. Once that completes, if the target state has an entry action, that is performed.
5. Once that completes, if the target state has a do action, that is performed.

The source of a transition property must be a state property, but its target may be any action property. In particular, a transition to done indicates that the source state is the final state of the containing state performance, though the containing state does not necessarily terminate immediately. Alternatively, a transition to a terminate action may be used to immediately terminate the containing state performance if that transition is triggered.