Designing with Interaction and Design Class Diagrams

Two kinds of UML Interaction Diagrams Designing with Interaction and Design Class Diagrams

  z Sequence Diagrams: show object interactions arranged in time sequence, vertically z z Communication Diagrams: show object Communication Diagrams: show object

  Chapters 15 & 16 Ch t 15 & 16 interactions arranged as a flow of objects and Applying UML and Patterns their links to each other, numerically Craig Larman z

  Semantically equivalent, structurally different Sequence diagram emphasize time ordering – Communication diagrams make object linkages

• – explicit Oleh:

  I Gede Made Karma

Sequence diagram notation Interaction Diagram notation

  : Register : Sale doX doA doB doB a found message whose sender will not be specified doC doD execution specification

  Which would you expect to find most often in Interaction diagrams? bar indicates focus of control typical sychronous message

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

  shown with a filled-arrow line

Figure 15.7 What does vertical placement Communication Diagram: communicate? makePayment

  note that newly created direction of message : Register : Sale objects are placed at their creation "height"

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

  makePayment(cashTendered) create(cashTendered) : Payment

  1.1: create(cashTendered)

  authorize

  :Payment

  What do the numbers communicate? What does a create message communicate? Figure 15.10 Figure 15.4

Communication Control logic in (aka Collaboration) diagrams Interaction Diagrams

  z Objects are rectangular icons z

  Conditional Message e.g., Order Entry Window, Order, etc.

• – [ variable = value ] : message()
• – z Messages are arrows between icons Messages are arrows between icons
• – e.g., prepare()

  M Message is sent only if clause evaluates to true i l if l l t

• – z

  Iteration (Looping) z

  Numbers on messages indicate sequence

• – – z Which do you prefer: sequence or communication? “*” is required; [ ... ] clause is optional
• – z Fowler doesn’t use communication diagrams

  z Communication diagrams add Seq. Numbers

  Show flow clearly, but awkward modeling alternatives

• – before conditional messages or loops

  z UML notation for control logic has changed in UML 2 but Fowler isn’t impressed

Logic in sequence diagrams: which notation do you prefer? Logic in communication diagrams

  : Foo : Bar xx

  [ color = red ] opt

  calculate

  conditional message, with test

  yy

Figure 15.13

  message1

  : Foo : Bar

  1 [ color = red ] : calculate

  : Foo : Bar

  xx [ color = red ] calculate

  Figure 15.14

Figure 15.29

  yy

Loops in sequence diagrams: Iteration in communication diagrams which notation do you prefer?

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

  SalesLineItem

  lineItems[i] : : Sale This lifeline box represents one

  SalesLineItem instance from a collection of many t = getTotal SalesLineItem objects.

  This lifeline box represents one instance from a this iteration and recurrence clause indicates

  lineItems[i] is the expression to collection of many SalesLineItem objects.

select one element from the we are looping across each element of the

loop [ i < lineItems.size ] collection of many lineItems collection. st = getSubtotal SalesLineItems; the ‘i” value

  lineItems[i] is the expression to select one

  refers to the same “i” in the guard i++

  element from the collection of many element from the collection of many

  in the LOOP frame i th LOOP f

  SalesLineItems; the ‘i” value comes from the

  an action box may contain arbitrary language message clause.

Figure 15.16 statements (in this case, incrementing ‘i’)

  it is placed over the lifeline to which it applies

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

  lineItems[i] :

  : Sale : Sale

  SalesLineItem SalesLineItem t = getTotal

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

  loop

  st = getSubtotal

  Figure 15.17 Figure 15.31

Polymorphism: Asynchronous calls How is it shown in interaction diagrams?

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

  startClock 3: runFinalization

  object in role of abstract doX authorize

  :ClockStarter System : Class y :Register g :Payment {abstract} y { }

  superclass superclass

  1: create asynchronous message

  authorize authorize doA doX

Figure 15.35

  doB :DebitPayment :Foo :CreditPayment :Bar

  active object :Clock

Active object runs in its own thread of execution

  separate diagrams for each polymorphic concrete case

What’s the difference between synchronous and asynchronous? Figure 15.34 Domain model vs. Design Class Diagrams (DCDs) Design Class Diagram – differences?

  z During analysis, emphasize domain concepts Sale Domain Model

  Register Captures

  1

  1 z During design, shift to software artifacts time

conceptual conceptual

  ... isComplete : Boolean

perspective

z

  UML has no explicit notation for DCDs /total z

  Uniform UML notation supports smoother Register Sale development from analysis to design

  Design Model ... time 1 isComplete : Boolean

  DCD; software endSale() currentSale /total

perspective

enterItem(...) makePayment(...) makeLineItem(...)

Figure 16.2 Developing a Domain Class Diagram: How to show attribute collections? the NextGen POS DCD

  Sale SalesLineItem

  1) Identify software classes: time: DateTime ...

  lineItems : SalesLineItem [1..*] Register Sale or ... lineItems : SalesLineItem [1..*] {ordered} li It S l Li It [1 *] { d d}

  ProductCatalog P d C l P d ProductSpecification S ifi i ... Store SalesLineItem

  Two ways to show a

  Payment collection attribute 2) Begin drawing a class diagram

  Sale SalesLineItem * 1.. time: DateTime ...

  3) Include the attributes from the domain model

  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

Parameters, return types optional? —readability vs. code generation Method body pseudo-code also optional

  : 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

  Register «method» // pseudo-code or a specific language is OK ... endSale() enterItem(id, qty) makeNewSale() makePayment(cashTendered)

  // pseudo code or a specific language is OK public void enterItem( id, qty ) { ProductDescription desc = catalog.getProductDescription(id); sale.makeLineItem(desc, qty); }

  5) Add associations and navigability —Navigability implies visibility of attributes How does navigability l if thi What attribute does ProductCatalog implicitly contain? clarify this design? 6) Adding dependency relationships z Indicates that one element has knowledge of another element z

What does dependency add to this DCD?

ProductDescription , and thus some kind of

  I.e., a change in specification of one thing may affect another thing that uses it, but not necessarily the reverse z A dashed directed line z Typically non-attribute visibility between classes

  ProductDescription the Sale has parameter visibility to a

  dependency SalesLineItem ... ...

  ProductDescription ... ...

  1.. * lineItems Sale

...

updatePriceFor( ProductDescription )

...

Association classes Composition (whole-part) relations —model association with attributes & operations

  Employs

  1 Company Person 0..7 composition means

  Hand Finger

• a part instance ( Square) can only be part of one composite ( composite ( Board) at a time Board) at a time composition -the composite has sole responsibility for management of its parts, especially creation and deletion

  a person may have Employment employment with several

  1

  1 40 1..

• Board Square

  salary startDate Figure 16.13

Figure 16.16

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

  SuperClassFoo { abstract } unofficially, the second alternative

• classOrStaticAttribute : Int is common
• publicAttribute : String

  Interfaces and Template Classes 3 common

• privateAttribute compartments assumedPrivateAttribute

  —Interface is a predefined «stereotype» isInitializedAttribute : Bool = true 1. classifier name java.awt::Font aCollection : VeggieBurger [ * ] or

  —Templates take parameters in corner attributeMayLegallyBeNull : String [0..1] java.awt.Font

2. attributes

finalConstantAttribute : Int = 5 { readOnly } /derivedAttribute plain : Int = 0 { readOnly }

  3. operations bold : Int = 1 { readOnly }

  the attribute type may be expressed in

• classOrStaticMethod() name : String

  parameterized or template K official UML, with the template binding + publicMethod()

  style : Int = 0

  «interface»

DCD

  syntax requiring an arrow assumedPublicMethod() interfaces and classes

  ... an interface

  List - privateMethod() or

  shown with a # protectedMethod() getFont(name : String) : Font summary

  K is a template parameter in another language, such as Java keyword

  ~ packageVisibleMethod() getName() : String

  clear()

  «constructor» SuperclassFoo( Long ) ...

  ...

  methodWithParms(parm1 : String, parm2 : Float) methodReturnsSomething() : VeggieBurger

  Board «interface» methodThrowsException() {exception IOException}

  abstractMethod() Questions? Runnable Fruit abstractMethod2() { abstract } // alternate

  squares : List<K Square>

  dependency run() finalMethod() { leaf } // no override in subclass

  anonymous class with or ...

  synchronizedMethod() { guarded } template binding complete T squares : List<Square>

  ArrayList ...

  ... elements : T[*] interface

  ArrayList<T Square> implementation ...

  

and

subclassing SubclassFoo

  clear() clear()

  PurchaseOrder

  for example, the elements attribute is an ... ... ...

  1 array of type T, parameterized and bound ... order before actual use. run() ... ...

  there is a chance the UML 2 “arrow” symbol will

  association with Figure 16.1

  eventually be replaced with something else e.g., ‘=’

  multiplicities

• ellipsis “…” means there may be elements, but not shown
• a blank compartment officially means “unknown” but as a

Figure 16.18

  convention will be used to mean “no members”

Designing with interaction and class diagrams

  z Beginners often emphasize Class diagrams z Interaction diagrams deserve more attention z

Some tools can help:

  Convert between sequence and communication

• – diagrams automatically Reflect changes in class and interaction diagrams
• – in parallel