Behavioral vs Protocol State Machines

The UML Specification (here is a link to version 2.5.1, look under section 14.1) describes two types of state machines…

These two kinds of StateMachines are referred to as behavior state machines and protocol state machines respectively.

The main difference between the two, is that for protocol state machines, all of the behaviors are defined in the transitions.

Protocol State Machines

Let’s look at an example of a protocol state machine for a Soda vending machine…

As we can see, all of the actions for this state machine are called on the transitions. Also, take a look at the names of the states… OFF, ON_READY, WAITING. The thing to notice is that the states aren’t doing anything.

The vast majority of the state machines that have been written to date are protocol state machines and they work great and can be run very efficiently on many small, embedded devices. Think vending machines, traffic signals, alarm clocks, etc.

Behavioral State Machines

Now, lets take a look at an example of a behavioral state machine, where we’ll use an Anti-Aircraft (AA) Gun…

Note the difference in the nature of the individual states in comparison to the protocol state machine, CALIBRATE, ACQUIRE_TARGET, etc. In a behavioral state machine, the states are actually doing something, and because of this fact you can’t just tie all of your actions to the transitions (despite the possible benefits of doing so).

Further, it’s fairly obvious that behavioral states like the ones shown above are going to need state-specific variables and functions. – This is extremely important, as we’ll see later, because it means that you are going to want your states to be classes, along with member variables and member functions.