UML - Use Case Diagrams

In this article, I will explain some facts you should know when drawing Use Case Diagrams; using an example of an Online Hotel Reservation System.

First, let's see what are the functional requirements of the system.

• Should be able to search hotels.
• Should be able to make a reservation.
• Should be able to make the payment.
• Should be able to validate the credit card.
• Should be able to issue payment confirmation receipts.
• Should be able to cancel the reservation.

We get functional requirements as use cases of the system. Use cases are represented in an oval shaped symbol. Therefore our use cases are,

Then we should identify the actors of the system to be designed.In this example, there are two such actors,

1. Customer
2. Payment Gateway

Primary actors are the main users of the system, in our scenario, it is the Customer and Secondary actors are other users including external systems, here it is the Payment Gateway. Actors are represented using a human user icon as the following,

Therefore customer use cases and payment gateway system use cases can be represented as follows and note that the association between an actor and a use case is shown using a solid line.

There are dependency relationships that we consider in use case diagrams. The three major types are,

• Include
• Exclude
• Generalization

Use of Include: When a certain use case is invoked by another use case this relationship is used.

Example: 

In our scenario, the credit card should be validated before making a payment and if there are any issues with the credit card, hence credit card validation failed, then the payment cannot be made. Here the invoking use case is 'Make the Payment' and included use case which invoked that is 'Validate the Credit Card'.

The standard way of representing the ‘include dependency relationship’, is to draw the ‘included use case’ on the right side of the ‘invoking use case’ as shown above.

Use of Extend: Extending use cases are the use cases, extending from another use case and are optional use cases and are not major functionalities.

Example:

In our scenario, 'Print the Payment Receipt' is an optional use case extended from 'Make the Payment' base use case.

It is a good practice to draw the extending use case below the base use case.

To represent these dependency relationships, ‘dotted arrows’ are used. And the standard is to point the arrow to ‘Included use case’  and to ‘Base use case’ in  ‘include dependency’ and ‘extend dependency’ respectively.

Use of Generalization: Generalization can be between either use cases or actors.

As an example, let's assume doing a transaction in an ATM machine. Transfer money and withdraw money are types of transactions and therefore 'Transfer Money', 'Withdraw Money' can be considered as uses cases derived from 'Do a Transaction' use case.

When it comes to actors, Cooperate customer is a kind of a customer.

So far I have explained the facts you should know when drawing a use case diagram. Now, let's see a complete use case diagram of the Online Hotel Reservation System. We are representing the use cases within a square and that is called the boundary of the system. Name of the system should be written on the top of the boundary square.  

Actors are drawn outside the boundary and the standard way of drawing an actor is, primary actors on the left side and secondary actors on the right side.

Use cases are drawn within the system boundary and they should follow the facts I have explained before. Therefore the use case diagram for online hotel reservation system can be drawn as shown below.

I hope you learnt the basics of drawing use case diagrams from this article and Good luck on your UML studies!