CMPS311– Fall 2010

Dr. Abdelkarim Erradi
Dept. of Computer & Engineering Science 
QU 1
 Outline
• Use Case Model
• Major Concepts in Use‐Case Modeling
• Use Case Relationships
• Benefits of a Use‐Case Model
• How to develop a Use‐Case Model?
 What Is a Use‐Case Model?

• A model that describes a system’s functional 
requirements in terms of use cases
– shows the system’s intended functionality (use 
cases) and its environment (actors)

– shows how the users can use the system to achieve 
their goals
 Use cases vs. internal features
• Consider software to run a cell phone:

Use Cases Internal Functions

„ call someone „ transmit / receive data
„ receive a call „ energy (battery)
„ send a message „ user I/O (display, keys, ...)
„ store a number „ phone-book mgmt.

Point of view: user Point of view: designer/developer

4
Simplified Use case model for Banner
System Boundary
Banner System

Association Use Case
Register for
Actor Courses

View Schedule

Student
View Transcript

+ A document describing the use case scenarios in details

 A Use‐Case Model is Mostly Text
The System
The diagrams Use case 1
give a visual Actor 1

overview of Use case 2

Actor 2

the system
Use case 3

Actor 3

Use-Case 1 Spec Use-Case 2 Spec Use-Case 3 Spec

- brief description - brief description - brief description
- flow of events - flow of events - flow of events
 System Boundary
Banner System
ƒ Marks off the system 
as separate from its 
environment

ƒ Actors are outside
 Actor
• Basically users of the system
– Actors represent “roles” not 
individuals

• External entities (people or 
systems)
– That interact with the system
– In order to achieve a desired 
goal
 Register for
Courses Use Case
• Describe the goal that the use case is intended 
to achieve
– Use active verb to describe the intended goal 
to be attained by using the system
Example: Register in an event, Issue an ID Card, 
Renew a Membership
– It is the outwardly visible and testable activity 
of a system => “external view” of the system
– Each use case describes a significant chunk of 
system usage
 Use Case Scenarios
• A scenario is a sequence of steps describing the 
interaction (a dialog) + the exchanged 
information between the actor and the system
– A story of using the system to achieve a user goal
• A use case has one normal scenario (happy day 
scenario) and several alternative flows:
– Normal scenario describes what "normally" happens 
when the use case is performed 
– Alternative flows describe optional or exceptional 
behavior for handling errors or exceptions during the 
normal flow of events.
11
Normal Flow of Events and Alternate 
Flows of Events for a Use Case

12
 Writing the normal scenario
• The normal scenario is written under the 
assumption that everything is okay, no errors  Start Pre-conditions

or problems occur. It describes: Action 1

– Pre‐conditions : what must be true before 
Action 2
the use case starts
– The interaction and what data are 
exchanged between the actor and the  Action 3

system 
– The data validation performed by the  Action 4
system
End Post-conditions
– State change by the system (e.g., 
recording or modifying something)
– Post‐conditions = what will be true upon 
successful completion 13
 Preconditions vs. Post‐Conditions
• Preconditions = what must always be true before beginning a 
scenario. Preconditions are not tested within the use case but they 
are conditions that are assumed to be true. E.g. :
– Student identified and authenticated
– User account exists
– User has enough money in her account
– There is enough disk space
• A post‐condition = success guarantee = the outcome of the use‐case. 
E.g.:
– Money was transferred to the user account
– User is logged in
– The file is saved to the hard‐disk
– The file is saved; Money is transferred
– Sale is saved. Tax is correctly calculated. Inventory updated. Receipt is 
generated.
 Normal Scenario Example

Interaction 
step

1. Administrator enters course name, code and description

Validation 
2. System validates the course code Step
3. System adds the course to the db and shows a confirmation message
Internal Change  (plus) Interaction 
Step Step
 Writing Alternative Flows
• List what can go wrong in the normal 
flow. e.g.: Start Pre-conditions

– course registration closed Action 1

– invalid studentId
Action 2
• Describe what to do to handle the 
Action 3
identified exceptions? 
– Sometimes the exception is recoverable i.e., the 
alternative flow rejoins the normal flow
e.g., if the course is full the system can display 
Action 4
alternative courses then the normal flow resumes
– Or the exception could be non‐recoverable and  End Post-conditions
ends the use case
e.g., if the registration is close, display a message 
and the use case ends.
16
 Student Registration Use Cases
Register for Courses

<<system>>
Maintain Faculty
View Transcript
Course Catalog Information

Student

Login Maintain Student

Information

Registrar

View Schedule
Close Registration

Faculty
Select Courses to
Teach
<<system>>
Billing System
Submit Grades
 Primary Actors vs. Secondary Actors
• Primary Actor: 
– The Actor that uses the system to achieve a goal
=> acts on the system

• Secondary Actor: 
– Actor that the system needs assistance from to 
achieve the primary actors goal
– Play a supporting role 
=> acted on by the system

18
 ‘Register For Courses’ – Normal Scenario
1. Logon
The system asks for, and the Student enters, the student ID and password.
2. Select 'Create a Schedule'
The system displays the functions available to the student. The student selects "Create a Schedule.“
3. Obtain Course Information
The system retrieves a list of available course offerings from the Course Catalog System and displays
the list to the Student.
4. Select Courses
The Student selects up to 4 core course offerings and up two alternate course offerings from the list of
available course offerings.
5. Submit Schedule
The student indicates that the schedule is complete. For each selected course offering on the schedule,
the system verifies that the Student has the necessary prerequisites.
6. Display Completed Schedule
The system displays a confirmation message and the schedule containing the selected course offerings
for the Student.

19
‘Register For Courses’ – Alternative Scenarios
1.a. Unidentified Student
If the system determines that the student ID and/or password is not valid,
an error message is displayed.
2.a. Course Registration Closed
If, when the use case starts, it is determined that registration has been
closed, a message is displayed, and the use case ends.
3.a. Course Catalog System Unavailable
If the system is down, a message is displayed and the use case ends.
5.a. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts
If the system determines that prerequisites for a selected course are not
satisfied, that the course is full, or that there are schedule conflicts, the
system will not enroll the student in the course. A message is displayed
that the student can select a different course. The use case continues at
Step 4, Select Courses, in the basic flow.
20
 Guidelines for Effective Scenario Writing
• Use simple and clear language
• Only one side (system or actor) 
is doing something in a single  System Actor
step Actor asks for money

• Any step should lead to some  System asks for amount

progress Actor gives the amount

– Bad: “User click the enter key” System produce the money

• Avoid describing the user 
interface details
– “User types ID and password, 
clicks OK or hits Enter”
22
 Use Case Relationships in UML
• Possible relationships between actors:
– Generalization

• Possible relationships between use cases:
ƒ Include
– Included use case represents common behavior
ƒ Extend
– Extending use case adds behavior
ƒ Generalization
– One use case is a special case of another
23
Generalization of Actors

ƒ One actor can be a 
specialization of another.

ƒ Arrow points to the 
more general (base) 
actor.
 Example: Generalization of Actors
The child actor 
inherits all use‐
cases associations
Should be used if (and only
if), the specific actor has
more responsibility than the
generalized one (i.e.,
associated with more use-
cases)

Example
Using Actor Generalization
 Use case Generalization

ƒ One use case is simply a special kind of another
ƒ Shows inheritance and specialization. The child use case inherits:
– The interaction (described in the textual description)
– Use case links (associations, include, extend, generalization)
 The <<include>> Relationship

ƒ <<include>> relationship represents a common 
behavior among several use cases
• Decompose complicated use case
• Centralize common behavior
The <<include>> Relationship

Used directly by Buy

Products
the user
<<include>> <<include>>
User goals

Sub-functionality
Choose Fill-in
Products billing info

Source - Alistair Cockburn “Writing Effective Use Cases”

 Writing Include

• If a normal scenario includes another use‐
case, we will describe this as a step within 
the normal flow:

1. System presents homepage
2. <include: login to the system>
 The <<extend> Relationship

• <<extend>> relationship represent an exceptional case
– The exceptional event flows are factored out of the main event 
flow for clarity.
• Use cases representing exceptional flows can extend more than 
one use case.
• The direction of a <<extend>> relationship is to the extended use 
case
Example: <<extend> Relationship
• The base use case can incorporate another 
use case at certain points, called extension 
points.
• Note the direction of the arrow
– The base use‐case does not know which use‐
case extends it

<<extend>>
Product is a gift
Buy Products Gift wrap
After checkout
Products
Example
 Example – cont’d
«extend» Rank
Search «include» Supplier
Product View Product
Details
After page Write
generation
«include»
«extend» Review
Navigate
Deals
«extend» Add to
cart

«include»
Checkout «extend»
user is not
a member
Login Register

Handle Order
Status «include»
Example: Use Case Relationships

Check <<include>>
grades
Login
Student <<include>>
Get Students User
List <<include>>
<<extend>> <<include>>
Faculty
Enter Verify
grades grades

Registrar

34
35
 Benefits
• Discover, describe and understand requirements
– Identification of users and what they can do
• Verification that requirements are complete and 
consistent
• Communication with the end users and domain 
experts:
– Ensures a mutual understanding of the requirements
• Serve as a basis for scheduling and estimating
– Use cases are the basis for the entire development process
• Re‐useable deliverable that can be used to create:
– Test Cases
– User Manual and online‐help
– User Interface design 36
 Use cases drive the entire 
development process

Use-Case Model Design Model

Communication
Sequence Diagrams
Diagrams

Use Case
Class Diagrams
Use-Case Realization
38
 Steps to develop use case
Use Case Writing Process:

1. identify actors and their goals

2. write the normal scenario
3. identify and list possible failure conditions that
could occur
4. describe how the system handles each failure
+ Walkthrough & Revise

‐ Start out at a high level and add detail as you go
‐ It is an iterative, incremental process 39
Structure of a Use Case Specification
Name
Brief Description
Actors
Preconditions
Post conditions

Normal Scenario Alistair Cockburn

“Writing Effective
Use Cases”
Alternatives Flows

Non-Functional (optional) List of NFRs that the use case 

must meet
 Example Use case Specification
• Name
– Withdraw cash
• Actor
– Customer
• Description
– Customer withdraws cash from a bank account using an ATM
• Triggering event
– Card inserted into ATM machine
• Pre‐conditions
– Actor has a bank card and a valid pin
• Post‐conditions
– Account has been debited
• Normal Scenario
– …
Example Use case Specification (cont.)
Normal scenario
 Customer inserts card
ƒ System prompts for PIN
 Customer enters PIN
ƒ System asks for transaction type
 Customer indicates “withdrawal”
ƒ System asks for account type
 Customer indicates account type
ƒ System asks for amount
 Customer enters amount
ƒ System displays advertisement
ƒ System dispenses cash
ƒ System prints receipt
ƒ Systems asks “another transaction?”
 Customer indicates “no”
ƒ System ejects card
ƒ Systems displays start screen
 Tips for writing effective Use Cases
• Actors should represent roles (not persons)
• Actor names should singular (not plural)
• Actor names should be consistent (e.g., if you use Faculty
always use the same name and not Professor)
• Use case name should be a verb followed by a direct 
object.
• Make sure that each use case describes a significant chunk 
of system usage 
• Do not represent communication between actors. Actors 
may collaborate through a use case.
• Reuse common Use Cases using <<include>> and 
<<extend>>
• Create detailed Use Case scenarios
 Validating Use Cases
• Since Use Cases are used in subsequent stages of 
software development, it is important to validate them
• Questions to ask:
– Is the Use Case complete? Are there any details that need to 
be added?
– Do I feel confident that the actor’s goal is going to be 
properly met?
– Are there any procedural or requirement changes I can 
suggest that would simplify the process depicted in the Use 
Case?
– Are there any additional Goals of the Actors that are not 
addressed?
– Are there any additional Actors that are not represented?
 More Information
• Best Use cases book:
‐ Alistair Cockburn, ‘Writing Effective Use 
Cases’ 2000.
http://www.infor.uva.es/~mlaguna/is1/mater
iales/BookDraft1.pdf
‐ Rebecca Wirfs‐Brock, ‘The Art of Writing Use 
Cases’ 2001.
www.wirfs‐
brock.com/PDFs/Art_of_Writing_Use_Cases.pdf

45