Master2Teach YouTube

1. System: The project that you are developing is a system. It could be an application software (desktop, web, or mobile), a website, a software component, a business process, or any other project. The System is represented 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 doesn't happen in the system.

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.

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 another word, the list of tasks that the system can perform is 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. But 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 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 Extend Use Case. The Display Error Message Use Case may or may not execute when 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 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.

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 as below.

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.

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