Modeling UML Use Case Diagrams

and Capturing Use Case Scenarios

Prepared By:
Prof. Prashant Udawant
MPSTME SHIRPUR CAMPUS

1
 Objectives
After completing this experiment you will be
able to:
• How to identify different actors and use cases
from a given problem statement
• How to associate use cases with different types
of relationships
• How to draw a use-case diagram

[email protected] 2
 Prerequisite
• Knowledge of Requirements Document.

[email protected] 3
 Introduction
• Use case diagram is a platform that can provide a
common understanding for the end-users,
developers and the domain experts.
• It is used to capture the basic functionality i.e. use
cases, and the users of those available functionality,
i.e. actors, from a given problem statement.
• In this experiment, we will learn how use cases and
actors can be captured and how different use cases
are related in a system.

[email protected] 4
 Why Create a Use Case Model?
• A Use Case Model allow the customer and
system developer to communicate WHAT the
system should do.
• Consider the use case model as the visual
contract between customer and developer.
• Use case Model should be basis for all system
design activities.

[email protected] 5
 Use case diagrams
• Use case diagrams belong to the category of
behavioral diagram of UML diagrams.
• Use case diagrams aim to present a graphical
overview of the functionality provided by the
system.
• It consists of a set of actions (referred to as use
cases) that the concerned system can perform .

[email protected] 6
 Actor
• An actor can be defined as an object or set of
objects, external to the system, which interacts
with the system to get some meaningful work
done.
• Actors could be human, devices, or even other
systems.
• For example, consider the case where a
customer withdraws cash from an ATM. Here,
customer is a human actor.
[email protected] 7
 Classification of Actors
• Primary actor:
– They are principal users of the system, who fulfill their goal by
availing some service from the system.

• Supporting actor:
– They render some kind of service to the system. For example "Bank
representatives", who replenishes the stock of cash.
– replenishing stock of cash in an ATM is not the prime functionality of
an ATM.
• In a use case diagram primary actors are usually drawn on the top left side of
the diagram.

[email protected] 8
 Use Case
• A use case is simply a functionality provided
by a system.
• Example of the ATM, withdraw cash is a
functionality that the ATM provides.
Therefore, this is a use case.
• Other possible use cases includes, check
balance, change PIN, and so on.

[email protected] 9
 Subject /System Boundaries
• Subject is simply the system under
consideration.
• Use cases apply to a subject.

[email protected] 10
 Graphical Representation
• An actor is represented by a stick figure and
name of the actor is written below it.
• Use case is depicted by an ellipse and name of
the use case is written inside it.
• The subject is shown by drawing a rectangle.
• Use cases are drawn inside the rectangle, and
actors are drawn outside the rectangle

[email protected] 11
Graphical Representation cont’d

Use case diagram for a book store

[email protected] 12
 Association between Actors
and Use Cases
• A use case is triggered by an actor.
• Actors and use cases are connected through binary
associations indicating that the two communicates
through message passing.
• An actor must be associated with at least one use case.
Similarly, a given use case must be associated with at
least one actor.
• Association among the actors are usually not shown.
• Indicate that instances of one model element are
connected to instances of another model element
[email protected] 13
 Use Case Relationships
• Three types of relationships exist among use
cases:
– Include relationship
– Extend relationship
– Use case generalization

[email protected] 14
 Include Relationship
• Include relationships are used to depict common
behavior that are shared by multiple use cases.
• an include relationship is a relationship in which one
use case (the base use case) includes the functionality
of another use case (the inclusion use case).
• Include relationship is depicted by a dashed arrow
with a «include» stereotype from the including use
case to the included use case.

[email protected] 15
Include Relationship cont’d

System

Issue book
<<include>>

Check availability
<<include>>

Library Member

verify issue count

[email protected] 16
 Include Relationship cont’d
Example:

• We have a login use case, which is included by compose

mail, reply, and forward email use cases.

[email protected] 17
 Extend Relationship
• Use case extensions are used to depict any
variation to an existing use case.
• In UML modeling, you can use an extend
relationship to specify that one use case
(extension) extends the behavior of another
use case (base).
• Extend relationship is depicted by a dashed
arrow with a «extend» stereotype from the
extending use case to the extended use case.
[email protected] 18
 Extend Relationship cont’d
• The extend relationship specifies that the
incorporation of the extension use case is
dependent on what happens when the base use
case executes.
• While the base use case is defined
independently and is meaningful by itself, the
extension use case is not meaningful on its
own.

[email protected] 19
Extend Relationship cont’d

System

User login

<<extend>>

Member Answer Security Questions

[email protected] 20
 Extend Relationship cont’d
Example:

[email protected] 21
 Generalization Relationship
• Generalization relationship are used to
represent the inheritance between use cases.
• A derived use case specializes some
functionality it has already inherited from the
base use case.
• Generalization relationship is depicted by a
solid arrow from the specialized (derived) use
case to the more generalized (base) use case.

[email protected] 22
 Generalization Relationship cont’d

Example:

[email protected] 23
 Identifying Actors
Given a problem statement, the actors could be
identified by asking the following questions:
• Who gets most of the benefits from the system? (The
answer would lead to the identification of the primary
actor)
• Who keeps the system working? (This will help to identify
a list of potential users)
• What other software / hardware does the system interact
with?
• Any interface (interaction) between the concerned system
and any other system?
[email protected] 24
 Identifying Use cases
• Once the primary and secondary actors have
been identified, we have to find out their goals
i.e. what are the functionality they can obtain
from the system.
• Any use case name should start with a verb
like, "Check balance".

[email protected] 25
 Guidelines for drawing Use Case
diagrams
• Determine the system boundary.
• Ensure that individual actors have well-defined
purpose.
• Use cases identified should let some meaningful
work done by the actors
• Associate the actors and use cases
– there shouldn't be any actor or use case floating without
any connection
• Use include relationship to encapsulate common
behavior among use cases
[email protected] 26
Exercise: Case Study of OBCS

Adobe Acrobat
Document

[email protected] 27
 Functional Requirements
• A proper login system will be provided to each user of the system.
• Administrator will be able to add/delete/edit any system user.
• Administrator will be able to add/edit/delete any department.
• Administrator will be able to change the profile of a user.
• HOD’s will be able to submit the request of budget acquisition for their particular department.
• HOD’s will be able to raise the budget/indent.
• HOD’s will be able to get the response from the Budget Control Module that budget is allocated.
• HOD’s will be able to get the response from the PM that items are purchased.
• HOD will be able to generate different kind of reports like stock reports etc.
• Budget Control Module (BCM) will be able to allocate budget to different departments.
• Budget Control Module will be able to check status of each department.
• Budget Control Module will be able to check/approve/reject budget raised by each department.
• Budget Control Module will be able to accept and reject the budget/indent.
• Purchase Manager (PM) will be able to handle all purchases raised by the departments.
• PM will be able to confirm the departments that item's pertaining to each department is purchased.
• PM will be able to check the status of indents submitted by any department.

[email protected] 28
 Hints
Actors:
• Budget Control Manager
• Purchase Manager
• Head of Dept.
• Admin.

[email protected] 29
 Hints cont’d
Use Cases:
• Login: All Actors
• Allocate Budget, Control Budget, Process Indents: BCM
• Add/Edit/Delete Dept., User, Head, General Settings:
Admin.
• Generate Reports, Search, Check Indent Status, Help: All
Actors
• Purchase Items, Update Indent Status: PM
• Budget Requisition, Raise Indents, Request for stock:
HOD
• Logout: All Actors
[email protected] 30
Use Case Diagram for OBCS

Adobe Acrobat
Document

[email protected] 31
 Assignment2
Case Study: BBLMS

Last Date for Assignment 2 25 Jan. 2017 (Uploaded on

BBLMS).

Adobe Acrobat
Document

[email protected] 32
 Assignments
Case Study
• Assignment I: Functional and Non Functional
Requirements
Last Date: 25 Jan 2017
• Assignment II: Use Case Diagram
Last Date: 25 Jan 2017

[email protected] 33