Learning Objectives

 Explain use cases and use case

diagrams and how they can be used
to model system functionality.
 Discuss process modeling with use
cases for electronic commerce
application.

1
Use Cases
 Use case is a depiction of a system’s
behavior or functionality under various
conditions as the system responds to
requests from users.
 Actor is an external entity that interacts
with the system.

2
Use Cases (Cont.)

FIGURE 7-26
A use case diagram for a university registration system

3
Use Cases (Cont.)
 Most actors represent user roles, but actors can
also be external systems.
 An actor is a role, not a specific user; one user
may play many roles, and an actor may
represent many users.
 A use case model consists of actors and use
cases.

4
Use Cases diagrams
 Use case diagram: a picture showing
system behavior along with the key actors
that interact with the system
 Abstract use case is when a use case is
initiated by another use case.
 A use case represents completely
functionality.

5
Definitions and Symbols

Use Case
Actor
Boundary
Connection
<<include>>
Include relationship
<<extend>>
Extend relationship
6
Actor
Divided into two groups
Primary actors:
Supply data or receive information from the
system
Provide details on what the use case should do
Supporting actors:
Help to keep the system running or provide help
The people who run the help desk, the analysts,
programmers, and so on

2-7
A Use Case Always Provides Three
Things
An actor that initiates an event
The event that triggers a use case
The use case that performs the actions
triggered by the event

2-8
Use Case Relations
Behavioral relationships
Communicates
Used to connect an actor to a use
case
Includes
Describes the situation in which a use
case contains behavior that is
common to more than one use case

2-9
Use Case Relations
Behavioral relationships (continued)
Extends
Describes the situation in which one use
case possesses the behavior that allows
the new case to handle a variation or
exception from the basic use case
Generalizes
Implies that one thing is more typical
than the other thing

2-10
Four Types Of Behavioral Relationships And
The Lines Used To Diagram Each
(Figure 2.13)

2-11
Some components of use case diagrams showing actors,
use cases, and relationships for a student enrollment
example (Figure 2.14)

2-12
Scope
System scope defines its boundaries:
What is in or outside the system
Project has a budget that helps to define scope
Project has a start and an end time
Actors are always outside of scope
Communication lines are the boundaries and
define the scope

2-13
Developing Use Case Diagrams
Review the business specifications and identify the actors
involved
May use agile stories
Identify the high-level events and develop the primary use
cases that describe those events and how the actors
initiate them
Review each primary use case to determine the possible
variations of flow through the use case
The context-level data flow diagram could act as a starting
point for creating a use case

2-14
A Use Case Diagram Representing a System Used
to Plan a Conference (Figure 2.15 )

2-15
Developing the Use Case
Scenarios
The description of the use case
Three main areas:
Use case identifiers and initiators
Steps performed
Conditions, assumptions, and questions

2-16
Definitions and Symbols (Cont.)
 Actor is a role, not an individual.
 Involved
with the functioning of the system at
some basic level
 Represented by stick figures
 Use case represents a single system
function.
 Represented as an eclipse

17
Definitions and Symbols (Cont.)
 System boundary includes all the
relevant use cases.
A boundary is the dividing line between the
system and its environment.
 Use cases are within the boundary.
 Actors are outside of the boundary.
 Represented as a box

18
Definitions and Symbols (Cont.)
 Connection is an association between an
actor and a use case.
 Depicts a usage relationship
 Connection does not indicate data flow
 Actors are connected to use cases with lines.
 Use cases are connected to each other with
arrows.
Definitions and Symbols (Cont.)

 Extend relationship is an association

between two use cases where one adds
new behaviors or actions to the other.
 Extends a use case by adding new behavior
or actions.
 Specialized use case extends the general use
case.
Definitions and Symbols (Cont.)

 Include relationship is an association

between two use cases where one use
case uses the functionality contained in
the other.
 Indicates a use case that is used (invoked) by
another use case.
 Links to general purpose functions, used by
many other use cases.
Definitions and Symbols (Cont.)

FIGURE 7-27
A use case diagram featuring an include relationship
Written Use Cases
 Document containing detailed
specifications for a use case
 Contents can be written as simple text or
in a specified format
 Step-by-step description of what must
occur in a successful use case
 Level of Use Case
 Refers to degree of detail in the use case
description

 Five suggested levels (Cockburn)

summary
1. White – as seen from clouds
2. Kite – “birds-eye view”
3. Blue – sea-level view
4. Fish – below sea-level
detail
5. Black – bottom of the sea
Sample Format for Written Use
Case
 Title – descriptive name, matches name in
use case diagram

 Primary actor – usually a user role

 Stakeholders – any group or individual

with an interest in the function of the use
case
 Sample Format for Written Use
Case (Continued)
 Precondition – conditions that must be
satisfied in order to execute the use case

 Minimal guarantee – outputs that can be

expected if the service attempt failed

 Success guarantee – outputs that can be

expected if the service succeeds
 Sample Format for Written Use
Case (Continued)
 Trigger – an event or action that initiates
the use case

 Main success scenario – description of

sequence of interactions between actor and
use case during the use case execution

 Extensions – detailed description of how

errors are dealt with
Use case at kite level
11/18/13 31
Building Use Cases

.
 Process of Developing Use
Cases
 Identify the major use cases
 Identify the major steps within each use
case
 Identify elements within steps
 Confirm the use case
 Cycle through the above steps iteratively

5 - 33
 Step 1:
Identify the major use cases

Activities Typical Questions Asked

Start a use case form for Ask who, what, and where about the tasks and their
each use case inputs and outputs:
If more than nine, group What are the major tasks performed?
into packages What triggers this task? What tells you to perform this
task?
What information/forms/reports do you need to perform
this task?
Who gives you these information/forms/reports?
What information/forms/reports does this produce and
where do they go?

5 - 34
 Step 2: Identify the major steps within
each use case

Activities Typical Questions Asked

For each use case, fill Ask how about each use case:
in the major steps How do you produce this report?
needed to process the How do you change the information on the report?
inputs and produce the
outputs How do you process forms?
What tools do you use to do this step (e.g., on
paper, by email, by phone)?
 Step 3:
Identify elements within steps

Activities Typical Questions Asked

For each step, identify Ask how about each step

its triggers and its How does the person know when to perform this
inputs and outputs step?
What forms/reports/data does this step produce?
What forms/reports/data does this step need?
What happens when this form/report/data is not
available?

.
 Step 4:
Confirm the use case

Activities Typical Questions Asked

•For each use case, •Ask the user to execute the process using the
validate that it is correct written steps in the use case – that is, have the
and complete user role-play the use case

.
Process Modeling using Data Flow
Diagrams

38
Process Modeling using Data Flow
Diagrams

39
Summary
 In chapter you learned how to:
 Explain use cases and use case
diagrams.
 Explain how they can be used to model
system functionality.
 Discuss process modeling with use cases
for electronic commerce application.
Object-Oriented Analysis and Design:
Use Cases
A Sample Case Study
 Consider an example: The First Bank of
Nunavut
 The application will manage the bank’s
accounts, including:
 In-branch transactions
 ATM transactions

 Web transactions

 Automatic deposit transactions

 The application will facilitate the loan

application and approval process
Use Case Descriptions
 A use case description is a detailed description of a
use case, including:
 A list of primary and secondary participants (actors)
 A step-by-step description of the main success scenario of
the use case
 Alternative flows (exceptional conditions) that may occur
(and when they could occur)
 Much of this information comes from the
requirements document (from requirements capture)
 The rest of the information should be obtained using
questionnaires and interviews with the customer
A Sample Use Case Description
Use Case: Deposit into Account
Primary Actor: Teller
Stakeholders and Interests: Customers want to deposit money
into their account. The want the transaction to be completed
correctly, as losing their money would be unacceptable.
Customers also want transactions, such as this, recorded so they
can be viewed later.
Main Success Scenario:
1. The customer arrives at the teller with some amount of money
(cash or cheque) to deposit, and provides the account ID of the
account they wish to use
2. The teller accepts the money and verifies the account ID
3. The teller prepares a deposit slip including the account ID and
amount
4. The customer signs the deposit slip, and keeps a copy
A Sample Use Case Description
5. The teller files the deposit slip
6. The teller updates the balance of the account with the provided
account ID
7. A transaction record is generated, including transaction details
Alternative Flows:
2a. If the account ID is invalid, the teller asks the customer to verify.
If unable to correct the account ID, the teller returns the money
and cancels the transaction.
6a. The customer asks for a printout of the account balance. The
teller prints an account balance summary, and gives it to the
customer.
Technical Considerations:
 Many customers provide their debit card instead of their account
ID. A card reading device is used to get the account ID from the
debit card.
Use Case Diagrams
 A use case diagram is a diagram depicting use
cases, the actors involved
 In the second iteration of Elaboration, we also add possible
relationships between use cases
 Use cases are shown as ellipses with the use case
name inside
 Actors are shown as stick figures, with the actor
name underneath
 Actors that are non-human may also be shown as
rectangles with the actor name inside, including the
stereotype «actor»
 A non-human actor would be used to represent an external
system (e.g. a credit card company)
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services

Primary actors
go on the left
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services

Secondary
actors on the
right
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services

Use cases may

be grouped
like this
Elaboration Phase Checkpoint
 This is usually where the first iteration of the
Elaboration phase ends
 So far we’ve started the use case model:
 We’ve created use case descriptions
 We’ve drawn a simple use case diagrams

 The next iteration will involve the improvements of

the use case model:
 Improvements to the use case diagrams, and the addition
of use case contracts and system sequence diagrams
 We will also create a domain model, which describes the
objects and classes in the application domain
Use Case Contracts
 A use case contracts is like any other contract: an
agreement between the producer and consumer
 In this case, the producer is the use case, and the
consumer is the actor using it
 The contract outlines pre-conditions and post-
conditions
 Pre-conditions: A description of the context prior to the
execution of the use case
 Post-conditions: A description of the context after the
execution of the use case
A Sample Use Case Contract
Use Case: Deposit into Account
Pre-conditions:
 The account exists and is active
Post-conditions:
 For a deposit of N dollars, the balance of
the account is increased by N
 A transaction record is recorded for
accountability, tracing, and customer
information