1 module 3: advanced features – part ii: behavioral...
TRANSCRIPT
2
3 b
asic
build
ing b
locks o
f U
ML
-D
iag
ram
sG
raphic
al re
pre
senta
tion o
f a
set
of ele
ments
.
Repre
sente
d b
y a
connecte
d g
raph: V
ert
ices a
re t
hin
gs; A
rcs a
re r
ela
tionship
s/b
ehavio
rs.
5 m
ost
com
mon v
iew
s b
uilt
fro
m
UML 1.x: 9 diagram types.
UML 2.0: 12 diagram types
Behavio
ral D
iagra
ms
Represent the dynamicaspects.
–U
se c
ase
–S
equence;
Colla
bora
tion
–S
tate
chart
–A
ctivity
Str
uctu
ral D
iagra
ms
Represent the static aspects of a system.
–C
lass;
Obje
ct
–C
om
ponent
–D
eplo
ym
ent
Behavio
ral D
iagra
ms
–U
se c
ase
–S
tate
chart
–A
ctivity
Str
uctu
ral D
iagra
ms
–C
lass;
Obje
ct
–C
om
ponent
–D
eplo
ym
ent
–C
om
posite S
tructu
re
–P
ackage
Inte
raction D
iagra
ms
–S
equence;
Communication
–In
tera
ction O
verv
iew
–T
imin
g
3
Use C
ase D
iagra
ms
Behavio
ral D
iagra
ms
–Use case
–S
tate
chart
–A
ctivity
Inte
raction D
iagra
ms
–S
equence;
Communication
–In
tera
ction O
verv
iew
–T
imin
g
4
Use Cases
�S
cenarios
describe a
sin
gle
path
, or
a p
art
icula
r sequence
�E
.g., U
se C
ase:
Ord
er
Goods
�S
cenario 1
: all
goes w
ell
�S
cenario 2
: in
suffic
ient fu
nds
�S
cenario 3
: out o
f sto
ck
�S
yste
m test cases: G
enera
te a
test script fo
r each s
cenario (
flow
of
events
).
�O
bta
in initia
l sta
te f
rom
pre
conditio
ns.
�T
est success a
gain
st post conditio
ns.
�W
hen to U
se
Use C
ases
�F
ow
ler’s V
iew
: do u
se c
ases f
irst
befo
re o
bje
ct
modelin
g
�C
aptu
re t
he sim
ple, norm
al use-case
firs
t
�F
or
eve
ry s
tep
ask “What could go wrong?”
and h
ow
it
mig
ht
wo
rk o
ut diffe
rently
�P
lot all
variations a
s extension
s o
f th
e g
iven u
se c
ase
�A
noth
er
vie
w:
do o
bje
ct
mod
elin
g f
irst,
then u
se c
ases
�A
noth
er:
ite
rate
model -
use c
ase -
model -
use c
ase .
..What did we do?
5
Organizing U
se Cases
•G
enera
lization,
Exte
nd,
Inclu
de/U
se, packages
Track order
gen
eraliza
tion
Validate user
Retinal scan
Check password
Place rush order
Place order
Extension points:
set priority
extension
inclusion
extensionpoint
<<extend>>
(set priority)
<<include>
>
<<include>
>
•Track O
rder-Obtain and verify the order number; For each part in the order,query its status,
then report back to the user.
•Place O
rder-Collect the user’s order items. (set priority). Submit the order for processing.
com
mo
n to
multip
le u
se c
ase
s;
Often no
acto
r m
ay b
e a
ssocia
ted
with a
‘used’use c
ase
UML 1.3: Replaces <<uses>> relationship with Generalization and <<include>> dependency (http://www.jeckle.de/files/viewfront.pdf)
does a bit m
ore or deals w
ith a special situation
extension use case
inclusion use case
child use case
base use case
6
A AAAUse Case Template
(htt
p:/
/ww
w.b
rede
me
ye
r.com
/pdf_
file
s/u
se_
ca
se
.pdf)
No
n-F
un
ctio
na
l (o
ptio
na
l)L
ist of
NF
Rs th
at th
e u
se c
ase m
ust m
ee
t
Issu
es
Lis
t of
issue
s th
at re
ma
in to b
e r
eso
lve
d
Diffe
rence fo
r th
e s
pe
cific
su
bflo
wA
lt. flo
w o
f e
ve
nts
/sub
flo
ws
Wha
t sh
ou
ld h
old
afte
r th
e u
se c
ase s
ucce
ssfu
lly c
om
ple
tes.
Po
stc
on
ditio
ns
Su
bflo
ws m
ay b
e d
ivid
ed
in
to 1
) n
orm
al, 2
) successfu
l a
lte
rnate
action
s, a
nd 3
) e
xce
ptio
n/e
rro
r flo
ws.
Exce
ptio
n f
low
s
Th
e h
ap
py/s
un
ny d
ay f
low
. T
he
mo
st co
mm
on s
ucce
ssfu
l ca
se.
Ba
sic
flo
w o
f e
ve
nts
Wha
t sh
ou
ld b
e tru
e b
efo
re the
use c
ase c
an s
tart
.P
reco
nd
itio
ns
Goal: E
.g., “
Th
is u
se
case
lets
a b
ank a
cco
unt
ow
ne
r w
ith
dra
w
mo
ne
y f
rom
an
AT
M m
ach
ine”;
Source:
Ba
nk d
oc 2
.3
Bri
ef d
escri
ptio
n
Lis
t of a
cto
rs in
vo
lve
d in
use c
ase
Acto
rs
Ide
ntifier:
e.g
., “
With
dra
w m
on
ey”;
ref
# =
wm
3;
mo
d h
isto
ry =
…U
se
Ca
se
7
A Use C
ase Template
What
are
the
mode
s o
f co
mm
un
ica
tion
be
twe
en
fie
ld m
ain
tena
nce
en
gin
ee
r and
ope
rato
rIs
su
es (
tha
t re
ma
in to
be
reso
lved
)
Pe
rfo
rma
nce
Me
an
: tim
e to
repa
ir n
etw
ork
fau
lt m
ust b
e le
ss tha
n3 h
ou
rsN
on
-Fun
ctiona
l (o
ptiona
l)
#1
. S
yste
m m
ay d
ete
ct fa
ult a
nd
no
tify
ope
rato
r o
r
Fie
ld m
ain
tenan
ce e
ngin
ee
r m
ay r
epo
rt f
au
lt t
o O
pe
rato
r
Va
ria
tio
ns (
op
tiona
l)
1.
Op
era
tor
no
tifie
d o
f n
etw
ork
pro
ble
m
2.
Op
era
tor
sta
rts r
epa
ir s
essio
n
3.
RE
PE
AT
3.1
Ope
rato
r ru
ns n
etw
ork
dia
gno
sis
app
lica
tio
n
3.2
Ope
rato
r id
en
tifie
s c
ells
to
be
change
s a
nd
the
ir n
ew
pa
ram
ete
r va
lue
s
3.3
IN P
AR
ALLE
L
3.3
.1 M
ain
tena
nce
en
gin
ee
r te
sts
ne
two
rk c
ells
||
3.3
.2 M
ain
tena
nce
en
gin
ee
r send
s fa
ult r
ep
ort
s
UN
TIL
no
mo
re r
ep
ort
s o
f p
roble
m
4.
Ope
rato
r clo
se
s r
epa
ir s
essio
n
Ste
ps
Chan
ge
s to
ne
two
rk a
re a
lwa
ys s
ucce
ssfu
l w
he
n a
pp
lied
to
a n
etw
ork
Assum
ption
s (
su
cce
ssfu
l u
se
ca
se
te
rmin
ation
cond
itio
n)
Op
era
tor
(prim
ary
, C
ellu
lar
ne
two
rk,
Fie
ld m
ain
tenan
ce
en
gin
ee
r)A
cto
rs
Op
era
tor
rectifie
s a
repo
rt b
y c
han
gin
g p
ara
me
ters
of
a c
ell
De
scrip
tion
(goa
l, s
ou
rce
)
2.
Repa
rin
g_
Ce
llula
r_N
etw
ork
His
tory
cre
ate
d 1
/5/9
8 D
ere
k C
ole
ma
n, m
od
ifie
d 5
/5/9
8
Use
Ca
se
(id
, re
f#,
mod
his
tory
)
(htt
p:/
/ww
w.b
rede
me
ye
r.com
/pdf_
file
s/u
se_
ca
se
.pdf)
Ho
w a
re fa
ilure
s d
ete
cte
d?
Are
roll
ba
cks a
uto
ma
tic o
r is
Ope
rato
r in
terv
en
tion
re
qu
ired?
Issu
es
#3.3
.if th
e c
han
ge
s to
ne
two
rk f
ail
then
th
e n
etw
ork
is r
olle
d b
ack t
o its
pre
vio
us s
tate
Ste
ps
Dea
ls w
ith
assum
ption t
ha
t ne
two
rk c
ha
nge
s c
an
ne
ve
r fa
ilD
escrip
tion
Repa
ir_m
ay_
fail
exte
nd
s 2
. R
epa
rin
g_
Ce
llula
r_N
etw
ork
Use
Ca
se
Exte
nsio
n
8
Sequence D
iagra
ms
Behavio
ral D
iagra
ms
–U
se c
ase
–S
tate
chart
–A
ctivity
Inte
raction D
iagra
ms
–Sequence
;
Communication
–In
tera
ction O
verv
iew
–T
imin
g
9
Interaction Diagrams (sd and cd)
�sho
w t
he inte
raction o
fany kind ofinstance (classes, interfaces, components,
nodes and subsystems);
�m
essages s
ent/
receiv
ed b
y t
hose o
bje
cts
/insta
nces (
invocation,
constr
uction/d
estr
uction,
of
an o
pera
tio
n)
�re
aliz
es u
se c
ases t
o m
odel a s
cenari
o
�In
tera
ction t
yp
es (
these a
re isom
orp
hic
, w
hen n
o lo
ops o
r bra
nch
ing)
–S
equence
dia
gra
m—
em
phasiz
es the tim
e o
rdering
of m
essages.
–C
om
munic
ation
(Colla
bora
tion)
dia
gra
m—
em
phasiz
es the s
tructu
ral org
aniz
ation o
f obje
cts
th
at directly s
end a
nd r
eceiv
e m
essages.
�O
bje
cts
within
an inte
raction c
an b
e:
–C
oncre
te:
som
eth
ing f
rom
the r
eal w
orld.
(e.g
., John: Person)
–P
roto
typic
al:
repre
se
nta
tive insta
nce o
f som
eth
ing f
rom
the
real w
orl
d
(e.g
., p: Person)
•C
om
mun
icatio
n d
iagra
ms u
se (
str
ictly)
pro
toty
pic
al th
ings.
•P
roto
typ
ical in
sta
nces o
f in
terf
aces a
nd a
bstr
act
types a
re v
alid
.
10
Interaction Diagram: sequencevs communication
s1 : StockQuoteSubscriber
p : StockQuotePublisher attach(s1)
s2 : StockQuoteSubscriber
attach(s2)
notify()
update()
update()
getState()
getState()
s1 : StockQuoteSubscriber
p : StockQuotePublisher
s2 : StockQuoteSubscriber
1 : attach(s1)
6 : getState()
2 : attach(s2)
7 : getState()
3 : notify()
4 : update()
5 : update()
Observer
design
pattern
object
role:ClassName
Procedure call, RMI, JDBC, …
Activations (See pg 17)
-S
ho
w d
ura
tion
of
execu
tio
n
-S
ho
ws c
all
sta
ck
-R
etu
rn m
essa
ge
Imp
licit a
t en
d o
f a
ctiva
tion
Exp
licit w
ith
a d
ashed
arr
ow
objects
Tim
e
{update
< 1
min
ute
s}
classifiers or their instances,
use cases or actors.
11
Interactions -Modeling Actions
•S
imple
•C
all
•R
etu
rn
•S
end
: TicketAgent
c : Client
p : PlanningAgent
<<create>>
setItenerary( i )
calculateRoute()
route
Xnotify()
return value
send
call on self
<<destroy>>
actual parameter
return
end of object life
destroy: e.g., in C
++ m
anual garbage co
llection; in Java
/C#, unnecessary
Additional co
nsiderations
�T
o s
how
neste
d m
essages, use ?
.
�T
o s
how
constr
ain
ts lik
e tim
e a
nd s
pace, use ?
.
�F
or
form
al flow
of contr
ol, a
ttach p
re a
nd p
ost conditio
ns to e
ach m
essage (?
)
1
natural dea
th/
self destruction
asynchronous in 2.0 (stick arrowhead) –no return value expected at end of callee activation
half arrow in 1.x
activation of caller may end before callee’s
(???)
(???)
(???)
(???)
for each conference
loop
12
concurrent lifelines
-for conditionals
-for concurrency
linking sequence diagrams
ob1:C
1
ob3:C
3
ob2:C
2
ob3:C
3
op1
[x>
0] fo
o(x
)
[x<
0] bar(
x)
do(w
)
do(z
)
recurs
e()
[z=
0] ja
r(z)
ob3:C
3
[z=
0] ja
r(z)
ob3:C
3
conditional
recursion
Sequence Diagrams –
Generic vs. Instance
�2 f
orm
s o
f sd:
�Instance
sd:
describes a
specific
scenario in d
eta
il; n
o c
on
ditio
ns, bra
nches o
r lo
ops.
�Generic
sd:
a u
se c
ase d
escription w
ith a
lte
rnative c
ours
es.
Here, conditional or concurrency?
13
Tim
ing constraints
�U
sefu
l in
real-tim
e a
pplic
ations
�usefu
l to
specify r
ace c
onditio
n b
ehavio
ur
�T
wo w
ays to s
pecify (
in 1
.x)
any example?
14
Interactions -
Procedural Sequencing vs. Flat Sequencing
Fla
t S
equ
encin
g•
Infr
equent: Not recommended for most
situations.
•E
ach m
essage is n
um
bere
d s
equentially
in
ord
er
of tim
ing.
•R
endere
d w
ith s
tick
arr
ow
head.
c : Client
xx.k
c : Client
xy
7
4 5 6
1 2 3
CAN’T
TELL R
ELATIO
NSHIP
S
Pro
ce
du
ral S
eq
ue
ncin
g
(Dew
ey d
ecim
al syste
m)
•M
ost com
mon.
•E
ach m
essage w
ithin
the s
am
e o
pera
tion is
num
bere
d s
eque
ntially
.
•N
este
dm
essages a
re p
refixed w
ith the
sequence n
um
ber
of
the invokin
g o
pera
tion.
•R
endere
d w
ith fill
ed s
olid
arr
ow
.
8 9
3.1.1
1.1
1.2
3.1
1 2 3
1.1.1
1.1.2
15
:Eunconditional
Interactions –
conditional paths, asynchronous m
essage
[Cra
ig L
arm
an
] [h
ttp
://w
ww
.php
tr.c
om
/art
icle
s/a
rtic
le.a
sp?
p=
36
0441
&se
qN
um
=6
&rl=
1]
:A :C
:B :D
1: m
sg1
1a [te
st1
]:m
sg2
2: m
sg7
1b [not
test1
]:m
sg3
1c: m
sg4
a.1:<<create>>
1a and 1b are mutually
exclusive conditional paths
1c.1
: m
sg5
active object
asynchrous message
a.2:update( p )
:F
Is this ok?
Can you produce a corresponding sd?
Is there a unique sequence of paths?
16
Use Case
Modeling Different Levels of Abstraction
Interaction Diagram at a High Level of Abstraction
: Order Clerk
: Order Taker
: Order
Fulfillm
ent
submitOrder
placeOrder
acknowledgeOrder
Interaction Diagram at a Lower Level of Abstraction
: Order Clerk
: Order Taker
: Order
Fulfillm
ent
: Billing Agent
: CreditCard
Agen
submitOrder
placeOrder
processCard
acknowledgeOrder
triggerB
ill
Order Clerk
Place O
rder
�E
sta
blis
h t
race
depen
dencie
s b
etw
ee
n h
igh a
nd lo
w levels
of
abstr
action
�Loosely couple different levels of abstraction
•Use Cases
trac
e to
Collaborations
in the Design M
odel, t
o a
soci
ety
of classes
•Components
trac
e to
the
elem
ents
in th
e de
sign
mod
el, t
hen
to Nodes
<<
trace>
>
<<
trace>
>
model
17
public Class Selection
{private
Purc
hase m
yP
urc
hase =
new
Purc
hase()
;
private Payment myPayment;
public void purchase()
{m
yP
urc
hase.b
uyM
ajo
r();
myP
urc
hase.b
uyM
inor(
):
myPayment = new Payment( cashTender );
//..
}
// ..
}
:Sele
ction
:Purc
hase
:Paym
ent
purc
hase
buyM
ajo
r
buyM
inor
cre
ate
(ca
shT
ende
r)
Sequence Diagrams & Some Programming
18
�Why do people call it an ATM m
achine, but they know it's
really saying Automated Teller Machine M
achine?
�Why do people say PIN
number when that truly m
eans
Personal Identification Number Number?
19
sd W
ithdra
wal
:User
:AT
M:B
ank
ref
Authenticate
alt
alt
PIN O
K
PIN NOK
with
dra
w
msg (
“am
oun
t”)
am
oun
t (a
)ch
kA
cct
(a)
msg (
“ca
rd”)
msg (
“ille
gal en
try”)
en
ou
gh
ba
l
no
t enou
gh
ba
l
mone
y
rece
ipt
msg(“
am
oun
t to
o b
ig”)
sd A
uth
enticate
:User
:AT
M:B
ank
ref
EnterP
IN
loop(0
,3)
PIN NOK
msg (
“try
aga
in”)
ca
rdId
(cid
)Idle
ref
EnterP
IN
sd E
nte
rPIN
:User
:AT
M:B
ank
PIN NOK
pin
-no
k
Dig
it[4
]
alt
pin
-ok
PIN NOK
Code
(cid
,pin
)
Frames: References
continuation
nested fragment
operandsoperator
20
Interaction O
verview Diagram
-variants
on U
ML a
ctivity d
iagra
ms
wh
ich o
ve
rvie
w c
ontr
ol flo
w.
-nodes a
re f
ram
es inste
ad o
f activitie
s.
-tw
o t
ypes o
f fr
am
e:
> inte
raction f
ram
es -
an
y t
ype o
f U
ML inte
raction d
iagra
m (
sd,
cd,
td, io
d)
or
> inte
raction o
ccurr
ence f
ram
es (ref)
whic
h indic
ate
an a
ctivity o
r op
era
tion t
o invoke.
21
sd W
ithdra
wal
:User
:AT
M:B
ank
ref
Authenticate
PIN O
KPIN NOK
with
dra
w
msg (
“am
oun
t”)
am
oun
t (a
)ch
kA
cct
(a)
msg (
“ca
rd”)
msg (
“ille
gal en
try”)
no
t enou
gh
ba
lm
sg(“
am
oun
t to
o b
ig”)
Interaction O
verview Diagram
:User
:AT
M:B
ank
sd
:User
:AT
M
sd
:User
:AT
M
sd
en
ou
gh
ba
lm
one
y
rece
ipt
:User
:AT
M:B
ank
sd
sd
Relationship with Sequence Diagram?
22
Frames & Interaction Fragment Operators
Flo
w o
f C
ontr
ol
–sd
: nam
ed s
equence d
iagra
m r
ef: r
efe
rence to “
inte
raction fra
gm
ent”
Nam
ing
–lo
op
: r
epeat in
tera
ction fra
gm
ent
–opt: o
ptional “e
xem
pla
r”(c
f. b
rea
k)
–alt: sele
ction
–par:
concurr
ent (p
ara
llel) r
egio
ns (
e.g
., m
o.c
ookF
ood -
> p
ar(
nukeF
ood, ro
tate
Food)
Ord
ering
–seq
: part
ial ord
ering (
defa
ult)
(aka “
weak”)
–str
ict: s
tric
t ord
ering
–criticalR
egio
n: id
entifies “
ato
mic
”fr
agm
ents
Causalit
y
–assert
: re
quired (
i.e. causal)
–neg
: “c
an’t h
appen”
or
a n
egative s
pecific
ation
–Ig
nore
/consid
er:
messages o
uts
ide/insid
e c
ausal str
eam
Frame:
as t
he g
raphic
al bo
und
ary
, an
d a
lab
elin
g m
echan
ism
Frame name:
“fr
am
e t
yp
e n
am
e[(
para
m t
ype:
para
m n
am
e)]
[:
retu
rn t
ype:
retu
rnnam
e]”
[guard
con
ditio
n]
can a
ppe
ar
as t
he f
irst
item
undern
eath
23
What can be in the top boxes?
(htt
p://w
ww
.agile
mo
delin
g.c
om
/art
ifa
cts
/se
que
nceD
iag
ram
.htm
)
Outputting
transcripts
Boundary/interface elements
: softw
are
ele
ments
such a
s s
cre
ens, re
port
s, H
TM
L p
ages, or
syste
m inte
rfaces that acto
rs inte
ract w
ith.
Control/processelements (controllers):
These s
erv
e a
s the g
lue b
etw
een b
oundary
ele
ments
and e
ntity
ele
ments
, im
ple
menting the logic
require
d to m
anage the v
arious e
lem
ents
and their
inte
ractions.
Often im
ple
mente
d u
sin
g o
bje
cts
, but sim
ple
ones u
sin
g m
eth
ods o
f an e
ntity
or
boundary
cla
ss.
Entity
elements
24
Modeling Protocols
-Associating Protocols w
ith Ports
«interface»
Callee
««interface
interface»»
Callee
Callee
«interface»
Caller
««interface
interface»»
Caller
Caller
«interface»
Operator
««interface
interface»»
Operator
Operator
Cla
ssX
Cla
ssX
�B
y a
set of interconnected interfaces,in
voked a
ccord
ing to a
form
al
behavioral specific
ation.
ca
ller
ca
ller
ca
ller
op
era
tor
op
era
tor
op
era
tor
ca
llee
ca
llee
ca
llee
Interaction specs
initia
lin
itia
lin
itia
l
con
ne
cte
dcon
ne
cte
dcon
ne
cte
d
con
ne
ctin
gcon
ne
ctin
gcon
ne
ctin
g
state machine spec
Operator Assisted Call
Operator Assisted Call
«uses»
«uses»
«provides»
Can you depict this using balls & sockets?
25
call
ack
number
call
ack
talk
transfer
Caller
Caller
Caller
Operator
Operator
Operator
Callee
Callee
Callee
Protocols: Reusable Interaction Sequences
(http://cot.uni-mb.si/ots2003/ppt/Selic-U
ML2.0-tutorial.030504.pdf)
�C
om
munic
ation s
equences that
�alw
ays follo
w a
pre
-defined d
ynam
ic o
rder
�occur
in d
iffe
rent conte
xts
with d
iffe
rent specific
part
icip
ants
(i.e
., insta
nces)
Interfaces
26
From Diagrams to O
bjects
Colle
ct all
messages to d
efine o
bje
ct’s m
eth
ods a
nd
sta
te tra
nsitio
ns !
Ph
on
e
Dir
ecto
ry
27
Sta
te T
ransitio
n D
iagra
ms
Behavio
ral D
iagra
ms
–U
se c
ase
–Statechart
–A
ctivity
Inte
raction D
iagra
ms
–S
equence;
Com
munic
ation
–In
tera
ction O
verv
iew
–T
imin
g
28
State Transitions
even
t name [guard condition] / action
^object/className.even
t
15 sec
send
•State machine
-event-
ord
ere
dbehavio
r th
at
specifie
s t
he s
eque
nces o
f states
an o
bje
ct/
insta
nce (
of
cla
ss/in
terf
ace/c
olla
bo
ration/…
/syste
m)
goes t
hro
ug
h
durin
g its
lifetim
e; events
trig
ger transitions
and c
ause responses.
(Sta
teC
ha
rt is o
ne p
art
icula
r kin
d o
f sta
te m
achin
e b
y D
avid
Hare
l)
•State
-conditio
n o
r situation d
uring w
hic
h a
n o
bje
ct/
insta
nce
ma
y p
erf
orm
som
e
activity;
The s
tate
of
an o
bje
ct
is c
hara
cte
rized b
y t
he v
alu
e o
f one o
r m
ore
of
its
att
ribute
s.
•Activity
-ongo
ing non-atomic
executio
n w
ithin
a s
tate
machin
e.
•Action
-execu
table
atomic c
om
puta
tion t
hat
results in a
cha
nge in s
tate
of
the
model or
the r
etu
rn o
f a v
alu
e.
even
t name (a:T
) [guard condition] / action
29
State Transitions
initia
liza
tion
open
add stu
den
t
[count<
10]
cance
lca
nce
lclose
d
cance
led
add stu
den
t/ set
count=
0;^
Cours
eRoster
.cre
ate(
cours
e)
[count=
10]
^Cours
eRoster
.del
ete
triggerless transition
guard
action
event trigger
send signal
�E
ach d
iagra
m m
ust have o
ne a
nd o
nly
one s
tart
sta
te
�A
dia
gra
m m
ay h
ave o
ne o
r m
ore
sto
p s
tate
s
�A
uto
matic tra
nsitio
n -
occurs
when the a
ctivity o
f o
ne s
tate
com
ple
tes
�N
on-a
uto
matic tra
nsitio
n -
caused b
y a
nam
ed e
vent
30
State Transitions –notational variation
open
cance
l
close
d
cance
led
[count=
10]
open
cance
l
close
d
cance
led[count=
10]
open
cance
l
close
d
cance
led
not ca
nce
l an
d [co
unt=
10]
-se
man
tic-f
ree
ve
rtic
es,
-u
sed
to
cha
in t
oge
ther
mu
ltip
le t
ran
sitio
ns.
-U
ML
2.0
Supe
rstr
uctu
re S
pe
cific
ation
, p
. 5
91
Junction pseudo state
-dyn
am
ic c
on
ditio
na
l b
ran
ch
.
--sp
littin
g o
f tr
an
sitio
ns in
to m
ultip
le o
utg
oin
g p
ath
s
--U
ML
2.0
Supe
rstr
uctu
re S
pe
cific
ation
, p
. 5
92
)
Choice pseudo state
31
State Transitions –History States
-used t
o r
em
em
ber
the p
revio
us s
tate
of
a s
tate
machin
e w
he
n it
was inte
rru
pte
d.
http://w
ww
.sparx
syste
ms.c
om
/resourc
es/u
ml2
_tu
torial/um
l2_sta
tedia
gra
m.h
tml
Cf.
deep h
isto
ry s
tate
(H
*) –
the r
ecentm
ost
sta
te in t
he r
ecentm
ost
sta
te in …
32
Advanced States
�Entry & exit actions
-actions that alw
ays o
ccur
upon e
ntr
y into
or
exit a
way fro
m a
sta
te r
egard
less o
f tr
ansitio
n.
�Internal Transitions
-tr
iggere
d b
y e
vents
but don’t c
hange s
tate
.
�Activities
-ongoin
g b
ehavio
r w
hic
h c
ontinues u
ntil in
terr
upte
d.
�Deferred events
-events
ignore
d b
y the c
urr
ent sta
te, but postp
oned
fo
r la
ter
pro
cessin
g.
Tra
ckin
g
entr
y /
setM
ode(
onT
rack )
exit /
setM
ode(
off
Tra
ck )
ne
wT
arg
et
/ tr
acker.
Acquire()
do /
follo
wT
arg
et
selfT
est /
defe
r
entry action
exit action
internal transition
activity
deferred event
name
33
Substates
�S
ubsta
te -
-sta
te n
este
d insid
e o
f anoth
er
sta
te.
�S
equential substa
tes (
then a
nonort
hogonal sta
te)
�C
oncurr
ent substa
tes (
then a
n o
rthogonal sta
te)
Idle
Main
tenance
Active
Valid
ating
Sele
cting
Pro
cessin
g
Printing
[not continue]
entr
y / r
eadC
ard
exit / e
jectC
ard
[continue]
sequential substate
composite state
main
tain
card
Insert
ed
cancel
Idle
Main
tenance
Testing
Com
mandin
g
H H
Testing
devic
es
Waitin
g
Self
dia
gnosis
Com
mand
main
tain
composite state
concurrent
substate
[continue]
join
fork
[not continue]
keyP
ress
Initial state/ pseudostate
34
Verify
Card
OutO
fServ
ice
acce
ptC
ard
Rele
aseC
ard
Verify
Tra
nsaction
outO
fServ
ice
rele
ase
Ca
rdATM
ReadA
mount :
ReadA
mountS
Maborted
aborted
reje
ctT
ran
sa
ctio
n
again
again
Modular Submachines
usage of
exit point
usage of
exit point
usage of
entry point
usage of
entry point
invoked
submachine
invoked
submachine
ReadAmountSM
sele
ctA
mount
Ente
rAm
ount
ok
abort
aborted
aborted
am
ount
oth
erA
mount
abort
again
again
EXIT point
EXIT point
ENTRY point
ENTRY point
Submachine
definition
Submachine
definition
htt
p:/
/ww
w.x
pd
ian
.com
/UM
L2
.0cha
nge
s.h
tml
-A c
om
posite s
tate
may h
ave s
evera
l entr
y a
nd e
xit p
oin
ts;
-how
does e
ntr
y p
oin
t diffe
r fr
om
H/H
*?
-pro
mote
s r
euse (
next
slid
e)
35
Specialization
•R
edefinitio
n a
s p
art
of sta
ndard
cla
ss s
pecia
lizatio
n
AT
M
acceptC
ard
()outO
fServ
ice()
am
ount(
)
Behaviour
Statemachine
Fle
xib
leA
TM
oth
erA
mou
nt(
)re
jectT
ransaction()
Behaviour
Statemachine
<<Redefine>>
36
Events –
External vs. Intern
al Events
�E
vents
can b
e c
ate
gorized into
exte
rnal or
inte
rnal events
.
�Externalevents
are
those that pass b
etw
een the A
cto
rs a
nd the s
yste
m.
System
Event
Event
NetworkElement
elementPort: Port
�Internalevents
pass b
etw
een o
bje
cts
resid
ing w
ithin
the a
pp
lication s
yste
m.
NetworkController
consolePort[2..*] : Port1
37
•Signal-
kin
d o
f eve
nt
that
rep
rese
nts
the s
pecific
ation o
f a
n
asynchronous
stim
ulu
s c
om
mu
nic
ate
d b
etw
een insta
nces.
•M
od
ele
d a
s a
cla
ss
•D
ispatc
he
d (
thro
wn)
by o
ne
obje
ct
and c
ontin
ues f
low
of
executio
n
•R
eceiv
ed (
ca
ught)
by a
noth
er
obje
ct
at
so
me f
utu
re p
oin
t in
tim
e.
•C
an b
e s
ent as:
–A
ction o
f a s
tate
tra
nsitio
n
–M
essage in a
n o
bje
ct
inte
raction
–D
epe
nde
ncie
s <
<send>
> s
how
sig
na
ls s
ent
by a
cla
ss
moveTo
position
velocity
MovementA
gent
<<signal>>
Collision
force : float
<<send>>
send dependency
Signal parameters
signal
Signals
collision( force : float )
powerLoss
powerD
own
TroubleManager
•M
odelin
g S
ign
al R
ece
iver:
as a
n a
ctive c
lass; C
onsid
er
4th
co
mpart
ment fo
r sig
nals
.
Events –
4 K
inds: Signals
; C
alls
; P
assin
g o
f T
ime; C
hange in S
tate
38
Call Events
�R
epre
sents
the
dis
patc
h o
f an o
pera
tion
�Synchronous
Automatic
Manual
startAutopilot( norm
al )
event parameter
Tim
e & C
hange Event
•T
ime e
vent
-re
pre
sents
the p
assage o
f tim
e:
after( periodOfTime )
•C
hange e
vent -
repre
sents
a c
han
ge in s
tate
or
the s
atisfa
ction o
f som
e c
onditio
n:
when( booleanExpr )
time event
Idle
Active
when( 11:49pm ) / selfTest()
after( 2 sec ) / dropConnection()
change event
Events –
4 K
inds: S
ignals
; Calls; Passing of Time; Change in State
39
Modeling Family of Signals and Exceptions
�S
ignal events
are
typic
ally
hie
rarc
hic
al.
�Look for
com
mo
n g
enera
lizations.
�Look for
poly
mo
rphic
opport
unitie
s.
<<signal>>
RobotSignal
<<signal>>
HardwareFault
<<signal>>
Collision
sensor : int
<<signal>>
MotorS
tall
<<signal>>
MovementFault
<<signal>>
BatteryFault
<<signal>>
VisionFault
<<signal>>
RangingFault
�C
onsid
er
the
exceptional conditio
ns o
f each c
lass.
�A
rrange e
xceptions in g
enera
lization h
iera
rch
y.
�S
pecify the
exce
ptions that each o
pera
tion m
ay r
ais
e.
–U
se s
end d
ependencie
s
–S
how
in o
pera
tion s
pecific
ation
setH
andler()
firstH
andler()
lastH
andler()
<<exception>>
Exception
<<exception>>
Duplicate
<<exception>>
Underflow
<<exception>>
Overflow
add()
remove()
Set
item
<<send>>
<<send>>
<<send>>
40
Activity D
iagra
ms
Behavio
ral D
iagra
ms
–U
se c
ase
–S
tate
chart
–Activity
Inte
raction D
iagra
ms
–S
equence;
Com
munic
ation
–In
tera
ction O
verv
iew
–T
imin
g
41
Activity Diagram Basics
•Activity Diagram
–a s
pecia
l kin
d o
f S
tate
cha
rt d
iagra
m, bu
t show
ing t
he f
low
fro
mactivity to
activity (
not
from
sta
te t
o s
tate
).
•Activity state
–non-atomic
execution, ultim
ate
ly r
esult in s
om
e a
ction; a c
om
posite m
ade u
p o
f oth
er
activity/a
ction s
tate
s;
can b
e r
ep
resente
d b
y o
ther
activity d
iagra
ms
•Action state
–atomic
execution,
results in a
change in s
tate
of
the s
yste
m o
r th
e r
etu
rn o
f a
valu
e
(i.e
., c
alli
ng a
noth
er
ope
ration, se
ndin
g a
sig
nal, c
reating o
r destr
oyin
g a
n o
bje
ct, o
r som
e
com
puta
tion);
no
n-d
ecom
posable
actionstate
: Cer
tifica
teO
fOcc
upan
cy
[com
ple
ted]
objectflow
Se
lect
site
Com
mis
sio
n
arc
hite
ct
De
ve
lop
pla
n
Bid
pla
n
Do
site
wo
rkD
o t
rade
w
ork
()
Fin
ish
con
str
uction
initial state
sequential branch/decision
[not ac
cepte
d]
[els
e]
finalstate
concurrent fork
activity state with submachine
concurrentjoin
do c
onstr
uct(
)
Entr
y/ setL
ock()
triggerless transition
guard expression
No notational distinction between
action and activity states!
But, activity states can have certain
types of parts
op
tiona
l
0..*
AND
on
e in
com
ing,
se
ve
ral ou
tgo
ing
merge
(unbranch
) m
ultip
le in
com
ing, on
e o
utg
oin
g
(fo
r a
lte
rna
tive
th
read
s)OR
42
Sw
imla
nes &
Obje
ct F
low
Request service
Pay
Collect order
Take order
Deliver order
Fill order
Customer
Sales
Stockroom
Order
[placed]
Order
[filled]
Order
[entered]
Order
[delivered]
object flow ?
•Object flow
–o
bje
cts
conn
ecte
d u
sin
g a
dep
ende
ncy t
o t
he
activity or transition
that
cre
ate
s,
destr
oys,
or
mo
difie
s t
hem
•A
swimlane
is a
kin
d o
f packa
ge.
•E
very
activity b
elo
ngs t
o e
xactly o
ne s
wim
lan
e,
but
transitio
ns m
ay c
ross lanes.
swim
lane
What if using pins?
flow final
the p
rocess s
tops a
t th
is p
oin
t fo
r th
is
part
of th
e a
ctivity d
iagra
m
sub-activity indicator
43
Object Flows and Pins
A s
hort
hand n
ota
tion:
use inp
ut
pin
s a
nd o
utp
ut
pin
s (
para
mete
rs).
Invoic
e inv;
inv =
ne
w I
nvo
ice;
Fill
Ord
er(
inv);
44
A Sim
ple Example
–O
rder
Pro
cessin
g
<<
pre
conditio
n>
> O
rder
com
ple
te
<<
postc
onditio
n>
> O
rder
clo
sed
activity
para
mete
r
node =
obje
ct
node
What if using swimlanes?
merge
46
POEmployee.sortMail
Activity Diagram even as M
ethod
POEmployee.deliverM
ail
POEmployee
sortMail()
deliverM
ail(k: Key) ad POEmployee.deliverM
ail
Check Out Truck
Put Mail in Boxes
ke
y
ad POEmployee.sort-deliverM
ail
47
Interruptible A
ctivity Region
•A
n interruptible activity region
surr
ounds a
gro
up o
f actions that can b
e
inte
rrupte
d.
•th
e P
rocess O
rder
action w
ill e
xecute
until com
ple
tion, th
en p
ass
contr
ol to
the C
lose O
rder
action, unle
ss a
Cancel R
equest in
terr
upt is
received w
hic
h w
ill p
ass c
ontr
ol to
the C
ancel O
rder
actio
n.
48
An Activity Diagram
–Distributing schedules
<<
sig
nal>
> redundant constr
ain
t
obje
ct
pin
parameter
htt
p:/
/ww
w.a
gile
mode
ling.c
om
/art
ifacts
/activityD
iagra
m.h
tm
hour-glass symbol represents time
send
receive
send
receive
49
Pins, Parameters, Effects
(ww
w.jo
t.fm
/issu
es/issu
e_
20
04_
01/c
olu
mn
3.p
df )
�effect
that th
eir a
ctions h
ave o
n o
bje
cts
that
move t
hro
ug
h t
he p
in:
one o
f th
e f
our
valu
es create, read, update, or delete
.
�T
ake O
rder
cre
ate
s a
n insta
nce o
f O
rder
and F
ill O
rder
rea
ds it.
�T
he create
eff
ect
is o
nly
possib
le o
n outputs
; and
the delete
eff
ect
is o
nly
possib
le o
n inputs
.
50
Multip
le T
okens
�O
bje
ct
nodes c
an h
old
more
than o
ne v
alu
e a
t a t
ime,
and s
om
e o
f th
ese v
alu
es c
an
be t
he s
am
e.
�Upper bound:
the m
axim
um
num
ber
of
toke
ns a
n o
bje
ct
no
de c
an h
old
, in
clu
din
gan
y
duplic
ate
valu
es.
�A
t ru
ntim
e,
wh
en t
he n
um
ber
of
valu
es in a
n o
bje
ct
no
de r
eaches
its u
pp
er
bound,
it
cannot
acce
pt
an
y m
ore
.
�If p
ain
ting is d
ela
yed t
oo m
uch f
or
som
e r
eason,
the input pin
will
reach its
uppe
r bound, and
part
s f
rom
polis
hin
g w
ill n
ot be a
ble
to m
ove d
ow
nstr
ea
m;
If p
ain
ting is d
ela
yed f
urt
he
r, th
e o
utp
ut
pin
of p
olis
hin
g w
ill fill
up a
nd the
polis
hin
g b
ehavio
r w
ill
not be a
ble
to
tra
nsfe
r ou
t polis
hed p
art
s;
Unle
ss the p
olis
hin
g b
ehavio
r has a
n o
bje
ct node in
tern
al to
it th
at buff
ers
outp
ut
part
s,
it w
ill n
ot
be a
ble
to take p
art
s f
rom
its
input pin
, w
hic
h w
ill lik
ew
ise fill
up a
nd p
ropaga
te the
backup; O
nly
when t
he input pin
to P
AIN
T g
oes b
elo
w its
upper
bo
und w
ill p
art
s b
e a
ble
to flo
w a
gain
.
51
Multiple Tokens -Ord
ering
•O
bje
ct nodes h
old
ing m
ultip
le v
alu
es c
an s
pecify the order
in w
hic
h
valu
es m
ove d
ow
nstr
eam
.
•T
he d
efa
ult is F
IFO
(a p
ipe);
users
can c
hange this
to L
IFO
(a q
ueue),
or
specify their o
wn b
ehavio
r to
sele
ct w
hic
h v
alu
e is p
assed o
ut firs
t.
Non-D
eterm
inism
(htt
p://w
ww
.jot.
fm/issues/issue
_2
004
_0
1/c
olu
mn3
.pd
f)
52
Parameter Multiplicity & O
bject Flow W
eight
•Minimum multiplicity
on a
ninput
para
mete
r m
eans a
be
ha
vio
r or
opera
tio
n
cannot
be invo
ked b
y a
n a
ctio
n u
ntil th
e n
um
ber
of
valu
es a
vaila
ble
at
each o
f its
input
pin
s r
eaches t
he m
inim
um
for
the c
orr
espond
ing p
ara
mete
r, w
hic
h m
ight
be z
ero
�W
eig
ht
on o
bje
ct
flo
w e
dg
es s
pecifie
s t
he m
inim
um
num
ber
of
valu
es t
hat
can t
ravers
e a
n o
bje
ct
flo
w e
dge a
t one t
ime.
53
Inte
raction O
verv
iew
Dia
gra
ms
Behavio
ral D
iagra
ms
–U
se c
ase
–S
tate
chart
–A
ctivity
Inte
raction D
iagra
ms
–S
equence;
Com
munic
ation
–Interaction
Overview
–T
imin
g
54
Interaction O
verview Diagram
(htt
p:/
/ww
w.a
gile
mode
ling.c
om
/art
ifa
cts
/in
tera
ction
Ove
rvie
wD
iagra
m.h
tm)
�variants
on U
ML
activity d
iagra
ms
whic
h o
verv
iew
contr
ol flow
.
�T
he n
odes w
ithin
the d
iagra
m a
re frames, not activitie
s
�T
wo
types o
f fr
am
e s
how
n:
�in
tera
ction f
ram
es d
epic
ting a
ny t
ype
of
UM
L inte
raction d
iagra
m (
sequence d
iagra
m: sd
,
com
munic
ation d
iagra
m: cd,
tim
ing d
iagra
m: td
, in
tera
ction o
verv
iew
dia
gra
m: iod
)
�in
tera
ction o
ccurr
ence f
ram
es (ref;
typic
ally
anon
ym
ous)
whic
h indic
ate
an a
ctivity o
r
opera
tion to
invoke.
sd E
nro
ll in
Sem
inar
lif
elin
es :
Stu
dent :S
em
inar
:Cours
e :E
nro
llment
:Stu
dent
:Sem
inar
:Cours
e
ref
Select Seminar()
ge
tPre
req (
)is
Elig
ible
(std
)
sd D
ete
rmin
e E
ligib
ility
{0..7m
sec}
[not elig
ible
]
:Sem
inar
:Enro
llment
Num
be
r e
nro
lled
cd D
ete
rmin
e S
eat A
vaila
bili
ty
ref
AddToWaitingList()
ref
Enroll in Seminar()
[seat availa
ble
]
[no s
eat]
55
sd W
ithdra
wal
:User
:AT
M:B
ank
ref
Authenticate
PIN O
KPIN NOK
with
dra
w
msg (
“am
oun
t”)
am
oun
t (a
)ch
kA
cct
(a)
msg (
“ca
rd”)
msg (
“ille
gal en
try”)
no
t enou
gh
ba
lm
sg(“
am
oun
t to
o b
ig”)
Interaction O
verview Diagram
:User
:AT
M:B
ank
sd
:User
:AT
M
sd
:User
:AT
M
sd
en
ou
gh
ba
lm
one
y
rece
ipt
:User
:AT
M:B
ank
sd
sd
Relationship with Sequence Diagram?
56
Tim
ing D
iagra
ms
Behavio
ral D
iagra
ms
–U
se c
ase
–S
tate
chart
–A
ctivity
Inte
raction D
iagra
ms
–S
equence;
Com
munic
ation
–In
tera
ction O
verv
iew
–Timing
57
Inte
raction D
iagra
m: T
imin
g D
iagra
m�
To
exp
lore
th
e b
eh
avio
rs o
f 0
..*
obje
cts
th
rou
gh
ou
t a
giv
en
pe
rio
d
of
tim
e.
�T
wo
ba
sic
fla
vo
rs:
concise
no
tatio
n a
nd
ro
bu
st
no
tatio
n
The lifecycle of a single seminar
�T
he c
ritical sta
tes
–Proposed, Scheduled
, Enrolling Students
, Being Taught,
Final Exams, Closed
�T
he t
wo lin
es s
urr
oundin
g the s
tate
s a
re c
alle
d a
genera
l valu
e lifelin
e.
�W
hen the
tw
o lin
es c
ross o
ne a
no
ther
it indic
ate
s a
transition point
betw
een
sta
tes.
�Timing constraints
alo
ng the b
otto
m o
f th
e d
iagra
m,
indic
ating the p
eriod o
f tim
e d
uring w
hic
h the s
em
ina
r is
in
each s
tate
.
critical
sta
tes
Timing
constraints
58
htt
p:/
/ww
w.v
isu
al-para
dig
m.c
om
/hig
hlig
ht/
hig
hlig
htu
ml2
supp
ort
.jsp
Interaction Diagram: Tim
ing Diagram (robust notation)
timing ruler w. tick marks
states
state timeline
transition point
Can you transform this into a concise notation?
61
Iterative M
essages
[Cra
ig L
arm
an] [h
ttp
://w
ww
.phptr
.co
m/a
rtic
les/a
rtic
le.a
sp?p
=3
6044
1&
se
qN
um
=6&
rl=
1]
62
Polymorphic M
essage
[Cra
ig L
arm
an] [h
ttp
://w
ww
.phptr
.co
m/a
rtic
les/a
rtic
le.a
sp?p
=3
6044
1&
se
qN
um
=6&
rl=
1]
65
Race conditions
�E
.g. an o
bje
ct re
ceiv
es t
wo m
essages
�O
rder
of arr
ival changes b
ehavio
ur
�O
nly
one o
rder
leads to c
orr
ect behavio
ur
�C
ellu
larR
adio
expects
Answ
er(
) not C
onnect(
pno)
�T
wo s
tate
s w
hen S
end c
an b
e p
ressed
�T
o m
ake o
utg
oin
g c
all
(after
dia
lling d
igits)
�T
o a
nsw
er
incom
ing c
all
�S
tate
dia
gra
m c
an b
e u
sefu
l here
�T
o h
elp
realiz
e there
is a
race c
onditio
n
�T
o s
pecify w
hat should
happen
�A
ngle
d a
rrow
s-
Show
message d
ela
y
•D
iale
r: g
ath
er
dig
its, em
it tones
•C
ellu
lar
Radio
: com
munic
ate
with c
ellu
lar
netw
ork
•B
utton, S
peaker,
Mic
rophone, D
ispla
y h
ard
ware
68
Verify
Card
acceptC
ard
Rele
aseC
ard
Verify
Tra
nsaction
outO
fServ
ice
rele
aseC
ard
OutO
fServ
ice
AT
M
{final}
{final}
{final}{final}
ReadA
mount
sele
ctA
mou
nt
am
ount
State M
achine Redefinition
ente
rAm
ou
nt
ok
reje
ct
{extended
}
oth
erA
moun
t
{extended
}
Fle
xib
leA
TM
69
Inte
raction
Dia
gra
m:
Tim
ing
Dia
gra
m (
rob
ust
no
tatio
n)
A frame to bound the two lifelines
states/conditions
events/stimuli
transition point
message
state timeline
state timeline timing ruler w. tick marks
timing constraint
timing observation
70
Tim
ing
Dia
gra
m –
anoth
er
exam
ple
(ww
w.c
s.t
ut.
fi/t
ap
ah
tum
at/o
lio20
04
/ric
ha
rdson
.pdf)