Designing with Interaction

and Design Class Diagrams

Chapters 15 & 16
Applying UML and Patterns
Craig Larman
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

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
a found message
whose sender will not
be specified doC

doD

execution specification
bar indicates focus of
control typical sychronous message
shown with a filled-arrow line
Figure 15.7
 What does vertical placement
communicate?
note that newly created
: Register : Sale
objects are placed at their
creation "height"

makePayment(cashTendered)
create(cashTendered) : Payment

authorize

Figure 15.10
 Communication Diagram:
makePayment
direction of message

makePayment(cashTendered) :Register 1: makePayment(cashTendered) :Sale

1.1: create(cashTendered)

:Payment

What do the numbers communicate?

What does a create message communicate?

Figure 15.4
Communication (aka Collaboration)
diagrams
Objects are rectangular icons
e.g., Order Entry Window, Order, etc.
Messages are arrows between icons
e.g., prepare()
Numbers on messages indicate sequence
Also spatial layout helps show flow
Which do you prefer: sequence or communication?
Fowler doesnt use communication diagrams
Show flow clearly, but awkward modeling alternatives
UML notation for control logic has changed in UML 2
but Fowler isnt impressed
 Control logic in
Interaction Diagrams

Conditional Message
[ variable = value ] : message()
Message is sent only if clause evaluates to true
Iteration (Looping)
* [ 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?
: Foo : Bar
xx

opt [ color = red ]

calculate

Figure 15.13 yy

: Foo : Bar
xx

[ color = red ] calculate

Figure 15.14
yy
 Logic in communication diagrams

conditional message, with test

message1

1 [ color = red ] : calculate

: Foo : Bar

Figure 15.29
 Loops in sequence diagrams:
which notation do you prefer?
lineItems[i] :
: Sale This lifeline box represents one
SalesLineItem
instance from a collection of many
t = getTotal SalesLineItem objects.

lineItems[i] is the expression to

loop select one element from the
[ i < lineItems.size ]
st = getSubtotal collection of many
SalesLineItems; the i value
refers to the same i in the guard
i++
in the LOOP frame

an action box may contain arbitrary language

Figure 15.16 statements (in this case, incrementing i)

it is placed over the lifeline to which it applies

lineItems[i] :
: Sale
SalesLineItem

t = getTotal

loop
st = getSubtotal
Figure 15.17
 Iteration in communication diagrams
t = getTotal 1 * [i = 1..n]: st = getSubtotal lineItems[i]:
: Sale
SalesLineItem

this iteration and recurrence clause indicates
we are looping across each element of the
lineItems collection.
This lifeline box represents one instance from a
collection of many SalesLineItem objects.
lineItems[i] is the expression to select one
element from the collection of many
SalesLineItems; the i value comes from the
message clause.

t = getTotal 1 *: st = getSubtotal lineItems[i]:

: Sale
SalesLineItem

Less precise, but usually good enough to imply

iteration across the collection members

Figure 15.31
 Asynchronous calls

startClock

3: runFinalization
:ClockStarter System : Class

1: create
asynchronous message
2: run
Figure 15.35
active object
:Clock

Active object runs in its own thread of execution

Whats the difference between synchronous and asynchronous?

 Polymorphism:
How is it shown in interaction diagrams?
stop at this point dont show any
polymorphic message further details for this message

doX authorize object in role of abstract

:Register :Payment {abstract} superclass

authorize authorize
doA
doX
:DebitPayment doB :Foo :CreditPayment :Bar

separate diagrams for each polymorphic concrete case

Figure 15.34
 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?

Domain Model Sale

Register Captures 1
1
time
conceptual
... isComplete : Boolean
perspective
/total

Register Sale
Design Model ... time
1
isComplete : Boolean
DCD; software endSale() currentSale /total
perspective enterItem(...)
makePayment(...) makeLineItem(...)

Figure 16.2
 Developing a Domain Class Diagram:
the NextGen POS DCD

1) Identify software classes:

Register Sale
ProductCatalog ProductSpecification
Store SalesLineItem
Payment
2) Begin drawing a class diagram
3) Include the attributes from the domain model
 How to show attribute collections?

Sale SalesLineItem

time: DateTime ...

lineItems : SalesLineItem [1..*]
or ...
lineItems : SalesLineItem [1..*] {ordered}

...
Two ways to show a
collection attribute

Sale SalesLineItem
1..*
time: DateTime ...
lineItems
... {ordered, List} ...

Figure 16.4 notice that an association end can optionally also

have a property string such as {ordered, List}
4) Add method names
from interaction diagrams
model class & interaction diagrams in parallel

: Register : Sale

makePayment(cashTendered)

makePayment(cashTendered)

messages in interaction
diagrams indicate operations
in the class diagrams classes
identified in the
interaction
diagrams are
Register Sale declared in the
1 class diagrams
... ...
currentSale
makePayment() makePayment()
... ...
Parameters, return types optional?
readability vs. code generation
 Method body pseudo-code also optional

Register
method
// pseudo-code or a specific language is OK ...
public void enterItem( id, qty )
{ endSale()
ProductDescription desc = catalog.getProductDescription(id); enterItem(id, qty)
sale.makeLineItem(desc, qty); makeNewSale()
} makePayment(cashTendered)
 5) Add associations and navigability
Navigability implies visibility ofattribute
What attributes
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?

the Sale has parameter visibility to a

ProductDescription, and thus some kind of
dependency
ProductDescription

...
Sale
...
...

updatePriceFor( ProductDescription )
... SalesLineItem

1..* ...
lineItems
...
 Composition (whole-part) relations

1 0..7 composition means

Hand Finger
-a part instance (Square) can only be part of one
composite (Board) at a time

composition -the composite has sole responsibility for management of

its parts, especially creation and deletion

1 40 1 1..*
Board Square Sale SalesLineItem

Figure 16.13
 Association classes
model association with attributes & operations

Company * Employs
* Person

a person may have Employment

employment with several
companies salary
startDate

Figure 16.16
 Interfaces and Template Classes
Interface is a predefined stereotype
Templates take parameters in corner
the attribute type may be expressed in
parameterized or template K official UML, with the template binding
interfaces and classes interface syntax requiring an arrow
List or
K is a template parameter in another language, such as Java
clear()
...

Board

squares : List<K Square>

anonymous class with or
template binding complete T squares : List<Square>
ArrayList ...
elements : T[*]
ArrayList<T Square> ...
clear() clear()
... for example, the elements attribute is an
...
array of type T, parameterized and bound
before actual use.
there is a chance the UML 2 arrow symbol will
eventually be replaced with something else e.g., =

Figure 16.18
 officially in UML, the top format is
SuperclassFoo used to distinguish the package
or name from the class name
SuperClassFoo { abstract }
unofficially, the second alternative
- classOrStaticAttribute : Int is common
+ publicAttribute : String
3 common
- privateAttribute
compartments
assumedPrivateAttribute
isInitializedAttribute : Bool = true java.awt::Font
1. classifier name
aCollection : VeggieBurger [ * ] or
attributeMayLegallyBeNull : String [0..1] java.awt.Font
2. attributes
finalConstantAttribute : Int = 5 { readOnly }
/derivedAttribute plain : Int = 0 { readOnly }
3. operations
bold : Int = 1 { readOnly }
+ classOrStaticMethod() name : String

an interface
+ publicMethod()
assumedPublicMethod()
style : Int = 0
...
DCD
- privateMethod()
shown with a
keyword
# protectedMethod()
~ packageVisibleMethod()
getFont(name : String) : Font
getName() : String
summary
constructor SuperclassFoo( Long ) ...
methodWithParms(parm1 : String, parm2 : Float)
methodReturnsSomething() : VeggieBurger
interface
Runnable
methodThrowsException() {exception IOException}
abstractMethod() Questions?
abstractMethod2() { abstract } // alternate Fruit
run() finalMethod() { leaf } // no override in subclass dependency
synchronizedMethod() { guarded } ...

...

interface
implementation
and
subclassing SubclassFoo
PurchaseOrder
... 1
...
run() order
...
...
association with Figure 16.1
multiplicities
- ellipsis means there may be elements, but not shown
- a blank compartment officially means unknown but as a
convention will be used to mean no members
 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