Applying UML & Patterns (3 rd ed.) Chapter 15

Applying UML & Patterns (3 rd ed.) Chapter 15 UML INTERACTION DIAGRAMS This document may not be used or altered without the express permission of the author. Dr. Glenn L. Ray School of Information Sciences University of Pittsburgh gray@sis.pitt.edu 412-624-9470

Fig. 15.1 : A myb : B doone dotwo dothree Sequence diagram s fence format Time is increasing in the downward direction 2

Fig 15.1 : A myb : B doone dotwo dothree public class A { private B myb = new B(); } public void doone() { myb.dotwo(); myb.dothree(); } 3

Fig. 15.2 doone : A 1: dotwo 2: dothree myb : B Same collaboration using communication diagram Uses network (or graph) format 4

Interaction Diagrams Sequence vs. Communication diagrams Sequence Diagrams Easier to see sequence of method calls over time More expressive UML notation Better support from many tools Communication Diagrams Better fit on limited space (page or whiteboard) Easier to edit/amend Look more like class diagram 5

Fig. 15.3 : Register : Sale makepayment(cashtendered) makepayment(cashtendered) create(cashtendered) : Payment 1. Someone(?) sends makepayment(..) msg to Register 2. Register sends makepayment(..) msg to Sale 3. Sale creates an instance of Payment Who created Register & Sale? IDs show a fragment of system behavior during isolated snapshot in time. This can be confusing and lead to modeling errors/omissions! 6

Fig. 15.4 direction of message makepayment(cashtendered) :Register 1: makepayment(cashtendered) :Sale 1.1: create(cashtendered) :Payment Same collaboration using communication diagram 7

Interaction Diagrams Essential UML models for OOAD 1. Use cases Functional requirements 2. Class diagram Objects with knowledge (attributes) and behavior (operations) Static relationships between objects 3. Interaction diagrams Dynamic collaboration between objects 8

Fig. 15.5 lifeline box representing an unnamed instance of class Sale lifeline box representing a named instance lifeline box representing the class Font, or more precisely, that Font is an instance of class Class an instance of a metaclass :Sale s1 : Sale «metaclass» Font lifeline box representing an instance of an ArrayList class, parameterized (templatized) to hold Sale objects lifeline box representing one instance of class Sale, selected from the sales ArrayList <Sale> collection List is an interface in UML 1.x we could not use an interface here, but in UML 2, this (or an abstract class) is legal sales: ArrayList<Sale> sales[ i ] : Sale x : List related example 9

Interaction Diagrams UML expression syntax Don t have to use full syntax in all cases return = msgname(param:paramtype1, ) : returntype 10

Fig. 15.6 dox : Register doa : Store 1 the 1 implies this is a Singleton, and accessed via the Singleton pattern Notation for Singleton 11

Fig. 15.7 : Register : Sale dox doa a found message whose sender will not be specified dob doc dod execution specification bar indicates focus of control typical sychronous message shown with a filled-arrow line 12

Fig. 15.8 : Register : Sale dox More common return syntax d1 = getdate getdate adate A return from method call, usually considered optional Overuse clutters diagram! 13

Fig. 15.9 : Register dox clear Objects commonly invoke their own methods 14

Fig. 15.10 : Register : Sale note that newly created objects are placed at their creation "height" makepayment(cashtendered) create(cashtendered) : Payment authorize Dashed line for create really not needed, though its now official UML Use create for calls to a constructor 15

Fig. 15.11 : Sale create(cashtendered)... «destroy» : Payment X the «destroy» stereotyped message, with the large X and short lifeline indicates explicit object destruction Usually not necessary for languages with automatic garbage collection (e.g., Java) 16

Fig. 15.12 : A : B makenewsale a UML loop frame, with a boolean guard expression loop [ more items ] enteritem(itemid, quantity) description, total endsale UML Loop frame 17

Fig. 15.13 : Foo : Bar xx opt [ color = red ] calculate yy UML 2 frame showing an optional message 18

Fig. 15.14 : Foo : Bar xx [ color = red ] calculate yy The same ID using pre-uml 2 notation Guards must evaluate to true for the message to be sent 19

Fig. 15.15 : A : B : C dox alt [ x < 10 ] calculate [ else ] calculate Alt frame show mutually exclusive interactions 20

Fig. 15.16 t = gettotal lineitems[i] : : Sale SalesLineItem This lifeline box represents one instance from a collection of many SalesLineItem objects. loop [ i < lineitems.size ] i++ st = getsubtotal 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 Technique for looping over a collection Loop details are explicit; diagram more cluttered Note Java code on p. 234 showing new for loop syntax 21

Fig. 15.17 : Sale lineitems[i] : SalesLineItem t = gettotal loop st = getsubtotal A 2 nd technique for looping Loop details are implicit; diagram less cluttered 22

Fig. 15.18 : Foo : Bar xx opt [ color = red ] loop(n) calculate A loop frame nested within an optional frame 23

Fig. 15.19 SD can contain frames that Reference other SDs : A : B : C sd AuthenticateUser : B : C dox doa authenticate(id) ref dob AuthenticateUser authenticate(id) dom1 dom2 ref DoFoo sd DoFoo : B : C interaction occurrence note it covers a set of lifelines note that the sd frame it relates to has the same lifelines: B and C dox doy doz 24

Fig. 15.20 message to class, or a static method call dox : Foo 1: locs = getavailablelocales «metaclass» Calendar Call to a static class method Notice there is no implied instance to the Calendar class ( : is omitted) 25

Fig. 15.21 Payment is an abstract superclass, with concrete subclasses that implement the polymorphic authorize operation Payment {abstract} authorize() {abstract}... CreditPayment authorize()... DebitPayment authorize()... polymorphic message object in role of abstract superclass :Register :Payment {abstract} dox authorize stop at this point don t show any further details for this message :DebitPayment :Foo :CreditPayment :Bar authorize doa authorize dox dob separate diagrams for each polymorphic concrete case Polymorphic method calls 26

Fig. 15.22 a stick arrow in UML implies an asynchronous call a filled arrow is the more common synchronous call In Java, for example, an asynchronous call may occur as follows: // Clock implements the Runnable interface Thread t = new Thread( new Clock() ); t.start(); the asynchronous start call always invokes the run method on the Runnable (Clock) object to simplify the UML diagram, the Thread object and the start message may be avoided (they are standard overhead ); instead, the essential detail of the Clock creation and the run message imply the asynchronous call startclock Active objects run in their own thread :ClockStarter create run active object runfinalization :Clock System : Class Solid vs. stick arrowheads easily confused when sketching models See Java code p. 239-240 27

Fig. 15.23 UML for Communication Diagrams.. 1: makepayment(cashtendered) 2: foo : Register :Sale 2.1: bar link line A link is to objects as an association is to classes A link is an instance of an association 28

Fig. 15.24 msg1 1: msg2 2: msg3 3: msg4 : Register :Sale 3.1: msg5 all messages flow on the same link Link does not show directionality that is indicated by each msg 29

Fig. 15.25 A message to this msg1 : Register 1: clear 30

Fig. 15.26 Three ways to show creation in a communication diagram create message, with optional initializing parameters. This will normally be interpreted as a constructor call. Simplest & most common 1: create(cashier) : Register :Sale 1: create(cashier) : Register :Sale {new} «create» 1: make(cashier) : Register :Sale if an unobvious creation message name is used, the message may be stereotyped for clarity 31

Fig. 15.27 msg1 : A 1: msg2 : B not numbered 1.1: msg3 legal numbering : C Message numbering can be tricky to follow 32

Fig. 15.28 first second third msg1 : A 1: msg2 : B 1.1: msg3 2.1: msg5 2: msg4 : C fourth 2.2: msg6 fifth Complex message numbering sixth : D 33

Fig. 15.29 conditional message, with test message1 1 [ color = red ] : calculate : Foo : Bar Conditional message with guard 34

Fig. 15.30 unconditional after either msg2 or msg4 : E 1a and 1b are mutually exclusive conditional paths 2: msg6 msg1 1a [test1] : msg2 : A : B 1b [not test1] : msg4 1a.1: msg3 : D 1b.1: msg5 : C Mutually exclusive conditional messages 35

Fig. 15.31 runsimulation : Simulator 1 * [ i = 1..n ]: num = nextint : Random iteration is indicated with a * and an optional iteration clause following the sequence number Iteration/looping 36

Fig. 15.32 t = gettotal : Sale 1 * [i = 1..n]: st = getsubtotal lineitems[i]: 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 : Sale 1 *: st = getsubtotal lineitems[i]: SalesLineItem Less precise, but usually good enough to imply iteration across the collection members Iteration over a collection 37

Fig. 15.33 message to class, or a static method call dox : Foo 1: locs = getavailablelocales «metaclass» Calendar Static method call or message to a class 38

Fig. 15.34 polymorphic message stop at this point don t show any further details for this message dox :Register authorize :Payment {abstract} object in role of abstract superclass authorize authorize :DebitPayment doa dob :Foo :CreditPayment dox :Bar separate diagrams for each polymorphic concrete case Polymorphic messages 39

Fig. 15.35 startclock :ClockStarter 3: runfinalization System : Class :Clock 1: create 2: run asynchronous message active object Asychronous calls 40