Designing with Interaction and Design Class Diagrams Chapters 15 & 16 Applying UML and Patterns Craig Larman With some ideas from students in George Blank’s course at.

Download Report

Transcript Designing with Interaction and Design Class Diagrams Chapters 15 & 16 Applying UML and Patterns Craig Larman With some ideas from students in George Blank’s course at.

Designing with Interaction
and Design Class Diagrams
Chapters 15 & 16
Applying UML and Patterns
Craig Larman
With some ideas from
students in George Blank’s
course at NJIT
Two kinds of UML Interaction Diagrams



Sequence Diagrams: show object interactions
arranged in time sequence, vertically
Communication Diagrams: show object
interactions arranged as a flow of objects and
their links to each other, numerically
Semantically equivalent, structurally different
–
–
Sequence diagram emphasize time ordering
Communication diagrams make object linkages
explicit
Interaction Diagram notation
Sale
:Sale
class
s1:Sale
instance
named instance
Which would you expect to find most often in Interaction diagrams?
What do you think of “:Sale” instead of “aSale”?
Sequence diagram notation
: Register
: Sale
doX
doA
doB
afoundmessage
whosesender will not
bespecified
doC
doD
executionspecification
bar indicatesfocusof
control
Figure 15.7
typical sychronousmessage
shownwithafilled-arrowline
What does vertical placement
communicate?
:R
e
g
is
te
r
:S
a
le
n
o
teth
a
tn
e
w
lyc
re
a
te
d
o
b
je
c
tsa
rep
la
c
e
da
tth
e
ir
c
re
a
tio
n"h
e
ig
h
t"
m
a
k
e
P
a
y
m
e
n
t(c
a
s
h
T
e
n
d
e
re
d
)
c
re
a
te
(c
a
s
h
T
e
n
d
e
re
d
)
a
u
th
o
riz
e
Figure 15.10
:P
a
y
m
e
n
t
Communication Diagram:
makePayment
d
ir
e
c
t
io
n
o
fm
e
s
s
a
g
e
m
a
k
e
P
a
y
m
e
n
t
(
c
a
s
h
T
e
n
d
e
r
e
d
)
:
R
e
g
is
t
e
r
1
:m
a
k
e
P
a
y
m
e
n
t
(
c
a
s
h
T
e
n
d
e
r
e
d
)
:
S
a
le
1
.
1
:c
r
e
a
t
e
(
c
a
s
h
T
e
n
d
e
r
e
d
)
:
P
a
y
m
e
n
t
What do the numbers communicate?
What does a create message communicate?
Figure 15.4
Communication
(aka Collaboration) diagrams

Objects are rectangular icons
–

Messages are arrows between icons
–


Also spatial layout helps show flow
Which do you prefer: sequence or communication?
Fowler doesn’t use communication diagrams
–

e.g., prepare()
Numbers on messages indicate sequence
–

e.g., Order Entry Window, Order, etc.
Show flow clearly, but awkward modeling alternatives
UML notation for control logic has changed in UML 2
but Fowler isn’t impressed
Control logic in
Interaction Diagrams

Conditional Message
–
–

Iteration (Looping)
–
–

[ variable = value ] : message()
Message is sent only if clause evaluates to true
* [ i := 1..N ]: message()
“*” is required; [ ... ] clause is optional
Communication diagrams add Seq. Numbers
before conditional messages or loops
Logic in sequence diagrams:
which notation do you prefer?
:F
o
o
:B
a
r
x
x
o
p
t
[c
o
lo
r=
re
d
]
c
a
lc
u
la
te
y
y
Figure 15.13
:F
o
o
:B
a
r
x
x
[c
o
lo
r=
re
d]c
a
lc
u
la
te
Figure 15.14
y
y
Logic in communication diagrams
c
o
n
d
itio
n
a
lm
e
s
s
a
g
e
,w
ith
te
s
t
m
e
s
s
a
g
e
1
:F
o
o
1
[c
o
lo
r=
r
e
d
]: c
a
lc
u
la
te
Figure 15.29
:B
a
r
Loops in sequence diagrams:
which notation do you prefer?
l
i
n
e
I
t
e
m
s
[
i
]:
S
a
le
s
L
in
e
I
t
e
m
:S
a
le
t=
g
e
t
T
o
t
a
l
l
o
o
p
[i<
l
i
n
e
I
t
e
m
s
.
s
i
z
e
]
s
t=
g
e
t
S
u
b
t
o
t
a
l
i
+
+
T
h
is
lif
e
lin
e
b
o
x
r
e
p
r
e
s
e
n
t
s
o
n
e
in
s
t
a
n
c
e
f
r
o
m
a
c
o
lle
c
t
io
n
o
fm
a
n
y
S
a
le
s
L
in
e
I
t
e
m
o
b
je
c
t
s
.
lin
e
I
t
e
m
s
[
i]is
t
h
e
e
x
p
r
e
s
s
io
n
t
o
s
e
le
c
to
n
e
e
le
m
e
n
tf
r
o
m
t
h
e
c
o
lle
c
t
io
n
o
fm
a
n
y
S
a
le
s
L
in
e
I
t
e
m
s
;t
h
e
‘i”v
a
lu
e
r
e
f
e
r
s
t
o
t
h
e
s
a
m
e
“
i”in
t
h
e
g
u
a
r
d
in
t
h
e
L
O
O
P
f
r
a
m
e
a
n
a
c
t
i
o
n
b
o
x
m
a
y
c
o
n
t
a
in
a
r
b
it
r
a
r
y
la
n
g
u
a
g
e
s
t
a
t
e
m
e
n
t
s
(
in
t
h
is
c
a
s
e
,in
c
r
e
m
e
n
t
in
g
‘i’)
Figure 15.16
itis
p
la
c
e
d
o
v
e
rt
h
e
lif
e
lin
e
t
o
w
h
ic
h
ita
p
p
lie
s
lin
e
It
e
m
s
[
i]:
S
a
le
s
L
in
e
Ite
m
:S
a
le
t=
g
e
tT
o
ta
l
lo
o
p
Figure 15.17
s
t=
g
e
tS
u
b
to
ta
l
Iteration in communication diagrams
t =getTotal
: Sale
1*[i =1..n]: st =getSubtotal
thisiterationandrecurrenceclauseindicates
w
eareloopingacrosseachelem
ent of the
lineItem
scollection.
lineItem
s[i]:
SalesLineItem
Thislifelineboxrepresentsoneinstancefroma
collectionof m
anySalesLineItemobjects.
lineItem
s[i]istheexpressiontoselect one
elem
ent fromthecollectionof m
any
SalesLineItem
s; the‘i” valuecom
esfromthe
m
essageclause.
t =getTotal
: Sale
1*: st =getSubtotal
lineItem
s[i]:
SalesLineItem
Lessprecise, but usuallygoodenoughtoim
ply
iterationacrossthecollectionm
em
bers
Figure 15.31
Asynchronous calls
s
ta
rtC
lo
c
k
3
:ru
n
F
in
a
liz
a
tio
n
:C
lo
c
k
S
ta
rte
r
S
y
s
te
m
:C
la
s
s
1
:c
re
a
te
a
s
y
n
c
h
ro
n
o
u
sm
e
s
s
a
g
e
2
:ru
n
:C
lo
c
k
a
c
tiv
e
o
b
je
c
t
Figure 15.35
Active object runs in its own thread of execution
What’s the difference between synchronous and asynchronous?
Polymorphism:
How is it shown in interaction diagrams?
p
o
ly
m
o
rp
h
icm
e
s
s
a
g
e
d
o
X
:R
e
g
is
te
r
s
to
pa
tth
isp
o
in
t–d
o
n
’ts
h
o
wa
n
y
fu
rth
e
rd
e
ta
ilsfo
rth
ism
e
s
s
a
g
e
a
u
th
o
riz
e
:P
a
y
m
e
n
t{a
b
s
tra
c
t}
a
u
th
o
riz
e
:D
e
b
itP
a
y
m
e
n
t
o
b
je
c
tinro
leo
fa
b
s
tra
c
t
s
u
p
e
rc
la
s
s
a
u
th
o
riz
e
d
o
A
d
o
B
d
o
X
:F
o
o
:C
re
d
itP
a
y
m
e
n
t
s
e
p
a
ra
ted
ia
g
ra
m
sfo
re
a
c
hp
o
ly
m
o
rp
h
icc
o
n
c
re
tec
a
s
e
Figure 15.34
:B
a
r
Chapter 16
Design Class Diagrams (DCDs)




During analysis, emphasize domain concepts
During design, shift to software artifacts
UML has no explicit notation for DCDs
Uniform UML notation supports smoother
development from analysis to design
Domain model vs.
Design Class Diagram – differences?
S
a
le
D
o
m
a
in
M
o
d
e
l
c
o
n
c
e
p
tu
a
l
p
e
rs
p
e
c
tiv
e
R
e
g
is
te
r
a
p
tu
re
s
1 C
...
R
e
g
is
te
r
1
tim
e
is
C
o
m
p
le
te
:B
o
o
le
a
n
/to
ta
l
S
a
le
D
e
s
ig
n
M
o
d
e
l
...
D
C
D
;s
o
ftw
a
re
p
e
rs
p
e
c
tiv
e
e
n
d
S
a
le
()
e
n
te
rIte
m
(...)
m
a
k
e
P
a
y
m
e
n
t(...)
Figure 16.2
e
1 tim
is
C
o
m
p
le
te
:B
o
o
le
a
n
c
u
rre
n
tS
a
le /to
ta
l
m
a
k
e
L
in
e
Ite
m
(...)
Developing a Domain Class Diagram:
the NextGen POS DCD
1) Identify software classes:
Register
ProductCatalog
Store
Payment
Sale
ProductSpecification
SalesLineItem
2) Begin drawing a class diagram
3) Include the attributes from the domain model
How to show attribute collections?
S
ale
S
alesLineItem
tim
e: D
ateTim
e
lineItem
s: S
alesLineItem[1..*]
or
lineItem
s: S
alesLineItem[1..*] {ordered}
...
...
...
Tw
ow
aystoshowa
collectionattribute
S
ale
S
alesLineItem
tim
e: D
ateTim
e
...
Figure 16.4
1..*
...
lineItem
s
{ordered, List} ...
noticethat anassociationendcanoptionallyalso
haveapropertystringsuchas{ordered, List}
4) Add method names
—from interaction diagrams
—model class & interaction diagrams in parallel
:R
e
g
iste
r
:S
a
le
m
a
ke
P
a
ym
e
n
t(ca
sh
T
e
n
d
e
re
d)
m
a
ke
P
a
ym
e
n
t(ca
sh
T
e
n
d
e
re
d)
m
e
ssa
g
e
sinin
te
ra
ctio
n
d
ia
g
ra
m
sin
d
ica
teo
p
e
ra
tio
n
s
inth
ecla
ssd
ia
g
ra
m
s
R
e
g
iste
r
...
m
a
ke
P
a
ym
e
n
t(…
)
...
S
a
le
1
cu
rre
n
tS
a
le
...
m
a
ke
P
a
ym
e
n
t(…
)
...
cla
sse
s
id
e
n
tifie
dinth
e
in
te
ra
ctio
n
d
ia
g
ra
m
sa
re
d
e
cla
re
dinth
e
cla
ssd
ia
g
ra
m
s
Parameters, return types optional?
—readability vs. code generation
Method body pseudo-code also optional
R
e
g
i
s
t
e
r
«
m
e
t
h
o
d
»
/
/
p
s
e
u
d
o
c
o
d
e
o
r
a
s
p
e
c
i
f
i
c
l
a
n
g
u
a
g
e
i
s
O
K
p
u
b
l
i
c
v
o
i
d
e
n
t
e
r
I
t
e
m
(
i
d
,
q
t
y
)
{
P
r
o
d
u
c
t
D
e
s
c
r
i
p
t
i
o
n
d
e
s
c
=
c
a
t
a
l
o
g
.
g
e
t
P
r
o
d
u
c
t
D
e
s
c
r
i
p
t
i
o
n
(
i
d
)
;
s
a
l
e
.
m
a
k
e
L
i
n
e
I
t
e
m
(
d
e
s
c
,
q
t
y
)
;
}
.
.
.
e
n
d
S
a
l
e
(
)
e
n
t
e
r
I
t
e
m
(
i
d
,
q
t
y
)
m
a
k
e
N
e
w
S
a
l
e
(
)
m
a
k
e
P
a
y
m
e
n
t
(
c
a
s
h
T
e
n
d
e
r
e
d
)
5) Add associations and navigability
—Navigability implies visibility of attributes
What attribute does
ProductCatalog
implicitly contain?
How does
navigability
clarify this
design?
6) Adding dependency relationships




Indicates that one element has knowledge of
another element
I.e., a change in specification of one thing may
affect another thing that uses it, but not
necessarily the reverse
A dashed directed line
Typically non-attribute visibility between classes
What does dependency add to this DCD?
th
eS
a
leh
a
sp
a
ra
m
e
te
rvisib
ilitytoa
P
ro
d
u
ctD
e
scrip
tio
n
,a
n
dth
u
sso
m
ekin
do
f
d
e
p
e
n
d
e
n
cy
P
ro
d
u
ctD
e
scrip
tio
n
...
S
a
le
...
...
u
p
d
a
te
P
rice
F
o
r(P
ro
d
u
ctD
e
scrip
tio
n)
...
S
a
le
sL
in
e
Ite
m
1
..*
lin
e
Ite
m
s
...
...
Composition (whole-part) relations
1
H
a
n
d
0
.
.
7
F
i
n
g
e
r
c
o
m
p
o
s
i
t
i
o
n
1
B
o
a
r
d
4
0
c
o
m
p
o
s
i
t
i
o
n
m
e
a
n
s
a
p
a
r
t
i
n
s
t
a
n
c
e
(
S
q
u
a
r
e
)
c
a
n
o
n
l
y
b
e
p
a
r
t
o
f
o
n
e
c
o
m
p
o
s
i
t
e
(
B
o
a
r
d
)
a
t
a
t
i
m
e
t
h
e
c
o
m
p
o
s
i
t
e
h
a
s
s
o
l
e
r
e
s
p
o
n
s
i
b
i
l
i
t
y
f
o
r
m
a
n
a
g
e
m
e
n
t
o
f
i
t
s
p
a
r
t
s
,
e
s
p
e
c
i
a
l
l
y
c
r
e
a
t
i
o
n
a
n
d
d
e
l
e
t
i
o
n
1
S
a
l
e
S
q
u
a
r
e
Figure 16.13
1
.
.
*
S
a
l
e
s
L
i
n
e
I
t
e
m
Association classes
—model association with attributes & operations
C
o
m
p
a
n
y
*
a
p
e
r
s
o
n
m
a
y
h
a
v
e
e
m
p
l
o
y
m
e
n
tw
i
t
h
s
e
v
e
r
a
l
c
o
m
p
a
n
i
e
s
E
m
p
l
o
y
s
*
P
e
r
s
o
n
E
m
p
l
o
y
m
e
n
t
s
a
l
a
r
y
s
t
a
r
t
D
a
t
e
Figure 16.16
Interfaces and Template Classes
—Interface is a predefined «stereotype»
—Templates take parameters in corner
p
a
ra
m
e
te
riz
e
do
rte
m
p
la
te
in
te
rfa
c
e
sa
n
dc
la
s
s
e
s
Kisate
m
p
la
tep
a
ra
m
e
te
r
«
in
te
rfa
c
e
»
L
is
t
K
c
le
a
r()
...
th
ea
ttrib
u
tety
p
em
a
yb
ee
x
p
re
s
s
e
din
o
ffic
ia
lU
M
L
,w
ithth
ete
m
p
la
teb
in
d
in
g
s
y
n
ta
xre
q
u
irin
ga
na
rro
w
o
r
ina
n
o
th
e
rla
n
g
u
a
g
e
,s
u
c
ha
sJ
a
v
a
B
o
a
rd
a
n
o
n
y
m
o
u
sc
la
s
sw
ith
te
m
p
la
teb
in
d
in
gc
o
m
p
le
te
A
rra
y
L
is
t
A
rra
y
L
is
t<
TS
q
u
a
re
>
c
le
a
r()
...
T
s
q
u
a
re
s:L
is
t<
KS
q
u
a
re
>
o
r
s
q
u
a
re
s:L
is
t<
S
q
u
a
re
>
...
e
le
m
e
n
ts:T
[*]
...
c
le
a
r()
...
fo
re
x
a
m
p
le
,th
ee
le
m
e
n
tsa
ttrib
u
teisa
n
a
rra
yo
fty
p
eT
,p
a
ra
m
e
te
riz
e
da
n
db
o
u
n
d
b
e
fo
rea
c
tu
a
lu
s
e
.
th
e
reisac
h
a
n
c
eth
eU
M
L2“a
rro
w
”s
y
m
b
o
lw
ill
e
v
e
n
tu
a
llyb
ere
p
la
c
e
dw
iths
o
m
e
th
in
ge
ls
ee
.g
.,‘=
’
Figure 16.18
S u p e r c la s s F o o
or
S u p e r C la s s F o o { a b s tr a c t }
3 com m on
c o m p a r tm e n ts
1 . c la s s ifie r n a m e
2 . a ttr ib u te s
3 . o p e r a tio n s
a n in te r fa c e
s h o w n w ith a
k e y w o rd
« in te r fa c e »
R u n n a b le
ru n ()
- c la s s O r S ta tic A ttr ib u te : In t
+ p u b lic A ttr ib u te : S tr in g
- p r iv a te A ttr ib u te
a s s u m e d P r iv a te A ttr ib u te
is In itia liz e d A ttr ib u te : B o o l = tr u e
a C o lle c tio n : V e g g ie B u r g e r [ * ]
a ttr ib u te M a y L e g a lly B e N u ll : S tr in g [0 ..1 ]
fin a lC o n s ta n tA ttr ib u te : In t = 5 { r e a d O n ly }
/d e r iv e d A ttr ib u te
+ c la s s O r S ta tic M e th o d ( )
+ p u b lic M e th o d ( )
a s s u m e d P u b lic M e th o d ( )
- p r iv a te M e th o d ( )
# p r o te c te d M e th o d ( )
~ p a c k a g e V is ib le M e th o d ( )
« c o n s tr u c to r » S u p e r c la s s F o o ( L o n g )
m e th o d W ith P a r m s ( p a r m 1 : S tr in g , p a r m 2 : F lo a t)
m e th o d R e tu r n s S o m e th in g ( ) : V e g g ie B u r g e r
m e th o d T h r o w s E x c e p tio n ( ) {e x c e p tio n IO E x c e p tio n }
a b s tr a c tM e th o d ( )
a b s tr a c tM e th o d 2 ( ) { a b s tr a c t } // a lte r n a te
fin a lM e th o d ( ) { le a f } // n o o v e r r id e in s u b c la s s
s y n c h r o n iz e d M e th o d ( ) { g u a r d e d }
o ffic ia lly in U M L , th e to p fo r m a t is
u s e d to d is tin g u is h th e p a c k a g e
n a m e fr o m th e c la s s n a m e
u n o ffic ia lly , th e s e c o n d a lte r n a tiv e
is c o m m o n
ja v a .a w t::F o n t
or
ja v a .a w t.F o n t
p la in : In t = 0 { r e a d O n ly }
b o ld : In t = 1 { r e a d O n ly }
n a m e : S tr in g
s ty le : In t = 0
...
g e tF o n t(n a m e : S tr in g ) : F o n t
g e tN a m e ( ) : S tr in g
...
DCD
summary
Questions?
F r u it
dependency
...
...
in te r fa c e
im p le m e n ta tio n
and
s u b c la s s in g
S u b c la s s F o o
P u rc h a s e O rd e r
1
...
ru n ()
...
- e llip s is “ … ” m e a n s th e r e m a y b e e le m e n ts, b u t n o t s h o w n
- a b la n k c o m p a r tm e n t o ffic ia lly m e a n s “ u n k n o w n ” b u t a s a
c o n v e n tio n w ill b e u s e d to m e a n “ n o m e m b e r s ”
...
o rd e r
...
a s s o c ia tio n w ith
m u ltip lic itie s
Figure 16.1
Designing with interaction
and class diagrams



Beginners often emphasize Class diagrams
Interaction diagrams deserve more attention
Some tools can help:
–
–
Convert between sequence and communication
diagrams automatically
Reflect changes in class and interaction diagrams
in parallel