System Sequence Diagrams. CSC 440: Software Engineering Slide #1

Transcription

1 System Sequence Diagrams CSC 440: Software Engineering Slide #1

2 Topics 1. Objectives 2. What is a SSD? 3. Notation 4. SSDs and Use Cases CSC 440: Software Engineering Slide #2

3 What is a SSD? A quick and easily created artifact that illustrates input and output events related to systems under discussion UML provides Sequence Diagrams SSDs are Sequence Diagrams used to illustrate a use case scenario where an external actor interacts with system. An SSD describes what a system does, not how it does it. CSC 440: Software Engineering Slide #3

4 What is a SSD? SSD shows for one scenario of a use case: Events generated by external actors Time ordering of events Inter-system events System viewed as a black box Internal objects not shown Emphasis on events that cross boundary from actors to systems CSC 440: Software Engineering Slide #4

5 SSDs in the Unified Process Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use-Case Model Vision Requirements Cashier Process Sale Use Case Diagram use case names Process Sale 1. Customer arrives Cashier makes new sale Use Case Text system events parameters and return value details Glossary System Sequence Diagrams : System Operation: enteritem( ) Post-conditions: -... Operation Contracts system operations : Cashier make NewSale() enteritem (id, quantity) System Sequence Diagrams Supplementary Specification starting events to design for : Register Design Model : ProductCatalog : Sale Design enteritem (itemid, quantity) spec = getproductspec( itemid ) addlineitem( spec, quantity )

6 When to draw SSDs Draw a SSD for 1. Basic flow of every use case 2. Commonly used or complex alternate scenarios CSC 440: Software Engineering Slide #6

7 How to draw SSDs 1. Describe only one scenario of a use case. 2. Name system events based on intentions, not on software implementation. authenticate vs. enterpassword selectitem vs. clickitemindropdownlist 3. Start system event names with verbs. 4. Include interactions with external systems. better name : Cashier enteritem(itemid, quantity) :System worse name scan(itemid, quantity) CSC 440: Software Engineering Slide #7

8 SSD for Process Sale UC system as black box the name could be "NextGenPOS" but "System" keeps it simple the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML external actor to system Process Sale Scenario : Cashier :System makenewsale a UML loop interaction frame, with a boolean guard expression loop [ more items ] enteritem(itemid, quantity) description, total return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned endsale total with taxes makepayment(amount) change due, receipt a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism CSC 440: Software Engineering Slide #8

9 Notation Participant: The objects and actors which interact in the sequence diagram. Object: An instance of class denoted by a rectangle containing the name of the object, which is underlined and preceded by a : Actor: An actor is modeled by a stick figure and labeled by the role the actor is performing in the sequence diagram. CSC 440: Software Engineering Slide #9

10 Notation Message: Messages are indicated by solid horizontal lines ending in arrow labeled with the name of the message and its parameters in () s Return Message: Return messages are responses to messages denoted by horizontal dashed arrow lines. Optional. CSC 440: Software Engineering Slide #10

11 Notation Lifeline: The lifetime of an object in a sequence diagram is denoted by a dotted vertical line. Iteration: Some messages may be sent multiple times. Iteration is denoted by a box around the iterated messages and an iteration marker *[ ] which explains the iteration condition. CSC 440: Software Engineering Slide #11

12 System Boundary Need to find system boundary to identify SSD actors and to find system events. : Cashier makenewsale() :System For SSDs, the system boundary is the software system itself, possibly including relevant hardware. enteritem(itemid, quantity) endsale() makepayment(amount) system boundary CSC 440: Software Engineering Slide #12

13 SSDs and Use Cases SSDs are generated from inspecting use cases Find external actors in use case that directly interact with system ex: Process Sale Customer interacts with Cashier, not system Cashier interacts directly w/ system CSC 440: Software Engineering Slide #13

14 SSDs and Use Cases Process Sale Scenario : Cashier :System Simple cash-only Process Sale scenario: makenewsale 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.... loop [ more items ] enteritem(itemid, quantity) description, total endsale total with taxes makepayment(amount) change due, receipt CSC 440: Software Engineering Slide #14

15 SSDs within the UP 1. Visualization of interactions implied in use cases 2. Created in Elaboration Phase to Identify major operations Write system operation contracts 3. Not necessary to create SSDs for every scenario CSC 440: Software Engineering Slide #15