Use Case Diagram
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 Descriptions, Extended Use Case Descriptions, Alternatives as well as ACTIVITY diagrams.
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 he/she is talking about. The explainer thinks that he has explained very well, but the listener may not understand it. For example, you want to make a new app and explain it. However, the listener doesn’t know how they will interact with the app or what it will do.
GA
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 and a proposed system.
How to start drawing a Use Case Diagram?
- List use cases and identify the actors.
- Prioritize use cases and focus from the top of the list.
- Develop each of the priority use cases starting with writing a description for each.
4 elements of the USE CASE
- System
- Actors
- Use Cases
- Relationships
2. Actor: The Actor is represented by the human stick image. Anyone who used 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:
- Primary Actors
- 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 the 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.
Primary Actors should be positioned to the left of the system whereas Secondary Actors are placed on the right side of the system.
3. Use Case: All the functionality that the system does is the USE CASE. In other words, the list of tasks that the system can perform is a Use Case. Use Case is denoted by the oval shape. For example: – login, check balance, transfer funds, 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)
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:
- Include
- Extend
- Generalization
Whenever a customer requests the login, the system will automatically call the login verification Use Case before completing the login process. However, if the login 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 the 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.
Another type of relationship is Extend Relationship which defines the relationship between the Base Use Case and the Extend Use Case. In the Extend relationship, the extended 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 an Extend Use Case. The Display Error Message Use Case may or may not execute when the Base Use Case is executed. For the Extend the Relation between the base and extend use case, draw a dashed line with an arrow that points towards the base use case and write as << Extend >> label between them.
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 whenever 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.
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 a New Customer as well as an Old Customer which can be shown in generalization.
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.
Types of Use Case Descriptions
- High Level A general description
- Expanded (Detailed) Step by step
- Essential – free of technological detail
- 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. |
