Class Notes Week 7 PDF

Outline ⚫ The System Sequence Diagram— Identifying Inputs and Outputs ⚫ Integrating Requirements Models Systems Analysis and Design in a Changing World, 6th Edition 1 The System Sequence Diagram Draw a system sequence diagram for each use case scenario. System Sequenc...

Outline ⚫ The System Sequence Diagram— Identifying Inputs and Outputs ⚫ Integrating Requirements Models Systems Analysis and Design in a Changing World, 6th Edition 1 The System Sequence Diagram Draw a system sequence diagram for each use case scenario. System Sequence Diagram A system sequence diagram shows the interaction between an actor and the system for one use case scenario. It shows: ⚫ The system (as a black box) ⚫ The initiating actor ⚫ Each external system which sends messages to the system ⚫ The messages into and out of the system ⚫ The sequence in which the messages occur System Sequence Diagram (SSD) ⚫ A UML sequence diagram ⚫ Special case for a sequence diagram ⚫ Only shows actor and one object ⚫ The one object represents the complete system ⚫ Shows input & output messaging requirements for a use case ⚫ Actor, :System, object lifeline ⚫ Messages Systems Analysis and Design in a Changing World, 6th Edition 4 System Sequence Diagram (SSD) Notation Systems Analysis and Design in a Changing World, 6th Edition 5 System Sequence Diagram (continued) A system sequence diagram focuses on the content and structure of the system input. It should show whether any messages are repeated or are alternatives. A system sequence diagram is not the place to show the design of the detailed interaction between the user and the system. Message Formats in System Sequence Diagrams The UML format for a message consists of a message name followed (in parentheses) by a parameter list. All names begin with a lower-case letter. There are no spaces in a name. Upper-case letters separate the words within a name. Names in the parameter list are separated by commas. Even if there are no parameters an empty () is used Outgoing Messages (System Outputs) There are two types of outgoing messages: ⚫ A response of the system which completes an event. ⚫ A message from the system to an external system requesting action and a reply. Remember that every output must be derivable from the input to the use case combined with stored data. SSD Message Examples with Loop Frame Systems Analysis and Design in a Changing World, 6th Edition 9  Message Notation for SSD ⚫ [true/false condition] return-value := message-name (parameter- list) ⚫ An asterisk (*) indicates repeating or looping of the message ⚫ Brackets [ ] indicate a true/false condition. This is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message isn’t sent. ⚫ Message-name is the description of the requested service written as a verb- noun. ⚫ Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. ⚫ Return-value on the same line as the message (requires :=) is used to describe data being returned from the destination object to the source object in response to the message. Systems Analysis and Design in a Changing World, 7th edition – 10 Chapter 5 ©2016. Cengage SSD Message Examples Opt Frame (optional based on Yes/No condition) Alt Frame (if-Then-else) Systems Analysis and Design in a Changing World, 6th Edition 11 Steps for Developing SSD 1. Identify input message ⚫ See use case flow of activities or activity diagram 2. Describe the message from the external actor to the system using the message notation ⚫ Name it verb-noun: what the system is asked to do ⚫ Consider parameters the system will need 3. Identify any special conditions on input messages ⚫ Iteration/loop frame ⚫ Opt or Alt frame 4. Identify and add output return values ⚫ As explicit return on separate dashed line or ⚫ On message itself: aValue:= getValue(valueID) Systems Analysis and Design in a Changing World, 6th Edition 12 SSD for Create customer account Use case Systems Analysis and Design in a Changing World, 6th Edition 13 SSD for Ship items Use Case Note : getNextSale () has no parameters but () is still used. This notation convention is not universal but we will follow it here. Systems Analysis and Design in a Changing World, 6th Edition 14 A system sequence diagram (SSD) illustrates input and output events. An SSD shows – for one particular scenario of a use case – the events that external actors generate, their order, and inter-system events The system is treated as a black-box SSDs are derived from use cases; SSDs are often drawn for the main success scenarios of each use case and frequent or complex alternative scenarios SSDs are used as input for object design System Events and System Operations System operations are the operations that the system as a black box component off ers in its public interface. These are high-level operations triggered by an external input event / system event generated by an external actor During system behavior analysis, system operations are assigned to a conceptual class System NOTE: In the following example when a message has no parameters no brackets are shown. As noted earlier this is not a convention we are following. E.g. not makeNewSale but makeNewSale () Example of an SSD for the Process Sale Scenario System Sequence Diagram | 7 Use Case: Process Sale Scenario - Main Success Story 1. Cashier starts new sale 2. Cashier enters item identifier 3. System records sale line item and presents item description, price and running total Steps 2 and 3 are repeated until all items are processed. 4. System presents total with taxes calculated 5. Cashier tells Customer the total and asks for payment 6. Customer pays and System handles payment Example of an SSD for the Process Sale Scenario SSDs are drawn using UML’s sequence diagram notation. The name of each event should state the intention (e.g. “enterItem(itemId)” vs. “scan(itemId)”). Communication Partners Process S ale S cenario Message :Cashier :System makeNewS ale Order enterItem(itemId, quantity) description, price, total endSale total with taxes makePayment (amount) change due, receipt Example of an SSD for the Process Sale Scenario SSDs are drawn using UML’s sequence diagram notation. The name of each event should state the intention (e.g. “enterItem(itemId)” vs. “scan(itemId)”). Process Sale Scenario :Cashier :System makeNewSale an external actor to the system a message with parameters enterItem(itemId, quantity) description, price, total endSale total with taxes return value(s) (optional if nothing is returned) makePayment (amount) change due, receipt Example of an SSD for the Process Sale Scenario Use Case: Process Sale Scenario - Main Success Story 1. Cashier starts new sale 2. Cashier enters item identifier 3. System records sale line item and presents item description, price and running total Steps 2 and 3 are repeated until all items are processed. 4. System presents total with taxes calculated 5. Cashier tells Customer the total and asks for payment 6. Customer pays and System handles payment Example of an SSD for the Process Sale Scenario Use Case: Process Sale Scenario - Main Success Story 1. Cashier starts new sale 2. Cashier enters item identifier 3. System records sale line item and presents item description, price and running total Steps 2 and 3 are repeated until all items are processed. 4. System presents total with taxes calculated 5. Cashier tells Customer the total and asks for payment 6. Customer pays and System handles payment Visualizing SSDs - Excerpt From the POS Domain Process Sale Scenario :Cashier :System loop [more items] enterItem(itemId, quantity) description, price, total “Complete” SSD for the Process Sale Scenario Process Sale Scenario :Cashier :System makeNewSale loop [more items] enterItem(itemId, quantity) description, price, total endSale total with taxes makePayment (amount) change due, receipt Drawing UML diagrams is a reflection of making decisions about the design. What matters are the fundamental object design skills - not knowing how to draw UML. Extending and Integrating Requirements Models ⚫ Use cases ⚫ Use case diagram ⚫ Use case description ⚫ Activity diagram ⚫ System sequence diagram (SSD) ⚫ Domain Classes ⚫ Domain model class diagram ⚫ Use Case Realisations Systems Analysis and Design in a Changing World, 6th Edition 25 Integrating Requirements Models Use Case Realizations Systems Analysis and Design in a Changing World, 6th Edition 26