1

Lecture Slides for

UML and Use Cases
 2

Overview

What use cases are and how to write them.

Different format of use cases.

How to draw a use case diagram.

Extend and include use cases.

 3

By the end of this chapter, you will..

 Understands the use case diagram and the different relationship

types inside the use case diagram.

 Understands the meaning of “Use Case”.

 Understands the different methods in writing the use cases.

 4

What is UML ?
UML is not a language in the same way that we view programming
languages such as ‘C++’, ‘Java’ or ‘Basic’.
UML is however a language in the sense that it has syntax and semantics
which convey meaning, understanding and constraints (i.e. what is right
and wrong and the limitations of those decisions) to the reader and thereby
allows two people fluent in that language to communicate and understand
the intention of the other.
UML represents a collection of 13 essentially graphical (i.e. drawing)
notations supplemented by textual descriptions designed to capture
requirements and design alternatives. You don’t have to use them all, you
just chose the ones that capture important information about the system
you are working on.
UML is to software engineers what building plans are to an architect and
an electrical circuit diagrams is to an electrician.
 5

Unified Modeling Language

A notational system aimed at modeling systems using object oriented
concepts.
 6

Capturing functional requirements

with use case diagram
 A simple but very effective model used during the analysis phase for analysing
requirements through the process of exploring user interactions with the
system.
 It describes the main system functions from the standpoint of an external observer.
 Used during requirements elicitation to represent external behavior.
 It emphasize on what the system does rather than how it.
 It is created during the early stages of a project – during the analysis phase rather
than during the design phase.
 It provides a high-level view of what the system does and who uses it.
 It provides the basis for determining the user interfaces (UIs) to the system.
7
 8

Use Case Diagram

Any use case diagram should contain:

 Actor(s).
 Use cases.
 Associations/Relationships among
actors and use cases.
 9

Use Case Diagram

Actor
 Actors are drawn as stick persons with the role of the actor written
below.

 Actor names are unique typically represent the role that

an actor plays with respect to the system.

 Is someone (e.g. human beings) or something (e.g. other objects

or systems) that interact with the system.

 Is entity external to the system who participates in the story of the

use case (receive or input), such as a person, computer system or
organization. Actor role name

 Example: a library clerk, cashier, customer, Passenger, GPS

satellite, bank, customer department.
 10

Use Case Diagram

Use Case

 Use cases are drawn as ellipses with the name of the use case written inside
the ellipse.

 Use case name typically consists of an active verb and one or more nouns that
concisely describe the system function modeled.

Use case
 11

Use Case Diagram

Use Case

Use Cases: is a collection of related scenarios that describe actors using a system
to support a goal.

Scenario (Use Case instance):

 Is a possible example of what happens when an actor interacts with the system.
 Represents a unit of functionality that the system provides.
 Contains a specific sequence of actions and interactions between actors and the
system under discussion.
 Example: the scenario of entering book information into the catalog, or buying items at
a store, or using an ATM.
 12

Use Case Diagram

Association/Relationship
 Actors are connected to the use case(s) with which they interact by a line, which
represents the relationship between the actor(s) and the use case(s).
 One actor may be associated with one or more use cases.
 One use case may be associated with one or more actors.
Example . A Cash Dispenser/ATM. 13

• As an example of use-case analysis, let’s attempt to identify a user

interaction with a cash dispenser or ATM.

• In essence, this system (a completely automated system, as

opposed to a manual one) provides the following functionality.

• Request Cash
• Request Balance
• Request Statement
• Request Cheque book

• Let’s take the ‘Request Cash’ use-case and identify the interaction
that takes place between user (a person with an ID card wishing to
borrow money) and the system (the cash dispenser/ATM).
 14

Request Balance Request Statement

Customer

Request Cash Request Cheque Book

ATM Use-Case Diagram

 15

Example : Use Case Diagram for

Banking System
Example 2 Library user Interaction - Use Cases 16

• As a user, you expect a library to offer you the following services and the
librarian, being a domain expert will know how to perform these tasks.

Library Use-cases
• Checking out a book for loan.
• Checking in a returned book.
• Checking if a book is in stock and where to find it.
• Reserving a book that is currently out on loan.
• Dealing with payment of overdue fines.
• Adding new members to the library.
• Deleting old members from the library.
• Dealing with changes of members details e.g. name address etc.

• In this case the librarian is part of the system that we are trying to automate
and he/she may or may not be present in the automated version or at the
very least he or she may find their job has changed

• So we need to interview him/her to gain the knowledge inside their head.

 17

Use Case(s)
 Each use case have an associated behavior specification which describes the sequence
of actions making up a use case scenario.

 Use case behavioral description has two formats:

High Level Use Case Expanded Use Case
Describes a process very briefly, usually in 2 or 3 Describes a process in details.
sentences. It has an additional section not present in HL.

It consists of : • Purpose: Intention of the use case.

•Use Case: Use case name. • Type:
•Actors: List of actors (external agents) indicating 1- Primary, Secondary or Optional.
who initiates the use case. 2- Essential or Real.
•Description (Success scenario): Narrative • Cross References: Related use cases and system
description of the process. functions.
• Typical course of actions: describes in detail the
conservation of interaction between the actors
and the system.
 18

High Level Use Case Format: HL

Example 1: Buy Items

Use Case: Buy Items

Actor: Customer(initiator) , Cashier

Description (Success Scenario):

A customer arrives at a checkout with items to purchase. The
Cashier records the purchase items and collects payment. On
completion, the Customer leaves with the items.
 19

High Level Use Case Format: HL

Example 2: Library - Add Resources

Use Case: Add Resources

Actor: Librarian

Description (Success Scenario):

The use case begins when the Librarian receives new resources
(books and videos) to add to the catalog. The title, call number,
and other information are recorded. Then the resources are
placed on a shelf organized by resource type and call numbers.
 20

Identifying Use Cases

Either by:
Type1: Actor based Type 2: Event based
• Identify the actors related to an organization. • Identify the external events that a
• For each actor, identify the processes they system must respond to.
initiate or participate in. • Relate the events to actors and use
cases.

Example:
Cashier Log in, Cash out.
Customer Buy items, Refund items.
 21

Use Cases = Processes

 A use case describes a process, such as business process.

 A process describes, from start to finish, a sequence of events, actions and

transactions required to produce or complete something of value.

 Example:
• Withdraw cash from an ATM.
• Order a product.
• Register for courses at a school.
• Check the spelling.
• Handle a call.
 22

Example 1
2- Define actors and use cases:

Cashier Log in, Cash out.

Customer Buy items, Refund items.

Manager Start up, Shut down.

System Administrators Add new users.

 23

Example 1 (cont.)
3- Use cases in HL format:

Use Case: Buy Items

Actors: Customer (initiator), Cashier
Type: Primary
Description: A Customer arrives at a checkout with items to purchase. The Cashier
records the purchase items and collects a payment. On completion, the Customer
leaves the store with the items.

Use Case: Start Up

Actors: Manager
Type: Primary
Description: A Manager powers on a POST in order to prepare it for use by Cashiers.
The Manager makes sure the date and time are correct, after which the system is
ready for Cashiers’ use.
 24

Example 1 (cont.)
4- Use cases diagram:
 25

Example 2

Use Case: Make a book Entry

Use Case: UC1 - Make Book Entry

Actor: Library clerk
Success Scenario:
A library clerk accesses a terminal in order to enter one or possibly
many book entries in a database. At the end of every entry, the system
displays a confirmation message. At the end of the session the system
would display an informative message.
 26

Example 2 (cont.)

Use Case Diagram