State Model Concepts

Certain classes describe instances with interesting dynamic behavior; An instance comes into existence, participates in relationships and then goes out of existence. We call this a born-and-die lifecycle and we use a state model to formalize this behavior. A perfect example of this is the Driving Lane Change state model in the Ego Subsystem. Here the lane change begins at some point in time, develops a relationship with a target lane and then terminates successfully or unsuccessfully.

Other instances have relatively boring behavior. A Road Segment in the Road Subsystem, for example, is detected and then retained until it is no longer perceived to be relevant in the Ego Vehicle's environment. We do not use state models to manage such routine behavior.

An Executable UML state model consists of two components: a UML state machine diagram and a state table.

State machine diagram

In the case of a born-and-die lifecycle (the only pattern we are using at the moment), an initial transition triggers creation of the instance passing in any required parameter values. Upon success or termination a final deletion state is entered. When an instance enters such a state it executes whatever activity is defined in that state and is then automatically deleted.

Here we use standard UML, but we restrict ourselves to the Moore formulation of state machines. It is computationally equivalent to the alternative Mealy formulation with which you might be more familiar. Here's the difference:

In a Moore state machine, the activity triggered by an event is associated with the destination state. Thus, you enter a state and then immediately execute the activity in that state.

In a Mealy state machine, the activity is associated with the transition. So when an event occurs, a transition is selected, the activity on that transition executes leaving the instance in the target state.

The Moore formulation results in more states while the Mealy gives you more complicated transitions. One reason that our methodology uses Moore is because the state tables are easier to manage. And we don't generate code from the diagrams anyway. We generate code from the tables.

State table

The state machine diagram is useful for visualizing the core lifecycle. But when we start considering all the things that can go wrong, a table gives us a significantly more complete definition of behavior. This is because the diagram focuses on anticipated events. If we are in state A, event Y is expected and it triggers transition Q.

The table, on the other hand, considers what to do with each event in each state. A transition is only one of three options in the table. The other two are: ignore (just throw out the event and remain in the same state) and can't happen (model exits leaving the model execution engine to handle the exception in some non-model specific way).