1. Interaction Diagrams - Chapter 15 Describe/illustrate sequence of message exchanges among objects show the flow of control across many objects used to illustrate a use case, a scenario,... Types Collaboration diagram Sequence diagram

2. Interaction Diagrams Message asynchronous or synchronous components numbered (collaboration diagram) guard name parameter list name is mandatory... others as required

3. Interaction Diagrams Synchronous vs asynchronous messages We will assume (at first) that all messages are synchronous: if object A sends a message to object B then A is suspended object B gains control, and B begins to compute object A waits until B responds (i.e. B sends a message back to A) When an asynchronous message is sent from A to B, A does not pause and wait for B to finish … results in multiple threads of control.

4. Interaction Diagrams Synchronous messages: control, or the ability to compute, is gained by holding a token that is passed with a message consider that there is an activation stack: when object A sends a message to object B, object B goes on to the top of the stack and it can compute. If B responds to A then B is popped from the stack and A, being at the top, begins to compute

5. Collaboration Diagram Objects are represented similarly to classes in a class model … relationships are indicated clearly Objects may be named or unnamed Timing is understood by the numbering scheme. We use a nested decimal numbering to indicate the order in which messages are sent Many messages may be sent across one link

6. Figure 15.3 Collaboration diagram for makePayment

7. Figure 15.7 Messages

8. Figure 15.8 Message to ‘this’

9. Figure 15.9 Instance creation

10. Figure 15.10 Sequence Numbering

11. Figure 15.11 Complex numbering

12. Figure 15.12 Conditional Message

13. Figure 15.13 Mutually exclusive messages

14. Figure 15.14 Iteration

15. Figure 15.15 Iteration over a multiobject

16. Figure 15.16 Messages to a class itself, not an object

17. Collaboration Diagram - example Suppose we have classes for POrder, Customer, LineItem, Product with the following class model POrder LineItemProduct Customer 1 1 0..* 1 We want to exhibit how objects of these classes communicate in order for the POrder to learn its value

18. Collaboration Diagram - example Suppose POrder does not know its value. To determine its value it must ask each of its line items “what are you worth?”, and then ask the customer “what discount do you get”. Each line doesn’t remember the corresponding products price and so it must interrogate the product to determine the price POrder LineItemProduct Customer 1 1 0..* 1

19. Collaboration Diagram 128937:POrder line1:LineItemTYZMonitor:Product line2:LineItemOptMouseX :Product JonesSupply:Customer 1:cost:=reportTotal() 1.1:price:=reportPrice() 2:reportTotal() 2.1:price:=reportPrice() 3:discount:=reportDiscount() reportTotal() Given that the objects below are involved, we show them along with the basic associations Since these are objects, not classes, there are no multiplicities Some message starts things off

20. Collaboration Diagram Use the diagramming technique to show the complexity you need to understand or represent Example: consider the creation of the lines of a Purchase Order, and where we are checking for adequate stock on hand we reorder if we fall below a reorder quantity - a reorder item line is created if there’s enough on hand, a delivery line item gets created and quantity on hand must be decremented

21. Collaboration Diagram - example 128937:POrder :LineItem :DeliveryItem {new} 1*[for all order lines]: prepare() 1.1:reportPrice() 1.2:[hasStock]:=remove() 1.2.1:needsToReorder:=needToReorder() 1.2.2:[needsToReorder]:create 1.3:[hasStock]:=create :Product :ReorderItem {new}