OO Using UML: Dynamic Models - PowerPoint PPT Presentation

About This Presentation
Title:

OO Using UML: Dynamic Models

Description:

Overview The object model describes the structure of the system ... send(event) Pulse ... The Callee Idle Dial tone off-hook Dialing Ringing ... – PowerPoint PPT presentation

Number of Views:57
Avg rating:3.0/5.0
Slides: 51
Provided by: cseMsuEd2
Learn more at: http://www.cse.msu.edu
Category:

less

Transcript and Presenter's Notes

Title: OO Using UML: Dynamic Models


1
OO Using UMLDynamic Models
  • Defining how the objects behave

2
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
  • State Diagrams
  • Activity Diagrams
  • Uses finite state machines and expresses the
    changes in terms of events and states

3
Interaction Diagrams
4
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

5
Different Types of Interaction Diagrams
  • An Interaction Diagram typically captures a
    use-case
  • A sequence of user interactions
  • Sequence diagrams
  • Highlight the sequencing of the interactions
    between objects
  • Collaboration diagrams
  • Highlight the structure of the components
    (objects) involved in the interaction

6
Home Heating Use-Case
Use case Power Up Actors Home Owner
(initiator) Type Primary and
essential Description 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. Cross Ref. Requirements XX,
YY, and ZZ Use-Cases None
7
Sequence Diagrams
e
r
O
n
(
)


f
o
r

a
l
l

r
o
o
m
s

t
e
m
p
S
t
a
t
u
s


c
h
e
c
k
T
e
m
p
(
)

t
e
m
p
S
t
a
t
u
s




l
o
w

p
u
m
p
O
n
(
)

t
e
m
p
S
t
a
t
u
s




l
o
w

o
p
e
n
V
a
l
v
e
(
)

t
e
m
p
S
t
a
t
u
s




l
o
w

s
t
a
r
t
B
u
r
n
e
r
(
)
8
Example from Fowler
p
a
r
e
(
)
h
a
s
S
t
o
c
k




c
h
e
c
k
(
)

h
a
s
S
t
o
c
k

r
e
m
o
v
e
(
)
n
e
e
d
s
R
e
o
r
d
e
r




n
e
e
d
s
T
o
R
e
o
r
d
e
r
(
)

n
e
e
d
s
R
e
o
r
d
e
r

n
e
w
a

R
e
o
r
d
e
r

I
t
e
m

h
a
s
S
t
o
c
k


n
e
w
a

D
e
l
i
v
e
r
y

I
t
e
m
M
H
9
Concurrency
o
k
o
k
a
l
l
V
a
l
i
d
a
l
l
D
o
n
e
?
10
Another Example
r
O
n
(
)


f
o
r

e
a
c
h

r
o
o
m

i
n

h
o
u
s
e

n
e
w
c
h
e
c
k
T
e
m
p
(
)
t
e
m
p
L
o
w

t
e
m
p
L
o
w

p
u
m
p
O
n
(
)

t
e
m
p
L
o
w

o
p
e
n
V
a
l
v
e
(
)

t
e
m
p
L
o
w

s
t
a
r
t
B
u
r
n
e
r
(
)
M
H
11
Comment the Diagram

c
o
n
t
r
o
l
l
e
r
T
h
e

c
o
n
t
r
o
l
l
e
r
c
r
e
a
t
e
s

a

r
o
o
m

o
b
j
e
c
t
f
o
r

e
a
c
h

r
o
o
m

i
n

t
h
e
b
u
i
l
d
i
n
g
T
h
e

r
o
o
m
s

s
a
m
p
l
e
t
h
e

t
e
m
p
e
r
a
t
u
r
e

i
n
t
h
e

t
o
o
m

e
v
e
r
y

5

s
.
W
h
e
n

a

l
o
w

t
e
m
p

i
s
d
e
t
e
c
t
e
d

t
h
e

r
o
o
m
n
o
t
i
f
i
e
s

t
h
e
c
o
n
t
r
o
l
l
e
r
.
12
Collaboration Diagrams
R
e
o
r
d
e
r




n
e
e
d
s
T
o
R
e
o
r
d
e
r
(
)
6




n
e
e
d
s
R
e
o
r
d
e
r


7




h
a
s
S
t
o
c
k



n
e
w
n
e
w

D
e
l
i
v
e
r
y

I
t
e
m
a

R
e
o
r
d
e
r

I
t
e
m
M
H
13
Conditional Behavior
  • Something you will encounter trying to capture
    complex use-cases
  • The user does something. If this something is X
    do this If this something is Y do something
    else If this something is Z
  • Split the diagram into several
  • Split the use-case also
  • Use the conditional message
  • Could become messy
  • Remember, clarity is the goal!

14
Comparison
  • Both diagrams capture the same information
  • People just have different preferences
  • We prefer sequence diagrams
  • 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

15
When to Use Interaction Diagrams
  • When you want to clarify and explore single
    use-cases involving several objects
  • Quickly becomes unruly if you do not watch it
  • If you are interested in one object over many
    use-cases -- state transition diagrams
  • If you are interested in many objects over many
    use cases -- activity diagrams

16
State Diagrams
17
We Will Cover
  • State Machines
  • An alternate way of capturing scenarios
  • Large classes of scenarios
  • Syntax and Semantics
  • When to use state machines

18
Where Do State Diagrams Fit?
Class
Behavior
Has a
  • Generally, one state diagram per class
  • Describe the entire behavior of class
  • All methods in one state diagram

Class
1
State Diagram
19
Events, Conditions, and States
  • Event something that happens at a point in time
  • Operator presses self-test button
  • The alarm goes off
  • Condition something that has a duration
  • 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

20
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.

21
Partial Class Diagram
1
.
.
1
L
i
n
e
P
h
o
n
e
1
.
.
1
C
a
l
l
e
r
1
.
.
1
1
.
.
1
C
a
l
l
e
e
22
Event Trace
The Caller
The Callee
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)
phone rings
ringing tone
callee answers
ringing stops
tone stops
phones connected
phones connected
caller hangs up
phones disconnected
phones disconnected
callee hangs up
23
State Diagram for Scenario
Idle
on-hook
off-hook
Dial tone
digit(x)
digit(x)
Dialing
valid-number
Ringing
called-phone-answers
Connected
called-phone-hangs-up
Disconnected
24
Scenario 2
The Caller
The Callee
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
25
Modified State Machine
Idle
off-hook
digit(x)
Dial tone
Dialing
digit(x)
on-hook
valid-number
Busy tone
number-busy
Connecting
routed
Ringing
called-phone-answers
Connected
called-phone-hangs-up
Disconnected
on-hook
26
Conditions
  • Sometimes the state transitions are conditional

Idle
on-hook
off-hook
Dial tone
digit(x) x 8
digit(x) x ! 8
digit(x)
digit(x)
Dial tone (external)
digit(x)
Dialing
Dialing
valid-number
valid-number
Busy tone
number-busy
Connecting
routed
Ringing
27
Operations (AKA Actions)
Idle
off-hook
  • Actions are performed when a transition is taken
    or performed while in a state
  • Actions are terminated when leaving the state

Dial tone
digit(x)
on-hook
do/ sound dial tone
Dialing
digit(x)
on-hook
valid-number
Busy tone
on-hook
number-busy
do/ busy tone
Connecting
on-hook
do/ find connection
routed
Ringing
on-hook
do/ ring bell
called-phone-answers / connect line
Connected
on-hook / disconnect line
called-phone-hangs-up / disconnect line
Disconnected
on-hook
28
Hierarchical State Machines
on-hook
Idle
Dial tone
do/ sound dial tone
off-hook
dial(x) x is a digit
dial(x) x
Make Call
  • Group states with similar characteristics
  • Enables information hiding
  • Simplifies the diagrams

Establish call
Voice Mail
dial(x)
Dialing
valid-number
number-busy
Connecting
on-hook
do/ find connection
Busy tone
do/ busy tone
routed
Ringing
do/ ring bell
called-phone-answers / connect line
on-hook / disconnect line
Connected
called-phone-hangs-up / disconnect line
on-hook
Disconnected
29
Information Hiding
Establish call
on-hook
dial(x)
Idle
Dialing
Dial tone
off-hook
do/ sound dial tone
valid-number
dial(x) x is a digit
dial(x) x
number-busy
Connecting
Make Call
do/ find connection
Busy tone
Establish call
do/ busy tone
Voice Mail
routed
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
30
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
keyboard-key character
mouse-down
mouse-up
31
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
32
Ambiguous Semantics 1
Is F transition ever taken? How?
A
B
E
F
G
33
Ambiguous Semantics 2
What happens when G is false after event E?
G
A
B
E
Are we stuck here?
34
Ambiguous Semantics 3
How many threads are running in here?
F
A
B
J
G
D
C
K
H
E
What does this mean?
35
Ambiguous Semantics 4
F
A
B
J
G
D
C
K
H
E
Does this component get started?
36
Ambiguous Semantics 5
Class_One
Class_Two
Class_Two.message
What is the semantics of message
passing? Queued? Rendezvous? Lost if no
transition?
37
Transition Rules
  • Find all the transitions with the trigger event
  • If there are none, the event is lost. This is not
    an error.
  • Evaluate the guards (if any)
  • 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.

38
More Transition Rules
  • Descendants of actions (in an 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.

39
Transition Syntax
EventGuard/Action1Action2.ActionN
Actions include send(event)
Events include timeout(), when(boolean)
Pulsepulsemode/count
Sample triggers
Timeout(10s)/send(reset)
Digit(d)isvalid(d)/stash(d)
40
State Machines - Summary
  • Events
  • instances in time
  • Conditions
  • conditions over time
  • States
  • abstraction of the attributes and associations
  • Transitions
  • Takes the state machine from one state to the
    next
  • Triggered by events
  • Guarded by conditions
  • Cause actions to happen
  • Internal actions
  • something performed in a state
  • Hierarchies
  • allows abstraction and information hiding
  • Parallelism
  • models concurrent concepts

41
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

42
Coming up with the State Diagrams
43
Modeling Approach
  • Prepare scenarios
  • Work with the customer
  • Start with normal scenarios
  • Add abnormal scenarios
  • Identify events (often messages)
  • Group into event classes
  • Draw some sequence diagrams
  • Find objects with complex functionality you want
    to understand better
  • Build a state diagram for the complex classes

44
Scenario-1
Fuel Valve
Room
Controller
Burner
Water Pump
request-temp
Every 5s
respond-temp
open-valve
Temp Low
start-burner
pump-on
open-water-valve
request-temp
Every 5s
respond-temp
Temp Normal
45
Scenario-2
Fuel Valve
Water Pump
Control Panel
Room
Controller
Burner
request-temp
respond-temp
Every 5s
desired-temp-change
Desired temp change
request-temp
respond-temp
Every 5s
open-valve
Temp Low
start-burner
pump-on
open-water-valve
request-temp
respond-temp
Every 5s
Temp Normal
46
Dynamic Model
47
More Dynamic Model
48
Even More Dynamic Model
Controller
Temperature
respond-temp(x)xgtdesired-temp2/stop-heating
timeout(5s)\ request-temp
timeout(5s)\ request-temp
Temp-Low
Temp-Normal
respond-temp(x)xltdesired-temp-2/start-heating
Home Heating System
timeout(1s)/start-burner
timeout(1s)/ pump-on,open-water-valve
Burner-On
Fuel-Open
start-heating/open-valve
All-Running
All-Off
Water-Off
Fuel-Off
timeout(1s)/close-valve
stop-heating/ pump-off,close-water-valve
timeout(1s)/stop-burner
49
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
  • Actions and activities represent some processing
    activity within some object
  • Operations from functions
  • Each function typically represent one or more
    operations
  • Shopping list operations
  • Inherent operations (what should be there)

50
Complete OO Model
Home Heating
System
Control Panel
Water Pump
3
Runs
Furnace
operating()
on()
target-temp()
off()
Fuel Valve
Burner
On-Off Switch
Thermostat
1..
open()
on()
setting
desired-temp
Room
close()
off()
3
8
Pushes
Adjusts
3
Opens/Closes
open-valve()
3
Ignites
1..
close-valve()
Operator
Notifies
room-temp()
3
8
1..
3
Monitor
Heats
Water Valve
Temp Sensor
temperature
Controller
51
Iterate the Model
  • Keep on doing this until you, your customer, and
    your engineers are happy with the model

52
Activity Diagrams
53
We Will Cover
  • History of activity diagrams in UML
  • A highly personal perspective
  • Activity diagrams
  • Swimlanes
  • When to use activity diagrams
  • When not to

54
Activity Diagrams
  • Shows how activities are connected together
  • Shows the order of processing
  • Captures parallelism
  • Mechanisms to express
  • Processing
  • Synchronization
  • Conditional selection of processing
  • A glorified flowchart

55
Why Activity Diagrams
  • Very good question
  • Not part of any previous (UML related) method
  • Introduced for activities, like business
    processes
  • Introduced to sell products (drawing tools)
  • Suitable for modeling of business activities
  • 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.
56
Why Activity Diagrams
  • Very good question
  • Not part of any previous (UML related) method
  • Introduced for activities, like business
    processes
  • Introduced to sell products (drawing tools)
  • Suitable for modeling of business activities
  • 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
  • Swimlanes are useful
  • State diagrams are not very clear to many people
  • Suitable for customer viewing

w.e.m.
57
Coffee Example

n
o

c
o
k
e


f
o
u
n
d

c
o
k
e

A
d
d

W
a
t
e
r

t
o
G
e
t

C
u
p
s
R
e
s
e
r
v
o
i
r

c
o
f
f
e
P
o
t
.
T
u
r
n
O
n
58
HACS Use-Cases
Use case Distribute Assignments Actors Instructo
r (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
59
Activity Diagrams for Use Cases

s
u
b
m
i
s
s
i
o
n

t
i
m
e

A
s
s
i
g
n
m
e
n
t
60
Swimlanes (Who Does What?)
I
n
s
t
r
u
c
t
o
r
H
A
C
S
S
t
u
d
e
n
t
e

G
r
a
d
e
A
s
s
i
g
n
m
e
n
t
61
Problems with Activity Diagrams
  • NOT good for design not bad for biz process
  • Flow to OO is hard
  • 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
  • Extensive use of activity charts can make this
    shift even harder
  • However...
  • Very powerful when you know how to use them
    correctly

62
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
Write a Comment
User Comments (0)
About PowerShow.com