A use case diagram captures system functionality and requirements by modeling actors and use cases. Actors represent roles that interact with the system, while use cases represent system functions. A use case diagram visually shows the relationships between actors and use cases. An include relationship shows that one use case includes the functionality of another, while an extend relationship shows optional or conditional behavior. Generalization defines one use case as a generalization of another to replace generic functionality.

1. Use Case Diagram

2. What is Use Case Diagram?
• Use Case Diagram captures the system’s functionality and
requirements by using actors and use cases.
• Use Cases model the services, tasks, function that a system needs to
perform.
• Use cases represent high-level functionalities and how a user will
handle the system.
• Use-cases are the core concepts of Unified Modelling language
modeling.

3. Use Case Diagrams
• Use Case Diagrams provide a visual way to document user goals and explore possible
functionality
• Three primary modeling components:
• Actors
• Use Cases
• Relationships between use cases
Authorized
Staff Worker
Teacher
Student
Record class
grades
Review
Transcripts

4. Why Use-Case Diagram?
• A Use Case consists of use cases, persons, or various things that are
invoking the features called as actors and the elements that are
responsible for implementing the use cases.
• Use case diagrams capture the dynamic behaviour of a live system.
• It models how an external entity interacts with the system to make it
work.
• Use case diagrams are responsible for visualizing the external things
that interact with the part of the system.

5. When to use a use-case diagram?
In general use case diagrams are used for:
• Analyzing the requirements of a system
• High-level visual software designing
• Capturing the functionalities of a system
• Modeling the basic idea behind the system
• Forward and reverse engineering of a system using various test cases.

6. Use-case diagram notations
Use-case:
Use cases are used to represent high-level functionalities and how the
user will handle the system. A use case represents a distinct
functionality of a system, a component, a package, or a class. It is
denoted by an oval shape with the name of a use case written inside
the oval shape. The notation of a use case in UML is given below:

7. Use-case diagram notations
• Actor:
Actors can be a human user, some internal applications, or
may be some external applications
The actor is an entity that interacts with the system. A user
is the best example of an actor.
An actor is an entity that initiates the use case from outside
the scope of a use case.
One actor can be associated with multiple use cases in the
system. The actor notation in UML is given below.

8. How to draw a use-case diagram?
• Following rules must be followed while drawing use-case for any
system:
• The name of an actor or a use case must be meaningful and relevant to the
system.
• Interaction of an actor with the use case must be defined clearly and in an
understandable way.
• Annotations must be used wherever they are required.
• If a use case or an actor has multiple relationships, then only significant
interactions must be displayed.

9. Example Use Case Diagram
Coming up: Use Case Diagrams

10. Relationships Between Actors
• Actors can be related by generalization/specialization
• Generalization of an actor means that one actor can inherit the role
of the other actor. The descendant inherits all the use cases of the
ancestor. The descendant has one or more use cases that are
specific to that role

11. Use Case Relationships
Includes
Extends
Generalization
After a while you realize extends and generalization are not too
different. Just know generalization and includes… forget about
extends (the difference is only in intent)

12. <<Include>> Relationship
In UML modeling, 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).
The include relationship supports the reuse of functionality in a use-case model.
Includes Dependency: Defines how one use case can invoke behavior defined by
another use case
Few things to consider when using the <<include>> relationship.
• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.
.

13. <<Include>> Relationship
For example – both withdraw money and deposit
money use case require the customer to login
The <<include>> association specifies that to
accomplish the use-case withdraw money the user
must login to the account

14. <<Include>> Relationship

15. <<include>> Relationships
• In an online retail system if Make a Purchase is a use case what could
be the included use case?
Make a
Purchase
Verify Credit
Cards
<<include>>

16. <<include> Relationship
• In an ATM system, what common use case can be included for both
withdraw cash and transfer funds use case?
Withdraw
cash
Transfer
Fund
Verify
Balance
<<include>>
<<include>>

17. <<extend>> Relationships
• Extends dependency: defines a use-case that is a variation of another,
usually for handling an abnormal situation
• You can add extend relationships to a model to show the following
situations:
• A part of a use case that is optional system behavior
• A subflow is executed only under certain conditions
• A set of behavior segments that may be inserted in a base use case

18. <<extend>> Relationships

20. Use-Case Relations
• Generalization: Defines one use case as a generalization of another.
Replaces generic functionality with alternate implementation
Teacher
Alter Student
Grade
Alter Student Grade for
a Graduate Course
20
Coming up: Documenting Use Cases