Professional Documents
Culture Documents
Exp 3 Modeling UML Use Case Diagrams and Capturing Use
Exp 3 Modeling UML Use Case Diagrams and Capturing Use
Exp 3 Modeling UML Use Case Diagrams and Capturing Use
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
prashant.udawant@nmims.edu 2
Prerequisite
• Knowledge of Requirements Document.
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 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 .
prashant.udawant@nmims.edu 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.
upendra.verma@nmims.edu 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.
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 9
Subject /System Boundaries
• Subject is simply the system under
consideration.
• Use cases apply to a subject.
prashant.udawant@nmims.edu 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
prashant.udawant@nmims.edu 11
Graphical Representation cont’d
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 15
Include Relationship cont’d
System
Issue book
<<include>>
Check availability
<<include>>
Library Member
prashant.udawant@nmims.edu 16
Include Relationship cont’d
Example:
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 19
Extend Relationship cont’d
System
User login
<<extend>>
prashant.udawant@nmims.edu 20
Extend Relationship cont’d
Example:
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 22
Generalization Relationship cont’d
Example:
prashant.udawant@nmims.edu 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?
prashant.udawant@nmims.edu 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".
prashant.udawant@nmims.edu 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
prashant.udawant@nmims.edu 26
Exercise: Case Study of OBCS
Adobe Acrobat
Document
prashant.udawant@nmims.edu 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.
prashant.udawant@nmims.edu 28
Hints
Actors:
• Budget Control Manager
• Purchase Manager
• Head of Dept.
• Admin.
prashant.udawant@nmims.edu 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
prashant.udawant@nmims.edu 30
Use Case Diagram for OBCS
Adobe Acrobat
Document
prashant.udawant@nmims.edu 31
Assignment2
Case Study: BBLMS
Adobe Acrobat
Document
prashant.udawant@nmims.edu 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
prashant.udawant@nmims.edu 33