Transcript 07-UML-Dynamic.ppt

OO Using UML:
Dynamic Models
Defining how the objects behave
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
Interaction Diagrams
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
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
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.
Sequence Diagrams
a Home Owner
the On-Off Switch
the Controller
a Room
System On
powerOn()
*[for all rooms]
tempStatus:=checkTemp()
[tempStatus == low]
pumpOn()
[tempStatus == low]
openValve()
[tempStatus == low]
startBurner()
the Water Pump
Example from Fowler
an Order entry
Window
an Order
an Order Line
a Stock Item
prepare()
*[for all order lines]
prepare()
hasStock := check()
[hasStock]
remove()
needsReorder := needsToReorder()
[needsReorder]
new
[hasStock] new
a Reorder Item
a Delivery Item
MH
Concurrency
new
a Transaction
new
a Transaction
Coordinator
new
a first Transaction
Checker
a second
Transaction
Checker
new
ok
allDone?
ok
allValid
allDone?
Another Example
a Home Owner
the On-Off Switch
System On
the Controller
the Water Pump
powerOn()
*[for each room in house]
new
a Room
checkTemp()
tempLow
[tempLow]
pumpOn()
[tempLow]
openValve()
[tempLow]
startBurner()
MH
Comment the Diagram
When the owner
turns the system on
the on switch notifies
the controller
The controller
creates a room object
for each room in the
building
a Home Owner
the On-Off Switch
System On
the Controller
the Water Pump
powerOn()
*[for each room in house]
new
a Room
checkTemp()
The rooms sample
the temperature in
the toom every 5 s.
When a low temp is
detected the room
notifies the
controller.
tempLow
[tempLow]
pumpOn()
[tempLow]
openValve()
[tempLow]
startBurner()
MH
Collaboration Diagrams
:Order Entry
Window
1 : prepare()
:Order
5 : needsReorder := needsToReorder()
2 : *[for all order lines]:
prepare()
3 : hasStock := check()
Winter stock :
Stock Item
Winter line : Order Line
7 : [hasStock] :new
:Delivery Item
4 : [hasStock]:
remove()
6 : [needsReorder]:
new
a Reorder Item
MH
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!
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
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
State Diagrams
We Will Cover

State Machines

An alternate way of capturing scenarios



Large classes of scenarios
Syntax and Semantics
When to use state machines
Where Do State Diagrams Fit?
Has a
Class
Class
1
State Diagram
Behavior
• Generally, one state diagram per class
• Describe the entire behavior of class
• All methods in one state diagram
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
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.
Partial Class Diagram
1..1
Line
1..1
Caller
1..1
1..1
Callee
Phone
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
callee answers
ringing stops
phones connected
phones connected
phones disconnected
caller hangs up
phones disconnected
callee hangs up
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
valid-number
number-busy
routed
Ringing
digit(x)
Connecting
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
number-busy
on-hook
Dialing
valid-number
Connecting
routed do/ find connection
on-hook
Ringing
do/ ring bell
called-phone-answers / connect line
on-hook / disconnect line
Connected
called-phone-hangs-up / disconnect line
on-hook
Disconnected
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
dial(x) [x = *]
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
Voice Mail
Information Hiding
on-hook
Idle
off-hook
Establish call
Dial tone
Dialing
do/ sound dial tone
dial(x) [x is a digit]
dial(x) [x = *]
valid-number
number-busy
Make Call
Busy tone
Establish call
Voice Mail
on-hook
dial(x)
do/ busy tone
Connecting
do/ find connection
routed
Ringing
on-hook /
disconnect line
on-hook
Connected
called-phone-answers /
connect line
called-phone-hangs-up /
disconnect line
Disconnected
do/ ring bell
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
mouse-up
keyboard-key
character
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 Enabled
Visual Alarm
reset
On
Off
visual-on
Aural Alarm
reset
On
Off
aural-on
Ambiguous Semantics 1
Is F transition ever taken?
How?
A
E
F
B
[G]
Ambiguous Semantics 2
What happens when G is false after event E?
A
E
[G]
B
Are we stuck here?
Ambiguous Semantics 3
How many threads are running in here?
A
B
F
J
G
C
D
K
H
E
What does this mean?
Ambiguous Semantics 4
A
B
F
J
G
C
D
K
H
E
Does this component get started?
Ambiguous Semantics 5
Class_One
Class_Two
Class_Two.message
What is the semantics
of message passing?
Queued?
Rendezvous?
Lost if no transition?
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.
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.
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)
State Machines - Summary

Events


conditions over time

abstraction of the attributes
and associations
Takes the state machine from
one state to the next



Triggered by events
Guarded by conditions
Cause actions to happen

something performed in a
state
Hierarchies

Transitions

Internal actions

States



Conditions


instances in time
allows abstraction and
information hiding
Parallelism

models concurrent concepts
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
Coming up with the State
Diagrams
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
Scenario-1
Room
Fuel
Valve
Controller
Burner
request-temp
Every 5s
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
Room
Controller
Fuel
Valve
Burner
request-temp
Every 5s
Desired temp
change
Every 5s
respond-temp
desired-temp-change
request-temp
respond-temp
open-valve
start-burner
Temp Low
pump-on
open-water-valve
request-temp
Every 5s
respond-temp
pump-off
Temp Normal
close-water-valve
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
More Dynamic Model
Room
Water-Valve
open-water-valve/
wv-open
Temp-Sensor
Idle
Valve
request-temp
close-water-valve/
wv-close
temp-report(x)/
respond-temp(x)
Processing
Request
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
All-Running
stop-heating/
pump-off,close-water-valve
start-heating/open-valve
All-Off
Water-Off
Fuel-Off
timeout(1s)/stop-burner
timeout(1s)/close-valve
Identify Key Operations

Operations from the object model



Accessing and setting attributes
and associations (often not shown)
Operations from actions and
activities

Operations from events

All events represent some
operation

Operations from functions


Actions and activities represent
some processing activity within
some object
Each function typically represent
one or more operations
Shopping list operations

Inherent operations (what should
be there)
Complete OO Model
Home Heating
System
Control Panel
Water Pump
Runs
Furnace
operating()
target-temp()
on()
off()
On-Off Switch
Thermostat
setting
desired-temp
Burner
Fuel Valve
on()
off()
open()
close()
1..*
Room
Pushes
Adjusts 
Ignites
Water Valve
Temp Sensor
temperature
Opens/Closes
Monitor
1..*
Heats
Notifies 
Operator
open-valve()
close-valve() 1..*
room-temp()
Controller
Iterate the Model

Keep on doing this until
you, your customer, and
your engineers are happy
with the model
Iterate
Activity Diagrams
We Will Cover

History of activity diagrams in UML




A highly personal perspective
Activity diagrams
Swimlanes
When to use activity diagrams

When not to
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
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

B.H.C.
Probably because I do not do business systems
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
Coffee Example
Find Beverage
[no coffee]
Decision
[no coke]
[found coffee]
[found coke]
Put Coffee in Filter
Add Water to
Reservoir
Get Cups
Get Can of Coke
Put Filter in
Machine
Turn On Machine
^coffePot.TurnOn
Brew Coffee
Drink Beverage
Pour Coffee
MH
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
Activity Diagrams for Use Cases
Write
Assignment
[submission time]
Write Solution
Submit
Assignment
Mail
Assignment
Submit Solved
Assignment
Submit
Solution
Mail Solution
Grade
Assignment
Solve
Assignment
Review
Solution
Hit the Pub
Swimlanes (Who Does What?)
Instructor
HACS
Student
Write
Assignment
[submission time]
Write Solution
Submit
Assignment
Mail
Assignment
Submit Solved
Assignment
Submit
Solution
Mail Solution
Grade
Assignment
Solve
Assignment
Review
Solution
Hit the Pub
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
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