Object Oriented Analysis & Design Use Cases. Object Oriented Analysis & Design Use-Cases: an Example

Object Oriented Analysis & Design

Use Cases


Use-Cases: an Example


Using use cases to describe requirements

• Use cases can show the sets of possible interactions between the system and the people who use it

• Use cases can also show interactions between computer systems

• Use cases can also be used at the subsystem level (to show interactions between subsystems)

register

deleteoffering

create newcourse

My systemStudent

Administrator

Instructor

Example use case diagram

actors use cases


What is a Use Case?• A Use Case captures a contract between the stakeholders of a

system about its behavior. Use cases describes the system’s behavior under various conditions as the system responds to requests from its users (actors) specifying how the actors’ goals get delivered or fail.

• A use case is:– a set of scenarios that describe the behavior of the system and its users– at a high level of detail– with “sunny-day” and “rainy-day” scenarios being defined

• A use case gathers the scenarios related to the (primary) actor’s goal

• Actors are the people and/or computer systems that are outside the system under development (SuD)and interact with it:– Primary actor – a stakeholder who requests that the system deliver a goal– Supporting/secondary actor – an external system against which the SuD

has a goal• Scenarios are dialogs between actors and the system


What is a Use Case (cont)?

• A Use Case is the set of scenarios that provides positive value to one or more external actors

– actors are the people and/or computer systems that are outside the system under development

– scenarios are dialogs between actors and the system

– no information about the internal design


More about Use-Cases

• A use-case is – a set of activities within a system – presented from the point of view of the associated actors– leading to an externally visible result– a (simplified) part of a business process model

• A use defines WHAT is the system supposed to do– not for functional decomposition– simplified and limited graphical notation– other diagrams and text templates used to support it– combined with prototypes


Actors

• An actor is an entity that is outside of the system• Actors will interact with the system:

– an actor will often request the system to perform some actions on behalf of the actor

– an actor may also receive responses from the system• An actor plays a “role” in the use of the system

– the name given to an actor is usually the “role name”: for example, an actor who is a Person will usually be called a User, Operator, Administrator, or something like that

– each role might be treated as a different actor in the use cases


Communication between actors and the system

• In each use case, a “primary actor” starts things off: that actor initiates an interaction with the system

• The system will then respond to messages and might send messages of its own to other actors

• In a use case, the primary actor is trying to achieve a specific goal:

– the use case consists of all the possible interactions that take place in the attempt to reach the goal

– there may be many scenarios in a use case - each scenario shows an alternative “course” that is based on the success or failure of some of the intermediate steps

– the goal might not be reached (because of some of the failures)


Goals

• A goal is a result that one of the actors wants to achieve

• Example goals:

– An administrator wants to add a new user to the system

– A pilot wants to land a plane

– A customer wants to file a claim on an insurance policy

– A service person wants to file a trouble report


Scenarios

• A scenario is a little story

– it is an outline of some expected sequence of events

• A scenario is used to convey the fundamentals of “how things work”

• It usually includes at least one actor

• Each actor can make requests of the system or respond to system activity

That will be $7.40.

Here is $10.

Thanks. Here are your stamps and your change.

Yes.

OK. Will that be all?

I would like a book of stamps, please.


Identifying actors

• An Automated Teller Machine (ATM) permits customers to withdraw money from their accounts, make deposits, and check their account balances. The ATM machine communicates with a computer system in the bank’s central office to validate passwords and account information. The ATM is serviced on a regular basis by bank employees, to collect deposit envelopes and to load in more cash and receipt paper.

• Question: who are the actors in this system?

–

–

–

–


Creating a simple scenario

• Draw a sequence diagram for one of the scenarios in the ATM system. One prominent use case in this system is “customer performs an ATM transaction,” and one scenario in that use case is “customer withdraws money”. Assume we are in the sunny-day scenario.

Customer ATM

1. Customer inserts card???


Scenario - Example

• A scenario is a little story• It describes one possible course of events:

Customer puts ATM card into machine and types passwordSystem validates the card and passwordSystem prompts the customer for a transaction type and amountCustomer selects “withdraw $100 from checking”System checks with the central bank make sure customer has

sufficient fundsSystem dispenses the cash, returns card, and prints receiptSystem asks customer if he/she would like another transaction


Representing Use cases• Text templates:

– Informal text• informal paragraph summary – the paragraph will describe who

starts the scenario, the key actions by the actors and the system, and how to handle failures

• numbered list of steps – in this format, the main scenario is a list of sentences describing the sequence of actions by each actor and/or the system; failure scenarios can be written as branch scenarios at the end

– Tables – informal text– Structured templates – one popular example (A. Cockburn)– Structured (“semi-formal”) DOORS template

• Graphical formats:– UML Use Case diagrams capturing the system boundary,

use cases(names), actors, channels and use case relationships

– UML Sequence Diagrams (also known as message sequence charts, MSC) to represent scenarios


Showing a scenario in text format …

• A scenario can be written as a series of sentences:– each sentence shows one step of the scenario– each step needs to explain

• who does the operation• what operation is performed• when the operation is performed• are there any side conditions?

– one important thing that is not included in the description of each step of a scenario: how the operation is performed (this is left for the design phase)

• Important style points:– each step in the scenario must have a subject (either the system or an

actor is performing the step)– no passive or impersonal voice allowed (e.g., “the results are

displayed”)


Example of a text format scenario

Customer buys a single item:1. Customer asks for an item2. Postal clerk acknowledges customer request, checks if the

requested item is available3. Postal clerk asks the Customer if there will be anything else in

this transaction4. Customer indicates that they don’t want anything else5. Postal clerk determines the price of the requested items and

tells the customer6. Customer pays7. Postal clerk gives the Customer the items and change

• Note: this is not yet a use case, just a single scenario.


Showing a scenario in graphical form

• Scenarios can be shown in a standard graphical notation – this notation has many different names

– Sequence diagram, Event trace diagram, Interaction diagram, Fence post diagram

Acknowledge request

Postal clerkCustomer

No

Anything else?

Respond with price

Give item and change

Give money

Ask for item


Writing a use case

Step 1: Pick one of the potential goals of one of the actorsStep 2: Write down the preconditions for that goalStep 3: Write the “sunny-day” scenario for the interaction

between actors and systemStep 4: Identify the possible failures at each step - think about

the alternative scenarios that might resultStep 5: For the main failure situations, either create entire

scenarios or create extensions of the main scenariooptional step: Find common chunks that occur in several

scenarios that can be factored out to make the scenarios simpler


Example use case

Use case name: Ticket Buyer buys a lottery ticketPrimary actor: Ticket BuyerPrecondition: Ticket Buyer has $1Main scenario: 1. Ticket Buyer tells the system (person or machine) that he/she wants to buy a ticket 2. System asks the Ticket Buyer for his/her choice of lucky number 3. Ticket Buyer chooses a number 4. System asks for $1 5. Ticket Buyer supplies $1 6. System prints a lottery ticket and gives it to the Ticket BuyerVariations: 2. Ticket Buyer chooses a number: 2a. using keypad 2b. fills in circles on card 2c. asks for a “quick pick”


Example use case - scenario

Ticketbuyer

Ticketmachine

Sell me a ticket

Prompt for lucky number

Number choice

Prompt for $1

Insert $1

Dispense ticket

Alternative format for a scenario: UML Sequence Diagram (also known as Message sequence chart)

Note: the scenario explains “what” happens but not “how” it happens (that will be in the design)


Example use case (continued)

• The use case isn’t finished…

– still need to handle failures

– go through the steps, list the various ways that they could fail:

• Ticket Buyer can’t decide on a number, changes his/her mind

• Ticket Buyer fills in too many circles on the card

• System can’t print a ticket because it is out of ticket paper

– from some failures, the system can recover

– from other failures, the use case will “fail”


Making scenarios more elaborate

• There are three ways to create more elaborate scenarios:

– Variations

– Extensions

– Chunks (subfunctions)


Variations

• A variation is a way to avoid “scenario explosion”

• A variation is a list of alternatives that is tied to a specific line of a scenario

• Each variation could turn into a lower-level scenario

• An example variation (for the post office scenario):

1. Item isa. stampsb. postage on an item that the customer

is mailingc. postage due on an item that the

customer is receivingd. post office box rentale. mugs, t-shirts, and other Postal

Service merchandise6. Payment is

a. ______________b. ______________c. ______________

Main scenario:

1. Customer asks for an item

2. Postal clerk acknowledges customer request, checks if the requested item is available

3. Postal clerk asks the Customer if there will be anything else in this transaction

4. Customer indicates that they don’t want anything else

5. Postal clerk determines the price of the requested items and tells the customer

6. Customer pays

7. Postal clerk gives the Customer the items and change


Extensions

• An extension is a short scenario that “branches off” from another scenario

• Extensions are used to describe recovery actions when something goes wrong

– extensions might rejoin the main scenario

– or extensions might just terminate because the goal can’t be achieved

• An example extension (for the post office scenario):

2a. Item is not available:

2a1. Postal clerk looks for an equivalent item

2a2. If an equivalent item is found, the Postal clerk asks customer if the equivalent item is OK

Main scenario:

1. Customer asks for an item

2. Postal clerk acknowledges customer request, checks if the requested item is available

3. Postal clerk asks the Customer if there will be anything else in this transaction

4. …


Chunks

• A chunk is a “sub-scenario” - a sequence of messages that appears in several scenarios for one or more use cases.

– A chunk is a scenario that addresses a specific subgoal• for example: logging in, searching for a specific product, etc.

– They are the “subroutines” of the use case family

– They may express some common “user interface” sub-scenarios

– Alistair Cockburn calls them “subfunctions” (but we don’t want to think of them as associated with low-level code)


The UML Use Case Diagram

• In UML (Unified Modeling Language), it is possible to show a picture of the system as a group of use cases:– each stick figure is an

actor– each ellipse represents a

use case• The diagram is deceptively

simple– behind each ellipse, there

might be a whole bunch of scenarios – sunny-day, alternatives, failures

– the diagram is only a “summary”

Customer

Bank Employee

withdraw cash

check balance

service ATM


A simple format for a use case

Use case 1: Employee opens doorGoal: An Employee wants to unlock a door to pass from one room to

another.Preconditions: The Employee has valid identification to open the

door.Success end condition: Employee has successfully opened the door.Failed end condition: Door remains closed and the Security Guard on

duty is notified.Actors: Employee, Security GuardMain scenario:

1. Employee’s identification and door identification is sent to system2. Door is unlocked3. Employee opens door, passes through the door, and recloses door, SUCCESS

Extensions:2a. Employee’s identification is not valid

2a1. System notifies Security Guard, FAIL

opendoor

resetalarm

testalarm

Employee

SecurityGuard

RepairPerson

Office SecuritySystem


More Notations and Examples


Use-Case diagrams - actors

“actor“cellular network

Textual stereotype (class)

Visual stereotypes (classes)

actorpersons & roles

boundary/interfacecontrol entity

passive objectsdata stores


More on Use-Case diagrams

• Show use-cases & actors

• connected by „associations“

• refined by inheritance stereotypes

– “uses”• re-use of a set of activities (use-case)

• partitioning of activities

• points to the re-used use-case

– “extends”• variation of a use-case

• points to the standard use-case

make aninterview

produce a SRS

elicit customer needs

“uses “

“extends “


Use-Case diagrams: Example

customer

traveler

anybodyclerk

search fora flight

checktravel options

“uses”

flight db

“actor“flight res-sys

booka flight

“uses”

clerk

pay with cc “actor“

credit-card sys

Pay a bill

“extends”

prepare-travel


On Use Case Levels

• It is possible to write – “business-level” use cases –

• organizational goals (marketing, finance, systems engineering, installation)

– or “system-level” use cases• goals of specific users

– or “subsystem-level” use cases• goals of the other subsystems


Levels of scope (A. Cockburn)

Summary-level goals• “cloud-level”

User goals• “sea-level”• usually 2 to 20 minutes

Sub-functions• “under water”• not a real “user goal”:

these scenarios describe common sub-operations

Add newservice

Add newservice

Find list ofservices

Find list ofservices

Upgrade allcustomers

Upgrade allcustomers


Goals & Sub-goals

• Each use case represents a “goal” of one of the actors– the use case is “the set of all scenarios that might happen”

in trying to reach that goal – success or failure scenarios– each scenario is a series of smaller sub-goals

• if you can succeed in each step, you will reach the goal• if a step fails, then there might be an alternative series of steps that

get to the goal• the substeps might be lower-level use cases, or they might just be

“things implemented in the design”


Use Case diagram decomposition

uc-1

uc-3

uc-2

uc-4

diagram name: anything

uc-4.1

uc-4.2

Diagram name: anything-level2-for-uc4

Use- Case diagrams: Hiearachies


Use Case Process

Step 1: Create a list of Actors

Customer

Repair personAdministrator

Step 2: Create a list of Goals

Web-based music distribution system:UC1: Customer downloads a songUC2: Customer searches music directoryUC3: Administrator adds a new userUC4: Administrator updates directoryUC5: Support hotline person investigates a Customer problemUC6: Support hotline person authorizes Customer refundUC7: Repair person runs diagnostics

Step 3: Write simple use cases with only sunny-day scenarios

UC1: Customer downloads a songPrecondition: Song file is on a serverMain scenario: 1. Customer chooses song 2. System checks availability and

price; prompts Customer for payment

3. Customer enters credit card info 4. System sends credit card

transaction to Bank 5. Bank returns transaction number 6. System transmits the song to

Customer’s computer

Supporthotline person

Step 4: Review the use cases with customer (or customer surrogate)


Use Case Process (Cont.)

Step 5: Identify failure conditions

2a. Song is not available3a. Customer quits without entering

credit card info4a. Link to Bank is down5a. Credit card is rejected by Bank6a. Server fails during transmission6b. Customer cancels during

transmission

Step 6: Write a selected set of failure scenarios and alternatives

Step 7: Internal review

• review the scenarios and failure branches with testers, developers, project managers

Ongoing: make links to other requirements, update use case model as needed

• define the business rules and non-functional requirements (in text documents, with links to the use case model)

• add new use cases and new scenarios for new actors and goals; new variations for existing use cases

5a. Credit card is rejected by Bank: 5a1. System reports failure to the

Customer, prompts Customer for a different credit card

5a2. Customer enters card info 5a3. go to step 4


How many use cases is enough?

• It depends…– make sure you cover the

major goals of each actor– don’t forget OA&M –

administrative use cases usually include initialization, running backups, diagnosing problems, and reporting current status to another system

– some systems might need 100-200 use cases, but most only have 20-40

– do some “abstraction” to reduce the number of scenarios


Use Cases contribute to agility

• It is important to be “agile”– Requirements

• get direct customer involvement in documenting the requirements – using scenarios and use cases

– Architecture• make better architectural decisions – use the high-

runner, high-priority scenarios to assess “candidate architectures”

– Project management• use cases can help to plan an iterative development

process

– Test• update the tests as the requirements change


Scenarios and use cases in design, coding, and test

• The use cases are a very useful form of requirements

– they attempt to describe the externally visible behavior of the system

– they are concise enough for everyone to read (customers, developers, testers)

• Use cases can be kept under change control

• Design-level and code-level comments ought to refer to individual use cases, so that individual design decisions can be revisited when the use cases are changed

• System-level tests will use the information from use cases


Impact of Use Cases on Software Teams

• Systems engineers: improve communication with development team– SEs will write the key functional requirements as use cases (typically,

20 to 200 use cases for a system)– the set of system-level use cases (a subset of the overall requirements)

can be constructed and reviewed quickly– customers can validate the main scenarios

• Architects: benefit from using the most important “failure scenarios” to evaluate the architecture

• Development managers: “iterative and incremental development” can start with the high-priority use cases – focus on the scenarios that deliver the maximum value to customers

• Developers: code inspections can narrow the focus on the most important scenarios

• Testers: integration and system tests are guided by the use cases


Use cases and requirements• Use cases are requirements

– a use case will specify the essential behavior that the system must deliver

• Use cases are usually about 1/3 of the total volume of requirements

• The use cases are supplemented by other kinds of requirements information– Business Rules: conditions, policies, and conventions

– Operational Profiles: how many scenarios

– Architectural Requirements: “-ilities” (reliability, usability, performance)

Business Rules

BR1. Each employee has a unique identification number.

BR2. Each “open-door” request is logged.

Architectural Requirements

AR1. Maximum time to process an “open-door” request is 15 seconds.

AR2. No more than 5 minutes downtime per year.

Operational Profiles

OP1. During the busy hour (8-9am), the system should be able to handle 500 “open-door” requests (UC1 sunny-day).

OP2. The “test alarm” use case will be executed every weekend.


Why use cases?

• Why write use cases instead of “normal” functional requirements?– Use cases hold functional requirements in an easy-to-read,

easy-to-track format– Each use case gives information on how the system will

deliver a “goal” to one of the users of the system• a use case explains how a goal succeeds/fails using scenarios• the scenarios provide context – traditional requirements are often

too ambiguous• “If you have a requirement that doesn’t help meet any of the users’

goals, why do you have the requirement in the system?”• also need to look at the goals of the “stakeholders”

– Use cases show only the Functional requirements• the use cases are a framework to attach non-functional

requirements and other project details


After the use cases are written, what next?

• Jumpstart the OOAD – CRC and models– use cases describe the “externally-visible behavior” of the

system– an object model describes the internal behavior– Design decisions can be linked back to a use case

• Jumpstart test cases– Scenarios provide excellent start for “early testing”– Test planning – RTP and RSTP– DOORS-based traceability

• Use the Use Case list to manage your project– Use cases provide excellent basis for structuring and

monitoring your project iterations• It is important to be “agile”


Iteration management with use cases

• A use case model can be very useful in a project with rapid iteration– for each iteration, identify which use cases are “in” the iteration

• that is, will some or all of the use case’s scenarios work?• track progress by counting scenarios (with priority weighting)

– typical iteration scheme:• first iteration: highest priority use cases, sunny-day scenarios only• second iteration: add a few second-tier use cases, start

implementing the failure scenarios that fail completely• later iterations: add a few more use cases, start filling in the

“recovery” scenarios– you might choose certain use cases as “high-priority” because they

help validate key parts of the architecture


References

• Books:– Alistair Cockburn, Writing Effective Use Cases– Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in

Context– Steve Adolph and Paul Bramble, Patterns for Effective Use Cases

– Kurt Bittner and Ian Spence, Use Case Modeling

• Web sites:– http://www.usecases.org– http://agilealliance.org– http://members.aol.com/acockburn– http://members.aol.com/acockburn/papers/usecases.htm


Extra ...

• Summary …


Better Requirements and Product Quality through Use Cases (UC)• Summary of Characteristics

and Benefits – UCs capture a contract between

the stakeholders of a system about its behavior

– UCs specify system’s behavior under various conditions (success & failure modes) in a way that is concise and easy to understand, track, and validate

– UCs are collections of scenarios; scenarios provide context – traditional requirements are often too ambiguous

– UCs are a key to the creation/ generation of quality test cases and system verification

Industry data:

• Use cases improved developer productivity by 40% (DaimlerChrysler)

• 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases

Industry data:

• Use cases improved developer productivity by 40% (DaimlerChrysler)

• 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases


Vocabulary in this section

• use case: collection of scenarios related to a goal

• goal: what the actor is trying to accomplish when using the system (this might succeed or fail)

• scenario: a sequence of interactions

• sunny-day scenario: a scenario where everything works

• failure scenario: a scenario that explains what happens when something goes wrong

• variation: a set of choices for a single scenario step

• extension: a branch scenario that starts with an extension condition

• actor: a person or system outside of the system under development

• precondition: one of the conditions that must be true when a scenario of the use case is triggered

• chunk or subfunction: a set of scenario steps that are repeated in several different use cases

• business rule: one of the rules that describes how the business is run

• operational profile: description of which use cases will be run at the same time


Useful books

• Writing Effective Use Cases by Alistair Cockburn• Patterns for Effective Use Cases by Steve Adolph

and Paul Bramble• Use Case Modeling by Kurt Bittner and Ian Spence

Documents

Object Oriented Analysis & Design Use Cases. Object Oriented Analysis & Design Use-Cases: an Example