Use Case Diagrams
Use Cases
1. Introduction

A use case is a typical sequence of actions that a user performs in order to complete a given task. A use case
has a name. For example, in a library system, Check Out A Book would be a use case. More simply, a use case
is something the user wants to do with the software. (more later)

A use case model documents (often, graphically) the behavior of the system from the users' points of view.
In the use case model below for we depict a Library Management System (LMS). The symbols have these
meanings:
Symbol
Oval
Stick Figure
Solid Line
Definition
Use Case
Actor
Communicates Relation
Use Case model for LMS:

A use case model is good for:
1.
2.
3.
4.
5.
Capturing and validating requirements.
Determining the scope of the system.
Planning and scheduling.
Designing Tests.
Writing a user's manual or help system.
1
2. Details

Actor – a user of the system in a particular role and is usually depicted as a stick person. For example, in the
library system shown above, we see the Borrower, Librarian, Checkout Clerk, and Accounting System are
depicted as Actors in the system.
Many times Actors are humans, but not always. For instance, consider the following requirements for a
system. A computerized system needs to be developed to allow a person to buy train tickets. Customers can
purchase a one-way ticket, round-trip ticket, or a weekly pass. The Accounting System will also be required
to access the Ticket Sales System in order to update ticket prices. In this case, the Accounting System is an
actor in the system. Develop a use case model.

Use Case – a specific task that the system must accomplish. It is represented by a named oval. The UML
standard defines a use case as a "coherent unit of functionality." It comprises the typical sequence of actions
an actor takes on in order to complete a task.
A use case should:
1. Cover the full sequence of steps from the beginning of a task until the end.
2. Describe the user’s interaction with the system, not the computations the system performs.
3. Be written so as to be as independent as possible from any particular user interface design.
4. Only include actions in which the actor interacts with the computer, not actions a user does
manually

Communicates Relation – This exists if the actor plays some part in accomplishing the use case. This is
represented as a line. In the Library System example above, a Borrower can Search For Item By Title as
indicated by the communicate relation.
3. Generalizations – Can exist for Actors and for Use Cases. This typically results in a Use Case Model
that is easier to understand.
a. Example – The example shown at right shows a generalization in Actors in the LMS. It is
interpretted as meaning the Librarian can do everything the Checkout Clerk can do and the
Checkout Clerk can do everything the Borrower can do. The revised use case model is shown
below:
2
b. Example – The example shown at right
shows a generalized use case, Open File,
with specialized sub-use cases, Open File By
Typing Name and Open File By Browsing.
(Ignore the extend and include, we will
explain them next).
4. Include Relationships
a. There are two main types of extension mechanisms for use cases: Include and Extend relationships. We
use an Include relationship to show:
1. common functionality between use cases
2. how the system can use a component
3. the situation where we are creating a reusable component.
b. Example – Shows the situation where when extending a loan and borrowing a book both require checking
for a reservation (to see if the book is on hold).
c. Example:
d. There are also several dangers associated with identifying shared functionality:
1. A serious effort at this might force us into the traditional top-down functional decomposition of the
system which are inflexible and what we are trying to avoid.
2. Harder for someone without UML experience to understand the diagrams.
3
e. A project will probably utilize several versions of the use case model, simple versions those that show
more complex relationships between use-cases. Example: http://www.umldiagrams.org/examples/online-shopping-use-case-diagram-example.html?context=uc-examples
5. Extend Relationships
a. We use an Extend relationship when a use case incorporates two or more significantly different scenarios.
In other words, depending on the circumstances, one of several different things can happen. We usually
choose to document this as a main (normal) case, when everything goes correctly, and as one or more
subsidiary (unusual, variant) cases that extend the main use case.
b. Example - From text.
c. Example
6. Examples – Airline Reservation System:
4
7. Examples – Doctor’s Office:
8. Describing a Use Case
a. A use case describes (or generalizes) a set of related scenarios. For instance in the LMS, the Check out an
item Use Case can have: (a) a scenario where someone successfully checks out a book, and (b) a scenario
where someone attempts to check out a book, but the book is on reserve. The thing that scenarios have in
common is that they are all attempts to carry out essentially the same task. As shown in the previous
diagram, we can use the extend relation to handle the unusual situations or alternative situations.
b. A use case form is used to document a use case. A use case form for the Borrow Book use case is shown
below:
Name
Check out an item
Actors
Librarian or Checkout Clerk
Goals
Check book out to a library member (borrower).
Preconditions
Library member has a valid card and book has a valid bar code.
Summary
Related use cases
Actor
System
1. Scan library member’s card.
2. Display confirmation that
Steps
account is in good standing
3. Scan book bar code
4. Display confirmation that book
has ben checked out.
Postconditions
If the book is successfully borrowed, then the system records this.
5
9. Example
Source: http://www.isaca.org/Journal/Past-Issues/2007/Volume-3/Pages/Control-Considerations-in-Objectoriented-Systems1.aspx
6
10. Example
Source: https://code.google.com/p/e-card-system/wiki/Team_Skill6
7
11. Example
Source: http://www.cs.colorado.edu/~kena/classes/6448/s05/reference/usecases/examples.html
8
12. Use Case Senario – A use case scenario is an instance of a use case. It is an example of the use case. It is usually
written using a template. Many scenarios can be used to describe a use-case. It is a specific occurrence of the
use case: a specific actor, at a specific time, with specific data. These are used to draw the functional
requirements (details) out of the use case. Used for understanding business processes and usability design.
13. Excellent tutorial on use cases:
http://library.ac4d.com/d/AC4D_designlibrary_UseCasesScenarios.pdf
14. System Boundary – A box
can be drawn around the
use cases to denote the
system boundary. The
actors are drawn outside
the system boundary.
This is most useful when
you have complicated
systems that have been
broken
down
into
components
or
subsystems.
9
15. Planning – A Use Case diagram can be used to specify the phases that will implement the Use
Cases, as shown in the figure below. Note, in a similar way you could convey Teams,
Components, etc.
Homework
1. Draw and interpret Use Case diagrams.
2. Know the components of a Use Case description
3. Interpret this use case model:
10
4. Interpret this use case model:
11
5. Interpret this use case model:
Source: http://yuml.me/diagram/usecase/samples
12
6. Interpret this use case model:
Source: http://www.uml-diagrams.org/airport-checkin-uml-use-case-diagram-example.html
13
7. Interpret this use case model:
Source:
https://code.google.com/p/cmpe352spring2012group3/downloads/detail?name=Final_UseCaseDiagram.png&can=
2&q=
14