Use Cases: Each Use Case Represents A Set of Scenarios

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 17

Use cases

• Use-cases are a scenario based technique in the


UML which identify the actors in an interaction
and which describe the interaction itself
• A set of use cases should describe all possible
interactions with the system
• Sequence diagrams may be used to add detail to
use-cases by showing the sequence of event
processing in the system
Each use case represents a set of scenarios
An actor is something outside of the system to be developed.
Lending use-case

Lending services
Library use-cases

Lending services
Library
User

User administration
Library
Staff

Supplier Catalog services


Sequence diagram shows detail:
Catalogue management
Item: Books:
Library Item Catalog

Bookshop: Cataloguer:
Supplier Library Staff

Acquire New

Catalog Item

Dispose

Uncatalog Item
Another Library Use Case Diagram
A computerized library system for a
university keeps track of all books and
periodicals in the library and their check-out EmployeeLogin
status. Checkout and return are automated
through a bar code reader (an external CheckIn
device). The library system also interfaces LibEmployee
with an external relational database which BarCodeReader
stores information about the library users CheckOut

(students, faculty, and staff), including


whether they have any library items checked CheckAvailability
LibUser
out. . Library users can access the catalog UsersDB

and recall books and periodicals. Library


employees have the same access as well as Recall
additional capabilities (e.g., listing the status
of an item). (Note: the library catalog is part
of the library computer system so it is not
shown as an actor.)
Use Case for Employee Login

1. Employee initiates use case


by entering user name EmployeeLogin

2. System prompts for


CheckIn
password LibEmployee

3. If password is valid, CheckOut


BarCodeReader

employee is logged on and


now has access to employee CheckAvailability
commands LibUser
UsersDB

Starting and Ending


Recall
Conditions?
Exceptions? e.g., cannot find
the employee login
Use Case for
Check book availability
1. User/Employee initiates use case
by selecting the check book
availability option
2. System prompts for choice of EmployeeLogin

search by title, author, or call


CheckIn
number LibEmployee
3. User makes selection and enters BarCodeReader
title, author or call number CheckOut

4. System performs search through


the library catalog database LibUser
CheckAvailability

5. If a match is found, system UsersDB

displays item status (not checked


Recall
out, checked out and due date,
overdue)
Starting and Ending Conditions?
Exceptions?
Use Case Associations

• Use case association = relationship between use


cases
• Important types:
– Extends
• A use case extends another use case
– Include
• A use case uses another use case (“functional
decomposition”)
– Generalization
• An abstract use case has different specializations
<<Include>>: Functional Decomposition
• Problem:
– A function in the original problem statement is too complex to be
solvable immediately
• Solution:
– Describe the function as the aggregation of a set of simpler functions.
The associated use case is decomposed into smaller use cases

CreateDocument

<<include>> <<include>>
<<include>>

Scan OCR Check


<<Include>>: Reuse of Existing Functionality

• Problem:
– There are already existing functions. How can we reuse them?
• Solution:
– The include association from Use Case A to Use Case B indicates that
an instance of A performs all the behavior described in B (“A
delegates to B”)
• Example:
– The use case “ViewMap” describes behavior that can be used by the
use case “OpenIncident” (“ViewMap” is factored out)
• Note: The base case cannot exist alone. It is always called with the
supplier use case
<<include>>

OpenIncident
ViewMap
Base Use
Case <<include>>
Supplier
AllocateResources
Use Case
Home Automation example –
factor out common functionality

<<include>>

ToggleHotTub
<<include>> TeaPot

ToggleAppliance
ToggleShades
<<include>>
Shades

ToggleTeaPot

HotTub
User
Another Home Automation example –
factor out common functionality

ControlLights <<include>> Lights


(from Use Case View)

User
LogFunctions
(from Use Case View)
<<include>>

FeedDogs
DogFeeder
<<Extend>> Association for Use Cases
• Problem:
– The functionality in the original problem statement needs to be
extended.
• Solution:
– An extend association from Use Case B to Use Case A indicates that B
is an extension of A.
• Example:
– The use case “ReportEmergency” is complete by itself , but can be
extended by the use case “Help” for a specific scenario in which the
user requires help
• Note: In an extend association, the base use case can be executed without
the use case extension
Base Use
Case B
Help
FieldOfficer
A <<extend>>

ReportEmergency
Home Automation example

<<extend>>
False Alarm

User

Sound Alarm
Entry Sensor
Generalization association in use cases
• Problem:
– You have common behavior among use cases and want to factor this out.
• Solution:
– The generalization association among use cases factors out common behavior.
The child use cases inherit the behavior and meaning of the parent use case
and add or override some behavior.
• Example:
– Consider the use case “ValidateUser”, responsible for verifying the identity of
the user. The customer might require two realizations: “CheckPassword” and
“CheckFingerprint”

CheckPassword

Parent
ValidateUser
Case Child
CheckFingerprint Use Case
Example using <extend>

BuyOneWayTicket
<<extend>> TransactionAborted

<<extend>>
Traveler BuyWeeklyCard
<<extend>>
<<extend>>

<<extend>>
BuyMonthlyCard
<<extend>>
DistributorOutOfChange

UpdateTariff
CentralCompSys
Simplified with an abstract use case

BuyOneWayTicket
TransactionAborted

<<extend>>
Traveler BuyWeeklyCard
<<extend>>
DistributorException
<<extend>> DistributorOutOfChange

BuyMonthlyCard

UpdateTariff
CentralCompSys

You might also like