Use Case Driven Development

1

CSCD01

Sommerville 9ed, S. Easterbrook

● User StoriesUsed in XP, Scrum, etc.

Identify the user (role) who wants it

Typically written on notecards

● StoryboardsSketch of how a user will do a task

Shows the interactions at each step

Commonly used in UI Design

● Use CasesSets of user features

UML diagram shows inter-relationships

What do users want?

ICONIX process

Domain model

AnalyseRisks

Update Accounts

SetLimits

Price aDeal

Capture aDeal

Trader

Use Case Diagram

Tradingmanager

AccountingSystem

Salesperson

Value a Deal

<<includes>>

<<includes>>

<<extends>>

Check CampaignBudget

Print Campaign Summary

<<uses>>Find Campaign

Relationships between Use Cases

● <<extends>> when one use case adds behaviour to a base caseused to model a part of a use case that the user may see as optional system behavior;

also models a separate sub-case which is executed conditionally.

● <<uses>>: one use case invokes another (like a procedure call);used to avoid describing the same flow of events several times

puts the common behavior in a use case of its own.

Fowler suggests: use only << include>>

Using Generalizations● Actor classes

Identify classes of actorWhere several actors belong to a single class

Some use cases are needed by all members in the class

Other use cases are only needed by some members of the class

Actors inherit use cases from the class

● Use Case classesSometimes useful to identify a generalization of

several use cases

How to Write a Use Case: The Three Magic Questions

● What happens?● This gets your “sunny-day scenario” started.

● And then what happens?● Keep asking this question until your “sunny-day scenario”

is complete.

● What else might happen?● Keep asking this one until you’ve identified all the “rainy-

day scenarios” you can think of, and described the related behaviour.

Describing Use Cases

• For each use case:

– a “flow of events” document, written from an actor’s point of view.

– describes what the system must provide to the actor when the use case is executed.

• Typical contents

– How the use case starts and ends

– Normal flow of events

– Alternate flow of events

– Exceptional flow of events

10

Describing Use Cases

• Documentation style: Choice of how to elaborate the use case:

English language description Activity Diagrams - good for business process Collaboration Diagrams - good for high level design Sequence Diagrams - good for detailed design

11

Detailed Use Case

Buy a Product

Main Success Scenario:1. Customer browses catalog and selects items to buy2. Customer goes to check out3. Customer fills in shipping information (address, next-day or 3-day delivery)4. System presents full pricing information5. Customer fills in credit card information6. System authorizes purchase7. System confirms sale immediately8. System sends confirming email to customer

Extensions:3a: Customer is Regular Customer

.1 System displays current shipping, pricing and billing information

.2 Customer may accept or override these defaults, returns to MSS at step 66a: System fails to authorize credit card

.1 Customer may reenter credit card information or may cancel

Buy a Product

Main Success Scenario:1. Customer browses catalog and selects items to buy2. Customer goes to check out3. Customer fills in shipping information (address, next-day or 3-day delivery)4. System presents full pricing information5. Customer fills in credit card information6. System authorizes purchase7. System confirms sale immediately8. System sends confirming email to customer

Extensions:3a: Customer is Regular Customer

.1 System displays current shipping, pricing and billing information

.2 Customer may accept or override these defaults, returns to MSS at step 66a: System fails to authorize credit card

.1 Customer may reenter credit card information or may cancel

The context of the MHC-PMS

13Sommerville 9ed

Transfer-data use case

A use case in the MHC-PMS

14Sommerville 9ed

Tabular description of the ‘Transfer data’ use-case

MHC-PMS: Transfer dataActors Medical receptionist, patient records system (PRS)Description A receptionist may transfer data from the MHC-PMS to a

general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment.

Data Patient’s personal information, treatment summaryStimulus User command issued by medical receptionistResponse Confirmation that PRS has been updatedComments The receptionist must have appropriate security

permissions to access the patient information and the PRS.

15Sommerville 9ed

Use cases in the MHC-PMS involving the role ‘Medical Receptionist’

16Sommerville 9ed

Sequence diagram for View patient information

17Sommerville 9ed

Sequence diagram for Transfer Data

18Sommerville 9ed

Describing Use Cases Exercise

You need to re-design an Internet Bookstore. From talking to your customer you gather the following information.

– There are categories of books.

– Users should be able to read and write book reviews.

– There are also editorial reviews.

– Users should be able to rate books.

– The customer uses the term “line item”.

– Books are organized in catalogs. A master book catalog contains all books information.

– Customer talks about prices of books and/or line items.

19