How can use case relationships make my models more realistic?

Once we start getting used to documenting use cases, both in the written sense and in diagrams, we will probably start to identify particular steps in processes that are repeated. In fact as the use case are gathered and documented, you will find that you seem to be writing the same things over and over again.

What this means is that there are a lot of common steps that are carried out in many different use cases. For instance, read the following use cases and identify the common element:

Buy Product

1. The Customer selects a product and adds it to the shopping cart.
2. The System recalculates the value of the shopping cart and displays it on the screen.
3. The Customer selects 'checkout'.
4. The System asks the Customer to login.
5. The Customer completes the login form.
6. The Customer completes their personal details, including credit card details.

Check Account

1. The Customer selects 'check my account'.
2. The System asks the Customer to login.
3. The Customer completes the login form.
4. The System displays the Customer's account.

Request Catalogue

1. The customer selects 'request catalogue'.
2. The System asks the Customer to login.
3. The Customer completes the login form.
4. The System displays the 'catalogue requested' dialogue box.

In all of the above use cases, the steps 'The System asks the Customer to login' and 'The Customer completes the login form' are common. If we use abstraction to extract this common functionality, and create a new use case called 'login', the new use case might look like this:

Login

1. The System asks the Customer to login.
2. The Customer completes the login form.

This new use case could be referenced by each use case that requires 'login' functionality. But how do we show this on a use case diagram?

UML allows us to represent 'abstracted' use cases by using two specific relationships, include and extend. First, we shall look at the include relationship.