9.3 State Transition Table

Examination of the statechart diagram for the microwave oven reveals that the model fails to answer certain important questions:

• What happens if we press the button when cooking is complete?

• What happens if we press the button while cooking?

• What happens if we press the button when the door is open?

• Can we close the door when the door is already closed? (Put another way: What happens if we detect the doorClosed event when the door is already closed?)

The statechart diagram shows a set of states, events, and transitions, but the diagram cannot cover all possible combinations. In this section, we'll use an alternative representation^[2] of a state machine the state transition table (STT) to ensure completeness of the underlying model.

^[2] The underlying model is the same, we simply have two representations of it. One representation is graphical but incomplete, and the other is tabular, showing all combinations of states and events. Your tool should maintain the underlying model, not the diagram or the table.

9.3.1 Basics of the State Transition Table

A state machine's transitions can be presented in a state transition table as shown in Figure 9.4. In a state transition table, each row represents a state and each column represents an event. The cells are filled in to specify what happens when an object in a given state (the row) detects a particular event (the column).

Figure 9.4. State Transition Table Based on Microwave Oven Statechart Diagram

9.3.2 Discovering New Transitions

Empty cells on the STT represent combinations of states and events that may have been overlooked. Completing these will lead to a discussion among experts as to what features are required, and, one hopes, to a more complete model of the solution.

For example, pressing the button when cooking is complete currently does nothing. There's no entry showing any transition for this combination. Looking back to the specification of the oven, we find that this situation was in fact omitted: It is perfectly reasonable to start the oven again and to transition back to the Cooking state as shown in the revised STT and corresponding statechart diagram of Figure 9.5. (The new transition is shown in italics.)

Figure 9.5. Statechart Diagram and STT with Additional Transition

9.3.3 Discovering New States and Events

In many cases, analysis of a state machine using an STT may lead to new states and new events. In those cases, adding the new states and events will add new rows and columns to the state transition table.

In the last section we asked the question, "What happens if the user presses the button when the door is closed and cooking is complete?" We discovered a new transition. Now let's ask, "What happens if the user presses the button when the door is closed and the oven is cooking?" We decide that if the first button-press added a minute of time (from zero to one minute) and started the oven cooking, then another button-press should add another minute of time to the oven. Generally, if the user presses the button at any time when the oven is cooking, one minute is added to the cooking time. So if the oven has 40 seconds more cooking time to go, pressing the button twice sets the cooking time to 2 minutes and 40 seconds.

To address this, we could simply draw a transition from Cooking back to Cooking as shown in Figure 9.6, but the wrong actions occur when the second button-press occurs. The light and power tube are already on; we don't need to turn them on again. We want to add a minute to the timer; we don't want to set it to 1 minute. We therefore add a new state, CookingExtended, to the statechart diagram.

Figure 9.6. Wrong Transition Added to Extend the Cooking Period

Of course, you will need to analyze all the cells in those new rows and columns and add new transitions and possibly more states to the model. This also has the effect of adding a new row to the state transition table. Adding a new row to the state transition table adds a new state and some transitions to the statechart diagram. Figure 9.7 shows the combined effect of adding a new state to the statechart diagram and a new row to the state transition table.

The resulting model is "more complex" than before because it has an "extra" state. Yet the model should distinguish the various cases because they are different in the domain. A correct state machine has sufficient states to model properly all of the subtleties in the object's lifecycle. The purpose of modeling is to expose detail in the problem details such as the difference between what happens when the button is pressed the first time and what happens subsequent times.

9.3.4 Event Ignored and Can't Happen

Not every empty cell in the STT is a missing requirement. In some cases, a particular state-event combination may not cause a transition into a new state. For example, what happens if the cook presses the button on the microwave oven when the door is open? When the cooking is complete? You might say, "Nothing happens." But there are really two different kinds of "nothing." Under some situations, we really want nothing to happen; in other words, the event is ignored. In other situations, the event simply can't happen according to the rules and policies of the domain.

Event Ignored cell entry.

When a certain event can happen but causes no effect, the STT cell is filled in as "Event Ignored." In the case of the oven, pressing the button when the door is open has no effect. Figure 9.8 shows the state transition table with Event Ignored entries added. When an event is ignored, the object stays in the same state it is in and does not re-execute the procedure. In this way, an Event Ignored is different from a transition to the same state.

Figure 9.8. State Transition Table with "Event Ignored" Entries

Although the event is ignored in the sense of not causing a transition, it has been detected and consumed by the state machine. The event is not held until the object arrives in a state where the event can cause a transition.

Can't Happen cell entry.

If the event cannot happen when the object is in a particular state, record the fact by entering "Can't Happen" in the cell. The Can't Happen entry is reserved for occasions when the event simply cannot occur according to the rules and policies of the domain. For example, the oven cannot receive a doorClosed event when the oven is cooking. The door is already closed in this state; detecting this event in this state makes no sense. It just can't happen. Figure 9.9 shows the Can't Happen entries added to the table.

Figure 9.9. State Transition Table with "Can't Happen" Entries

Can't Happen combinations should have associated descriptions that state why a particular combination is disallowed. For example, doorOpen can't happen in the Interrupted state because the door is already open.

When filling out the state transition table, focus on the problem domain and not on the particular mechanisms implemented by the software. One could always argue that any event could be detected in any state. But if the event makes no sense according to the rules and policies of the domain, treat the combination as Can't Happen.

Event Ignored and Can't Happen entries do not appear in the statechart diagram. The statechart diagram shows only the active allowed transitions. Therefore, the state transition table is necessary for a complete interpretation of the state machine for the instances of a class.

Can't Happen or Shouldn't Happen?

Of course, the microwave oven could detect a doorOpen event when the door is already open, and in that sense the event shouldn't happen. But in the reality of the domain under study, the behavior of the microwave, the event really cannot happen. So which is it?

Because the model describes the microwave, it Can't Happen. It is the task of the domain that recognizes signals from the hardware to detect this case and filter it out so the microwave is blissfully unaware of the misbehavior of its internal devices.