Chapter 5 Systems Analysis and Design in a Changing World, 7th Edition

Chapter 5 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 5 2016. Cengage Learning. All rights reserved. 1

Use Case Modeling Chapter 5 Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 2

Chapter 5: Outline Use Case Descriptions Activity Diagrams for Use Cases The System Sequence Diagram—Identifying Inputs and Outputs SSD Notation Use Cases and CRUD Integrating Requirements Models Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 3

Learning Objectives Write fully developed use case descriptions Develop activity diagrams to model flow of activities Develop system sequence diagrams Use the CRUD technique to validate use cases Explain how use case descriptions and UML diagrams work together to define functional requirements Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 4

Overview (1 of 2) Chapters 3 and 4 identified and modeled the two primary aspects of functional requirements: use cases and domain classes This chapter focuses on detail modelling for use cases to document the internal steps within a use case Fully developed use case descriptions provide information about each use case, including actors, stakeholders, preconditions, post conditions, the flow of activities and exceptions conditions Activity diagrams (first shown in Chapter 2) can also be used to show the flow of activities for a use case Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 5

Overview (2 of 2) System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages CRUD analysis, which correlates problem domain classes and use cases, is an effective technique to double check that all required use cases have been identified Not all use cases are modelled at this level of detail. Only model when there is complexity and a need to communicate details Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 6

Use Case Descriptions (1 of 2) Write a brief description as shown in Chapter 3 for most use cases. Use case Brief use case description Create customer account User/actor enters new customer account data, and the system assigns account number, creates a customer record, and creates an account record. User/actor enters customer number, and the system retrieves and displays customer and account data. User/actor enters order number, and the system retrieves customer and order data; actor enters adjustment amount, and the system creates a transaction record for the adjustment. Look up customer Process account adjustment Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 7

Use Case Descriptions (2 of 2) Write a fully developed use case description for more complex use cases Typical use case description templates include: Use case name Scenario (if needed) Triggering event Brief description Actors Related use cases ( includes ) Stakeholders Preconditions Postconditions Flow of activities Exception conditions Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 8

Fully Developed Use Case Description: Use case: Create customer account Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 9

Fully Developed Use Case Description Create customer account (part 1) Use case name: Scenario: Triggering event: Brief description: Actors: Related use cases: Stakeholders: Preconditions: Postconditions: Create customer account. Create online customer account. New customer wants to set up account online. Online customer creates customer account by entering basic information and then following up with one or more addresses and a credit or debit card. Customer. Might be invoked by the Check out shopping cart use case. Accounting, Marketing, Sales. Customer account subsystem must be available. Credit/debit authorization services must be available. Customer must be created and saved. One or more Addresses must be created and saved. Credit/debit card information must be validated. Account must be created and saved. Address and Account must be associated with Customer. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 10

Fully Developed Use Case Description Create customer account (part 2) Flow of activities: blank Actor System 1. Customer indicates desire to create customer account and enters basic customer information. 2. Customer enters one or more addresses. 1.1 System creates a new customer. 1.2 System prompts for customer addresses. 3. Customer enters credit/debit card information. Exception conditions: 1.1 Basic customer data are incomplete. 2.1 The address isn’t valid. 3.2 Credit/debit information isn’t valid. 2.1 System creates addresses. 2.2 System prompts for credit/debit card. 3.1 System creates account. 3.2 System verifies authorization for credit/debit card. 3.3 System associates customer, address, and account. 3.4 System returns valid customer account details. Blank Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 11

Use Case Description Details (1 of 2) Use case name Verb-noun Scenario (if needed) A use case can have more than one scenario (special case or more specific path) Triggering event Based on event decomposition technique Brief description Written previously when use case was identified Actors One or more users from use case diagrams Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 12

Use Case Description Details (2 of 2) Related use cases includes If one use case invokes or includes another Stakeholders Anyone with an interest in the use case Preconditions What must be true before the use case begins Post conditions What must be true when the use case is completed Use for planning test case expected results Flow of activities The activities that go on between actor and the system Exception conditions Where and what can go wrong Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 13

Another Fully Developed Use Case Description Example: Use case Ship items Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 14

Fully Developed Use Case Description Ship items (part 1) Use case name: Ship items. Scenario: Ship items for a new sale. Triggering event: Shipping is notified of a new sale to be shipped. Brief description: Shipping retrieves sale details, finds each item and records it is shipped, records which items are not available, and sends shipment. Actors: Shipping clerk. Related use cases None. Stakeholders: Sales, Marketing, Shipping, warehouse manager. Preconditions: Customer and address must exist. Sale must exist. Sale items must exist. Postconditions: Shipment is created and associated with shipper. Shipped sale items are updated as shipped and associated with the shipment. Unshipped items are marked as on back order. Shipping label is verified and produced. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 15

Fully Developed Use Case Description Ship items (part 2) Flow of activities: blank Actor System 1. Shipping requests sale and sale item information. 1.1 System looks up sale and returns customer, address, sale, and sales item information. 2. Shipping assigns shipper. 3. For each available item, shipping records item is shipped. 4. For each unavailable item, shipping records back order. 3.1 System updates sale item as shipped and associates it with shipment. 5. Shipping requests shipping lablel supplying package size and weight. 4.1 System updates sale item as on back order. 2.1 System creates shipment and associates it with the shipper. 5.1 System produces shipping label for shipment. 5.2 System records shipment cost. Exception conditions: 2.1 Shipper is not available to that location, so select another. 3.1 If order item is damaged, get new item and updated item quantity. 3.1 If item bar code isn’t scanning, shipping must enter bar code manually. 5.1 If printing label isn’t printing correctly, the label must be addressed manually. blank Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 16

UML Activity Diagram for Use Case: Create Customer Account Note: this shows flow of activities only Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 17

Activity Diagram for Ship Items Use Case Note: Synchronization bar for loop Decision diamond Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 18

UML Activity Diagram for Use Case: Fill shopping cart Note: this shows use case with includes relationship Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 19

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 begin underline end underline Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 20

System Sequence Diagram (SSD) Notation Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 21

SSD Message Examples with Loop Frame Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 22

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 – Chapter 5 2016. Cengage Learning. All rights reserved. 23

SSD Message Examples Opt Frame (optional) Alt Frame (if-else) Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 24

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 On message itself: aValue: getValue(valueID) As explicit return on separate dashed line Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 25

SSD for Create customer account Use case Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 26

SSD for Ship items Use Case Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 27

Use Cases and CRUD CRUD technique – Create Read/Report Update Delete A good cross-check against the existing set of use cases. Used in database context Ensure that all classes have a complete “cover” of use cases Not for primary identification of use cases Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 28

Verifying use cases for Customer Data entity/domain class Customer BLANK CRU D Create Read/report BLANK Update BLANK Delete Verified use case Create customer account Look up customer Produce customer usage report Process account adjustment Update customer account Update customer account (to archive) Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 29

CRUD Analysis: Steps 1. Identify all domain classes 2. For each class verify that use cases exist to Create a new instance Update existing instances Reads or reports on information in the class Deletes or archives inactive instances 2. Add new use cases as required. Identify responsible stakeholders 3. Identify which application has responsibility for each action: which to create, which to update, which to use Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 30

Sample CRUD Matrix Use case vs. entity/domain class Create customer account Look up customer Produce customer usage report Process account adjustment Update customer account Customer Account Sale Adjustment C R R R UD (archive) C R R U UD (archive) BLANK R R BLANK BLANK BLANK C BLANK Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 31

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 State machine diagram Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 32

Integrating Requirements Models Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 33

Summary (1 of 2) Chapters 3 and 4 identified and modeled the two primary aspects of functional requirements: use cases and domain classes This chapter focuses on models to provide details of use cases Fully developed use case descriptions provide information about each use case, including actors, stakeholders, preconditions, post conditions, the flow of activities and exceptions conditions Activity diagrams (first shown in Chapter 2) can also be used to show the flow of activities for a use case Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 34

Summary (2 of 2) System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages CRUD analysis serves to verify that all domain classes are fully supported by the new system, i.e. have use cases to fully process all required actions Not all use cases and domain classes are modelled at a detailed level. Only model when there is complexity and a need to communicate details. All of the models must be consistent and integrate together to provide a complete picture of the requirements and specification. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 35

RTGM System Use Cases Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 2016. Cengage Learning. All rights reserved. 36