All about the Software Engineering

Use Case Diagram – Checklist

/0 Comments/in /by
Use Case Diagram Checklist
  1. Check if there are any non-functional requirements in Use Cases.
  2. Check the use case names properly whether it’s an active verb and a noun phrase or not.
  3. Check whether all the use cases are inside the system box or not.
  4. Check whether the use cases are in logical order or not.
  5. Check if there is any overlap and can be fixed by repositioning the use cases or actors.

GA

  1. Check whether the use case diagram contains at least one included relationship or not.
  2. Check whether there is a line between the actors and the Included Use Cases.
  3. Check Whether the include relationship arrow is pointed to Included Use Case or not and if the arrow is labeled with include or not.
  4. Check whether the use case diagram contains at least one extended relationship or not.
  5. Check whether there is a line between the actors and the Extended Use Cases.
  6. Check whether extend relationship arrow is pointed to Base Use Case or not and is arrow labeled with extend or not.
  7. Check whether more than one base use case extends or includes the same extended or included use case carefully.
  8. Check whether the use case diagram contains any generalizations or not.
  9. Check whether the arrow is a solid line with an arrow pointing towards parents actor or parents use case or not. Also, confirm that it doesn’t exist label in the arrow.
  10. If possible, show at least one extension point in the use case diagram.   

Ga

  1. Make sure to represent all actors with a human stick image even for the machine, and external devices, and also contains at least more than one actor in the use case diagram.
  2. Check whether primary actors are shown on the left side or not. Similarly, secondary actors are on the right side or not. 
  3. Check if is there any automatic job doing use cases in the system.
  4. Make sure there is only one rectangle box representing a system where all the use cases are included inside the box and actors are outside of the box.
  5. Check whether you have written the system name inside the box at the top or not.

Use Case Diagram

/0 Comments/in /by

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.

Use Case Diagram

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.

Use Case Diagram
Use Case Diagram

How to start drawing a 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 elements of the USE CASE

  1. System
  2. Actors
  3. Use Cases
  4. 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:
  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 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.

Use Case Actor
Use Case 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:

  1. Include
  2. Extend
  3. 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.

Include Extend Use Case
Include Extend Use Case

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.

Generalization Use Case
Use Case 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.

User Case Extension
User Case Extension

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.
High-Level Use Case Description