UML State Machine Diagrams and Modeling

State Machine Diagram

• Illustrates the interesting events and states
of an object and the behavior of an object
in reaction to an event.
– Event: significant or noteworthy occurrence.
• E.g., telephone receiver taken off hook.
– State: the condition of an object at a moment
in time (between events).
– Transition: a relationship between two states;
when an event occurs, the object moves from
the current state to a related state.
 UML State Machine Diagram
• States shown as rounded rectangles.
• Transitions shown as arrows.
• Events shown as labels on transition
arrows.
• Initial pseudo-state automatically
transitions to a particular state on object
instantiation.
• Events with no corresponding transitions
are ignored.
 State Transition Diagram
• A state transition diagram is a technique to depict:

1. The states of an entity

2. The transitions of states of the entity
3. The trigger or the event that caused the transition of state of
the entity

• The entity may be a physical device such as a light

switch or a vending machine; it may be a software
system or component such as a word processor or
an operating system; it may be a biological system
such as a cell or a human; or - - - -

This modeling technique came from a more formal area called automata theory.
State transition diagram depicted a Finite State Machine.
 Software Program View

• The end product of a software is a program

which executes. In depicting the program (or
an object) we can consider:

– Variables which take on different values

– Control structure and assignment statements
(events) in the program that change the values of
the variables; but “little” is said about how the
control structure or the statements work

1. Combination of values of the data (variables & constants) at any point of

the program represent the program state at that point.

2. The change made to the values of the variables through assignment statements
represent a transition of state
 A very simple example
light switch (page 368 of your text)
From To
Alt State Event State
(light) (switch) (light)
switch light
[l_st=on] on turnOff off
TurnOff ( )

[l_st=off] off turnOn on

TurnOn ( )

2. “State transition table”

1. “Sequence diagram” (alternative for light with switch events
fragment) for switch and light interaction

turnOff

light light
on off

turnOn
3. “State transition diagram”
for light with switch events
 A little “more” on the light switch

turnOff
turnOff turnOff

on off
on off

turnOn turnOn turnOn

What happens if we turn on

state can “transition” to its
a light that is already on?
current state
 Fig. 29.1 State machine diagram for a telephone

Telephone

initial state

off hook
Idle Active state

on hook

transition event
 Transition Actions and Guards
• A transition can cause an action to fire.
– In software implementation, a method of the
class of the state machine is invoked.
• A transition may have a conditional guard.
– The transition occurs only if the test passes.
 Fig. 29.2 Transition action and guard notation

transition action

off hook / play dial tone

[valid subscriber]
Idle Active

on hook

guard condition
 Nested States
• A state may be represented as nested
substates.
– In UML, substates are shown by nesting them
in a superstate box.
• A substate inherits the transitions of its
superstate.
– Allows succinct state machine diagrams.
 Fig. 29.3 Nested states

off hook / play dial tone

Active
[valid subscriber]
Idle

PlayingDialTone Talking
on h
o ok

digit digit connected

complete
Dialing Connecting
 State-Independent vs. State-Dependent
• State-independent (modeless) — type of
object that always responds the same way
to an event.
• State-dependent (modal) — type of object
that reacts differently to events depending
on its state or mode.
Use state machine diagrams for modeling
state-dependent objects with complex
behavior, or to model legal sequences of
operations.
 Modeling State-dependent Objects
• Complex reactive objects
– Physical devices controlled by software
• E.g., phone, microwave oven, thermostat
– Transactions and related business objects
• Protocols and legal sequences
– Communication protocols (e.g., TCP)
– UI page/window flow or navigation
– UI flow controllers or sessions
– Use case system operations
Fig. 29.4 Web page navigation modeling
 Fig. 29.5 Legal sequence of use case operations

Process Sale

WatingForSale makeNewSale EnteringItems

enterItem
endSale

authorized makeCashPayment WaitingForPayment

makeCreditPayment

AuthorizingPayment makeCheckPayment
 GoF State Pattern
• Problem:
– An object’s behavior is dependent on its state,
and its methods contain case logic reflecting
conditional state-dependent actions.
• Solution:
– Create a state class for each state,
implementing a common interface.
– Delegate state-dependent operations from the
context object to its current state object.
– Ensure context object always points to a state
object reflecting its current state.
 Example: Transactional States
• A transactional support system typically
keeps track of the state of each persistent
object.
– Modifying a persistent object does not cause
an immediate database update — an explicit
commit operation must be performed.
– A delete or save causes change of state, not
an immediate database delete or save.
– A commit operation updates the database if
an object was modified (“dirty”), but does
nothing if the object is “clean”.
 Fig. 38.12 Statechart for PersistentObject

State chart: PersistentObject

[new (not from DB)] [ from DB]

save
commit / insert rollback / reload
New OldClean OldDirty
commit / update

delete
Legend:
New--newly created; not in DB delete
Old--retrieved from DB
Clean--unmodified OldDelete
rollback / reload
Dirty--modified

Deleted commit / delete

 Fig. 38.13 Persistent Objects

• Assume all persistent object classes extend a

PersistentObject class that provides common
technical services for persistence.
Domain

ProductSpecification Persistence
... PersistentObject

oid : OID
timeStamp: DateTime

commit()
delete()
rollback()
save()
...
 Case-logic Structure
• Using case logic, commit and rollback
methods perform different actions, but
have a similar logic structure.
public void commit()
{
switch ( state )
{
case OLD_DIRTY:
// . . .
break;
case OLD_CLEAN:
// . . .
break;
. . .
 State Transition Model using State Pattern

• Implementing transactional states:

– Create static singleton objects for each state
that are specializations of PObjectState.
• The commit method is implemented differently in
each state object.
– PersistentObject is the context object.
• Keeps a reference to a state object representing
the current state.
• Methods in the state objects call setState() to
cause a transistion to the next state.
• No case logic is needed.
 { state.delete( this ) }

{ state.rollback( this ) }
{ state.commit( this ) }
{ state.save( this ) }
PersistentObject

oid : OID PObjectState

{
state : PObjectState
// default no-op
commit() // bodies for
commit(obj : PersistentObject) // each method
delete() 1
rollback() * delete(obj : PersistentObject) }
rollback(obj : PersistentObject)
save()
save(obj : PersistentObject)
setState(PObjectState)
...

OldDirty OldClean New OldDelete

State State State State
Product Sale
Specification
...
... commit(...) delete(...) commit(...) commit(...)
... delete(...) save(...) rollback(...)
... rollback(...)

{ // commit
PersistenceFacade.getInstance().update( obj )
obj.setState( OldCleanState.getInstance() ) }

{ // rollback
PersistenceFacade.getInstance().reload( obj )
obj.setState( OldCleanState.getInstance() ) } { // commit
PersistenceFacade.getInstance().insert( obj )
{ // delete obj.setState( OldCleanState.getInstance() ) }
obj.setState( OldDeleteState.getInstance() ) }
{ // commit
{ // save PersistenceFacade.getInstance().delete( obj )
obj.setState( OldDirtyState.getInstance() ) } obj.setState( DeletedState.getInstance() ) }