CS251 Software Engineering 1: OO Modelling, UML Interaction Diagrams

(CS251) Lecture 6 OO Modelling, Interaction Diagrams (Sequence, SOFTWARE ENGINEERING 1 Collaboration, & System Sequence Diagrams) Dr. Amr S. Ghoneim OO MODELLING, INTERAC...

(CS251) Lecture 6 OO Modelling, Interaction Diagrams (Sequence, SOFTWARE ENGINEERING 1 Collaboration, & System Sequence Diagrams) Dr. Amr S. Ghoneim OO MODELLING, INTERACTION DIAGRAMS 1 LECTURE OBJECTIVES 1. Learn the notation of interaction diagrams. 2. Learn how to visualize system-user interaction using system sequence diagrams, collaboration diagrams, system sequence diagrams. 3. Learn how to decide upon issues such as fork & cascade, or how to implement use-cases. OO MODELLING, INTERACTION DIAGRAMS 2  Functional Diagrams (Use case diagrams)   Describe the functional behavior of the system as seen by the user. Static Diagrams (Class, Object, & Package diagrams)   Describe the static structure of the system: Objects, attributes, associations. Dynamic Diagrams: UML  Interaction diagrams (Sequence, & DIAGRAMS Collaboration diagrams)   Describe the interaction between objects of the system.  State diagrams   Describe the dynamic behavior of an individual object.  Activity diagrams   Describe the dynamic behavior of a system, in particular the workflow. OO MODELLING, INTERACTION DIAGRAMS 3  OO MODELLING, INTERACTION DIAGRAMS 4 UML DYNAMIC MODELLING.. WHY? UML static modeling involves use cases, “activity diagrams,” and class/object modeling: − Use cases describe what a system should do (the required behavior/operations). It did not say which classes should be responsible for which parts of computation − An initial Class model identifies classes and its relationship but do not contain complete list of attributes and operations. Thus, a link is required between use cases and class modeling, which leads us to what is known as dynamic modeling. Dynamic Modelling shows how the objects interact by sending messages to implement the required functionality of the software system (to realize a Use-Case).  OO MODELLING, INTERACTION DIAGRAMS 5 UML DYNAMIC MODELLING: INTERACTION DIAGRAMS Interaction diagrams are UML notations representing dynamic modeling that are used to help make and record decisions relating to the behavior (operations) defined for each class. There are two types of interaction diagrams: 1. Sequence Diagram.. 2. Communication (Collaboration) Diagram.. Both are semantically equivalent to each other, and used for quite similar purposes, but each has different features as described next.  OO MODELLING, INTERACTION DIAGRAMS 6 UML INTERACTION DIAGRAMS SEQUENCE VERSUS COLLABORATION DIAGRAMS Sequence Diagrams Collaboration (Communication) Diagrams Definition Shows object interaction arranged in Shows how cooperating objects time sequence. That is, a 2-dimensional dynamically interact with each diagram, horizontally the objects other by sending and receiving participating in the interaction are messages. depicted, while vertical dimension represents time. Strengths Time relationship extremely clear. Objects’ interactions extremely clear. Weaknesses Not easy to see the overall pattern of Actual sequence of messages is message flow. difficult to see. SEQUENCE DIAGRAMS A sequence diagram shows the participants (objects) in an interaction (a use case or part of it) and the sequence of messages among them. Each Use Case requires one or more sequence diagrams to describe its behaviour. OO MODELLING, INTERACTION DIAGRAMS 7  OO MODELLING, INTERACTION DIAGRAMS 8 SEQUENCE DIAGRAMS Starting by building a sequence diagram: o Begin by looking at interactions implied by use cases. Consider a use case scenario to be modeled. o You need to know where the first message in the use case originates. (for example, a user interface). o You need to consider the message flow; o To where the initial message should be sent? o This implies which class should have this method in its protocol. o Use the post-condition(s) of the use cases which reflect how the system must change. o Take into consideration the main scenario and the alternative ones. o It may be helpful to use a pair of object diagrams, showing the states before and after the operation in question.  OO MODELLING, INTERACTION DIAGRAMS 9 OBJECT LIFELINES  OO MODELLING, INTERACTION DIAGRAMS 10 OBJECTS CREATION AND DESTRUCTION  OO MODELLING, INTERACTION DIAGRAMS 11 MESSAGES, RETURNS & ACTIVATION BOXES  OO MODELLING, INTERACTION DIAGRAMS 12 CONDITIONAL MESSAGES  OO MODELLING, INTERACTION DIAGRAMS 13 CONDITIONS AND ITERATIONS  OO MODELLING, INTERACTION DIAGRAMS 14 MESSAGES TO "SELF" OR "THIS"  OO MODELLING, INTERACTION DIAGRAMS 15 SEQUENCE DIAGRAM: AN EXAMPLE  OO MODELLING, INTERACTION DIAGRAMS 16 SEQUENCE DIAGRAM: EXAMPLE 2  OO MODELLING, INTERACTION DIAGRAMS 17 SEQUENCE DIAGRAM: EXAMPLE 2 (SEQUENCE TO CLASS DIAGRAM) A communication (collaboration) diagram is an object diagram with added message-sends. o Every message has a multi-stage number (1.1). o The numbers specify the sequencing, replacing vertical position in a sequence diagram. COLLABORATION DIAGRAMS OO MODELLING, INTERACTION DIAGRAMS 18  OO MODELLING, INTERACTION DIAGRAMS 19 COLLABORATION DIAGRAMS CONVERSION FROM A SEQUENCE DIAGRAM  OO MODELLING, INTERACTION DIAGRAMS 20 COLLABORATION DIAGRAMS CONVERSION FROM A SEQUENCE DIAGRAM  OO MODELLING, INTERACTION DIAGRAMS 21 COLLABORATION DIAGRAMS CONVERSION FROM A SEQUENCE DIAGRAM COLLABORATION OO MODELLING, INTERACTION DIAGRAMS 22 DIAGRAMS OBJECTS CREATION AND DESTRUCTION In a communication diagram: object creation and destruction are shown by the special constraints {new} and {destroyed} respectively.  OO MODELLING, INTERACTION DIAGRAMS 23 COLLABORATION DIAGRAMS AN EXAMPLE.. USE-CASE & CLASS DIAGRAMS ► A class model for lending books, where there is a requirement to record both past and current loans ►  OO MODELLING, INTERACTION DIAGRAMS 24 COLLABORATION DIAGRAMS AN EXAMPLE.. FROM STATIC TO DYNAMIC MODELLING Represent the interaction for the borrowing of a book. o Draw both a sequence diagram and a communication diagram that sends the message borrow(b) to an instance of LibraryMember from aUserInterface, where b is a reference to the object representing the book that the library member m wants to borrow. o At this point we are not concerned about where the object b came from.  OO MODELLING, INTERACTION DIAGRAMS 25 COLLABORATION DIAGRAMS AN EXAMPLE.. THE SEQUENCE DIAGRAM  OO MODELLING, INTERACTION DIAGRAMS 26 COLLABORATION DIAGRAMS AN EXAMPLE.. THE COLLABORATION DIAGRAM  OO MODELLING, INTERACTION DIAGRAMS 27 UML INTERACTION DIAGRAMS SEQUENCE VERSUS COLLABORATION DIAGRAMS There are two main differences between communication diagrams and sequence diagrams: 1. A communication diagram shows in one place all the links of interest between objects, whereas a sequence diagram does not. 2. The time-ordering of messages is clear in a sequence diagram (Time is viewed as running vertically downwards). However, some form of numbering is needed in a communication diagram to show the time-ordering of messages.  OO MODELLING, INTERACTION DIAGRAMS 28 COMMUNICATION DIAGRAM NOTATION SUMMARY The rectangles represent the various objects involved that make up the application. The same notation for classes and objects used on UML sequence diagrams are used on UML communication diagrams The lines between the classes represent the relationships (associations, composition, dependencies, or inheritance) between them. The details of the associations, such as their multiplicities, are not modeled because this information is contained on the class diagrams: remember, each UML diagram has its own specific purpose and no single diagram is sufficient on its own. Messages are depicted as a labeled arrow that indicates the direction of the message, using a notation similar to that used on sequence diagrams. Optionally, you may indicate the sequence number in which the message is sent, indicate an optional return value, and indicate the method name and the parameters (if any) passed to it. Sequence numbers should be in the format A.B.C.D to indicate the order in which the messages where sent. In the previous example message1 is sent to the Seminar object which in turn sends messages 1.1 and then 1.2 to the Course object. Message 5 is sent to the Seminar object, which sends message 5.1 to enrollment, which in turn sends message 5.1.1 to student, and it finally sends message 5.1.1.1 to itself.  OO MODELLING, INTERACTION DIAGRAMS 29 COMMUNICATION DIAGRAM FURTHER EXAMPLES  OO MODELLING, INTERACTION DIAGRAMS 30 COMMUNICATION DIAGRAM FURTHER EXAMPLES  SYSTEM SEQUENCE DIAGRAMS (SSD) SSDs are visual summaries of the individual use cases. SSD shows the events that external actors generate, their order, and possible inter-system events. All systems are treated as a black box; the diagram places emphasis on events that cross the system boundary from actors to systems. A SSD should be done for the main success scenario of the use case and frequent or complex alternative scenarios. A SSD should specify and show the following:  External actors.  Messages (methods) invoked by these actors.  Return values (if any) associated with previous messages.  Indication of any loops or iteration area. OO MODELLING, INTERACTION DIAGRAMS 31  OO MODELLING, INTERACTION DIAGRAMS 32 USE CASE DIAGRAM OF A VENDING MACHINE  OO MODELLING, INTERACTION DIAGRAMS 33 VENDING MACHINE USE CASES SUMMARIES  OO MODELLING, INTERACTION DIAGRAMS 34 FROM USE CASE TO SYSTEM SEQUENCE DIAGRAM Consider : “Buying a Beverage” Use Case. Think of the vending machine (system) as a black box and draw system sequence diagram to model the interactions between the system and the actors (system events). Tips:  Prepare at least one system sequence diagram per use case.  Prepare a system sequence diagram for each important Exception.  35 USE CASE MODELS: USE CASE DESCRIPTION  OO MODELLING, INTERACTION DIAGRAMS 36 SYSTEM SEQUENCE DIAGRAM FOR “BUY A BEVERAGE” USE CASE :Customer :VendingMachineSystem Insert coins() Check Amount ▪The system events are: Offer Choices ▪Insert coins() Enter Choice() ▪Enter choice() Dispatch Item Dispatch Change DESIGN ISSUES: STRATEGIES FOR IMPLEMENTING USE-CASES You have seen that when you construct interaction diagrams, the first two design decisions that have to be made are the following: o Which message should be sent from the interface? o To which object should the interface send the message? Three strategies for choosing which objects are to receive messages from the user interface: 1. One Central Class 2. Actor Class 3. Use-Case class OO MODELLING, INTERACTION DIAGRAMS 37  DESIGN ISSUES: STRATEGIES FOR IMPLEMENTING USE-CASES One Central Class: Making the interface sends all messages to a single object – usually some general object like a System or Hotel- who will in turn forward message to the concerned object. From the interface’s point of view, it has to know the existence of only one object. Advantages: o Minimizing the knowledge the interface must have of the business model which minimizes the dependency of the user interface on the rules and concepts of the business domain. o There is good traceability from use cases to code because every use case links to a method in the same central class (System or Hotel). Disadvantage: o One central class becomes overloaded with use cases. o One possible solution to this problem is to divide the software system into several packages. Each package could still make use of one class to respond to messages from the interface. OO MODELLING, INTERACTION DIAGRAMS 38  DESIGN ISSUES: STRATEGIES FOR IMPLEMENTING USE-CASES Actor classes: The message should be sent to the software object corresponding to the real-world actor object who initiated the operation (use actors as classes). Example: In case of check in a hotel, a person arrives to hotel initiates check in process by talking to receptionist who uses interface to do so. Therefore, the message ought to go to the Guest object. Advantage: o From some designers point of view this approach has clearer structure than the previous one. Weakness: o Traceability is more difficult than one central class. o Limitation of reusability; For example: an Actor-Class as Guest includes methods that are related to the role of the guest in this particular application, thus reducing its usefulness in another application. o There is a further complication when there are two actors that can initiate an interaction. OO MODELLING, INTERACTION DIAGRAMS 39  DESIGN ISSUES: STRATEGIES FOR IMPLEMENTING USE-CASES Use cases as classes: A new class is identified for each use case, E.g.: CheckerIn, and CheckerOut. Each class have a method with a name like run, with suitable arguments. The user interface would then create a single instance of the appropriate class, initialize it suitably, & then send the run(...) message. Advantages: o Overcomes the reuse limitations posed by the strategy of actors as classes. o Using use case objects lets you change or even replace the software to implement a given scenario so as to minimize the effects upon the core concepts. o Use case objects provide traceability from each use case to a class; so each use case can be understood in isolation. Disadvantages: o Large number of extra classes must be defined – one for each use case. o Many of the use case classes can be very similar, resulting in duplicated code and more difficult maintenance. OO MODELLING, INTERACTION DIAGRAMS 40  When designing an interaction diagram, sometimes an object needs to send a message to another object with which it has no direct associations. − For example, in the given below figure, Company has an association with a number of instances of Job, and each Job has an association with a Person. DESIGN − A Company has no direct association with a ISSUES: Person. FORKS & We can A fork centralizes CASCADES implement this as either forks control in the sender. or cascades. A cascade delegates responsibility to another object. OO MODELLING, INTERACTION DIAGRAMS 41  DESIGN ISSUES: FORKS & CASCADES Suppose that the company needs to collect information about the ages of all its employees. There are two ways to design this: Using fork pattern: where Company can send a message to Job to get back person. Then send message to Person to get the age. In this pattern, the company contacts two classes directly, using the value returned from the first message as parameter for the second one. OO MODELLING, INTERACTION DIAGRAMS 42  DESIGN ISSUES: FORKS & CASCADES Using Cascade pattern: Company send getAgeofPerson() to Job class, where Job class send another message getAge() to Person class. So there is no direct interaction between Company and Person. − A reasonable position is that Job should need to know only about the existence of Person, not particular attributes such as age. OO MODELLING, INTERACTION DIAGRAMS 43 THANK YOU! Questions? OO MODELLING, INTERACTION DIAGRAMS 44