Use Case Diagram

In this USE CASE DIAGRAM step by step tutorial, you will learn how to make USE CASE Diagrams from the beginning to end including HIGH LEVEL USE CASE DESCRIPTION, EXTENDED USE CASE DESCRIPTION, ALTERNATIVES as well as ACTIVITY DIAGRAM.

To explain all system to someone else is quite difficult. The explainer may be forgetting some main features of the system while the listener may have lost what actually he/she is talking about. Explainer thinks that he has explained very well but actually, the listener may not understand it. For example, you want to make a new app and explain it. But the listener doesnt understand how they will interact with the app or what it would do.

In this type of scenario, the Use Case Diagram is very helpful. Simply it shows a system or application, people or organization, or others that interact with the system, basic flow the system what the system or application does. Its a very high-level diagram and typically wont show a lot of detail, but its a great way to communicate complex ideas in a fairly basic way.


Use case show the functionality of a system from the users perspective. Each Use case name is usually an active verb and a noun phrase. Use case diagram is usually used to model a current system as well as to model a proposed system.

How to start drawing Use Case Diagram

  1. List use cases and identify the actors.
  2. Prioritize use cases and focus from the top of the list.
  3. Develop each of the priority use cases starting with writing a description for each.

4 different elements of the USE CASE DIAGRAM

  1. System
  2. Actors
  3. Use Cases
  4. Relationships
Use Case System

1. System: The project that you are developing is a system. It could be an application software (desktop, web, or mobile), a website, software component, business process, or any other projects. The System is representing with a rectangle shape where the system name is written inside the top of the system. The rectangle shape helps to define the overall scope of the system that you are going to develop. So that everything that the system does job places inside the system whereas anything outside the rectangle doesnt happen in the system.


Actor

2. Actor: The Actor is representing by the human stick image. Anyone how use to perform a certain function in the system is actors. Actors maybe someone or something that can be a person, an organization, another system, machine, or an external device. So who or what is going to using our system is Actors like customer, staff, admin, bank, student, teacher, etc.

Type of Actors:

primary secondary actor
Primary Secondary Actors
  1. Primary Actors
  2. Secondary Actors

A primary actor initiates the use of the system while the secondary actor is more reactionary. For example, customers are the primary actors because the system is mostly used by the customer whereas Bank is a secondary actor because the bank is only going to perform certain functions once the primary actor does something. In other simple words, primary actors request something to the system and secondary actor response to the primary actors.

Primary Actors should be position in the left of the system whereas Secondary Actors are placed on the right side of the system.

Use Cases

3. Use Case: All the functionality that the system does is the USE CASE. In another word, the list of tasks which the system can perform is Use Case. Use Case is denoted by the oval shape. For example: – log in, check balance, transfer fund, make payment, display error message, verify log in details, etc. Its good practice to put the Use Cases in a logical order where possible like login (1st job), book service (After Login Job), make payment (After Book Job)

Relationship in Use Case

4. Relationship: As we know, an actor uses the system to achieve a goal by interacting at least one of the Use Cases within the system. For example: Customers can log in, book the service, make payments, etc. So we draw the solid line between the Actor and the Use Case to show the relationship. This type of relationship is called an association and it just signifies a basic communication or interaction.

Type of Relationship in addition to association:

  1. Include
  2. Extend
  3. Generalization
Include relationship
Include relationship

Whenever a customer requests the login, the system will automatically call the login verification Use Case before completing the login process. But if the log in detail is incorrect, the system will display an error message. So Error Message is another extra Use Case to show the relationship. Neither of the actors is directly initiating these (Verify Login, Display Error Message, etc.) Use Cases. They are just immediately going to happen within the system whenever the actor performs the Log in Use Case. The relationship between the Login Use Case and the Verify Login Details Use Case is INCLUDE which is written as <<include>> because as the Login Use Case is called by the actor, Verify Login Details Use Case is automatically performed by the system. Here Login Use Case is the Base Use Case whereas Verify Login Details is an Included Use Case. In include relationship, whenever the base use case is in execution, the included use case is auto executed as well. In another way, the base use case requires an included use case in order to be complete. For showing Include Relationship, draw a dashed line with an arrow that points towards the included use case and write <<include>> as a label.


Extend Use Case
Extend relationship
Extend Use Case
Extend Relationship

Another type of relationship is Extend Relationship where it defines the relationship between the Base Use Case and the Extend Use Case. In Extend relationship, the extend use case may or may not execute when the base use case is executing. The extended use case will only happen if certain criteria are met. In the above example, the Login is a base use case whereas the Display Error Message is Extend Use Case. The Display Error Message Use Case may or may not execute when Base Use Case (Login Use Case) is executed. For the Extend Relation between the base and extend use case, draw a dashed line with an arrow that points towards the base use case and write <<Extend>> as label between them.

Include extend example
Include Extend Example

Another the best example to demonstrate the difference between include and extend relationships is: if you sneeze, you will close your eyes. Thats an included relationship because its going to happen every time when we sneeze. Whereas, if you sneeze, you might say excuse me. Thats an extended relationship because it supplements the sneeze, but isnt completely necessary in the sneezing process.

Note: Include happens every time, extend happens just sometimes and dont forget that the arrows point in opposite directions. Also multiple base use cases can point to the same included or extended use case. Avoid premature use, overuse, and misuse of the <<include>> and <<extend>> relationships.


The Simpler your diagram, the Better. When producing a Use Case Model always keep in mind what you are trying to portray and for what purpose.

Use Case Generalization
Use Case Generalization
actor generalization
Actor Generalization

Another type of relationship is Generalization, also known as inheritance. Generalization is showing the relationship between the parent and the child use case relationship. In simple words, generalization is showing the type of actor or use case in the system. For the generalization relationship, draw a solid line with an arrow from the child use case or actor to parent use case or actor as shown below.

For example, the system has New Customer as well as Old Customer which can be shown in generalization as below.

Extra Bonus:


Extension Points
Extension Points

Another type of Notation is Extension Points. Extension points are just a detailed version of extended relationships. And also can be shown in the note what sort of conditions would lead to these extension points.

In this way you can draw the complete Use Case Diagram with various elements that help explain what the system does.

Note: Even complex systems should be restricted to a simplistic visualization of functionality, behavior, and relationships.

Types of Use Case Descriptions

  1. High Level A general description
  2. Expanded (Detailed) Step by step
  3. Essential – free of technological detail
  4. Real adds technological detail

High Level Use Case Description: A short non-detailed description of each required process. Do not go into details on the interaction.

Example: High Level Use Case Description

Use Case:Enroll Student
Actor:New Student
Description:A new student provides personal details and his/her choice of course to the system. He/She pays fees and receives confirmation of enrollment.

Leave a Reply

Your email address will not be published. Required fields are marked *