Today s Agenda UML Sequence Diagrams Software Requirements Specification

Today’s Agenda UML Sequence Diagrams SE1: Software Requirements Specification and Analysis Lecture 5B These diagrams are a graphical representation of a scenario. Sequence Diagrams Reading: Blaha and Rumbaugh, Ch. 7.2. 8.2 U Waterloo SE1 (Fall 2007) – p.1/18 U Waterloo SE1 (Fall 2007) – p.2/18 Review: Use Case Diagrams Review: Use Case Descriptions Use cases are informal descriptions of the system’s basic functionality and its environment – used to facilitate understanding of the system’s requirements. A use case diagram provides a global view of all the system’s functions. It shows the boundary of the system the relationships between actors and use cases the relationships between use cases (e.g., include ) U Waterloo SE1 (Fall 2007) – p.4/18 U Waterloo SE1 (Fall 2007) – p.3/18 System Sequence Diagrams s: caller :telephone t:callee Dynamic view of system behaviour lift receiver Time-ordered sequence of messages Usually, depicts a scenario dial tone dial(digits) route call Similar to use cases, but Shows the sequence of cross-boundary communication rather than the sequence of actions Describes end-to-end behaviour Shows environmental input and system response establish conn Easy for users to understand ring phone ring tone answer stop ringing stop ring tone hangup disconnect U Waterloo SE1 (Fall 2007) – p.5/18 U Waterloo SE1 (Fall 2007) – p.6/18 Sequence Diagrams: Notation Basic Features Each column represents the lifeline of a domain object or the system column label is “name:entity” (name is optional) Sequence Diagrams: Notation Basic Features Horizontal arrow represents an event conveyed by source to target. A filled arrowhead represents a synchronous message The sender blocks until the recipient responds A rectangle on a lifeline is an activation bar Also called focus of control It’s the period during which the object is involved in the activity initiated at the top of the bar. “Call” to self can be shown as a nested focus of control A stick arrowhead represents an asynchronous message The sender carries on after sending the message Common in concurrent systems Dashed horizontal arrow represents transfer of control (return) without data. U Waterloo SE1 (Fall 2007) – p.7/18 U Waterloo SE1 (Fall 2007) – p.8/18 Elaborating Sequence Diagrams As we elaborate the domain model and specify in more detail the domain entities that the system senses and controls, the self calls become messages to these domain entities Some of these are transient entities that exist (conceptually) only during a system interaction. Create transient objects in response to a create ring tone s :caller lift receiver dial tone *dial(digit) Example :exchange t :callee route call <> :Connection ring phone answer Destroy transient objects either because it receives a destroys itself destroy message or because it stop ring tone disconnect disconnect stop ringing hangup U Waterloo SE1 (Fall 2007) – p.9/18 U Waterloo SE1 (Fall 2007) – p.10/18 Interaction Frames Interaction frames help to structure subsequences of events, enabling the modelling if, loop, parallelism constructs, etc. Basic idea: A box covers fragment of a sequence diagram The box is labelled at the top left with an operator name Depending on the operator kind: The box may be divided into several sections Each section may have a guard (boolean expression) Example of Loop U Waterloo SE1 (Fall 2007) – p.11/18 U Waterloo SE1 (Fall 2007) – p.12/18 Interaction Frame Operators Operator loop opt alt par ref Meaning Execute events inside box; guard controls iteration Like a simple if stmt; execute if guard is true Like a cascading if stmt; execute first body whose guard is true Execute fragments in parallel Refers to an interaction defined in another diagram (like a method call). Hides the details, but can have parameters and a return value The sequence diagram shows an invalid (negative) interaction Surrounds an entire sequence diagram (for inclusion in other kinds of diagrams) U Waterloo SE1 (Fall 2007) – p.13/18 Another Example neg sd U Waterloo SE1 (Fall 2007) – p.14/18 Sequence Diagrams Can be used for different levels of description: System level: Show system as one lifeline Show only environmental inputs and outputs Concept/object level (design-level): Show each system object involved in the scenario as one lifeline Show interaction among system objects and therefore show responsibilities of each class Don’t use the latter in this course! Advice For each use case, create a system sequence diagram for the main scenario. One lifeline for the system; one for each actor. Show inputs and outputs. U Waterloo SE1 (Fall 2007) – p.15/18 U Waterloo SE1 (Fall 2007) – p.16/18 Example Summary UML sequence diagram Sequence diagrams illustrate the communication between the system and the environment, for one scenario (and maybe some variants) Next Lecture: Domain Modelling (UML Class Diagrams) Reading: Blaha and Rumbaugh, Ch. 3-3.4, 4.4 U Waterloo SE1 (Fall 2007) – p.17/18 U Waterloo SE1 (Fall 2007) – p.18/18