9.5 Forming Lifecycles

Building good state machines takes practice. Here are two reminders to help you avoid traps.

The model is an abstraction.

Just as a class diagram doesn't model every fact about a thing as an attribute, so the state machines will capture only those stages and progressions that are relevant to the problem at hand. The light bulb model doesn't include its manufacture, sale, or disposal. These things do happen to a light bulb, but they are (presumably) outside the scope of the problem we're modeling.

Similarly, a light bulb takes time to heat up and is fully on only when the filament has reached a certain temperature. For most problems, this view is overly detailed and fails to abstract unnecessary detail. These decisions depend on the developer's judgment and understanding of the domain.

Capture purpose.

If you spot a microwave oven with the door closed and the light off, you don't know whether it contains food ready to eat or not.

This is because you don't know the history of states that led to this one. Put another way, you don't know why the microwave is exhibiting this behavior.

Modeling only the properties of the oven (light on or off, door open or closed, and power tube on or off) can lead to a model such as Figure 9.11. This model captures a limited snapshot of the microwave oven, where the properties alone established the state.

Figure 9.11. External View of the Microwave Oven

But our usage of state machines seeks to explain the details of the behavior from inside the class. Their purpose is one of specification: to explain details of behavior so that we can understand why an object needs to behave in a certain way and what actions are required to make it behave properly. This correct use of state machines is called a "clear-box" or internal view. The final model for the microwave oven shown in Figure 9.7 is an example.