1 Chapter 8 System Sequence Diagrams Chapter 9

1 Chapter 8: System Sequence Diagrams Chapter 9 in Applying UML and Patterns Book.

2 Overview Identify Create System Events. System Sequence Diagrams “SSD” for the events.

3 System Behavior It is useful to investigate and define the behavior of the software as a “black box”. System behavior is a description of what the system does (without an explanation of how it does it). Use cases describe how external actors interact with the software system. During this interaction, an actor generates events. A request event initiates an operation upon the system. System event are external input event generated by an external actor and indicates an operation that should be performed.

4 System Sequence Diagram - SSD A sequence diagram is a picture that shows, for a particular scenario of a use case, 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 typical course of events of a use case and for the most interesting alternative courses. System Sequence Diagrams provide a way to visually step through invocation of the operations defined by Use-Cases. It is not necessary to create SSDs for all scenarios of all use-cases, at least not at the same time.

5 Example: Borrow Resource Use Case Typical course of events

6 Example: Borrow Resource Use Case Typical course of events (cont. ) Alternatives: Line 4. If the Patron card is invalid, do not allow borrowing. Line 5. If the Resource is missing a call number, set it aside for repair and do not allow borrowing.

7 Example: Borrow Resource Use Case SSD

8 How to draw System Sequence Diagram ? 1. Draw a line representing the system as a black box. 2. Identify each actor that directly operates on the system. Draw a line for each such actor. 3. From the use case, typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the right hand side of the typical use case. Illustrate them on the diagram. 4. Optionally, include the use case text to the left of the diagram.

9 Naming System Events and Operations System events and their associated system operations should be expressed at the level of intent rather than in terms of the physical input medium or widget. In order to improve the clarity, it is appropriate to start the name of the system event with a verb (for example: add…. , enter…. , end…. , make…, etc. ). It also emphasizes the command origination of these events.

10 Example: Buy Item Use Case Typical course of events

11 Example: Buy Item Use Case Naming System Events and Operations The set of all required system operations is determined by identifying the system events. Ø make. New. Sale() Ø add. Line. Item(item. ID, quantity) Ø end. Sale() Ø make. Payment(amount)

12 Example: Buy Item Use Case Naming System Events and Operations (cont. )

13 Example: Buy Item Use Case SSD

14 Example: Buy Item Use Case SSD (cont. )

15 Example: Buy Item Use Case Typical course of events for Pay By Credit Section

16 Example: Buy Item Use Case SSD for Pay by Credit Section

17 Class Activity: Draw the SSD for the “Enroll in course” Use Case Actor Action System Response 1. This use case begins when a student asks to enroll in a specific course(s). 2. The clerk asks the student to complete an enrollment request. 3. The student provides registration information. 4. The clerk records the student's registration information. 5. The System verifies that all the required information presents and calculates the fees. 6. The student pay the fees. 7. The clerk make the payment. 9. The student leaves with the registration confirmation. 8. The system confirms the registration.