Lecture 4 USE Case Model Sequence Diagram Systems

Lecture 4 : USE Case Model( Sequence Diagram) Systems Analysis & Design CT 1414 * Nouf Aljaffan 25/05/2021 The College Of Applied Studies And Community Services Instructor: Nouf Aljaffan 1 February 2012

25/05/2021 SSD Definition SSD Notation Developing a System Sequence Diagram CASE STUDY OUTLINE CT 1414 * Nouf Aljaffan 1. 2. 3. 4. 2

UML Framework 3 CT 1414 * Nouf Aljaffan 25/05/2021

4 CT 1414 * Nouf Aljaffan 25/05/2021

• Before proceeding to a logical design of how a software application will work, we should investigate and define the system behavior as a "black box“. CT 1414 * Nouf Aljaffan • A system sequence diagram is a fast and easily created artifact that illustrates input and output events related to the systems under discussion 25/05/2021 Introduction – System Sequence Diagram 5

• During this interaction an actor generates events to a system, usually requesting some operation in response. For example, when a cashier enters an item's ID, the cashier is requesting the POS system to record that item's sale. That request event initiates an operation upon the system. CT 1414 * Nouf Aljaffan • Use cases describe how external actors interact with the software system. 25/05/2021 System Event and Response 6

• The emphasis of the diagram is events that cross the system boundary from actors to systems. • An SSD should be done for the main success scenario of the use case, and frequent or complex alternative scenarios. • An SSD is generated from inspection of a use case Suggestion: • One SSD – one Use Case CT 1414 * Nouf Aljaffan • A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events. 25/05/2021 System sequence diagram 7

Identifying Inputs and Outputs — the System Sequence Diagram • Identifies interaction between actors and system • Message oriented CT 1414 * Nouf Aljaffan • Describes flow of information 25/05/2021 • System sequence diagram (SSD) 8

object • Indicates sequence of the messages sent/received • If vertical line dashed • Creation and destruction of thing is not important for scenario • Long narrow rectangles CT 1414 * Nouf Aljaffan • Actor “interacts” with the system via input/output • SSDs use object notation • Box (rectangle) refers to individual object • Name of the object underlined • Lifeline • is a vertical line under object or actor to show passage of time for 25/05/2021 SSD Notation • Activation lifelines emphasize that object is active only during part of scenario • Message is labeled on arrows to show messages sent to or received by actor or system 9

25/05/2021 CT 1414 * Nouf Aljaffan Figure 6 -14 Sample System Sequence Diagram 10

SSD Notation (continued) • Message semantics: actions (like commands) invoked on destination object • Complete message notation: *[true/false condition] returnvalue : = message-name (parameter-list) CT 1414 * Nouf Aljaffan • Depends on send/return direction 25/05/2021 • Message syntax can take several forms 11

25/05/2021 CT 1414 * Nouf Aljaffan Figure 6 -15 Repeating Message (A) Detailed Notation (B) Alternate Notation 12

Developing a System Sequence Diagram • Activity diagrams ( out of our subject) • (4) step process for turning activity diagram or UC Description into SSD • [1] Identify the input messages • [2] Describe messages from external actor to system • [3] Identify/apply special conditions to input messages • [4] Identify and add the output return messages CT 1414 * Nouf Aljaffan • Fully developed form 25/05/2021 • Begin with detailed description of use case 13

Activity Diagram and Resulting SSD for Telephone Order Scenario 14

CT 1414 * Nouf Aljaffan • Simple cash-only Process Sale scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3 -4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. . 25/05/2021 Case Study: How to do SSD in the POS Project 15

25/05/2021 CT 1414 * Nouf Aljaffan Step 1: Define System Events and the System Boundary the system boundary is usually chosen to be the software system itself; in this context, a system event is an external event that directly stimulates the software 16

25/05/2021 CT 1414 * Nouf Aljaffan Step 2: Naming System Events and Operations 17

CT 1414 * Nouf Aljaffan • Simple cash-only Process Sale scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3 -4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. . 25/05/2021 Step 3: show Use Case 18

Step 4: Do SSD 19 CT 1414 * Nouf Aljaffan 25/05/2021

SSD of UC - Process Sale 20 CT 1414 * Nouf Aljaffan 25/05/2021

CT 1414 * Nouf Aljaffan • Complete use case diagram is needed to understand total scope of new system • Domain model class diagrams should also be as complete as possible for entire system • With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration • Development of a new diagram often helps refine and correct previous diagrams 25/05/2021 Integrating Object-Oriented Models 21

22 CT 1414 * Nouf Aljaffan 25/05/2021

25/05/2021 CT 1414 * Nouf Aljaffan Relationships Between OO Requirements Models 23