Chapter 7: State Machines


This chapter addresses the UML constructs that you can use to model discrete object behavior in terms of the states an object can reside in and the transitions that can happen between those states. The chapter addresses both behavioral state machines , which specify sequences of states that objects go through during their lifetimes in response to events and the responses that the objects make to those events, and protocol state machines, which specify which operations of a given class can be called when instances of that class are in particular states and under which conditions.

States and Transitions

A state is a condition in which an object can be at some point during its lifetime, for some finite amount of time.

An object can do any or all of the following while it's in a particular state:

  • Perform an activity (see the section "Activities, Activity Nodes, and Activity Edges" in Chapter 6)

  • Wait for an event (see the section "Signals, Triggers, and Events" in Chapter 6 for a list of events that the UML supports)

  • Satisfy one or more conditions

The UML notation for a state is a rectangle with rounded corners. Figure 7-1 shows three sample states in which an Order object can reside.


Figure 7-1: States

When an Order is in the Posting state, it performs an activity that involves other objects ‚ in this case, objects that belong to the Accounting portion of the system. (It's fairly common for other objects to be involved with a given object's activities.) The Retrieving Books state involves an ongoing activity but no outside objects. The Shipped state is an example of a state in which an object has satisfied some condition.

A transition is a change of an object from one state (the source state ) to another (the target state ).

A transition "fires" when an event of interest to the given object occurs. (The event "triggers" the transition.) Alternatively, a transition may fire unconditionally when the object is ready to move from one state to another, generally because the activity associated with the source state is complete. This is called a triggerless transition.

There may also be an action associated with a triggered transition. Unless there's also a guard (discussed later in this section), this action executes unconditionally before the object enters the target state.

An object doesn't have to go from one state to a different state within a transition. A self-transition is a transition whose source state and target state are the same.

Figure 7-2 shows some transitions that an Order object might go through.


Figure 7-2: Transitions

The transition from Packaging to Shipping is triggerless, just like the ones that appear on activity diagrams (see the section "Activity Diagrams" in Chapter 6). The transition from Shipping to Shipped occurs when the shipConfirm event occurs; the Order object records the change in state by performing a call action (invoking the setFulfilledFlag method on itself). The Retrieving Books state has a self-transition.

A guard is a Boolean expression that must evaluate to True before a given transition can fire.

You show a guard in square brackets near the transition arrow. Various guard forms are as follows :

  • If a guard is associated with an event, you use the form eventName [ guard ]. If the Boolean evaluates to False , the object ignores the event and doesn't change states.

  • If you have an event, a guard, and an action, the form is eventName [ guard ]/ action . Again, if the Boolean is False , the object doesn't execute the action, and no state change occurs.

  • You can also have a guard by itself on a transition, which takes the form [ guard ].

Figure 7-3 shows some guards that might apply to transitions associated with an Order object.


Figure 7-3: Guards

The transition between Packaging and Shipping occurs when the packageIsReady event comes in and it's been established that the associated Order has been posted to the General Ledger (GL). The Order object stays in the Retrieving Books state until the Order realizes that it's accumulated all the books that the Customer requested .

The symbol for a state may contain any of several other pieces of information, as follows:

  • An entry action is an action that the object always performs immediately upon entering the given state. This appears as entry / actionName within the state symbol. If a self-transition occurs, the object performs the entry action. Figure 7-4 shows an example of an entry action.


    Figure 7-4: Entry action

  • An exit action, similarly, is an action that the object always performs immediately before leaving the given state, in response to a regular transition or a self-transition. This appears in the form exit / actionName . Figure 7-5 shows an example of an exit action.


    Figure 7-5: Exit action

    In many cases, an object doesn't do anything except wait while it's in a particular state. However, you can show, within the state symbol, an activity that the object performs while it's in the state, using the notation do / activityName .

    Note ‚  

    An activity is interruptible, which means that when an event comes in, the object is likely to stop performing the activity and respond to the event.

  • An object may handle the reception of an event by performing some action while still remaining in the existing state. This is called an internal transition ; it's shown as eventName/actionName . If an object makes an internal transition, it does not execute the exit action or the entry action. (Note how this is different from a self-transition, which does result in the execution of the exit action and then the entry action.)

  • A deferred event is an event that's of interest to the object, but which the object defers handling until the object reaches a different state. This is shown as eventName/ defer . Deferred events get put into a queue; when the object changes state, the object first checks to see whether there are events in the queue to which it can now respond. Figure 7-6 shows an example of an exit action involving a GeneralLedger object.


    Figure 7-6: Deferred event

    If the GeneralLedger object receives a generateReport event, the object defers responding to the event because it's in the middle of posting journal entries. When this processing is complete, and the object enters the Idle state, the object responds appropriately to the event.




Fast Track Uml 2.0
Fast Track UML 2.0
ISBN: 1590593200
EAN: 2147483647
Year: 2004
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net