4.

Business Process Identification with Use

Case Modelling
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section, students will be introduced to

• Use Case Modeling with their benefits.
• Components of a Use Case Diagram, and steps
involved in drawing the diagram.
• The elements of a Use Case description.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• describe the benefits of Use-Case Modeling
• define actors, use cases and use-case
relationships
• identify and describe the steps for preparing a
use-case model

© e-Learning Centre, UCSC 3

 List of Subtopics
4. Business Process Identification with Use Case
Modelling (5 hours)
4.1 Introduction to Use-Case Modeling [Ref 1: Pg. 119-121]
4.2 Elements of a Use Case Diagram [Ref 1: Pg. 121-126]
4.2.1 Actors
4.2.2 Use Cases
4.2.3 Use Case Relationships
4.3 Creating a Use Case Diagram [Ref 1: Pg. 126-129]
4.4 Business Process Documentation with Use Cases and Use-
Case Descriptions [Ref 1: Pg. 140-152]
4.4.1 Elements of a Use-Case Description
4.4.2. Creating Use-case Descriptions

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object
Oriented Approach with UML : an object oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4
© e-Learning Centre, UCSC 4
4.1 Introduction to Use-Case Modeling

• Originally conceived by Dr. Ivar Jacobson in 1986.

• Proved to be a valuable aid in meeting the challenges of
determining what a system is required to do from a user and
stakeholder perspective.
• A best practice for defining, documenting and
understanding of an information system’s functional
requirements.

© e-Learning Centre, UCSC 5

4.1 Introduction to Use-Case Modeling

• All object-oriented systems development approaches are

use-case driven, architecture-centric, and iterative and
incremental.
• A use case is a formal way of representing the way a
business system interacts with its environment.
• Essentially, a use case is a high-level overview of the
business processes in a business information system.
• Use cases can document the current system or the new
system being developed.
• Given that object-oriented systems are use-case driven, use
cases also form the foundation for testing and for user-
interface design.

© e-Learning Centre, UCSC 6

4.1 Introduction to Use-Case Modeling
• It is the process of modeling a system’s functions in terms of
• business events
• who initiated the events
• how the system responds to those events
• An approach that facilitates user-centered development - a
process of systems development based on understanding
the needs of the stakeholders and the reasons why the
system should be developed

© e-Learning Centre, UCSC 7

4.1 Introduction to Use-Case Modeling

• Popular in non-object development environments

because of its usefulness in communicating with
users.
• Facilitates and encourages user involvement
• Provides a tool for capturing functional
requirements
• Provides a tool for requirements traceability
• Provides a framework for driving the system
development project

© e-Learning Centre, UCSC 8

4.1 Introduction to Use-Case Modeling

Use-case diagram
• Depicts the interactions between the system and external
systems / users.
• Graphically describes who will use the system and in
what ways the user expects to interact with the system
• A Subject Boundary represents the scope of the subject

Subject Boundary

UseCase1

Actor1 UseCase2

Actor3
UseCase1

Actor2

© e-Learning Centre, UCSC 9

4.2 Elements of a Use Case Diagram
Actor
• Anyone or anything that needs to interact with the
system to exchange information.
• Represented graphically as a stick figure labeled
with the name of the role the actor plays.
• Can be associated with other actors using a
specialization/superclass association, (see later)
• Is placed outside the subject boundary.

© e-Learning Centre, UCSC 10

 4.2 Elements of a Use Case Diagram

Actor
• An Actor may
• Only input information to the system.
• Only receive information from the system.
• Input and receive information to and from the system.

• Typically, they are found in the problem statement and by

conversations with customers and domain experts.

e.g. Librarian in a Library System

Grocery clerk in a Super Market

© e-Learning Centre, UCSC 11

4.2 Elements of a Use Case Diagram

Actors :
There are primarily four types of Actors.

- Primary Business Actor

- Primary System Actor
- External Server Actor
- External Receiver Actor

© e-Learning Centre, UCSC 12

4.2 Elements of a Use Case Diagram

Types of Actors
• Primary Business Actors – Benefits from the execution of use
cases by receiving some thing measurable.
e.g. Employee receiving a pay cheque.

• Primary System Actors - Directly Interfaces with the system to

trigger an event.
e.g. Grocery Clerk – Scan customer buying Items .

© e-Learning Centre, UCSC 13

 4.2 Elements of a Use Case Diagram

Types of Actors cont…

• External Server Actor

e.g. Credit bureau authorizing the charging by a credit card.

• External Receiver Actor

e.g. Warehouse receiving a package order to prepare a shipment.

© e-Learning Centre, UCSC 14

4.2 Elements of a Use Case Diagram
Actor Generalization

It factors out behaviour common to two or more actors

into a parent actor

Search library
inventory

Customer

Apply for
membership
Check out
books
Visitor Search library Patron
inventory
Visitor
Apply for
Check out membership
Patron books
© e-Learning Centre, UCSC 15
4.2 Elements of a Use Case Diagram

Use Case
• A behaviorally related sequence of steps both
automated and manual for the purpose of
completing a single business task.
• Describe system functions from the perspective of
external users in a manner they understand.
• They are the primary elements in software
development.
• They represent the functionality provided by the
system. i.e. what capabilities will be provided to an
actor by the system.

© e-Learning Centre, UCSC 16

4.2 Elements of a Use Case Diagram
Use Case
• Can extend another use case. (see later)
• Can include another use case. (see later)
• Is placed inside the system boundary.
• Is labeled with a descriptive verb–noun phrase.

© e-Learning Centre, UCSC 17

 4.2 Elements of a Use Case Diagram

Relationships
• Associations (also called <<Communicates>>)
• A relationship between an actor and a use case in which
an interaction occurs between them
• Modeled as a solid line connecting the actor and the use
case
• May be bidirectional or unidirectional
• UML 2.5 allows multiplicity

© e-Learning Centre, UCSC 18

 4.2 Elements of a Use Case Diagram
Multiplicity of an Actor/Use Case (UML 2.5)
• Required actor may be explicitly denoted using multiplicity 1 or
greater.
• UML 2.5 also allows actor to be optional.
• Multiplicity 0..1 of actor means that the actor may or may not
participate in any of their associated use cases.

© e-Learning Centre, UCSC 19

4.2 Elements of a Use Case Diagram

Use Case Diagram for an appointment system

© e-Learning Centre, UCSC 20

 4.2 Elements of a Use Case Diagram

Multiplicity of an Actor / Use Case (UML 2.5)

• When a use case has an association to an actor with a
multiplicity that is greater than one at the actor end, it means
that more than one actor instance is involved in the use case.

Two or more Player actors are involved in the Play Game use case.
Each Player participates in one Play Game.

© e-Learning Centre, UCSC 21

 4.2 Elements of a Use Case Diagram
Relationships
• Extend <<extend>>
• <<extend>> provides a way to insert new behaviour
into an existing use case.
• The extension use case extends the functionality of
the original use case.
• Shows optional behavior of a Use Case
• Depicted as an arrow headed line (either solid /
dashed)
• Has an arrow drawn from the extension use case to
the base use case.

© e-Learning Centre, UCSC 22

 4.2 Elements of a Use Case Diagram

Example: Extend Relationships

Extension Use Case

Refer Catalogue

Place New Order

© e-Learning Centre, UCSC 23

 4.2 Elements of a Use Case Diagram
Another Example for Extend Relationships

Base Use Case Return book

<<extend>>

Borrow book Issue fine

Librarian

Extension Use Case

© e-Learning Centre, UCSC 24

 4.2 Elements of a Use Case Diagram

Relationships
• Include <<include>>
• The base use case explicitly incorporates the
behavior of another use case.
• The relationship between the abstract use case
and use case that uses it.

© e-Learning Centre, UCSC 25

 4.2 Elements of a Use Case Diagram
Relationships
• include
• Another use case uses or includes the abstract use case.

ChangeEmployeeDetails

FindEmployee
Manager ViewEmployeeDetails
Details

DeleteEmployeeDetails

© e-Learning Centre, UCSC 26

 4.2 Elements of a Use Case Diagram
Relationships
• Depends on <<depends on>>
• A relationship between use cases indicating that
one use case cannot be performed until another
use case has been performed.
• e. g. banking business – use case ‘ Make a Withdrawal’
cannot be performed until the use case ‘Make a Deposit’
has been executed.
• Most analysts draw a separate diagram to show
dependency relationship.

© e-Learning Centre, UCSC 27

 4.2 Elements of a Use Case Diagram
Relationships

• Depends on
Establish
Bank Account
Make a
Deposit
Make a
Withdrawal

© e-Learning Centre, UCSC 28

 4.2 Elements of a Use Case Diagram
Relationships
• Relationships
• Generalization
• A relationship between actors created to simplify the
drawing when an abstract actor inherits the role of multiple
real actors

© e-Learning Centre, UCSC 29

 4.2 Elements of a Use Case Diagram

• Relationships
Search library
• Generalization inventory

Customer

Apply for
membership Check out
books
Visitor Search library Patron
inventory Visitor
Apply for
membership
Check out
Patron books

© e-Learning Centre, UCSC 30

4.2 Elements of a Use Case Diagram
Include, extend and generalization Compared

© e-Learning Centre, UCSC 31

A Use Case Diagram: An Example

© e-Learning Centre, UCSC 32

4.3 Creating a Use Case Diagram

• The first step is to review the requirements

definition. This helps the analyst to get a complete
overview of the underlying business process being
modeled.
• The second step is to identify the subject’s
boundaries. This helps the analyst to identify the
scope of the system. However, as we work through
the development process, the boundary of the
system most likely will change.
• The third step is to identify the primary actors and
their goals. The primary actors involved with the
system come from a list of stakeholders and users.
The goals represent the functionality that the
system must provide to the actor
© e-Learning Centre, UCSC 33
4.3 Creating a Use Case Diagram

• As actors are identified and their goals are

uncovered, the boundary of the system will change.
• The fourth step is to simply identify the business
processes and major use cases.
• The fifth step is to carefully review the current set
of use cases. It may be necessary to split some of
them into multiple use cases or merge some of
them into a single use case. Also, based on the
current set, a new use case may be identified.

© e-Learning Centre, UCSC 34

4.3 Creating a Use Case Diagram

• Basically, drawing the use-case diagram is

straightforward once use cases have been detailed.
• The only parts drawn on the use-case diagram are
the system boundary, the use cases themselves,
the actors, and the various associations between
these components.

© e-Learning Centre, UCSC 35

4.4 Business process documentation with use cases
and use case descriptions

• Use-case diagrams provide top level view of the basic

functionality of the business processes contained in the evolving
system.
• Use-case descriptions provide a means to more fully document
the different aspects of each individual use case.
• Use-case descriptions contain all the information needed to
document the functionality of the business processes.
• Although a use case may contain several paths that a user can
take while interacting with the system, each possible execution
path through the use case is referred to as a scenario.
• Another way to look at a scenario is as if a scenario is an
instantiation of a specific use case. Scenarios are used
extensively in behavioral modeling

© e-Learning Centre, UCSC 36

4.4 Business process documentation with use cases
and use case descriptions

Scenario – e.g. Purchase Items

• Customer Reviews items in the Shopping Cart
• Customer provides payment and shopping
information
• System validate payment Information and respond
with confirmation of order
• System will send confirmation of order details to
customer in an email.

© e-Learning Centre, UCSC 37

4.4 Business process documentation with use cases
and use case descriptions

• When creating use-case descriptions, the project team must

work closely with the users to fully document the functional
requirements.
• Organizing the functional requirements and documenting them
in a use-case description are a relatively simple process, but it
takes considerable practice to ensure that the descriptions are
complete enough to use in structural and behavioral modeling.
• A use-case description or Use Case narrative contains all the
information needed to build the structural and behavioral
diagrams that follow, but it expresses the information in a less-
formal way that is usually simpler for users to understand.

© e-Learning Centre, UCSC 38

4.4 Business process documentation with use cases
and use case descriptions

An Example :
Make Old Patient
Appointment

© e-Learning Centre, UCSC 39

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------

Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors: Importance of the
Other Interested Use Case – typically
Stakeholders:
Description: high , medium , low

There is no standard template for Use Case Narratives.

© e-Learning Centre, UCSC 40
4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------
Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Entity that triggers the
Other Participating Actors:
creation of the Use
Other Interested
Stakeholders: Case. E.g. Document
Description:

© e-Learning Centre, UCSC 41

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------

Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors:
Other Interested Who benefits from
Stakeholders: the use case
Description:

© e-Learning Centre, UCSC 42

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------
Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors:
Other Interested
Stakeholders: Facilitating Actors
Description:

© e-Learning Centre, UCSC 43

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------

Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors:
General understanding
Other Interested
Stakeholders: of problem domain and
Description: scope
In brief
© e-Learning Centre, UCSC 44
Sample High-Level Use-Case Narrative

© e-Learning Centre, UCSC 45

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
Typically another
- Trigger Use Case that must
- Typical Course of Events be previously
- Alternate Courses executed.
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 46

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger
Time receiving a cheque.
- Typical Course of Events
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 47

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as eg. Borrowing :

- Preconditions checkMember,
- Trigger checkOverdue,
- Typical Course of Events checkOverLimit,
checkCopyBorrowable,
- Alternate Courses
confirm Borrowing
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 48

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Errors, Confirm Messages
- Typical Course of Events
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 49

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Receipt Delivered to the
- Typical Course of Events Customer
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 50

 Summary
• Use Case Modeling is the process of modeling a system’s
functions in terms of business events, who initiated the
events, and how the system responds to those events.
• Shows the interactions between the system and external
systems / users.
• Graphically describes who will use the system and in what
ways the user expects to interact with the system.
• A Subject Boundary represents the scope of the subject.
• The elements of a use-case diagram include actors, use cases,
subject boundaries, and a set of relationships among actors,
actors and use cases, and use cases. These relationships
consist of association, include, extend, dependency and
generalization relationships.
• Actor is anyone or anything that needs to interact with the
system to exchange information.

© e-Learning Centre, UCSC 51

 Summary cont…
• Actors can be associated with other actors using a
specialization/superclass association and are labelled with a
noun phrase.
• A use case represents a major piece of system functionality.
• A Use Case can extend another use case or can include
another use case.
• A Use Case is placed inside the system boundary and is
labeled with a descriptive verb–noun phrase.
• An association relationship links an actor with the use case(s)
with which it interacts.
• An include relationship represents the inclusion of the
functionality of one use case within another and has an arrow
drawn from the base use case to the used use case.

© e-Learning Centre, UCSC 52

 Summary cont…
• An extend relationship represents the extension of the use
case to include optional behavior and has an arrow drawn
from the extension use case to the base use case.
• Generalization relationship represents a specialized use case
to a more generalized one and has an arrow drawn from the
specialized use case to the base use case.
• Steps to create a Use Case Diagram are:
• review the requirements definition, identify the subject’s boundaries,
identify the primary actors and their goals, simply identify the
business processes and major use cases, and carefully review the
current set of use cases.
• It may be necessary to split some of them into multiple use cases or
merge some of them into a single use case. Also, based on the current
set, a new use case may be identified.

© e-Learning Centre, UCSC 53

 Summary cont…
• Use-case descriptions/narratives provide a means to more
fully document the different aspects of each individual use
case.
• Use-case descriptions contain all the information needed to
document the functionality of the business processes.
• A use-case description or Use Case narrative contains all the
information needed to build the structural and behavioral
diagrams that follow, but it expresses the information in a
less-formal way that is usually simpler for users to
understand.
• Most analysts first start with a high-level version of a narrative
and subsequently prepare the expanded version. There is no
standard template exist for use case narratives.

© e-Learning Centre, UCSC 54