Use Case Diagram – Step by Step Tutorial with Example

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

To explain all systems 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. The 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 doesn’t 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 organizations, or others that interact with the system, the basic flow of the system what the system or application does. It’s a very high-level diagram and typically won’t show a lot of detail, but it’s a great way to communicate complex ideas in a fairly basic way.

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

Usecase Diagram

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

2. Actor: The Actor is represented by the human stick image. Anyone who use to perform a certain function in the system is an actor. Actors may be someone or something that can be a person, an organization, another system, a machine, or an external device. So who or what is going to using our system is Actors like customers, staff, admin, bank, students, teachers, etc.

Type of 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 from the system, and secondary actors respond to the primary actors.

Usecase Actor Types

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

4. Relationship: As we know, an actor uses the system to achieve a goal by interacting with 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 a 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

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

Note: Include happens every time, extend happens just sometimes, and don’t 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.

Usecase Extend Include

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.

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 the 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.

Usecase Generalization

Extra Bonus:

Another type of Notation is Extension Points. Extension points are just detailed versions of extended relationships. It 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.

Usecase Extension Points

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.

Master2Teach YouTube Channel

In this YouTube Channel, you can find different kind of useful tutorials related to information technologies.