OO Using UML:

Dynamic Models

Defining how the objects behave

07-UML-Dynamic

Overview

The object model describes the structure of the system (objects,

attributes, and operations)
The dynamic model describes how the objects change state (how
the attributes change) and in which order the state changes can
take place
Several models used to find the appropriate dynamic behavior

Interaction diagrams
Activity diagrams
State Diagrams

Uses finite state machines and expresses the changes in terms of

events and states

07-UML-Dynamic

Interaction Diagrams

07-UML-Dynamic

We Will Cover

Why interaction diagrams?

Sequence diagrams

Capturing use-cases
Dealing with concurrency

Collaboration diagrams
When to use what
When to use interaction diagrams

07-UML-Dynamic

Different Types of Interaction

Diagrams

An Interaction Diagram typically captures a usecase

Sequence diagrams

A sequence of user interactions

Highlight the sequencing of the interactions between
objects

Collaboration diagrams

Highlight the structure of the components (objects)

involved in the interaction

07-UML-Dynamic

Home Heating Use-Case

Use case:
Actors:
Type:
Description:

Power Up
Home Owner (initiator)
Primary and essential

Cross Ref.:
Use-Cases:

Requirements XX, YY, and ZZ

None

The Home Owner turns the power on. Each room

is temperature checked. If a room is below the
the desired temperature the valve for the room is
opened, the water pump started, the fuel valve
opened, and the burner ignited.
If the temperature in all rooms is above the desired
temperature, no actions are taken.

07-UML-Dynamic

Sequence Diagrams
a H om e O wner

t h e O n - O f f S w it c h

t h e C o n t r o lle r

a Room

S y s te m O n
p o w e rO n ()
* [fo r a ll r o o m s ]
te m p S ta tu s := c h e c k T e m p ()

[te m p S ta tu s = = lo w ]
p u m p O n ()
[te m p S ta tu s = = lo w ]
o p e n V a lv e ( )
[te m p S ta tu s = = lo w ]
s ta rtB u rn e r()

th e W a te r P u m p

Example from Fowler

a n O rd e r e n try
W in d o w

p re p a re ()

a n O rd e r

a n O r d e r L in e

a S to c k Ite m

* [ f o r a ll o r d e r lin e s ]
p re p a re ()
h a s S to c k := c h e c k ()
[h a s S to c k ]
re m o v e ()
n e e d s R e o rd e r := n e e d s T o R e o rd e r()

[n e e d s R e o rd e r]
new

[h a s S to c k ] n e w

a R e o rd e r Ite m

a D e liv e r y I t e m

M H

Concurrency
new

a T r a n s a c t io n

new

a T r a n s a c t io n
C o o r d in a t o r

new

a f ir s t T r a n s a c t io n
C hecker
a second
T r a n s a c tio n
C hecker

new

ok
a llD o n e ?
ok
a llV a lid

a llD o n e ?

Another Example
a H om e O wner

th e O n - O ff S w itc h

S y s te m O n

th e C o n tr o lle r

th e W a te r P u m p

p o w e rO n ()
* [ f o r e a c h r o o m in h o u s e ]
new
a R oom
c h e c k T e m p ()

te m p L o w
[te m p L o w ]
p u m p O n ()
[te m p L o w ]
o p e n V a lv e ( )
[te m p L o w ]
s ta rtB u rn e r()

M H

Comment the Diagram

W h e n th e o w n e r
tu rn s th e s y s te m o n
th e o n s w itc h n o tifie s
th e c o n tro lle r
T h e c o n tro lle r
c re a te s a ro o m o b je c t
fo r e a c h ro o m in th e
b u ild in g
T h e ro o m s s a m p le
th e te m p e ra tu re in
th e to o m e v e ry 5 s .
W h e n a lo w te m p is
d e te c te d th e ro o m
n o tifie s th e
c o n tro lle r.

a H om e O wner

th e O n - O f f S w itc h

S y s te m O n

t h e C o n t r o lle r

th e W a te r P u m p

p o w e rO n ()
* [ f o r e a c h r o o m in h o u s e ]
new
a Room
c h e c k T e m p ()

te m p L o w
[te m p L o w ]
p u m p O n ()
[te m p L o w ]
o p e n V a lv e ( )
[te m p L o w ]
s ta rtB u rn e r()

M H

Collaboration Diagrams
:O rd e r E n try
W in d o w

1 : p re p a re ()

:O rd e r

2 : * [ fo r a ll o r d e r lin e s ]:
p re p a re ()

5 : n e e d s R e o rd e r := n e e d s T o R e o rd e r()
3 : h a s S to c k := c h e c k ()
W in te r s t o c k :
S to c k Ite m

W in te r lin e : O r d e r L in e

7 : [h a s S to c k ] :n e w

: D e liv e r y It e m

4 : [h a s S to c k ]:
re m o v e ()

6 : [n e e d s R e o rd e r]:
new

a R e o rd e r Ite m

M H

Conditional Behavior

Something you will encounter trying to capture complex

use-cases

Split the diagram into several

Split the use-case also

Use the conditional message

The user does something. If this something is X do this If this

something is Y do something else If this something is Z

Could become messy

Remember, clarity is the goal!

07-UML-Dynamic

13

Comparison

Both diagrams capture the same information

We prefer sequence diagrams

People just have different preferences

They clearly highlight the order of things
Invaluable when reasoning about multi-tasking

Others like collaboration diagrams

Shows the static structure

Very useful when organizing classes into packages

We get the structure from the Class Diagrams

07-UML-Dynamic

14

When to Use Interaction

Diagrams

When you want to clarify and explore single usecases involving several objects

Quickly becomes unruly if you do not watch it

If you are interested in one object over many usecases -- state transition diagrams
If you are interested in many objects over many
use cases -- activity diagrams

07-UML-Dynamic

15

State Diagrams

07-UML-Dynamic

16

We Will Cover

State Machines

An alternate way of capturing scenarios

Large classes of scenarios

Syntax and Semantics

When to use state machines

07-UML-Dynamic

17

Where Do State Diagrams Fit?

Class
Class

Class

Has a

Behavior
Behavior
Generally, one state diagram per class
Describe the entire behavior of class
All methods in one state diagram

1
State Diagram

07-UML-Dynamic

18

Events, Conditions, and States

Event: something that happens at a point in time

Condition: something that has a duration

Operator presses self-test button

The alarm goes off
The fuel level is high
The alarm is on

State : an abstraction of the attributes and links of an object (or entire

system)

The controller is in the state self-test after the self-test button has been
pressed and the rest-button has not yet been pressed
The tank is in the state too-low when the fuel level has been below level-low
for alarm-threshold seconds

07-UML-Dynamic

19

Making a Phone Call Scenario

To make a call, the caller lifts receiver. The caller gets a dial
dial tone and the caller dials digit (x). The dial tone ends.
The caller completes dialing the number. The callee phone
begins ringing at the same time a ringing begins in caller
phone. When the callee answers the called phone stops
ringing and ringing ends in caller phone. The phones are
now connected. The caller hangs up and the phones are
disconnected. The callee hangs up.

07-UML-Dynamic

20

Partial Class Diagram

1 ..1
L in e

1 ..1

C a lle r

Phone

1 ..1
1 ..1

07-UML-Dynamic

C a lle e

21

Event Trace
The Caller

The Line

The Callee

caller lifts receiver

dial tone begins
dials digit (4)
dial tone ends
dials digit (2)
dials digit (3)
dials digit (4)
dials digit (5)
ringing tone

phone rings

tone stops
phones connected

callee answers
ringing stops
phones connected

phones disconnected
callee hangs up

caller hangs up
phones disconnected

State Diagram for Scenario

on-hook

Idle
off-hook

Dial tone
digit(x)

digit(x)

Dialing
valid-number

Ringing
called-phone-answers

Connected
called-phone-hangs-up

Disconnected

Scenario 2
The Caller

The Line

caller lifts receiver

dial tone begins
dials digit (4)
dial tone ends
dials digit (2)
dials digit (3)
dials digit (4)
dials digit (5)
busy tone
caller hangs up

The Callee

Modified State Machine

Idle
off-hook
digit(x)

Dial tone
digit(x)
on-hook

Busy tone

Dialing
valid-number

number-busy
routed

Connecting

Ringing
called-phone-answers

Connected
called-phone-hangs-up
on-hook

Disconnected

Conditions

Sometimes the state transitions are conditional

Idle

on-hook

off-hook

Dial tone
digit(x) [x = 8]
digit(x)

digit(x)

Dialing

digit(x) [x != 8]

Dial tone
(external)

Dialing

valid-number

Busy tone

routed

07-UML-Dynamic

valid-number

number-busy

Ringing

digit(x)

Connecting

26

Operations (AKA Actions)

Idle

Actions are
performed when a
transition is taken or
performed while in a
state
Actions are
terminated when
leaving the state

off-hook
on-hook

Dial tone

digit(x)

do/ sound dial tone

digit(x)

on-hook
on-hook

Busy tone
do/ busy tone
on-hook

Dialing
valid-number

number-busy

Connecting

on-hook

routed do/ find connection

Ringing

do/ ring bell

called-phone-answers / connect line
on-hook / disconnect line

Connected
called-phone-hangs-up / disconnect line

on-hook

07-UML-Dynamic

Disconnected

27

Hierarchical State Machines

on-hook

Idle

Dial tone

off-hook
do/ sound dial tone
dial(x) [x is a digit]

Group states with

similar characteristics
Enables information
hiding
Simplifies the
diagrams

Make Call
Establish call
Dialing

dial(x)

valid-number
number-busy

on-hook

Busy tone

Connecting

do/ find connection

do/ busy tone

routed

Ringing

do/ ring bell

on-hook / disconnect line

on-hook

Connected

called-phone-answers /
connect line

called-phone-hangs-up /
disconnect line

Disconnected

dial(x) [x = *]

Voice Mail

Information Hiding

Idle

on-hook
off-hook

Establish call

Dial tone

Dialing

do/ sound dial tone

dial(x) [x is a digit]
dial(x) [x = *]

Busy tone

Establish call

Voice Mail

on-hook

on-hook /
disconnect line

on-hook

valid-number
number-busy

Make Call

Connected

do/ busy tone

Connecting

do/ find connection

routed

Ringing

called-phone-answers /
connect line

do/ ring bell

called-phone-hangs-up /
disconnect line

Disconnected

07-UML-Dynamic

dial(x)

29

Event Generalization

Related events can inherit

properties from each other
If an event at a lower level
occurs - the event at a higher
level also occurred
Event attributes

mouse-up.location
mouse-down.device
mouse-button.time

event
time
user-input
device
mouse-button
location
mouse-down

07-UML-Dynamic

keyboard-key
character

mouse-up

30

Concurrency

Some states represent

several concurrent concepts
Concurrency is supported by
the state machines
Concurrent state machines
are separated by dashed
lines

Alarms Disabled
out-of-bounds-event

Alarms
Visual Alarm Enabled

reset

On

Off
visual-on

Aural Alarm

reset

On

Off
aural-on

07-UML-Dynamic

31

Ambiguous Semantics 1
Is F transition ever taken?
How?
A

B
[G]

07-UML-Dynamic

32

Ambiguous Semantics 2

What happens when G is false after event E?

[G]

Are we stuck here?

07-UML-Dynamic

33

Ambiguous Semantics 3
How many threads are running in here?
A

F
J
G

D
E

K
H
What does this mean?

07-UML-Dynamic

34

Ambiguous Semantics 4

F
J
G

D
E

07-UML-Dynamic

K
H
Does this component get started?

35

Ambiguous Semantics 5
Class_One
Class_Two.message

Class_Two

What is the semantics

of message passing?
Queued?
Rendezvous?
Lost if no transition?

07-UML-Dynamic

36

Transition Rules

Find all the transitions with the trigger event

Evaluate the guards (if any)

If there are none, the event is lost. This is not an error.

No guard = true guard
For false guard, ignore this transition
Guards can reference attributes of the class

If more than one transition on a state survives,

pick one at random.

07-UML-Dynamic

37

More Transition Rules

Descendants of actions (in a inheritance hierarchy)

can trigger a transition
Transitions in nested states take precedence over
enclosing states.
Null triggers occur when the state is done doing
whatever it does.

A transition with a null trigger and a false guard never fires

again.

Concurrent threads have to be joined or terminated.

07-UML-Dynamic

38

Transition Syntax
Event[Guard]/Action1;Action2;.;ActionN
Actions include: send(event)
Events include: timeout(), when(boolean)
Pulse[pulsemode]/count++
Sample triggers:

Timeout(10s)/send(reset)
Digit(d)[isvalid(d)]/stash(d)

07-UML-Dynamic

39

State Machines - Summary

Events

States

conditions over time

abstraction of the attributes
and associations
Takes the state machine from
one state to the next

something performed in a
state

Hierarchies

Transitions

Internal actions

Conditions

instances in time

allows abstraction and

information hiding

Parallelism

models concurrent concepts

Triggered by events
Guarded by conditions
Cause actions to happen

07-UML-Dynamic

40

When to use State Machines

When you want to describe the behavior of one object for

all (or at least many) scenarios that affect that object
Not good at showing the interaction between objects

Use interaction diagrams or activity diagrams

Probably not needed for all classes

Some methods prescribe this

Sometimes time consuming and questionable benefit

07-UML-Dynamic

41

Coming up with the State

Diagrams

07-UML-Dynamic

42

Modeling Approach

Prepare scenarios

Identify events (often messages)

Group into event classes

Draw some sequence diagrams

Work with the customer

Start with normal scenarios
Add abnormal scenarios

Find objects with complex functionality you want to understand

better

Build a state diagram for the complex classes

07-UML-Dynamic

43

Scenario-1
Room

Fuel
Valve

Controller
request-temp

Every 5s

Burner

respond-temp
open-valve

Temp Low

start-burner
pump-on
open-water-valve
request-temp
Every 5s

respond-temp
pump-off

Temp Normal

close-water-valve
stop-burner
close-valve

Water
Pump

Scenario-2
Control
Panel
Every 5s
Desired temp
change
Every 5s

Room

Controller

request-temp
respond-temp

Temp Normal

Burner

desired-temp-change
request-temp
respond-temp
open-valve
start-burner
pump-on

Temp Low

Every 5s

Fuel
Valve

open-water-valve
request-temp
respond-temp
close-water-valve

pump-off
stop-burner
close-valve

Water
Pump

Dynamic Model
Water Pump

pump-on

On

Off
pump-off

Fuel Valve

open-valve

Open

Closed
close-valve

Burner

start-burner

On

Off
stop-burner

07-UML-Dynamic

46

More Dynamic Model

Room
Water-Valve
open-water-valve/
wv-open

Temp-Sensor
Idle

Valve
request-temp
close-water-valve/
wv-close

07-UML-Dynamic

temp-report(x)/
respond-temp(x)

Processing
Request

47

Even More Dynamic Model

Controller
Temperature
timeout(5s)\
request-temp

respond-temp(x)[x>desired-temp+2]/stop-heating

Temp-Low

Temp-Normal

timeout(5s)\
request-temp

respond-temp(x)[x<desired-temp-2]/start-heating

Home Heating System

timeout(1s)/
pump-on,open-water-valve

timeout(1s)/start-burner

Burner-On

Fuel-Open

start-heating/open-valve

All-Running
stop-heating/
pump-off,close-water-valve

07-UML-Dynamic

All-Off
Water-Off

Fuel-Off

timeout(1s)/close-valve

timeout(1s)/stop-burner

48

Identify Key Operations

Operations from the object model

Accessing and setting attributes

and associations (often not shown)

Operations from events

All events represent some

operation

Operations from actions and

activities

Operations from functions

Each function typically represent

one or more operations

Shopping list operations

07-UML-Dynamic

Actions and activities represent

some processing activity within
some object

Inherent operations (what should

be there)

49

Complete OO Model
Home Heating
System

Control Panel

Water Pump
on()
off()

On-Off Switch

Thermostat

setting

desired-temp

Pushes

Runs

Furnace

operating()
target-temp()

Adjusts

Burner

Fuel Valve

on()
off()

open()
close()

1..*
Room

Notifies

open-valve()
close-valve()
room-temp()

Operator

1..*

Ignites

Temp Sensor

Heats

Water Valve

Monitor

1..*

Opens/Closes

temperature

07-UML-Dynamic

Controller

50

Iterate the Model

Keep on doing this until

you, your customer, and
your engineers are happy
with the model

Iterate

07-UML-Dynamic

51

Activity Diagrams

07-UML-Dynamic

52

We Will Cover

History of activity diagrams in UML

A highly personal perspective

Activity diagrams
Swimlanes
When to use activity diagrams

When not to

07-UML-Dynamic

53

Activity Diagrams

Shows how activities are connected together

Mechanisms to express

Shows the order of processing

Captures parallelism
Processing
Synchronization
Conditional selection of processing

A glorified flowchart

07-UML-Dynamic

54

Why Activity Diagrams

Very good question

Suitable for modeling of business activities

Not part of any previous (UML related) method

Introduced for activities, like business processes
Introduced to sell products (drawing tools)
UML and OO is becoming more prevalent in business applications
Object frameworks are making an inroad
Stay within one development approach and notation

Generally a flowchart and I do not really see the need in OO modeling

Probably because I do not do business systems

B.H.C.

07-UML-Dynamic

55

Why Activity Diagrams

Very good question

Suitable for modeling of business activities

Not part of any previous (UML related) method

Introduced for activities, like business processes
Introduced to sell products (drawing tools)
UML and OO is becoming more prevalent in business applications
Object frameworks are making an inroad
Stay within one development approach and notation

Not bad for group-capture of a business process

w.e.m.

Swimlanes are useful

State diagrams are not very clear to many people
Suitable for customer viewing

07-UML-Dynamic

56

Coffee Example
F in d B e v e r a g e

[n o c o ffe e ]

D e c is io n

[n o c o k e ]

[fo u n d c o ffe e ]
[fo u n d c o k e ]

P u t C o f f e e in F ilt e r

A d d W a te r to
R e s e r v o ir

G et Cups

G et C an of C oke

P u t F ilt e r in
M a c h in e

T u r n O n M a c h in e

^ c o ffe P o t.T u rn O n

B re w C o ffe e

D r in k B e v e r a g e

P o u r C o ffe e

M H

HACS Use-Cases
Use case:
Distribute Assignments
Actors: Instructor (initiator), Student
Type:
Primary and essential
Description:
The Instructor completes an assignment and submits
it to the system. The instructor will also submit the
delivery date, due date, and the class the assignment
is assigned for. The system will at the due date mail
the assignment to the student.
Cross Ref.:
Requirements XX, YY, and ZZ
Use-Cases:
Configure HACS must be done before any user
(Instructor or Student) can use HACS

07-UML-Dynamic

58

Activity Diagrams for Use Cases

W r it e
A s s ig n m e n t

[ s u b m is s io n t im e ]
W r it e S o lu t io n

S u b m it
A s s ig n m e n t

M a il
A s s ig n m e n t

S u b m it S o lv e d
A s s ig n m e n t

S u b m it
S o lu tio n

G ra d e
A s s ig n m e n t

S o lv e
A s s ig n m e n t

M a il S o lu tio n

R e v ie w
S o lu t io n

H it th e P u b

Swimlanes (Who Does What?)

In s tru c to r

H ACS

S tu d e n t

W r ite
A s s ig n m e n t

[s u b m is s io n tim e ]
W r it e S o lu t io n

S u b m it
A s s ig n m e n t

M a il
A s s ig n m e n t

S u b m it S o lv e d
A s s ig n m e n t

S u b m it
S o lu t io n

G ra d e
A s s ig n m e n t

S o lv e
A s s ig n m e n t

M a il S o lu t io n

R e v ie w
S o lu tio n

H it th e P u b

07-UML-Dynamic

60

Problems with Activity

Diagrams

NOT good for design not bad for biz process

They are glorified flowcharts

Very easy to make a traditional data-flow oriented design

Switching to the OO paradigm is hard enough as it is

Flow to OO is hard

Extensive use of activity charts can make this shift even harder

However...

Very powerful when you know how to use them correctly

07-UML-Dynamic

61

When to Use Activity Diagrams

Not clear how useful in OO modeling

Particularly when modeling control systems

Useful when

Understanding workflow in an organization

Analyzing a use case (or collection of use cases)
Working with multi-threaded applications (maybe)

For instance, process control applications

Do not use activity diagrams

To figure out how objects collaborate

See how objects behave over time

07-UML-Dynamic

62