Use Case Analysis
From soft systems methodology to
understanding the system functionality
The Vision
SSM Models
Databases
Use Cases
Activity
Models
Programs
Object
Models
Dynamic Models
Business
Computing
Beginnings of a Method
Soft
Systems
Model
Use Case Models
• Consist of
– Use Cases
– Actors
– Relationships between Actors and Use Cases
What is a Use Case?
Formal definition
“A Use Case is a sequence of transactions performed
by a system that yields a measurable result of values
for an actor”
A Use Case:
• is a meaningful piece of system functionality
• models a dialogue between a user and the system
Note - The user can be another system
• is more than a simple transaction (e.g. enter customer
address)
We draw a use case as:
A Use Case
Examples of Use Cases
• Print Invoice
• Correct Invoice
• Chase Payment
• Register Bad Debt
What is an Actor?
• Anyone or any thing that uses or interfaces with the
system, such as:
– customer
– credit controller
– EPOS system
– Bank system
We draw actors as:
An Actor
Actors and Use Cases
• An Actor may use many Use Cases
• A Use Case may interface with many Actors
• We draw a simple line to indicate interaction
Relationships between actors and
use cases
An Actor
A Use Case
Arrows indicate who initiates
interaction
An Actor
A Use Case
Sometimes the use case initiates interaction
Use Cases can be related
• One Use Case may use another Use Case
• Sometimes that use is an exception or
alternative, and we say that one Use Case
extends another Use Case
Stereotypes
UML has a concept called a stereotype which is used
to describe the type of relation ship that is being used.
Stereotypes are written between guillemets << >>
(pronounced “ gweemays”) which are placed on the
relationship lines.
Example
<<extend>>
Extend relationship
Used where an alternative or an exception is being
shown.
In this case as part of a money collecting function, it
is required that a warning letter is sent out.
<<extend>>
Chase Payment
Issue Warning Letter
Note the direction of the arrow. It always goes from
the extension to the base case.
Include relationship
When use cases share the same piece of functionality,
we use the include relationship whereby the common
use case is linked to the use cases that use its
functionality.
In this case, the Validate User
use case needs
to be used for taking
Confirm
details
<<include>>
Validat
e user
an order and for
displaying user
information
Take
order
<<include>>
Note direction is from base to extension case
SSM Conceptual Model
enrol students
educate
students
award
degrees + diplomas
to students reaching
acceptable levels
design
education
programmes
allot
resources
appreciate
national
standards
design
and carry out
assessment
Any use cases here?
Initial thoughts on a development
method
Problem Situation
• Student Retention
• Too many students
enrol on a course
then withdraw in
their first year
• Need a software
system to help
solve the problem
– An improved
school intranet
Identify Relevant Systems
1.
2.
3.
4.
5.
6.
7.
8.
Admissions
Pastoral Care
Timetabling
Module Delivery
Peer Tutoring
Assessment
Attendance Monitoring
Research
Definition of a Pastoral Services
System
• A system under the control of an in-school
counselling team – giving appropriate referrals to
external agencies to students presenting personal
problems to members of the counselling team.
Root Definition for Peer-Tutoring
• A system owned by the school that provides study
skills support to students using volunteers from the
student body with the quality of their support
activities monitored by academic staff
Conceptual Model
Advertise
Identify suitable peer tutors
Receive tutee
Train peer tutors
Document tutee needs
Document Skills of peer tutors
Book times and rooms
Attendance Monitoring
Know tutorial
group members
Record absentees during
a tutorial session
Inform pathway leader
of persistent absentees
Inform student of contact
with pathway leader
Know student's
pathway leader
Related Use Cases
Print Class List
Let’s consider this
one
Enter Attendance Data for Class
Tutorial
email pathway leader and student
Module Leader
Print Attendance Record for
Specific Class
Print Attendance Record for
Specific Student
Create Class List
The information displayed here might be brought
together through collaboration between objects
Create Class
List Form
: Module
CreateClassList( )
: Student
: Pathway
getStudentDetails( )
getPathwayTitle( )
Class Diagram showing relationships between
these objects
Pathway
Title
Description
registered on
1
get pathway title()
n
Module
Name
Module Code
Create Class List()
Student
enrolled on
n
Name
n
get student details()
We can do two things with this class
diagram
• Implement it in an OOPL
• Translate it into an entity model then implement the
entity model as a relational database
We’ve considered how class diagrams
can be implemented in an OOPL
And how class diagrams can drive
database design
• When the computer is switched off….
– …the data used by the class diagram must be stored in a
database
My Next Example Program
Another Student
The Underlying Database
The Program that uses the
Database
The Class Diagram
Group
n
Student
Module Work Record
1
n
System
Boundary
Get Group Student
Numbers
Group
Get Student Number
Student
System
Boundary
Group
Get Student Marks
Student
Module Results
Get Module
Results
Three Tiers
Group
n
Student
Module Work Record
1
n
Classic Three Tier Architecture
An interface
developed in Visual
Basic or HTML?
An implementation of
the class diagram using
VB class modules or
Java?
An implementation of the
entity model in MS
Access, ORACLE, MySQL?
Back to Use Cases
Finding Use Cases (cont’d)
• Examine all the activities in the conceptual model and
determine where the system is used
• Big use cases sometimes naturally break down via
includes and extends
• Elaborating the use case often finds other use cases
Finding Use Cases (cont’d)
To fulfil a defined role:
•
•
•
•
What do users need to be able to do?
What are users trying to accomplish
What are the main tasks of users in this role?
What information do users in this role need to
examine, create, or change?
• What do users in this role need to be informed of by
the system?
• What do users in this role need to inform the system
about?
What do Students do?
• Enroll in, attend, drop, fail, and pass modules.
• Need a list of available modules.
• Need to determine basic information about a module,
such as its description and its prerequisites.
• Obtain a copy of their transcript, their course
schedules, and the fees due.
• Pay fees, pay late charges, receive reimbursements
for dropped and cancelled modules, receive grants,
and receive student loans.
• Graduate from a school or drop out of it.
• Need to be informed of changes in modules, including
room changes, time changes, etc.
Prototyping and Use Cases
• Interface prototypes are good for:
– Agreeing user interaction (HCI factors)
– Clarifying with users
– Determining data requirements
– Working out how to group use cases in interfaces
Use Case Proforma
• Number and Name
• Primary Path
• Pre- and post-conditions
• Alternatives and Exceptions
• Related Use Cases
• Prototype Interfaces
• Activity Diagrams
• Supported Business Processes / Activities
• Notes
A Use Case Catalogue
• Is a Substantial Document
• Overviewed by set of Use Case Diagrams
• Has Individual Use Cases
• Linked into CASE tool
• This is your requirements definition!
Invoicing use case (1)
Use Case Number:
Use Case Name: Invoice Customer
99
Brief Description: This is run daily to send invoices to customers. Items
that have been delivered are billed all on the same invoice. Customers
are only billed once a month.
Actors: Daily batch run, customer (indirectly, through post)
Frequency of Execution: Daily
Scalability: Only one instance of this runs at any one time.
Criticality: Essential. Every days delay to printing invoices affects the
bank balance considerably. Not running this for 7 days could trigger a
serious cash flow problem.
Primary Path:
The following sequence is carried out for every customer on the sales
ledger who has not been billed in the last month:
1. Get sales items from the sales ledger.
2. Get customer details from the customer file, covering billing address
details.
3. Get any credits that the customer has.
4. Get discount details for customer.
5. Print the invoice header
6. Print the line items on the invoice
7. Calculate any discounts
8. Apply any credits
9. Calculate and print the invoice total
10. Calculate and print the VAT
11. Mark items on sales ledger as invoiced
Invoicing use case (2)
Use Cases Related to Primary Path:
Alternatives:
2.1 No customer details on customer file, so print an error message on a
report. Do not mark the items on the sales ledger as invoiced. The
message needs to detail the sales items that have been entered.
Use Cases Related to Alternatives:
Invoicing error report
Exceptions:
Use Cases Related to Exceptions:
Notes:
Why Use Case Modelling?
• Agree system functionality and scope
• Relate it to how business processes are supported
• High level soft model, can be understood by all parties
• Prioritise implementation - particularly important for
iterative development
What about Objects?
• You don’t need to be developing an OO system to use
Use Case analysis
• Once you have Use Cases, then OO analysis and
design can begin in earnest
Summary
• Use Cases are meaningful chunks of system
functionality
• They support business processes
• They are important for defining and agreeing scope of a
system
• They can be prototyped
• They are important for driving implementation
schedules
• Modern development methods are “use case centric”