Modeling Dynamic Behavior Sequence and Collaboration Diagrams LethbridgeLaganire

Modeling Dynamic Behavior: Sequence and Collaboration Diagrams © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour

Interaction Diagrams Interaction diagrams model the dynamic aspects of a software system • They help visualize how the system runs. • They are built from use cases and a class diagram. —The objective is to show a set of objects accomplish the required interactions with an actor (e. g. , a Student in Stress. Free). • They show actors and objects communicate to perform: —The steps of a use case, or —The steps of some other piece of functionality. • They can show several different types of communication. —E. g. method calls, messages sent over the network —These are all referred to as messages. © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 2

Elements of interaction diagrams • Instances of classes —Shown as boxes with the class and object identifier underlined • Actors —Use the stick-person symbol as in use case diagrams • Messages —Shown as arrows from actor to object, or from object to object • There are two kinds of interaction diagrams: —Sequence diagrams —Collaboration diagrams (We’ll focus on sequence diagrams. ) © Lethbridge/Laganière 2001 : Course. Record add. Course Chapter 8: Modelling Interactions and Behaviour 3

Sequence diagrams A sequence diagram shows how messages are exchanged among objects to complete a task (a use case) • The objects are arranged horizontally across the top of the diagram. • The vertical dimension represents time. • An actor that initiates the interaction is shown on the left. • A dotted lifeline is attached to each object or actor. • The lifeline becomes an activation box during the live activation period. • A message is an arrow between the activation boxes of the sender and receiver. —A message can have an argument list and a return value. © Lethbridge/Laganière 2001 : Course. Offering enroll. In. Courses Chapter 8: Modelling Interactions and Behaviour 4

Example Sequence Diagram : course. Offering enroll. In. Courses : Course. Record : Schedule <<create>> add. Course add. Student Course get. Prerequisites * Course. Offering request. To. Register add. Student © Lethbridge/Laganière 2001 * Course. Record * Schedule add. Course meets. Prerequisites Chapter 8: Modelling Interactions and Behaviour 5

A Sequence Diagram showing more detail GUI : course. Offering a. Student: : Course Student enroll. In. Courses (a. Student) prereq : = get. Prerequisites has. Prerequisites : = has. Taken(prereq) opt [has. Prerequisites] create : course. Record add. Student(a. Student) © Lethbridge/Laganière 2001 add. Course Chapter 8: Modelling Interactions and Behaviour 6

Sequence diagrams can show looping An iteration over objects is indicated by an asterisk preceding the message name : Bill loop [0. . num. Purchases] : Purchase get. Subtotal : Item get. Price compute. Total © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 7

Sequence diagrams – object deletion If an object’s life ends, an X appears at the end of the lifeline a. Student : Course. Record : Course. Offering delete. ACourse cancel delete. Course © Lethbridge/Laganière 2001 delete. Student (a. Student) Chapter 8: Modelling Interactions and Behaviour 8

Collaboration diagrams emphasise how objects collaborate during an interaction • It is a graph with the objects as the vertices. • Links are added between pairs of collaborating objects. • Messages are attached to the links. —Shown as arrows labelled with the message name • Time ordering is indicated by attaching a number to each message. © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 9

Collaboration diagrams provide an alternative to sequence diagrams 1: <<create>> 2: add. Course : Course. Offering : Course. Record : Schedule 3: add. Student : course. Offering enroll. In. Courses : Course. Record <<create>> : Schedule add. Course add. Student © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 10

Collaboration diagrams can also show details 2: prereq : = get. Prerequisites GUI 1: enroll. In. Courses(a. Student) 3: has. Prerequisites : = has. Taken(prereq) a. Student: Student © Lethbridge/Laganière 2001 : Course. Offering 4: [has. Prerequisite] <<create>> : Course 5: add. Student(a. Student) : Course. Record 5: add. Course Chapter 8: Modelling Interactions and Behaviour 11

Communication links in collaboration diagrams A link exists between two objects whenever one object can send a message to the other. Several situations make this possible: 1. The objects’ classes have an association between them. 2. The receiving object is stored in a local variable of the sending method. - 3. 4. A reference to the receiving object has been received as a parameter of the sending method. The receiving object is stored in a local variable of the sending method. - 5. This often happens when the object is created in the sending method or when some computation returns an object. A reference to the receiving object has been received as a parameter of the sending method. © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 12

Choosing a sequence or a collaboration diagram? Sequence diagrams • Make explicit the time ordering of the interaction (they align well with use cases) —So they are a natural choice when you build an interaction model from a use case. • Make it easy to add details to messages. Collaboration diagrams • Can be seen as a projection of the class diagram —Might be preferred when you are deriving an interaction diagram from a class diagram. —Are also useful for validating class diagrams. • Have less space for adding details to messages. © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 13

Implementing Classes from Sequence Diagrams • These diagrams are most useful for parts of the system that are most complex. • They help you create a correct implementation. • They are particularly useful when an activity is spread across several classes. • The operations become the class’s methods • But many operations are already indicated by the class diagram and use case preconditions and postconditions. • A good system model unifies class diagrams, use cases, and sequence diagrams into a coherent whole. © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 14

UML Tools generate the core Java classes E. g. , Course. Offering, Course. Record, and Schedule Classes Course. Offering request. To. Register add. Student * Course. Record grade * Schedule add. Course meets. Prerequisites instance variables /** @poseidon-generated */ public class Course. Record { private String grade; associations public Course. Offering course. Offering; public Transcript transcript; public Schedule schedule; © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 15

… and the methods for managing associated objects public Course. Offering get. Course. Offering() { return course. Offering; } public void set. Course. Offering( Course. Offering course. Offering) { if (this. course. Offering != null) this. course. Offering. remove. Course. Record(this); this. course. Offering = course. Offering; if (course. Offering != null) course. Offering. add. Course. Record(this); } } © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 16

Course. Offering class /** @poseidon-generated */ public class Course. Offering { private int id; private String section; private String lab. Section; private String sem. Year; private int capacity; private int enrollment; public Collection course. Record = new Hash. Map(); public Course course; public Instructor instructor; public Time. Slot time. Slot; © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 17

Course. Offering methods public boolean is. Full() { } public boolean has. Student(int id) { } public boolean add. Student(int id) { } public boolean delete. Student(int id) { } public Collection get. Course. Records() { return course. Record; } public void add. Course. Record(Course. Record course. Record) { if (! this. course. Record. contains(course. Record)) { this. course. Record. add(course. Record); course. Record. set. Course. Offering(this); } } public void remove. Course. Record( Course. Record course. Record) { … } © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 18

Risks in Modelling Interactions and Behaviour Dynamic modelling is a difficult skill • A large system has a very large number of possible paths. • It is hard to assign the right class(es) to each behaviour. • Strategies: —Work iteratively: - Develop initial class diagrams, use cases, responsibilities, interaction diagrams and state diagrams; - Then go back and verify that all of these are consistent, modifying them as necessary. —Use a good tool, like Poseidon UML, to helps ensure consistency among different diagram types. —Draw different diagrams that capture related ideas to help highlight problems. —Ensure that skilled developers lead the process. —Ensure that all aspects of the model are critically reviewed. © Lethbridge/Laganière 2001 Chapter 8: Modelling Interactions and Behaviour 19