Object-Oriented Analysis and Design

© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

3.5 State Diagrams

Subject/Topic/Focus:
❍ Intraclass behavior
Summary:
❍ States and transitions
❍ Events, guards, actions and activities
❍ Abstraction, nesting and concurrency
Literature:
❍ Fowler
❍ Rumbaugh

❍❍Developed
Developedas
as“Statecharts”
“Statecharts”by
byDavid
DavidHarel.
Harel.
❍❍Successor
Successorto
toDeterministic
DeterministicFinite
FiniteAutomata.
Automata.

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.1

Motivation
❍ Object-orientation = Structure + Behavior.
❍ Class diagrams capture
• structure (attributes and associations) and
• behavior interfaces (method signatures).
❍ How do we catch the dynamic behavior and life cycle of an object?
• Creation and deletion.
• Attribute and association changes.
❍ How does the object interact with other objects?
• Reacting to events and to messages received by the object.
• Triggering actions and sending messages to other objects.
• Handling of sequences of events accepted and actions triggered.

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.2

3.5.1
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Role of State Diagrams in UML

Reading:
Reading:
Class Diagrams AAdelegates
delegatestask
task
A B
to B
to B
Description of states and
state transitions in classes

State Diagrams Refinement of state sequences,

Workflow presentation i.e., instance of a state diagram

Activity Diagrams Interaction Diagrams

State
Statediagrams
diagramssupplement
supplementclass
classdiagrams
diagramswith
with
•• states (of attributes and associations) and
states (of attributes and associations) and
•• state
statetransitions,
transitions,i.e.,
i.e.,behavior
behaviorsequences.
sequences.
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.3

State Diagrams

State
Statediagrams
diagramsare
areaatechnique
techniqueto
todescribe
describethe
the
behavior,
behavior,i.e.,
i.e.,state
statechanges
changes
of
ofaasingle
singleclass
classaccording
accordingto
to
events
eventsand
andmessages
messages
which
whichthe
theclass
classsends
sendsand
andreceives.
receives.

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.4

3.5.2
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

States
❍ A state
• abstracts from attribute values and associations of an object;
• represents the internal condition/state of an object
for a certain period of time;
• corresponds to an interval of time between two events.
❍ The response to events may depend on the state of an object.
❍ Object creation comes together with an initial object state.
❍ Object deletion may be related with (one of many) final states.

Initial state State Final state

White’s turn Black wins

Draw
Black’s turn White wins
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.5

Events
❍ An event is something worth noticing at a point of time;
• a signal from one object to another, e.g., “delivered”,
• a message received by an object, e.g., “check item”,
• a certain date/time, e.g., “after 10 seconds” (being in a certain state) or
“at 31-dec-2000, 00:00”.
❍ Events may take arguments, e.g., “deliver to (receiver : Customer)”.
❍ Events may be declared in a class diagram with arguments shown as
attributes.
<<signal>>
mouse

<<signal>> <<signal>> location

IOEvent user input
<<signal>>
time : Time device keyboard

character
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.6

3.5.3
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Transitions
❍ A transition represents a change of the internal condition/state of an object.
❍ A transition is usually triggered (“fired”) by an event. Transitions without
event label (“lambda transitions”) fire immediately.
❍ Transitions fire instantly
• from exactly one state to another state or to itself (self-transition) and
• are not interruptible.
Transition

White’s turn Argument

white black
moves (piece : Piece) moves (piece : Piece)

Black’s turn Event

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.7

Guards
❍ A guard is a logical condition (value “true” or “false”).
❍ A guarded transition fires only if the guard resolves to “true”.
❍ Since only one transition can be fired in a given state, guards are
intended to be mutually exclusive for any event.
❍ Events may be guarded.

Guarded event

check next item

[Not all items checked]
Checking
Guard [All items checked &&
all items available]
[All items checked &&
some items not in stock]

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.8

3.5.4
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Actions
❍ An action is a short software process that executes immediately.
❍ A transition may trigger an action.
❍ Actions may be triggered on entry or exit of states (instead of labeling
each incoming (entry) and outgoing (exit) transition with these actions).
❍ An event may trigger an action without leaving the state, i.e., without
triggering exit and entry actions as a self-transition would do.
❍ An action may trigger events, usually in other objects.
❍ Actions may take arguments.

Checking
Dispatching
entry / display marker
/ prepare dispatching (receiver) too heavy / call help
exit / hide marker

Action Argument Event Action

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.9

Sending Messages
❍ Sending messages are special actions.
❍ Messages address an object or a set of objects.
❍ Messages occur after other actions.
❍ Messages trigger an event/transition in the receiving object.

Checking Dispatching
/ rep := get_Sales_Rep(receiver)
^rep.acknowledge(delivery)

Action
Sending message
Checking Dispatching
inform about(delivery)

Controller
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.10

3.5.5
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Activities
❍ Activities can take “longer”, i.e., they are processes which last as long as
an object is in a certain state.
❍ Activities are interruptible, i.e., an event causing a state transition may
abort an activity.
❍ Activities may be constructed from a start and a final action.

Checking Dispatching
do / show marker do / initiate delivery

Activity

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.11

State Diagram: Example

/ get first item

[All items checked
/ get next item
&&
[Not all items checked]
Checking all items available]
Dispatching
do/ check item do/ initiate
delivery
]
[All items checked && i ved lable
ce a i
some items not in stock] r e s av
m m Delivered
te
/ I ll ite
[Some items received && [A
some items not in stock]
Waiting Delivered

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.12

3.5.6
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Nesting (1)
Example: A state Cancelled is added to which transitions from all existing states
exist.

Checking Dispatching
do/ check item do/ initiate
delivery

Waiting Cancelled Delivered

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.13

Nesting (2)
Instead of drawing all the transitions from each state to the Cancelled state,
it is easier to “wrap” the states Checking, Waiting and Dispatching in
one superstate from which only one cancelled transition to the Cancelled state
is necessary.

❍ Superstates contain state diagrams or other superstates.

❍ Superstates allow to simplify multiple transitions from probably many
source states to a single target state by
• introducing a (superstate) name for a (nested) state diagram and
• substituting each of the transitions between source states and the
target state by a single transition between superstate and target state.

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.14

3.5.7
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Superstates: Nesting
Nesting:

Active order
Checking
do/ check item
Dispatching
do/ initiate
delivery
Waiting

Cancelled Delivered

Cancelled Delivered
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.15

Superstates: Abstration
Abstraction:

Active Order

Cancelled Delivered

Cancelled Delivered
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.16

3.5.8
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Concurrency in State Diagrams

Concurrent state diagrams are useful when a given object has sets of
independent behaviors.
The concurrent sections of a state diagram are places in which, at any time, the
given object is in a composite state defined by the given subsections.

Concurrent superstate Subsection

Join
Fork

Checking Dispatching

Delivered

Authorizing Authorized

Subsection
OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.17

Concurrency: Alternative Notation

Example: The authorization of a customer for a certain purchase
is checked concurrently to the item dispatching actions.
Cancelled

Waiting

Checking Dispatching
Delivered
[Payment OK]
Authorizing Authorized

[Payment not OK]

Rejected

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.18

3.5.9
Object-Oriented Analysis and Design
© J.W. Schmidt, F. Matthes, TU Hamburg-Harburg

Concurrency and Superstate Abstraction

Abstraction of previous example at a higher level.

Cancelled

Checking and Authorizing Delivered

Payment not OK
Rejected

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.19

When to Use State Diagrams

❍ State diagrams are good at describing the behavior of an object across

several use cases.
❍ Draw state diagrams especially for classes, which are not well understood
and which need detailed description.

❍ If you have to describe several objects, which are involved in a single use
case, use interaction diagrams.
❍ To show the general sequence for multiple use cases and multiple
objects, use activity diagrams.
❍ State diagrams are not very good at describing behavior that involves a
number of objects collaborating together.

OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.5.20

3.5.10