29
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

Designing with Interaction and Design Class Diagrams

Embed Size (px)

Citation preview

Page 1: Designing with Interaction and Design Class Diagrams

Designing with Interaction and Design Class Diagrams

Chapters 15 & 16Applying UML and Patterns

Craig Larman

With some ideas fromstudents in George Blank’s

course at NJIT

Page 2: Designing with Interaction and Design Class Diagrams

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

Page 3: Designing with Interaction and Design Class Diagrams

Interaction Diagram notation

class instance named instance

:Sale s1:SaleSale

Which would you expect to find most often in Interaction diagrams?

What do you think of “:Sale” instead of “aSale”?

Page 4: Designing with Interaction and Design Class Diagrams

Sequence diagram notation: Register : Sale

doA

doB

doX

doC

doD

typical sychronous message shown with a filled-arrow line

a found message whose sender will not be specified

execution specification bar indicates focus of control

Figure 15.7

Page 5: Designing with Interaction and Design Class Diagrams

What does vertical placement communicate?

: Register : Sale

makePayment(cashTendered)

: Paymentcreate(cashTendered)

authorize

note that newly created objects are placed at their creation "height"

Figure 15.10

Page 6: Designing with Interaction and Design Class Diagrams

Communication Diagram: makePayment

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Payment

makePayment(cashTendered)

direction of message

Figure 15.4

What do the numbers communicate?What does a create message communicate?

Page 7: Designing with Interaction and Design Class Diagrams

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 doesn’t use communication diagrams

– Show flow clearly, but awkward modeling alternatives UML notation for control logic has changed in UML 2

but Fowler isn’t impressed

Page 8: Designing with Interaction and Design Class Diagrams

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

Page 9: Designing with Interaction and Design Class Diagrams

Logic in sequence diagrams:which notation do you prefer?

calculate

: Bar

yy

xx

[ color = red ]opt

: Foo

[ color = red ] calculate

: Bar

yy

xx

: Foo

Figure 15.13

Figure 15.14

Page 10: Designing with Interaction and Design Class Diagrams

Logic in communication diagrams

1 [ color = red ] : calculate: Foo : Bar

message1

conditional message, with test

Figure 15.29

Page 11: Designing with Interaction and Design Class Diagrams

Loops in sequence diagrams:which notation do you prefer?

Figure 15.16

Figure 15.17

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

[ i < lineItems.size ]loop

: Sale 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 refers to the same “i” in the guard in the LOOP frame

an action box may contain arbitrary language statements (in this case, incrementing ‘i’)

it is placed over the lifeline to which it applies

i++

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

loop

: Sale

Page 12: Designing with Interaction and Design Class Diagrams

Iteration in communication diagrams1 * [i = 1..n]: st = getSubtotal: Salet = getTotal

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.

lineItems[i]:SalesLineItem

this iteration and recurrence clause indicates we are looping across each element of the lineItems collection.

1 *: st = getSubtotal: Salet = getTotal lineItems[i]:SalesLineItem

Less precise, but usually good enough to imply iteration across the collection members

Figure 15.31

Page 13: Designing with Interaction and Design Class Diagrams

Asynchronous calls

3: runFinalization:ClockStarter System : Class

startClock

:Clock

1: create

2: runasynchronous message

active objectFigure 15.35

What’s the difference between synchronous and asynchronous?

Active object runs in its own thread of execution

Page 14: Designing with Interaction and Design Class Diagrams

Polymorphism:How is it shown in interaction diagrams?

:Register authorizedoX :Payment {abstract}

polymorphic message

object in role of abstract superclass

:DebitPayment

authorize

:Foo

stop at this point – don’t show any further details for this message

separate diagrams for each polymorphic concrete case

doAdoB :CreditPayment

authorize

:BardoX

Figure 15.34

Page 15: Designing with Interaction and Design Class Diagrams

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

Page 16: Designing with Interaction and Design Class Diagrams

Domain model vs. Design Class Diagram – differences?

Register

...

endSale()enterItem(...)makePayment(...)

Sale

timeisComplete : Boolean/total

makeLineItem(...)

Register

...

Sale

timeisComplete : Boolean/total

Captures

1

11Domain Model

conceptual perspective

Design Model

DCD; software perspective

currentSale

Figure 16.2

Page 17: Designing with Interaction and Design Class Diagrams

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 diagram3) Include the attributes from the domain model

Page 18: Designing with Interaction and Design Class Diagrams

How to show attribute collections?

notice that an association end can optionally also have a property string such as {ordered, List}

Sale

time: DateTime

...

SalesLineItem

...

...

1..*lineItems

{ordered, List}

Sale

time: DateTimelineItems : SalesLineItem [1..*] orlineItems : SalesLineItem [1..*] {ordered}

...

SalesLineItem

...

...

Two ways to show a collection attribute

Figure 16.4

Page 19: Designing with Interaction and Design Class Diagrams

4) Add method names —from interaction diagrams —model class & interaction diagrams in parallel

: Register : Sale

makePayment(cashTendered)

makePayment(cashTendered)

Register

...

makePayment(…)...

Sale

...

makePayment(…)...

1

currentSale

messages in interaction diagrams indicate operations in the class diagrams classes

identified in the interaction diagrams are declared in the class diagrams

Page 20: Designing with Interaction and Design Class Diagrams

Parameters, return types optional?—readability vs. code generation

Page 21: Designing with Interaction and Design Class Diagrams

Method body pseudo-code also optional

Register

...

endSale()enterItem(id, qty)makeNewSale()makePayment(cashTendered)

«method»// pseudo-code or a specific language is OKpublic void enterItem( id, qty ){ ProductDescription desc = catalog.getProductDescription(id); sale.makeLineItem(desc, qty);}

Page 22: Designing with Interaction and Design Class Diagrams

5) Add associations and navigability—Navigability implies visibility of attributes

How does navigability clarify this design?

What attribute does ProductCatalog implicitly contain?

Page 23: Designing with Interaction and Design Class Diagrams

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

Page 24: Designing with Interaction and Design Class Diagrams

What does dependency add to this DCD?

SalesLineItem

...

...

ProductDescription

...

...

1..*lineItems

Sale

...

updatePriceFor( ProductDescription )...

the Sale has parameter visibility to a ProductDescription, and thus some kind of dependency

Page 25: Designing with Interaction and Design Class Diagrams

Composition (whole-part) relations

Finger0..7

Hand

composition

1

Square40

Board1

SalesLineItem1..*Sale1

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

-the composite has sole responsibility for management of its parts, especially creation and deletion

Figure 16.13

Page 26: Designing with Interaction and Design Class Diagrams

Association classes—model association with attributes & operations

salarystartDate

Employment

EmploysCompany Person**

a person may have employment with several companies

Figure 16.16

Page 27: Designing with Interaction and Design Class Diagrams

«interface»List

clear()...

Kparameterized or template interfaces and classes

K is a template parameter

anonymous class with template binding complete

Board

squares : List<K Square> orsquares : List<Square>...

ArrayList<T Square>

clear()...

the attribute type may be expressed in official UML, with the template binding syntax requiring an arrow orin another language, such as Java

ArrayList

elements : T[*]...

clear()...

T

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., ‘=’

Interfaces and Template Classes—Interface is a predefined «stereotype»—Templates take parameters in corner

Figure 16.18

Page 28: Designing with Interaction and Design Class Diagrams

DCD summary

Questions?

java.awt::Fontor

java.awt.Font

plain : Int = 0 { readOnly }bold : Int = 1 { readOnly }name : Stringstyle : Int = 0...

getFont(name : String) : FontgetName() : String...

«interface»Runnable

run()

- 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”

SubclassFoo

...

run()...

SuperclassFooor

SuperClassFoo { abstract }

- classOrStaticAttribute : Int+ publicAttribute : String- privateAttributeassumedPrivateAttributeisInitializedAttribute : Bool = trueaCollection : VeggieBurger [ * ]attributeMayLegallyBeNull : String [0..1] finalConstantAttribute : Int = 5 { readOnly }/derivedAttribute

+ classOrStaticMethod()+ publicMethod()assumedPublicMethod()- privateMethod()# protectedMethod()~ packageVisibleMethod()«constructor» SuperclassFoo( Long )methodWithParms(parm1 : String, parm2 : Float)methodReturnsSomething() : VeggieBurgermethodThrowsException() {exception IOException}abstractMethod()abstractMethod2() { abstract } // alternatefinalMethod() { leaf } // no override in subclasssynchronizedMethod() { guarded }

3 common compartments

1. classifier name

2. attributes

3. operations

interface implementation andsubclassing

Fruit

...

...

PurchaseOrder

...

...

1

association with multiplicities

dependency

officially in UML, the top format is used to distinguish the package name from the class name

unofficially, the second alternative is common

order

an interface shown with a keyword

Figure 16.1

Page 29: Designing with Interaction and Design Class Diagrams

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