SYSC 3100 - System Analysis and Design

1. SYSC 3100 - System Analysis and Design Interaction Diagrams (Sequence and Communication Diagrams) SYSC-3100 System Analysis and Design

2. Introduction • Interaction diagrams are used to illustrate how objects interact via messages. • They are used for dynamic object modeling. • There are two types: sequence and communication interaction diagrams. • Sequence Diagram: emphasizes the time ordering of messages • Communication Diagram: emphasizes the structural organization of the objects that send and receive messages • Interaction diagram is often built from a use case • Interaction diagrams help in refining initial class diagram (derived from use case descriptions) • Textbook reading: chapters 9 and 10 SYSC-3100 System Analysis and Design

3. Objectives • The main objective is to identify system events. • Create system interaction diagrams for use case scenarios. • An interesting and useful question in software design is this: What events are coming in to our system and how do we handle them? Basically, a software react to three things: • External events from actors (humans and computers) • Timer events, and • Faults or exceptions (which are often from external sources) • Therefore, it is useful to know what, precisely, are the external system events. They are an important part of analyzing system behaviour. SYSC-3100 System Analysis and Design

4. Example of Sequence & Communication Diagrams What might this represent in code? e.g. java public class A { private B myB = new B(); public void doOne() { myB.doTwo(); myB.doThree(); } // ... } Sequence diagram Equivalent communication diagram SYSC-3100 System Analysis and Design

5. Sequence Diagram Basic Structure SYSC-3100 System Analysis and Design

6. : Register : Sale makePayment ( cashTendered ) makePayment ( cashTendered ) create ( cashTendered ) : Payment Example Sequence Diagram: makePayment • The sequence diagram is read as follows: • The message makePayment is sent to an instance of a Register. The sender is not identifed. • The Register instance sends the makePayment message to Sale instance. • The Sale instance creates an instance of a Payment. • What might be some related code for the Sale class and its makePayment method? public class Sale { private Payment payment; public void makePayment (Money cashTendered ) { payment = new Payment ( cashTendered ); // ... } // ... } SYSC-3100 System Analysis and Design

7. Equivalent Communication diagram for makePayment • The communication diagram shown above has the same intent as the prior sequence diagram • In what follows, we will concentrate on sequence diagrams and come back to communication diagrams at the end of the section. SYSC-3100 System Analysis and Design

8. Sequence Diagram: Additional Details SYSC-3100 System Analysis and Design

9. Nested Messages SYSC-3100 System Analysis and Design

10. Messages SYSC-3100 System Analysis and Design

11. Lifelines: Messages and Focus of control • Focus of control is shown using an execution bar (previously called an activation bar or activation in UML 1.x) The bar is optional. SYSC-3100 System Analysis and Design

12. : Register : Sale doX d 1 = getDate getDate aDate Lifelines: Reply or Returns • There are two ways to show the return result from a message: • Using the message syntax returnVar = message(parameter) • Using a reply (or return) message line at the end of an execution specification bar. • Both are common in practice. The first one is preferred because it is less effort and the diagram is not cluttered. SYSC-3100 System Analysis and Design

13. Lifelines: Messages to “self” or “this” • You can show a message being sent from an object to self by using a nested execution specification bar. SYSC-3100 System Analysis and Design

14. note that newly created : Register : Sale objects are placed at their creation " height " makePayment ( cashTendered ) create ( cashTendered ) : Payment authorize Lifeline boxes: Creation of Instances • The message create is not required – anything is legal – but it is a UML idiom. Can also use <<create>>. • The typical interpretation (e.g. in Java or C#) of a create message is “invoke the new operator and call the constructor.” SYSC-3100 System Analysis and Design

15. Lifelines: Object Destruction • In some circumstances it is desirable to show explicit destruction of an object. E.g. In C++ which does not have automatic garbage collection, or when you want to indicate that an object is no longer usable such as closing database connection, etc.. : Sale create ( cashTendered ) : Payment the «destroy» stereotyped ... message , with the large X and short lifeline indicates explicit object «destroy» destruction X SYSC-3100 System Analysis and Design

16. : A : B makeNewSale [ more items ] loop a UML loop enterItem ( itemID , quantity ) frame , with a guard boolean expression description , total endSale Sequence Diagram Frames • To support conditional and looping constructs (among many other things), the UML 2.0 uses frames. • Frames are regions or fragments of the diagrams; they have an operator or label (such as loop) and guard (conditional clause). • The LOOP frame example is shown below. SYSC-3100 System Analysis and Design

17. Summary of some common frame operators SYSC-3100 System Analysis and Design

18. Summary of some common frame operators cont. SYSC-3100 System Analysis and Design

19. Frames: Conditional Messages - opt • An OPT frame is placed around one or more messages. • Notice (below) that the guard is placed over the related lifeline. SYSC-3100 System Analysis and Design

20. Frames: Mutually Exclusive Conditional Messages (alt + else) • An ALT frame is placed around the mutually exclusive alternatives. SYSC-3100 System Analysis and Design

21. Frames: Nested frames SYSC-3100 System Analysis and Design

22. Objects Design: Active and Passive Objects • An active object is an object that owns a process or thread and can initiate control activity. • An active class is a class whose instances are active objects. • A process is a heavyweight flow that can execute concurrently with other processes. • A thread is a lightweight flow that can execute concurrently with other threads within the same process. In UML 2, active classes are drawn with double vertical lines. • A passive object is an object that does not have its own thread of control. Its operations execute under a control thread anchored in an active object. SYSC-3100 System Analysis and Design

23. Objects Design: Flow of Control • Purely sequential system: There is only one flow of control. This means that one thing , and one thing only, can take place at a time. • At the start of a sequential system, control is rooted at the beginning of the program and operations are dispatched one after another. This is true even if there are concurrent things happening among the actors outside the system. In this case, a sequential system will process one thing at a time, queuing or discarding any concurrent external events. • Concurrent system: There is more than one flow of control. There are multiple simultaneous flows of control, each rooted at the head of an independent process or a thread. • In UML, active class is used to represent a process or thread that is the root of an independent flow of control and that is concurrent with all peer flows of control. SYSC-3100 System Analysis and Design

24. Justifications for Active Classes • Asynchronous events in the environment • Periodic handling • Time-critical functions • Computational tasks in background SYSC-3100 System Analysis and Design

25. Object Design: Classes and Events • Active classes are just classes. They represents an independent flow of control, whereas a plain class (i.e passive class) embodies no such flow. Passive classes cannot independently initiate control activity. • Active classes share the same properties as all other classes. • Active classes are used to model common families of processes or threads. This means that an active object – an instance of an active class – reifies (is a manifestation of) a process or thread. • Modeling concurrent systems with active classes means that a name is given to each independent flow of control. • When an active object is created, the associated flow of control is started; when the active object is destroyed, the associated flow of control is terminated. SYSC-3100 System Analysis and Design

26. Communication Between Active Objects • Passive objects: method invocation, synchronous, data passed as parameters • Active objects communicate through: • Method invocation • Signal object queues, mailbox … • Shared memory, e.g., monitor • Synchronization mechanism (wait and notify mechanisms in Java) • Remote method invocations (RMIs) • Those are implementation techniques – chosen in the object design phase • During analysis and system design, when modeling, active objects communicate through signals and messages. SYSC-3100 System Analysis and Design

27. Signals • A signal is a named object that is sent asynchronously by one object and then received by another (asynchronous message). • A signal is a classifier, a message type. • Signals have a lot in common with plain classes: • Signals may have instances, although you don’t generally need to model them explicitly. • May be involved in generalization relationships • May have attributes and operations • May be sent by action of a transition in a state machine • May be modeled as a message between two roles in an interaction. • The execution of a method can also send signals. SYSC-3100 System Analysis and Design

28. Signals cont. • It can consist of all of the elements of the following syntax: [attribute=] signal-name [(arguments)] [:return-value] | ‘*’ • Everything is optional apart from the signal-name. • The attribute= and return-value are only used on reply messages. • The signal-name is the event that is sent to the target object. • The full syntax for each argument is as follows: [parameter-name=] argument-value | attribute-parameter-name [:argument-value] | - • You do not show empty brackets after a signal name if there are no arguments. SYSC-3100 System Analysis and Design

29. Modeling Signals You model signals as stereotyped classes. You can use a dependency, stereotype as send, to indicate that an operation sends a particular signal In UML, you can model the named signals that an object may receive by naming them in an extra compartment of the class as shown SYSC-3100 System Analysis and Design

30. Modeling Family of Signals The figure models a family of signals that may be handled by an autonomous robot. Note that RobotSignal is an abstract signal. SYSC-3100 System Analysis and Design

31. House Alarm: Static Structure for Dynamic Messages • This slide and next 4 slides show the static structure associated with selected examples of a home alarm system. • The system consists of a main unit with a number of sensors and alarms. • The sensors detect movements in the guarded area. • The alarms generate sounds and/or lights to scare off an intruder. • The total area that can be guarded is divided into cells, where a cell contains some sensors and some alarms that guard a specific area. SYSC-3100 System Analysis and Design

32. Sensors for the House Alarm • The Sensor boundary class is active; it has its own thread of control that handles the low-level interrupts from actual device. SYSC-3100 System Analysis and Design

33. Alarms • The alarms are devices to scare off an intruder by means of sound and light effects, or by calling and sending information to the police station via a phone number: they require boundary classes SYSC-3100 System Analysis and Design

34. Active and Passive Objects in the Home Alarm System SYSC-3100 System Analysis and Design

35. <<signal>> Sensor Signals {abstract} <<signal>> AlarmSignals {abstract} <<signal>> General Signal {abstract} <<signal>> Signal {abstract} timeSent:Time sender:ObjectId <<signal>> TurnOff <<signal>> Alarm <<signal>> ACK <<signal>> NAK <<signal>> Trigger <<signal>> Error <<signal>> Heartbeat <<signal>> SelfTest <<signal>> Activate <<signal>> Deactivate Signal Hierarchy for Home Alarm System SYSC-3100 System Analysis and Design

36. Implementation of Asynchronous Messages with Signals SYSC-3100 System Analysis and Design

37. Example: Sequence diagram with asynchronous messages and active objects • The figure below shows a sequence diagram with asynchronous messages. Note that an asynchronous message is sent between the objects, :WordProcessor and :PrintSpooler. The :Printer is also shown as an active object. SYSC-3100 System Analysis and Design

38. Messages to Classes to Invoke Static (or class) Methods • It is possible to show class or static method calls by using lifeline box label that indicates the receiving object is a class, or more precisely, an instance of a metaclass (cf. figure below). • E.g. in Java and Smalltalk, all classes are conceptually or literally instances of class Class; in .NET classes are instances of class Type. In code, a likely implementation is: public class Foo { public void doX() { // static method call on class Calendar Locale[] locales = Calendar.getAvailableLocales(); // ... } // ... } SYSC-3100 System Analysis and Design

39. Polymorphic Messages and Cases • How do we show polymorphism in a sequence diagram? • One approach is to use multiple sequence diagrams – one that shows the polymorphic message to the abstract superclass diagrams or interface object, and • Then separate sequence diagrams detailing each polymorphic case, each starting with a found polymorphic message. • See next slide for an example. SYSC-3100 System Analysis and Design

40. Polymorphic Messages and Cases cont. SYSC-3100 System Analysis and Design

41. Interaction Occurrences • An interaction occurrence (also called interaction use) is a reference to an interaction within another interaction. • It is a way of hiding detail in sequence diagrams. It is useful for simplifying a diagram and factoring out a portion into another diagram, or when there is a reusable interaction occurrence. • They are created with two related frames: • A frame around an entire sequence diagram, labeled with the tag sd and a name, such as “AuthenticateUser” or “Spool File to Printer” • A frame tagged ref, called a reference, that refers to another named sequence diagram; it is the actual interaction occurrence SYSC-3100 System Analysis and Design

42. Example interaction occurrence, sd and ref frames SYSC-3100 System Analysis and Design

43. Example interaction occurrence – from text book pg 170-171 Sequence diagram in which the detail is shown in separate diagrams SYSC-3100 System Analysis and Design

44. sd Write File to Print :WordProcessor :PrinterSpooler open(name) t:File write(name) close Idle print(name) Lifeline and States • States can be placed on a lifeline to indicate the state that an object must be in as a pre-condition of an action or as a transition to the post-condition of an action. • For example, the spooler must be in the idle state when it receives the instruction to print the named file. SYSC-3100 System Analysis and Design

45. Message Sending • The sending of message is usually assumed to be virtually instantaneous. However in a situation where the message is sent over a communications link and a significant amount of time elapses between the sending and receiving of the message. • This is shown by a slanting down arrow in a sequence diagram. SYSC-3100 System Analysis and Design

46. Time and Duration Constraints • Time constraints are used in sequence diagram to show timing constraints on messages. They apply either to the time taken by one message or to the intervals between event occurrences on lifelines. The example shows the time taken by a message (range 0 to 10s) and the time between the event t and a subsequent event which must take place no later than t+30 seconds. • Duration constraints are related to the duration of messages. The example below indicates that the time between the two points marked on the lifeline must be at least d seconds and no greater than d*3 seconds. SYSC-3100 System Analysis and Design

47. sd sd Share Journey Get Journey Status :CarSharer :Journey :CarSharer :Journey getStatus ref Get Journey Status alt alt [status == available] ref Check Addresses available setPossibleMatch(true) available [else] [else] notAvailable notAvailable setPossibleMatch(false) Sequence diagram: Continuations • A continuation is shown as a rectangle with semi-circular ends. This is the same symbol as for states, but it may cover more than one lifeline. • The interaction Share Journey (on the right) includes the interaction occurrence Get JourneyStatus (on the left). The latter contains an alt combined fragment. • Stating from the Share Journey, Get Journey Status is referenced. One of the two operands will be selected depending on the value of status, and the interaction will run until it reaches one of the continuations, available or notAvailable (in Get Journey Status). After the interaction occurrence completes, the interaction in Share Journey will continue at the continuation of the same name in its alt combined fragment. [status == available] SYSC-3100 System Analysis and Design

48. Example: Continuations Continuations Interpretation of continuations SYSC-3100 System Analysis and Design

49. Example: States and Time Constraints • The next four slides (this included) will give example on delay, timing constraints, and duration constraints. This example is from the recommended text on when “Vehicle passes beacon.” • Please read (study) pages 190 to 195 (solved problems 9.5 to 9.10). 1st scenario: Vehicle passes beacon with timing constraints SYSC-3100 System Analysis and Design

50. Example cont.. 2nd Scenario – Vehicle passes beacon – optional interaction occurrence SYSC-3100 System Analysis and Design