USE CASE DIAGRAMS
Ever had a brilliant project
idea? The idea making a lot
of sense to you but you are
failing to put it across to
another person?
Or that person is simply
failing to understand it?
A Use case diagram can assist in
clarifying the high level operations
of a system without finer details of
how the system will be
implemented.
WHAT IS A USE CASE DIAGRAM?
It is the primary form of
system requirements for
a new software program to
be developed.
It specifies the expected
behaviour (what), and not
the exact method of making
it happen (how).
It helps us design a system
from an end user's
perspective.
• A use case diagram is usually simple.
• It summarizes some of the
relationships between use cases,
actors, and systems.
• It does not show the order in
which steps are performed to
achieve the goals of each use case.
PURPOSE OF USE CASE DIAGRAM
• Use case diagrams are typically
developed in early stage of
development.
• Often applied for the following
purposes:
• To specify the context of a
system
• To capture the requirements of
a system
NOTATION AND VISUAL REPRESENTATION
• Actor
• Anything that interacts with the system.
• Can be a user (different types of users), or
another system.
• A system can have two types of actors,
primary and secondary actors.
• Primary actor can initiate use cases. E.g.
user requests for authentication.
• Secondary actors are more of reactionary
actors. E.g. user receives notification.
• Each actor must be linked to at least one
NOTATION AND VISUAL REPRESENTATION
Use Case
• This is the functionality provided by the
system.
• Some use cases may be linked to an
actor,
• While some may not be linked to
NOTATION AND VISUAL REPRESENTATION
Communication link
• The participation of an actor in a use
case is shown by connecting an actor
to a use case by a solid link.
NOTATION AND VISUAL REPRESENTATION
Boundary of • The system boundary is the
system entire system as defined in
the requirements document.
• For large and complex systems,
each module may be the
system boundary.
• E.g, in an ERP system for an
organization, each of the
modules such as personnel,
payroll, accounting, etc. can
form a system boundary for use
STRUCTURING USE CASE DIAGRAM WITH
RELATIONSHIPS
• A relationship between two use cases is
basically modeling the dependency
between the two use cases.
• Reduces the overall effort required in
developing a system. (by reuse of
existing use cases)
• One use case can be connected to
another use case by an include or
extend relationship
RELATIONSHIPS
Extend
• Represents an optional behaviour / use
case
• Base use case is complete on its own
• Extended use case is optional
• Arrow points to the base use case.
Examples of extend relationship
It is optional for a user It is also not mandatory
to get help while filling for a user to give
a form feedback while booking
a ticket.
The two child use cases (Get Help and
Feedback) are functionalities that the
system can provide to the user during
filling form and Ticket booking if the user
RELATIONSHIPS
Include
• Represents a mandatory behaviour / or
functionality that should be present in the
base use case
• Base use case is incomplete on its own,
so it has to include the functionality of
another use case which is usually
common to a number of other base use
cases.
Examples of include relationship
To place an order, the
system has to provide a
login functionality also
To transfer
funds, the
system will
have to
verify
sufficient
funds firstto
Similarly,
make a
payment, the
system will
have to verify
sufficient
RELATIONSHIPS.
Generalization
• a child use case inherits the behaviour of
the parent use case.
• The child may add or override the
behaviour of the parent.
Generalization is represented by a directed
arrow with a triangle arrowhead.
The tip of the arrow is connected to the
parent use case.
Example - Generalization Relationship
• The search use case is a parent/base use
case
• When a user wants to search, the system
will have to provide the option to either
Search by Call number or Search by
EXAMPLE: ATM USE CASE DIAGRAM
SOMEONE CAN
• MAKE A
WITHDRAWAL
• CHECK BALANCE
• RESET PIN
• CONDUCT
MAINTENANCE
WORK
EXAMPL Add/Modify/update
students details like
E2 name, address.
Add/Modify/Update
Subject information
semester wise
Include entry of marks and
assignment of credit points
for each paper
Provide way to enter
through user id &
password.
Print various reports
(i) According to course code
(ii) According to Enrollment
number/registration number
HOW TO IDENTIFY ACTOR
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically?
HOW TO IDENTIFY USE CASES?
• The following questions can be asked to identify use cases, once
your actors have been identified
• What functions will the actor want from the system?
• What actors will create, read, update or delete this information?
• Does the system need to notify an actor about changes in the
internal state?
• Are there any external events the system must know about?
• What actor inform the system of those events?
USE CASE DIAGRAM TIPS
• Always structure and organize the use case diagram from
the perspective of actors.
• Use case diagrams are based upon functionality and thus
should focus on the "what" and not the "how".
