Practical Object-Oriented Design with UML 2e
PRACTICAL
OBJECT-ORIENTED
DESIGN WITH UML
2e
Chapter 10:
Statecharts
©The McGraw-Hill Companies, 2004
Slide 1/1
Practical Object-Oriented Design with UML 2e
Specifying Behaviour
● Interaction diagrams
– show how an object behaves in particular
interactions
– do not specify all the possible behaviours of an
object. The order of messages is specific to
particular interaction (e.g. a use case)
● Different notation is needed to summarize
the overall behaviour of objects
● UML defines statecharts for this purpose
©The McGraw-Hill Companies, 2004
Slide 1/2
Practical Object-Oriented Design with UML 2e
State-dependent Behaviour
● Objects respond differently to the same
stimulus at different times
● This is modelled by defining a set of states
– an object can be in one state at any time
– the state it is in determines how it responds to
events detected or messages received
– in particular, an event can cause the object to
move from one state to another (a transition)
©The McGraw-Hill Companies, 2004
Slide 1/3
Practical Object-Oriented Design with UML 2e
States, Events and Transitions
● A simple statechart for a CD player:
©The McGraw-Hill Companies, 2004
Slide 1/4
Practical Object-Oriented Design with UML 2e
Statechart Semantics
● A statechart defines the behaviour of
instances of a given class
● An object is in one active state at a time
● Events may be received at any time
● An event can trigger a transition
– a transition from the active state will fire if it is
labelled with the event just received
● The transition leads to the next active state
©The McGraw-Hill Companies, 2004
Slide 1/5
Practical Object-Oriented Design with UML 2e
Initial and Final States
● Model the creation and destruction of objects
©The McGraw-Hill Companies, 2004
Slide 1/6
Practical Object-Oriented Design with UML 2e
Non-determinism
● Sometimes there are two transitions with the
same event label leaving a state
● Some systems are non-deterministic
– but usually the non-determinism can be removed
by adding more information
©The McGraw-Hill Companies, 2004
Slide 1/7
Practical Object-Oriented Design with UML 2e
Guard Conditions
● Conditions added to events indicate when a
transition can fire
©The McGraw-Hill Companies, 2004
Slide 1/8
Practical Object-Oriented Design with UML 2e
Actions
● Actions are performed when a transition fires
©The McGraw-Hill Companies, 2004
Slide 1/9
Practical Object-Oriented Design with UML 2e
Entry and exit actions
● Entry and exit actions are properties of states
– they are performed whenever an object arrives
at or leaves the state, respectively
©The McGraw-Hill Companies, 2004
Slide 1/10
Practical Object-Oriented Design with UML 2e
Activities
● Activities are also properties of states
– they are performed while the object is in a state
– unlike actions, they can be interrupted by new
events
©The McGraw-Hill Companies, 2004
Slide 1/11
Practical Object-Oriented Design with UML 2e
Completion Transitions
● If an activity completes uninterrupted it can
trigger a completion transaction
– these are transitions without event labels
©The McGraw-Hill Companies, 2004
Slide 1/12
Practical Object-Oriented Design with UML 2e
Internal Transitions
● Internal transitions do not change state
– and so do not execute entry and exit actions
©The McGraw-Hill Companies, 2004
Slide 1/13
Practical Object-Oriented Design with UML 2e
Composite States
● Composite states group together states
– this can simplify a statechart by grouping
together states with similar behaviour
● An object still has one ‘bottom-level’ active
state
– but may be in a composite state as well
©The McGraw-Hill Companies, 2004
Slide 1/14
Practical Object-Oriented Design with UML 2e
A Composite State
©The McGraw-Hill Companies, 2004
Slide 1/15
Practical Object-Oriented Design with UML 2e
Properties of Composite States
● Transitions
– from a composite state apply to all substates
– to a composite state go to the state indicated by
a nested initial state
– can cross composite state boundaries
● Composite states can have activities and
entry and exit actions
● A final state in a composite triggers a
completion transition from the composite
©The McGraw-Hill Companies, 2004
Slide 1/16
Practical Object-Oriented Design with UML 2e
A Complex Composite State
©The McGraw-Hill Companies, 2004
Slide 1/17
Practical Object-Oriented Design with UML 2e
History States
● Often an object needs to ‘return to the
previous state’
● This can be done by defining conditions
– such as ‘[if the last state was Playing]’
● Composite states can have a history state
– this ‘remembers’ the last active substate
– a transition to a history state makes that substate
active again
©The McGraw-Hill Companies, 2004
Slide 1/18
Practical Object-Oriented Design with UML 2e
Use of a History State
©The McGraw-Hill Companies, 2004
Slide 1/19
Practical Object-Oriented Design with UML 2e
Complete CD Player Statechart
(Summary)
©The McGraw-Hill Companies, 2004
Slide 1/20
Practical Object-Oriented Design with UML 2e
Creating a Statechart
● It can be hard to identify all necessary states
● Statecharts can be developed incrementally
– consider individual sequences of events
received by an object
– these might be specified on interaction diagrams
– start with a statechart for one interaction
– add states as required by additional interactions
©The McGraw-Hill Companies, 2004
Slide 1/21
Practical Object-Oriented Design with UML 2e
Ticket Machine
● Consider a ticket machine with two events
– select a ticket type
– enter a coin
● Basic interaction is to select a ticket and then
enter coins
– model this as a ‘linear’ statechart
©The McGraw-Hill Companies, 2004
Slide 1/22
Practical Object-Oriented Design with UML 2e
Refining the Statechart
● This can be improved by adding ‘loops’
– the number of coins entered will vary: entry will
continue until the ticket is paid for
– the whole transaction can be repeated
©The McGraw-Hill Companies, 2004
Slide 1/23
Practical Object-Oriented Design with UML 2e
Adding Another Interaction
● The user could enter a coin before selecting
a ticket
● A ‘coin’ transition from the ‘Idle’ state is
needed to handle this event
– this transition can’t go to the ‘Paying for Ticket’
state as the ticket is not yet selected
– so a new state ‘Inserting Coins’ is required
● The statechart is thus built up step-by-step
©The McGraw-Hill Companies, 2004
Slide 1/24
Practical Object-Oriented Design with UML 2e
Adding a Second Interaction
● If all coins are entered before ticket selected:
©The McGraw-Hill Companies, 2004
Slide 1/25
Practical Object-Oriented Design with UML 2e
Integrating the Interactions
● In fact, events can occur in any sequence:
©The McGraw-Hill Companies, 2004
Slide 1/26
Practical Object-Oriented Design with UML 2e
Time Events
● Suppose the ticket machine times out after
30 seconds
– we need to fire a transition that is not triggered
by a user-generated event
– UML define time events to handle these cases
©The McGraw-Hill Companies, 2004
Slide 1/27
Practical Object-Oriented Design with UML 2e
Activity States
● Activity states defines periods of time when
the object is carrying out internal processing
– unlike normal activities, these cannot be
interrupted by external events
– only completion transitions leading from them
– useful for simplifying the structure of complex
statecharts
©The McGraw-Hill Companies, 2004
Slide 1/28
Practical Object-Oriented Design with UML 2e
Returning Change
● Use an activity state to calculate change
©The McGraw-Hill Companies, 2004
Slide 1/29
Practical Object-Oriented Design with UML 2e
Ticket Machine Statechart
©The McGraw-Hill Companies, 2004
Slide 1/30
Practical Object-Oriented Design with UML 2e
Statechart (Summary)
● What can be modelled?: In the UML, the term
state machine refers to the technique used to
model behavior in terms of states and transitions. A
UML statechart diagram is a graphical
representation of a state machine showing states,
transitions and events. SC represents the life
history of objects of a given class, rounded
rectangles represent a states with directed
transition lines between them. SC can be used to
model anything where state change is considered
important e.g. the state of a hospital ward could be
empty or full.
©The McGraw-Hill Companies, 2004
Slide 1/31
Practical Object-Oriented Design with UML 2e
Statechart (Summary)
● The main components are:1) the states involved which are
represented by the rectangles with rounded corners
containing their names; and 2) the transitions which are
represented by arrows and identified by the events thatgive
rise to them. SC shows states, state transitions, and events.
Transitions are said to be fired or triggered by events. The
firing of a particular transition depends on the current state.
In general a transition label can have three parts, all of
which are optional: Event [Guard] / Action.Events can be
Signals, calls, time, or state change. There can be entry
events and exit events, action that is marked as linked to the
entry event is executed whenever the given state is entered
via a transition. The action associated with the exit event is
executed whenever the state is left via a transition. A guard
or [condition] is a logical condition that will return only “true”
or “false.” A guarded transition occurs only if the guard
resolves to “true.”
©The McGraw-Hill Companies, 2004
Slide 1/32
Practical Object-Oriented Design with UML 2e
Statechart (Summary)
● How can statecharts can used by the analyst? State
diagrams are good at describing the behavior of a single
object across several use cases. They are not very good at
describing behavior that involves a number of objects
collaborating together. As such, it is useful to combine state
diagrams with other techniques. For instance, interaction
diagrams are good at describing the behavior of several
objects in a single use case, and activity diagrams are good
at showing the general sequence of actions for several
objects and use cases. Not needed for every class in the
system. Use state diagrams only for those classes that
exhibit interesting behavior, where building the state
diagram helps you understand what is going on. UI and
control objects have the kind of behavior that is useful to
depict with a state diagram.
©The McGraw-Hill Companies, 2004
Slide 1/33