1. INFO 620Lecture #51 Information Systems Analysis and Design Sequence and Collaboration Diagrams INFO 620 Glenn Booker

2. INFO 620Lecture #52 Interaction Diagrams Sequence diagrams and collaboration diagrams are both interaction diagrams; they show the interaction among actors, the system, and now, parts of the system The RUP’s Design Model consists of the interaction diagrams and the design class diagrams (notice we’re now doing design!)

3. INFO 620Lecture #53 Dynamic Modeling Even more generally, the following are all dynamic models – they show how things move into, out of, and within of the system –Sequence diagram –Collaboration diagram –State (or Statechart) diagram –Activity diagram We’ll discuss the latter two things later on

4. INFO 620Lecture #54 So in Summary The sequence and collaboration diagrams therefore have the following shared traits; they are both: –Interaction diagrams –Part of the Design Model of the RUP –Dynamic models of the system

5. INFO 620Lecture #55 System Sequence Diagram (SSD) The SSD focuses on one use case per diagram; and generally one scenario within that use case (the main success scenario) The system has been reduced to one box; a class generally called “:System” UML only defines a Sequence Diagram; we define the SSD for our purposes

6. INFO 620Lecture #56 System Sequence Diagram Take the system and reduce it to an object Name objects and classes using the form object:Class –For example employee:Person means there is an object “employee” of the Class “Person” Notice the Class name is capitalized, but the object name is all lower case, and it’s all underlined

7. INFO 620Lecture #57 System Sequence Diagram Now name the system :System to pretend there exists a Class of objects, from which our entire system is derived Recall the actors defined earlier, both primary and secondary Now summarize each interaction between the system and the actors with lines to represent each message or return of data

8. INFO 620Lecture #58 System Sequence Diagram The SSD defines interactions among the :System, and actors which are not part of the :System Each SSD starts, by definition, with the primary actor doing something to initiate the use case –All interactions are shown by messages, which may have parameters

9. INFO 620Lecture #59 System Sequence Diagram From Fig 13-1, p. 178

10. INFO 620Lecture #510 System Sequence Diagram Each message is a description of some task which will need to be accomplished We focus on what changes need to be made to objects in our system –Create or destroy objects –Read or change attributes within objects –Create or destroy associations between objects

11. INFO 620Lecture #511 System Sequence Diagram All sequence diagrams assume that time is moving forward as you move down the diagram Hence messages almost never touch each other – they are just passed from one actor to another –Time between messages is not explicitly shown; could be 1 ms or 5 minutes or 10 years

12. INFO 620Lecture #512 SSD Actors Actors for an SSD are only those actors who directly interact with the system for this use case Typical order of actors from left to right are –Primary actor –:System –Secondary actor(s)

13. INFO 620Lecture #513 Parameters Parameters are data which are passed with a message: “enterItem(itemID, quantity)” is a message called ‘enterItem’ which passes two parameters to the :System, ‘itemID’ and ‘quantity’ The system’s response, or “return value,” is kept abstract, such as ‘description, total’

14. INFO 620Lecture #514 Repeated Events A group of events which are repeated are shown in the SSD by a thin solid-lined box around all of the events which repeat The group is presumably repeated until the next event after (below) the box takes place

15. INFO 620Lecture #515 Naming and Defining Events Keep names of messages focused on the intent, rather than on how it is input –“enterItem” rather than “scanItem”, so we don’t limit how the data is entered into the :System All messages and parameters named in SSD’s or SQD’s (Sequence Diagrams) should later appear in the Glossary

16. INFO 620Lecture #516 Adding Use Case Text For SSD’s, it is possible (but optional) to show the text of the use case description next to each corresponding line of the SSD (p. 123)

17. INFO 620Lecture #517 SSD versus SQD The System Sequence Diagram (SSD) models the system as one class The Sequence Diagram (SQD) shows individual classes within the system which correspond to classes in the Design or Application Class Diagrams

18. INFO 620Lecture #518 SSD and the Unified Process SSD’s are generally not done in the Inception phase Most SSD’s are created during Elaboration

19. INFO 620Lecture #519 Operation Contracts Operation contracts are a way of documenting complex SSDs or SQDs Each operation, or method, needs to be clearly defined; that definition is a contract which describes its role and responsibilities Hence each operation contract describes what each message will need to accomplish

20. INFO 620Lecture #520 Operation Contracts Operation; the name of the operation, and the parameters sent to it Cross References; what use cases use this operation Preconditions; assumptions about what has occurred before using this operation Postconditions; what changed as a result of this operation

21. INFO 620Lecture #521 Operation Contracts Preconditions are expressed in present tense –For the enterItem method, “There is a sale underway” Postconditions are expressed in past tense –“A SalesLineItem instance was created” Contracts are used when a method is too complex to represent clearly with a use case

22. INFO 620Lecture #522 Operation Contracts Typically, a method which creates a new object and assigns data to it involves three steps: –Create the instance (make a new object) –Form an association with its parent object (SaleLineItem is associated with a Sale) –Assign the data to the object (attribute modification)

23. INFO 620Lecture #523 Interaction Diagrams Sequence diagrams and collaboration diagrams (CD) both show almost the same information, so doing both is redundant (for a given use case) How choose which one to do? –SQD focuses on time, shows lifeline of object –CD shows all possible events & context more clearly, but an individual sequence is less clear

24. INFO 620Lecture #524 Collaboration Diagrams Collaboration diagrams look kind of like flow charts Objects are shown by boxes Messages between objects are shown by lines connecting the boxes Lines are labeled, and have arrows to show in which direction the messages travel

25. INFO 620Lecture #525 Sample Collaboration Diagram

26. INFO 620Lecture #526 Parameters Notice that actors do not appear in CD’s!* CD starts with the message which initiates the use case, e.g. makePayment(cashTendered) Collaboration diagrams can also show parameters being passed between objects –Same notation as for SSD * Note that Rose requires an actor to start a CD; use the primary actor

27. INFO 620Lecture #527 Numbering Messages Here is one way a CD differs from an SSD Messages, after the first one, are numbered –The first numbered message is ‘1’ –Later messages which result from that message get 0.1 added, e.g. 1.1, 1.2, etc. –The next message from the starting point is ‘2’ –And so on… See example on page 205, Figure 15.11

28. INFO 620Lecture #528 SQD for Fig 15.11, p. 205 NOTE: Normally an SQD does NOT show numbering in front of messages – it’s shown here only to compare to the CD

29. INFO 620Lecture #529 Sequence Diagram Notes A sequence diagram can have messages passing left or right on the diagram; that’s why a return message uses a dashed line to make its meaning clear The left/right position of classes and actors in an SQD or SSD has no inherent meaning –Generally they are shown in the order in which they are used during the use case

30. INFO 620Lecture #530 Put It All Together Now translate the interaction diagrams to their corresponding class diagram This is REALLY IMPORTANT: The target of an arrow in an interaction diagram is the class which implements that message

31. INFO 620Lecture #531 Class Diagram for Fig 15.11

32. INFO 620Lecture #532 Conditional Messages A message may be sent only if some condition is met The syntax for this is to put the condition in brackets after the message number, but before the colon, e.g. 1 [color = red]: calculate() Means that the message ‘calculate’ will be sent only if color = red is a true statement

33. INFO 620Lecture #533 Mutually Exclusive Messages If you have two or more messages, exactly one of which will be used any given time, then the message numbering takes on a letter (a, b, …) after the leading number; from p. 206, Figure 15.13: 1a [test1]: msg2() or 1b [not test1]: msg4()

34. INFO 620Lecture #534 Iteration The use of iteration or looping, where a message is called repeatedly under specific conditions is flagged by a numbering suffix of “*” The iteration condition may follow, e.g. 1 * [I=1..N]: num := nextInt() which calls the message nextInt ‘N’ times

35. INFO 620Lecture #535 Sequence Diagram Notation The dashed line under each object is the lifeline of that object A solid lined box may be added over the lifeline to show when that object is active –Helps distinguish short-lived objects from long ones –Usually extends from first message to last return

36. INFO 620Lecture #536 For any Sequence Diagram (SQD), the system’s boundary can be shown by a heavy (2-3 pt) vertical dashed line This is a little redundant for an SSD (why?) System Boundary

37. INFO 620Lecture #537 Self-referential Objects Objects may send a message to themselves –E.g. a form clearing itself This can be shown as a message which turns around 180 degrees (p. 209)

38. INFO 620Lecture #538 Destroying Objects An object can be explicitly destroyed by stopping the lifeline and placing a big X over the end of the lifeline The corresponding message is simply “ >” –If you never get rid of objects, you create memory leaks; if you destroy them too soon, you might try to read data which isn’t there

39. INFO 620Lecture #539 Conditional Messages in SQD Conditional messages in a sequence diagram use the same notation as collaboration diagrams, only without the numbering: [color = red] calculate() means “only send the message ‘calculate’ if color equals red” (do nothing otherwise)

40. INFO 620Lecture #540 Multiple Conditions in SQD Multiple conditions (or mutually exclusive conditions) can be shown by feeding from the same origin (Fig 15.23, p. 211)

41. INFO 620Lecture #541 Iteration Iteration for a sequence diagram uses the same notation as a collaboration diagram * [I=1..N] num := nextInt()

42. INFO 620Lecture #542 Messages to Classes Messages may be sent to classes or static methods, such as libraries Denote the name of the class without an underline (e.g. java.util.Collections, instead of :Sale) The lack of underline means it’s a class instead of an object