1. Software Engineering Design & Modeling Sequence Diagram Communication Diagram Communication Diagram Timing Diagram Timing Diagram

2. 2 Introduction We started looking at the static aspects of UML models in the earlier chapters – classes and objects diagrams We started looking at the static aspects of UML models in the earlier chapters – classes and objects diagrams In previous chapter, we began to explore the dynamic aspects of UML model – use case diagrams In previous chapter, we began to explore the dynamic aspects of UML model – use case diagrams In this chapter, we are going to see how to look at the static and dynamic aspects of a system in parallel. In this chapter, we are going to see how to look at the static and dynamic aspects of a system in parallel.

3. 3 Chapter Outline Interactions Interactions Definition Definition Messages and actions Messages and actions Sequencing Sequencing Modelling an interaction Modelling an interaction Interaction diagram Interaction diagram Sequence diagram Sequence diagram Collaboration diagram Collaboration diagram Timing diagram Timing diagram Robustness Analysis Robustness Analysis Case Study Case Study

4. Interactions

5. 5 Introduction In every system, objects do not just sit idle; they interact with one another by passing messages. In every system, objects do not just sit idle; they interact with one another by passing messages. In the UML, the dynamic aspects of a system is modelled using interactions In the UML, the dynamic aspects of a system is modelled using interactions An interaction sets the stage for its behaviour by introducing An interaction sets the stage for its behaviour by introducing all the objects that work together to carry out some action, and all the objects that work together to carry out some action, and the messages that are dispatched from object to object the messages that are dispatched from object to object

6. 6 Definition An interaction is a behaviour that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose An interaction is a behaviour that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose Interactions can be found wherever objects are linked to one another, e.g. Interactions can be found wherever objects are linked to one another, e.g. in the collaboration of objects that exist in the context of a system and subsystem as a whole in the collaboration of objects that exist in the context of a system and subsystem as a whole among objects in the implementation of an operation among objects in the implementation of an operation in the context of a class in order to visualize, specify, construct and document the semantic of a class in the context of a class in order to visualize, specify, construct and document the semantic of a class

7. 7 Messages & Actions A message is a communication between two objects, or within an object, that is designed to result in some activity. A message is a communication between two objects, or within an object, that is designed to result in some activity. This activity involves one or more actions, which are executable statements that result in This activity involves one or more actions, which are executable statements that result in changes in the values of one or more attributes of an object, changes in the values of one or more attributes of an object, or the return of some value(s) to the object that sent the message, or the return of some value(s) to the object that sent the message, or both or both

8. 8 There are 5 kinds of actions that the UML explicitly supports: - There are 5 kinds of actions that the UML explicitly supports: - Call and Return Call and Return Create and Destroy Create and Destroy Send Send

9. 9 Call action Call action A call action invokes an operation on an object A call action invokes an operation on an object It is synchronous, meaning that It is synchronous, meaning that the sender assumes that the receiver is ready to accept the message, the sender assumes that the receiver is ready to accept the message, and the sender waits for a response from the receiver before proceeding and the sender waits for a response from the receiver before proceeding The UML represents a call action as an arrow from the calling object to the receiving object The UML represents a call action as an arrow from the calling object to the receiving object : ClassObject: Class action name A call action that involves two objects A call action from an object to itself A lifeline

10. 10 Return action Return action A return action is the return of a value to the caller, in response to a call action A return action is the return of a value to the caller, in response to a call action The UML represents a return action as a dashed arrow from the object returning the value to the object receiving the value The UML represents a return action as a dashed arrow from the object returning the value to the object receiving the value : ClassObject: Class return value

11. 11 : Customer : CustomerReview assignRating() computeAvgRating() average rating Example :- Call and Return action

12. 12 Create action Create action A create action creates an object A create action creates an object It tells a class to create an instance of itself It tells a class to create an instance of itself In the UML, create action is represented as an arrow with the stereotype > from the object that invokes the create action to the created object In the UML, create action is represented as an arrow with the stereotype > from the object that invokes the create action to the created object Object: Class: Class > Object: Class : Class create an object UML 2.0 UML 1.x

13. 13 Destroy action Destroy action A destroy action destroys an object A destroy action destroys an object It tells an object to destroy itself It tells an object to destroy itself An object can perform a destroy action on another object, or on itself An object can perform a destroy action on another object, or on itself In the UML, a destroy action is represented as an arrow with the stereotype > (UML 1.x) from the object that invokes the action to the destroyed object. A large X is also added at the end of the destroy arrow to denote that the object’s lifeline has been terminated In the UML, a destroy action is represented as an arrow with the stereotype > (UML 1.x) from the object that invokes the action to the destroyed object. A large X is also added at the end of the destroy arrow to denote that the object’s lifeline has been terminated Object: Class: Class > X

14. 14 Send action Send action A send action sends a signal to an object A send action sends a signal to an object A signal is an asynchronous communication between objects A signal is an asynchronous communication between objects One object “throws” a signal to another object that “catches” the signal One object “throws” a signal to another object that “catches” the signal The sender of the signal does not expect a response from the receiver (unlike the sender of a call action) The sender of the signal does not expect a response from the receiver (unlike the sender of a call action) Exceptions are the most common type of signals Exceptions are the most common type of signals In the UML, a send action is represented as an arrow with a half arrowhead at the lifeline of the receiving object In the UML, a send action is represented as an arrow with a half arrowhead at the lifeline of the receiving object : ClassObject: Class action name : ClassObject: Class action name UML 1.xUML 2.0

15. 15 In the UML, a signal is represented as stereotyped classes or as signals that objects belonging to a given class can respond to. In the UML, a signal is represented as stereotyped classes or as signals that objects belonging to a given class can respond to. The attributes of a signal serve as the signal’s parameters when an object sends the signal to another object The attributes of a signal serve as the signal’s parameters when an object sends the signal to another object The extra compartment in the class box contains the names of the signals to which objects of a given class can respond to. The extra compartment in the class box contains the names of the signals to which objects of a given class can respond to. Will learn more about signals in later chapters… Will learn more about signals in later chapters… attribute : type > >Signal Signals Signal SignalClass

16. 16 Example: A send action, with its sample signal : Login Page: Exception Handler BadPassword(userID) userID : String userID : String > >BadPassword Signals BadPassword BadPasswordExceptionHandler

17. 17 Asynchronous message Asynchronous message A message is sent by one object to another but the first object does not wait until the resulting action has completed, it carries on with the next step in its own sequence of actions. A message is sent by one object to another but the first object does not wait until the resulting action has completed, it carries on with the next step in its own sequence of actions. Synchronous message Synchronous message A message is sent by one object to another and the first object waits until the resulting action has been completed. A message is sent by one object to another and the first object waits until the resulting action has been completed. Creation message Creation message Represents a message that causes the creation of an object instance to which the message is sent. Represents a message that causes the creation of an object instance to which the message is sent. Reply message Reply message Represents the explicit return of control from the object to which the message was sent. Represents the explicit return of control from the object to which the message was sent. Lost message Lost message Have a send event but the receive event is unknown, normally because they do not reach their destination. Have a send event but the receive event is unknown, normally because they do not reach their destination. Found message Found message Have a receive event, but their origin is unknown, possibly, because it is outside the scope of the description. Have a receive event, but their origin is unknown, possibly, because it is outside the scope of the description.

18. 18 Sequencing When an object passes a message to another object, the receiving object might in turn send a message to another object, which might send a message to yet a different object, and so on. When an object passes a message to another object, the receiving object might in turn send a message to another object, which might send a message to yet a different object, and so on. This stream of messages forms a sequence This stream of messages forms a sequence Any sequence Any sequence must have a beginning: the start of every sequence is rooted in some process or thread must have a beginning: the start of every sequence is rooted in some process or thread will continue as long as the process or thread that owns it lives will continue as long as the process or thread that owns it lives

19. 19 Each process or thread within a system defines a distinct flow of control, and within each flow, messages are ordered in sequence by time Each process or thread within a system defines a distinct flow of control, and within each flow, messages are ordered in sequence by time The order of the message relative to the start of the sequence can be modelled by prefixing the message with a sequence number, set apart by a colon separator The order of the message relative to the start of the sequence can be modelled by prefixing the message with a sequence number, set apart by a colon separator A filled solid arrowhead is used to specify a procedural or nested flow of control A filled solid arrowhead is used to specify a procedural or nested flow of control A stick arrowhead is used to specify a flat flow of control, to model the non-procedural progression of control from step to step A stick arrowhead is used to specify a flat flow of control, to model the non-procedural progression of control from step to step

20. 20 : Viewc : Controller: Cache 2 : clickAt()2.2 : putRecentPick() 2.1 : findAt() sequence numbermessage nested flow of control c : Caller: Telephone: Exchange 1 : liftHandset()2 : assertCall() sequence number message flat flow of control link

21. 21 Modelling an interaction When modelling an interaction, we need to include both objects and messages When modelling an interaction, we need to include both objects and messages each object plays a specific role each object plays a specific role each message represents the communication between objects, with some resulting action each message represents the communication between objects, with some resulting action We can visualize objects and messages in an interaction in two ways: - We can visualize objects and messages in an interaction in two ways: - by emphasizing the time ordering of its message : sequence diagram by emphasizing the time ordering of its message : sequence diagram by emphasizing the structural organization of the objects that send and receive messages : communication diagram by emphasizing the structural organization of the objects that send and receive messages : communication diagram Both sequence and communication diagram are examples of interaction diagrams Both sequence and communication diagram are examples of interaction diagrams

22. Interactions diagram

23. 23 Introduction In the UML, an interaction diagram is used to model the dynamic aspect of a system. In the UML, an interaction diagram is used to model the dynamic aspect of a system. These dynamic aspect may involve : - These dynamic aspect may involve : - the interaction of any kind of instance in any view of a system’s architecture, including instances of a class, interface, components and nodes. the interaction of any kind of instance in any view of a system’s architecture, including instances of a class, interface, components and nodes. a system as a whole, a subsystem, an operation or a class a system as a whole, a subsystem, an operation or a class Interaction diagrams can also be attached to Interaction diagrams can also be attached to use cases : to model scenarios use cases : to model scenarios collaborations : to model the dynamic aspects of a society of objects collaborations : to model the dynamic aspects of a society of objects

24. 24 Definition An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. An interaction diagram contains: - An interaction diagram contains: - objects objects links links messages messages may also contain notes and constraints. may also contain notes and constraints.

25. 25 An interaction diagram can be used in two ways: - An interaction diagram can be used in two ways: - To model flows of control by time ordering To model flows of control by time ordering emphasizes the passing of messages as they unfold over time emphasizes the passing of messages as they unfold over time Sequence Diagram and Timing Diagram are used to model this Sequence Diagram and Timing Diagram are used to model this To model flows of control by organization To model flows of control by organization emphasizes the structural relationships among the instances in the interaction, along which messages may be passed emphasizes the structural relationships among the instances in the interaction, along which messages may be passed Communication Diagram is used to model this Communication Diagram is used to model this

26. 26 Sequence diagram A sequence diagram is an interaction diagram that emphasizes the time ordering of messages (sequence of calls). A sequence diagram is an interaction diagram that emphasizes the time ordering of messages (sequence of calls). A sequence diagram is formed by: - A sequence diagram is formed by: - 1. Placing the objects that participate in the interaction at the top of the diagram, along the X-axis The object that initiates the interaction is placed on the left most, and the other subordinate objects are placed to the right The object that initiates the interaction is placed on the left most, and the other subordinate objects are placed to the right 2. Placing the messages that these objects send and receive along the Y-axis, in order of increasing time from top to bottom

27. 27 A sequence diagram has four key elements: - A sequence diagram has four key elements: - Objects appear along the top margin Objects appear along the top margin Each object has a lifeline, which is a dashed line that represent the life and perhaps death of the object Each object has a lifeline, which is a dashed line that represent the life and perhaps death of the object Most objects will be in existence for the duration of the interaction Most objects will be in existence for the duration of the interaction Objects may also be created during the interaction, or destroyed Objects may also be created during the interaction, or destroyed A focus of control, which is a tall thin rectangle that sits on top of an object’s lifeline A focus of control, which is a tall thin rectangle that sits on top of an object’s lifeline It shows the period of time during which an object is performing an action, either directly or through subordinate procedure It shows the period of time during which an object is performing an action, either directly or through subordinate procedure The bottom part of a focus of control can be marked by a return message The bottom part of a focus of control can be marked by a return message Messages show the actions that objects perform on each other and on themselves Messages show the actions that objects perform on each other and on themselves

28. 28 Notations of Sequence Diagrams Frames Frames Sequence diagrams are drawn in frames. Frames are new in UML 2.0. Sequence diagrams are drawn in frames. Frames are new in UML 2.0. sd Interanction name heading Content area time lifeline

29. 29 Lifelines Lifelines Participating instances are represented in a sequence diagram by a dashed vertical line with, usually, a rectangle representing an object at the top of the line. Participating instances are represented in a sequence diagram by a dashed vertical line with, usually, a rectangle representing an object at the top of the line. lifeline name

30. 30 Messages Messages As previous slide As previous slide

31. 31 Combined fragments Combined fragments alt alt Alternatives : a choice in which at most one operand’s condition will evaluate to true. Alternatives : a choice in which at most one operand’s condition will evaluate to true. opt opt Option : a choice in which either this fragment will execute or it will not, depending on whether the operand’s condition evaluates to true. Option : a choice in which either this fragment will execute or it will not, depending on whether the operand’s condition evaluates to true. loop loop Loop : used to show that a fragment will be executed repeatedly Loop : used to show that a fragment will be executed repeatedly

32. 32 break break par par seq seq strict strict neg neg critical critical ignore ignore consider consider assert assert

33. 33 Interaction occurrences Interaction occurrences Another way of hiding detail in sequence diagrams has been introduced in UML 2.0 with the use of interaction occurrences. Another way of hiding detail in sequence diagrams has been introduced in UML 2.0 with the use of interaction occurrences. ref

34. 34 States 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 that it makes a transition to as the post- condition of an action. 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 that it makes a transition to as the post- condition of an action. idle Messages that take times to reach their destinations

35. 35 C : Client : Transaction create a transaction p : ODBCProxy X setActions(a, d, o) setValues(d, 3, 4) setValues(a, “CO”) committed > objects time focus of control lifeline Example of a sequence diagram

36. 36 Communication diagram A communication diagram is an interaction diagram that emphasizes the structural organization of the objects that participate in an interaction (send and receive messages) (emphasize on links). A communication diagram is an interaction diagram that emphasizes the structural organization of the objects that participate in an interaction (send and receive messages) (emphasize on links). A communication diagram is formed by:- A communication diagram is formed by:- 1. Placing the objects that participate in the interaction as the vertices in a graph 2. Rendering the links that connect these objects as the arcs of this graph 3. Adorning these links with the massages that the objects send and receive

37. 37 A communication has four key elements: - A communication has four key elements: - Objects appear at the vertices of the graph Objects appear at the vertices of the graph Paths that indicate how one object is linked to another Paths that indicate how one object is linked to another A path stereotype can be attached to the far end of a link, e.g. >, >, >, and > A path stereotype can be attached to the far end of a link, e.g. >, >, >, and > Sequence number to indicate the time order of a message Sequence number to indicate the time order of a message Each message is prefixed with a unique sequence number Each message is prefixed with a unique sequence number The UML standard is decimal numbering ( 1 is the first message; 1.1 is the first message nested in the first message; and so on) The UML standard is decimal numbering ( 1 is the first message; 1.1 is the first message nested in the first message; and so on) Messages show the actions that objects perform on each other and on themselves Messages show the actions that objects perform on each other and on themselves

38. 38 C : Client : Transaction 1 : > p : ODBCProxy 2 : setActions(a, d, o) 2.1 : setValues(d, 3, 4) 2.2 : setValues(a, “CO”) 3 : > > objects link path stereotype sequence number message Example of a collaboration diagram

39. 39 A communication may also show iteration and branching A communication may also show iteration and branching To model an iteration, prefix the sequence number of a message with an expression that begins with *, e.g. *[ i := 1..n ], or with just an * To model an iteration, prefix the sequence number of a message with an expression that begins with *, e.g. *[ i := 1..n ], or with just an * To model a condition, prefix the sequence number of a message with a condition clause, e.g [ x > 0 ] To model a condition, prefix the sequence number of a message with a condition clause, e.g [ x > 0 ]

40. 40 Semantic Equivalence Both sequence and communication diagrams are semantically equivalent Both sequence and communication diagrams are semantically equivalent A sequence diagram can be converted into a communication diagram, and vice versa, without any loss of information A sequence diagram can be converted into a communication diagram, and vice versa, without any loss of information However, this does not mean that both diagrams will explicitly visualize the same information However, this does not mean that both diagrams will explicitly visualize the same information

41. 41 C : Client : Transaction p : ODBCProxy X setActions(a, d, o) setValues(d, 3, 4) setValues(a, “CO”) committed C : Client : Transaction 1 : > p : ODBCProxy 2 : setActions(a, d, o) 2.1 : setValues(d, 3, 4) 2.2 : setValues(a, “CO”) 3 : > > semantically equivalent transaction

42. 42 You built sequence diagrams or communication diagrams from the use-case and class diagrams that were built before. You built sequence diagrams or communication diagrams from the use-case and class diagrams that were built before. Each use cases in a use-case diagram has its corresponding sequence or communication diagram Each use cases in a use-case diagram has its corresponding sequence or communication diagram You model the diagrams from the main flow of events, or the alternate flow of events, or the scenarios, of each use case You model the diagrams from the main flow of events, or the alternate flow of events, or the scenarios, of each use case Every object that you have identified in the sequence or communication diagram, MUST have its corresponding class in the class diagram Every object that you have identified in the sequence or communication diagram, MUST have its corresponding class in the class diagram

43. 43 Example: - Modelling a sequence diagram for the log-in use case from the on-line Bookstore Case Study. Example: - Modelling a sequence diagram for the log-in use case from the on-line Bookstore Case Study. The main-flow of events that are involved is: - The main-flow of events that are involved is: - 1. The CUSTOMER clicks the Log-in button on the Home Page. 2. The system displays the Log-in Page. 3. The CUSTOMER enters his/her user ID and password. The CUSTOMER clicks the OK button. CUSTOMER clicks the OK button. 4. The system validates the log-in information against the ACCOUNT table in the database. table in the database. 5. CUSTOMER is an authorised user; the system displays the Personal Home Page to the CUSTOMER Home Page to the CUSTOMER

44. 44 Actors: Customer Actors: Customer Messages and Objects Messages and Objects 1. The CUSTOMER clicks the Log-in button on the Home Page. 2. The system displays the Log-in Page. 3. The CUSTOMER enters his/her user ID and password. The CUSTOMER clicks the OK button. CUSTOMER clicks the OK button. 5. The system validates the log-in information against the ACCOUNT table in the database. ACCOUNT table in the database. 6. CUSTOMER is an authorised user; the system displays the Personal Home Page to the CUSTOMER Personal Home Page to the CUSTOMER

45. 45 :HomePage :LoginPage:Account :Customer clickLogin( ) display( ) enter userID and password clickOK( ) validateLogin(userID, password) login OK display( ) The Customer clicks the Login button on the Home Page The system displays the Login Page The Customer enters his or her user ID and password, and then clicks the OK button. The system validates the login information against the persistent Account data … … and then returns the Customer to the Home Page. Sequence Diagram

46. 46 :HomePage :LoginPage :Account :Customer 1 : clickLogin( ) 3 : enter userID and password 4 : clickOK( ) 2 : display( )6 : display( ) 5 : validateLogin(userID, password) Communication Diagram

47. 47 Robustness Analysis Sometimes when drawing an interaction diagram, we may be confused about the objects that are involved. Sometimes when drawing an interaction diagram, we may be confused about the objects that are involved. Because each object that we use in an interaction diagram MUST have its corresponding classes in the class diagram, we may find ourselves in a situation where we have already determined the objects that are needed in an interaction diagram but the objects do not have their corresponding classes in our class diagram. Because each object that we use in an interaction diagram MUST have its corresponding classes in the class diagram, we may find ourselves in a situation where we have already determined the objects that are needed in an interaction diagram but the objects do not have their corresponding classes in our class diagram. In the previous example, we discovered that the only object in the interaction diagrams that has its corresponding class in the class diagram in Account. In the previous example, we discovered that the only object in the interaction diagrams that has its corresponding class in the class diagram in Account. There is no HomePage and Log-in Page class in the class diagram (refer to Case Study in Chapter 5) There is no HomePage and Log-in Page class in the class diagram (refer to Case Study in Chapter 5) To solve this problem, we can perform robustness analysis To solve this problem, we can perform robustness analysis

48. 48 Robustness analysis involves analysing the text of a use case and identifying a first-guess set of objects that will participate in the use case, and then classifying these objects based on their characteristics. Robustness analysis involves analysing the text of a use case and identifying a first-guess set of objects that will participate in the use case, and then classifying these objects based on their characteristics. It involves defining analysis classes It involves defining analysis classes There are 3 types of analysis classes: There are 3 types of analysis classes: boundary classes boundary classes entity classes entity classes control classes control classes Instances of each of these analysis classes are called objects.

49. 49 Boundary objects Boundary objects is an object with which an actor associated with a use case interacts. is an object with which an actor associated with a use case interacts. if the actor is human, the boundary object may be a window, screen, dialog box, or menu if the actor is human, the boundary object may be a window, screen, dialog box, or menu if the actor is non-human, the boundary object may be application program interfaces (APIs) if the actor is non-human, the boundary object may be application program interfaces (APIs) boundary object

50. 50 Entity objects Entity objects is an object that contains long-lived information, such as that associated with databases. is an object that contains long-lived information, such as that associated with databases. will be mapped to a table (part of the database) in the design phase will be mapped to a table (part of the database) in the design phase It can also contain transient objects, i.e. contents of lists in windows, or search results. It can also contain transient objects, i.e. contents of lists in windows, or search results. entity object

51. 51 Control objects Control objects is an object that embodies application logic is an object that embodies application logic correspond with system actions (not actions taken by actors) correspond with system actions (not actions taken by actors) are often used to handle things such as coordination and sequencing are often used to handle things such as coordination and sequencing are also useful for calculations involving multiple entity objects are also useful for calculations involving multiple entity objects will be mapped to codes during implementation phase will be mapped to codes during implementation phase used as a connecting tissue between boundary objects and entity objects. used as a connecting tissue between boundary objects and entity objects. control object

52. 52 Using the previous example (the log-in use case of the Online Bookstore), we can identify that the HomePage and Log-in Page objects are boundary objects, whereas the Account object is an entity object. Therefore, taking this into account, we can draw a new interaction diagram. Using the previous example (the log-in use case of the Online Bookstore), we can identify that the HomePage and Log-in Page objects are boundary objects, whereas the Account object is an entity object. Therefore, taking this into account, we can draw a new interaction diagram. We need to also modify our previous class diagram to reflect this changes. We need to also modify our previous class diagram to reflect this changes. Analysing our previous class diagram, we would realised that we have only included entity objects. Analysing our previous class diagram, we would realised that we have only included entity objects. We now need to also include our boundary objects. We now need to also include our boundary objects. The changes is reflected in the Case Study The changes is reflected in the Case Study

53. 53 :HomePage :LoginPage:Account :Customer clickLogin( ) display( ) enter userID and password clickOK( ) validateLogin(userID, password) login OK display( ) The Customer clicks the Login button on the Home Page The system displays the Login Page The Customer enters his or her user ID and password, and then clicks the OK button. The system validates the login information against the persistent Account data … … and then returns the Customer to the Home Page. Sequence Diagram

54. 54 :HomePage :LoginPage :Account :Customer 1 : clickLogin( ) 3 : enter userID and password 4 : clickOK( ) 2 : display( )6 : display( ) 5 : validateLogin(userID, password) Communication Diagram

55. 55 Expressing time on Interaction Diagram It is often useful to enhanced interaction diagram by specifying time-related requirements, esp. when the system being modelled involves real-time operation or geographic distribution. It is often useful to enhanced interaction diagram by specifying time-related requirements, esp. when the system being modelled involves real-time operation or geographic distribution. The UML defines the following time specific term: - The UML defines the following time specific term: - Time expression Time expression Timing mark Timing mark Timing constraint Timing constraint

56. 56 Definitions: - Definitions: - A time expression is an expression that resolves to a relative or absolute value of time once it’s evaluated A time expression is an expression that resolves to a relative or absolute value of time once it’s evaluated A timing mark is a time related name or label on a message A timing mark is a time related name or label on a message A timing constraint is a condition that must be satisfied with regard to time. It usually contains A timing constraint is a condition that must be satisfied with regard to time. It usually contains a time expression a time expression a timing mark a timing mark

57. 57 There exist a timing mark on the message validateLogin(…). There exist a timing mark on the message validateLogin(…). The timing constraint in the above example, uses a timing mark (v) and a time expression (executionTime < 3). The timing constraint in the above example, uses a timing mark (v) and a time expression (executionTime < 3). : LoginPage: Account v : validateLogin(userID, password) { v.executionTime < 3 sec} timing mark time expression timing constraint Example: - Timing on a Sequence diagram

58. 58 Timing Diagram Timing diagrams are another form of interaction diagram, where the focus is on timing constraints: either for a single object or, more usefully, for a bunch of objects. Timing diagrams are another form of interaction diagram, where the focus is on timing constraints: either for a single object or, more usefully, for a bunch of objects. When to use timing diagram? When to use timing diagram? Timing diagrams are useful for showing timing constraints between state changes on different objects. Timing diagrams are useful for showing timing constraints between state changes on different objects. The diagrams are particularly familiar to hardware engineers. The diagrams are particularly familiar to hardware engineers.

59. 59 Graphic nodes and paths Graphic nodes and paths Frame Frame Notation Notation Focuses on the observable exchange of information between connectable elements. Focuses on the observable exchange of information between connectable elements. Message Message Notation Notation Messages come in different variants depending on what kind of Message they convey. Messages come in different variants depending on what kind of Message they convey. There are 5 types of messages in this diagram. There are 5 types of messages in this diagram.

60. 60 1. Asynchronous Messages 2. Synchronous Messages 3. Object creation Message 4. Lost Messages 5. Found Messages Message Label Message Label Notation Notation Labels are only notational shorthands used to prevent cluttering of the diagrams with a number of messages crisscrossing the diagram between Lifelines that are far apart. Labels are only notational shorthands used to prevent cluttering of the diagrams with a number of messages crisscrossing the diagram between Lifelines that are far apart. The labels denote that a message may be disrupted by introducing labels with the same name. The labels denote that a message may be disrupted by introducing labels with the same name.

61. 61 State or condition timeline State or condition timeline Notation Notation This is the state of the classifier or attribute, or some testable condition, such as an discrete enumerable value. It is also permissible to let the state-dimension be continuous as well as discrete. This is illustrative for scenarios where certain entities undergo continuous state changes, such as temperature or density. This is the state of the classifier or attribute, or some testable condition, such as an discrete enumerable value. It is also permissible to let the state-dimension be continuous as well as discrete. This is illustrative for scenarios where certain entities undergo continuous state changes, such as temperature or density. initialising acquiring reporting idle

62. 62 General value lifeline General value lifeline Notation Notation Shows the value of the connectable element as a function of time. Value is explicitly denoted as text. Crossing reflects the event where the value changed. Shows the value of the connectable element as a function of time. Value is explicitly denoted as text. Crossing reflects the event where the value changed. Lifeline Lifeline GeneralOrdering GeneralOrdering Notation Notation To describe that one occurrence must occur before the other in a valid trace. To describe that one occurrence must occur before the other in a valid trace. Destruction Event Destruction Event OnOff

63. 63 Example

64. 64

65. 65 Summary No single interaction diagram can capture everything about a system’s dynamic aspect No single interaction diagram can capture everything about a system’s dynamic aspect may need to use many interaction diagrams to model the dynamic aspects of a system as a whole, as well as its subsystem, operations, classes, use cases and collaborations. may need to use many interaction diagrams to model the dynamic aspects of a system as a whole, as well as its subsystem, operations, classes, use cases and collaborations.

66. 66 To model a sequence diagram: - To model a sequence diagram: - Set the context for the interaction Set the context for the interaction Whether it is a system, subsystem, operation, class or a scenario of a use case or collaboration Whether it is a system, subsystem, operation, class or a scenario of a use case or collaboration Identify which objects play a role in the interaction Identify which objects play a role in the interaction Place them from left-to-right, at the top of the diagram Place them from left-to-right, at the top of the diagram Set the lifeline for each object Set the lifeline for each object Starting with the message that initiates the interaction, layout each subsequent message from top to bottom between each lifelines Starting with the message that initiates the interaction, layout each subsequent message from top to bottom between each lifelines May adorn each object’s lifeline with its focus of control May adorn each object’s lifeline with its focus of control May also adorn each message with a timing mark and attach suitable time or space constraints May also adorn each message with a timing mark and attach suitable time or space constraints May also attach pre or post-conditions to each message May also attach pre or post-conditions to each message

67. 67 To model a communication diagram: - To model a communication diagram: - Set the context for the interaction Set the context for the interaction Whether it is a system, subsystem, operation, class or a scenario of a use case or communication Whether it is a system, subsystem, operation, class or a scenario of a use case or communication Identify which objects play a role in the interaction Identify which objects play a role in the interaction Place them as vertices in the graph Place them as vertices in the graph May set the initial properties (e.g attribute values, tagged values, state or role) for each of the object May set the initial properties (e.g attribute values, tagged values, state or role) for each of the object Specify the links among these objects, along which messages may be passed Specify the links among these objects, along which messages may be passed Starting with the message that initiates the interaction, attach each subsequent message to the appropriate link, setting its sequence number as appropriate Starting with the message that initiates the interaction, attach each subsequent message to the appropriate link, setting its sequence number as appropriate May also adorn each message with a timing mark and attach suitable time or space constraints May also adorn each message with a timing mark and attach suitable time or space constraints May also attach pre or post-conditions to each message May also attach pre or post-conditions to each message

68. Case Study: On-Line Bookstore (cont…)

69. 69 On-line Bookstore is a web application that can be accessed by the store’s registered customer, whereby each customer can order books, review one or more books sold in the book store, and sell used books to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their account. On-line Bookstore is a web application that can be accessed by the store’s registered customer, whereby each customer can order books, review one or more books sold in the book store, and sell used books to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their account. Problem: Draw the sequence diagram for the above system Problem: Draw the sequence diagram for the above system

70. 70 we know that the functional requirements for the Online Bookstore can be seen from the use case diagram (as shown in the next slide) we know that the functional requirements for the Online Bookstore can be seen from the use case diagram (as shown in the next slide) Each of the use cases in the use case diagram must have its corresponding interaction diagram Each of the use cases in the use case diagram must have its corresponding interaction diagram We will use the scenarios in the ‘Main flow of events’ for each use case to model the interaction diagram We will use the scenarios in the ‘Main flow of events’ for each use case to model the interaction diagram Remember that each object MUST have its corresponding classes in the class diagram Remember that each object MUST have its corresponding classes in the class diagram

71. 71 Register Order books Sell used books Review books Customer On-line Bookstore System Log-in <<include>> <<include>> <<include>> Check out <<extend>>(CustID) Use Case Functional Requirements Diagram

72. 72 Customer userId: String userId: String name: String name: String e-mail: String e-mail: String … Book bookId: String bookId: String title: String title: String … Order orderId: String orderId: String bookId: String bookId: String userId: String userId: String quantity: Integer quantity: Integer status: String status: String Review bookId: String bookId: String review: String review: String … calcAvgRating() calcAvgRating()UsedBook userId: String userId: String quality: String quality: String … Account userId: String userId: String password: String password: String checkPassword() checkPassword() has sell make order has 1 1..* 1 1 1

73. 73 :HomePage :LoginPage:Account :Customer clickLogin( ) display( ) enter userID and password clickOK( ) validateLogin(userID, password) login OK display( ) The Customer clicks the Login button on the Home Page The system displays the Login Page The Customer enters his or her user ID and password, and then clicks the OK button. The system validates the login information against the persistent Account data … … and then returns the Customer to the Home Page. Log-in

74. 74 Use Case: Register Use Case: Register Main flow of events: Main flow of events: 1. The CUSTOMER clicks the REGISTER button on the Home Page. 2. The system displays the Register Page. 3. The CUSTOMER enters all of the required information. 4. The CUSTOMER clicks the SEND button. 5. The system checks that all of the required information were entered. If yes, the system update the CUSTOMER’s record in the CUSTOMER yes, the system update the CUSTOMER’s record in the CUSTOMER and ACCOUNT tables in the database. System displays OK message. and ACCOUNT tables in the database. System displays OK message. Objects:- Objects:- CUSTOMER: actor CUSTOMER: actor CUSTOMER and ACCOUNT: entity objects CUSTOMER and ACCOUNT: entity objects Home Page and Register Page: boundary objects Home Page and Register Page: boundary objects

75. 75 :HomePage :RegisterPage :Account :Customer clickRegister( ) display( ) enter information clickSEND( ) verify info display( ) The customer clicks the REGISTER button on the Home Page The system displays the Register Page The Customer enters the required information and then clicks the SEND button. The system checks that all of the required information were entered. If yes, the system updates the CUSTOMER’s record in the CUSTOMER and ACCOUNT tables in the database. The system displays OK message Register :Customer create

76. 76 Case Study: Order Books Case Study: Order Books Main Flow of events: - Main Flow of events: - 1. The CUSTOMER enters the keyword for a book and clicks the SEARCH button on the personal Home Page. SEARCH button on the personal Home Page. 2. The system displays the matching books on the web Page. 3. The CUSTOMER chooses the desired book and clicks the ADD TO SHOPPING CART button on the web page. SHOPPING CART button on the web page. 4. The system adds the book into the CUSTOMER’s Order table in the database. database. Objects: Objects: Customer: actor Customer: actor Home Page: boundary object Home Page: boundary object Book and Order: entity object Book and Order: entity object

77. 77 :HomePage :Book:Order :Customer enters keyword search( ) choose books The CUSTOMER enters the keyword for a book and clicks the SEARCH button on the personal Home Page The system displays the matching books on the web Page The CUSTOMER chooses the desired book and clicks the ADD TO SHOPPING CART button on the web page. The system adds the book into the CUSTOMER’s Order table in the database. Order books clickSearch( ) displayMatch( ) clickAdd() create addBook( )

78. 78 Use Case: Check-out Use Case: Check-out Main flow of events Main flow of events 1. The CUSTOMER clicks the Check out button on the Home Page 2. The system displays the books in the ORDER table of the CUSTOMER on the web Page. the web Page. 3. The CUSTOMER checks the order list for any inconsistency. If nothing was found, CUSTOMER clicks the PROCEED button. found, CUSTOMER clicks the PROCEED button. 4. The system displays the Invoice page. 5. The Customer enters the relevant credit card information and clicks OK. 6. The system checks that the credit card is valid. Then, the system displays the Delivery Details page. Delivery Details page. 7. The CUSTOMER chooses destination for delivery, along with delivery options. Then, he/she clicks the PROCEED button. options. Then, he/she clicks the PROCEED button. 8. The system will display the check-out information for confirmation. 7. The CUSTOMER checks that all information is correct and then clicks the OK button. OK button. 8. The system sends a confirmation via CUSTOMER’s e-mail. Objects: - Objects: - Home Page, Invoice Page and Delivery Page: boundary objects Home Page, Invoice Page and Delivery Page: boundary objects Customer and Order: entity objects Customer and Order: entity objects

79. 79 :HomePage :Customer clickCheckOut( ) retrieve() display( ) :Order display( ) verify info clickProceed( ) :InvoicePage clickOK() validate( ) :DeliveryPage display( ) enter credit card info clickOK() choose destination display() confirm and clickOK ()

80. 80 Use case: Sell used books Use case: Sell used books Main flow of events: - Main flow of events: - 1. The CUSTOMER clicks the Sell Used Books button on the Home Page. Page. 2. The system displays the sell used books web page. 3. The CUSTOMER enters the required information on the used books that he/she wants to sell. that he/she wants to sell. 4. The CUSTOMER clicks the SEND button on the webpage. 5. The system displays a confirmation page listing the information that the CUSTOMER has entered. the CUSTOMER has entered. 6. The CUSTOMER checks that the information displayed are accurate. If yes, the CUSTOMER clicks the OK button on the web page. If yes, the CUSTOMER clicks the OK button on the web page. 7. The system updates the USED BOOKS table in the database. Objects: Objects: Home Page, Used Books Page and Confirmation Page: boundary objects Home Page, Used Books Page and Confirmation Page: boundary objects Customer and Used Books: entity objects Customer and Used Books: entity objects

81. 81 :HomePage :UsedBooksPage :Customer clickUsedBooks( ) display( ) enter book info clickSend( ) verify info Sell used books :UsedBook :ConfPage display( ) clickOK( ) add( )

82. 82 Use case: Review Use case: Review Main flow of events: - Main flow of events: - 1. The CUSTOMER enters the keyword to search for a book and then clicks the SEARCH button on the Personal Web Page. clicks the SEARCH button on the Personal Web Page. 2. The system displays the matching books on the web Page. 3. The CUSTOMER checks for the desired book and clicks on the chosen book icon. chosen book icon. 4. The system displays the book’s detail in the Book Detail web page. 5. The CUSTOMER clicks the REVIEW button on the web page. 6. The system displays the Review Book web page. 7. The CUSTOMER clicks on the desired star button and the click the OK button on the web page. OK button on the web page. 8. The system calculates the overall rating of the book and updates the Book table in the database. Book table in the database. 9. The system displays the Book Detail web pages that have been updated. updated. Objects? Objects? Diagram? Diagram?

83. 83 The class diagram that was built before needs to be changed in order to reflect the changes that took place. The class diagram that was built before needs to be changed in order to reflect the changes that took place. We need to add the boundary objects into the class diagram, and also the relationships between the old objects and the added ones. We need to add the boundary objects into the class diagram, and also the relationships between the old objects and the added ones. Each operations performed in the sequence diagram must be shown in the respective classes Each operations performed in the sequence diagram must be shown in the respective classes Each data entered must also be shown in the respective classes Each data entered must also be shown in the respective classes

84. 84 The objects identified: - The objects identified: - Entity objects: Entity objects: Account, Customer, Book, Used Book, Order, Review Account, Customer, Book, Used Book, Order, Review Boundary objects Boundary objects Home Page, Log-in Page, Register Page, Invoice Page, Delivery Page, Used Book Page, Confirm Page, Book Detail Page and Review Page Home Page, Log-in Page, Register Page, Invoice Page, Delivery Page, Used Book Page, Confirm Page, Book Detail Page and Review Page The modified class diagram The modified class diagrammodified class diagrammodified class diagram

85. 85

86. The End