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

Transcription

1 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

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

3 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

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

5 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

6 Fig : 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

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

8 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

9 Fig 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

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

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

12 Fig : 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

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

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

15 Fig : 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

16 Fig : 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

17 Fig : 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

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

19 Fig : 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

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

21 Fig 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

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

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

24 Fig 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

25 Fig 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

26 Fig 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

27 Fig 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

28 Fig 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

29 Fig 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

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

31 Fig 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

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

33 Fig 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

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

35 Fig 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

36 Fig 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

37 Fig 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

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

39 Fig 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

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