The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling the Lifetime of an Object

The most common purpose for which you'll use state machines is to model the lifetime of an object, especially instances of classes, use cases, and the system as a whole. Whereas interactions model the behavior of a society of objects working together, a state machine models the behavior of a single object over its lifetime, such as you'll find with user interfaces, controllers, and devices.

When you model the lifetime of an object, you essentially specify three things: the events to which the object can respond, the response to those events, and the impact of the past on current behavior. Modeling the lifetime of an object also involves deciding on the order in which the object can meaningfully respond to events, starting at the time of the object's creation and continuing until its destruction.

To model the lifetime of an object,

• Set the context for the state machine, whether it is a class, a use case, or the system as a whole.

  • If the context is a class or a use case, find the neighboring classes, including any parents of the class and any classes reachable by associations or dependences. These neighbors are candidate targets for actions and are candidates for including in guard conditions.

  • If the context is the system as a whole, narrow your focus to one behavior of the system. Theoretically, every object in the system may be a participant in a model of the system's lifetime, and except for the most trivial systems, a complete model would be intractable.

• Establish the initial and final states for the object. To guide the rest of your model, possibly state the pre- and postconditions of the initial and final states, respectively.

• Decide on the events to which this object may respond. If already specified, you'll find these in the object's interfaces; if not already specified, you'll have to consider which objects may interact with the object in your context, and then which events they may possibly dispatch.

• Starting from the initial state to the final state, lay out the top-level states the object may be in. Connect these states with transitions triggered by the appropriate events. Continue by adding actions to these transitions.

• Identify any entry or exit actions (especially if you find that the idiom they cover is used in the state machine).

• Expand these states as necessary by using substates.

• Check that all events mentioned in the state machine match events expected by the interface of the object. Similarly, check that all events expected by the interface of the object are handled by the state machine. Finally, look to places where you explicitly want to ignore events.

• Check that all actions mentioned in the state machine are sustained by the relationships, methods, and operations of the enclosing object.

• Trace through the state machine, either manually or by using tools, to check it against expected sequences of events and their responses. Be especially diligent in looking for unreachable states and states in which the machine may get stuck.

• After rearranging your state machine, check it against expected sequences again to ensure that you have not changed the object's semantics.

For example, Figure 22-9 shows the state machine for the controller in a home security system, which is responsible for monitoring various sensors around the perimeter of the house.

In the lifetime of this controller class, there are four main states: Initializing (the controller is starting up), Idle (the controller is ready and waiting for alarms or commands from the user), Command (the controller is processing commands from the user), and Active (the controller is processing an alarm condition). When the controller object is first created, it moves first to the Initializing state and then unconditionally to the Idle state. The details of these two states are not shown, other than the self-transition with the time event in the Idle state. This kind of time event is commonly found in embedded systems, which often have a heartbeat timer that causes a periodic check of the system's health.