What does the 'include' relationship in use case diagrams mean?

 

Rectangular Callout: 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. Continuing with the previous example, our use case diagram would look like this:

 

 

 

 


 

 


Of course we wouldn't normally show the written descriptions of the use cases, but these are here just as a reminder. Within the three use cases identified, we have noticed that some steps are being repeated and we can therefore use abstraction to define another use case called 'login'.

So the notation so far allows us to draw the new use case, but how do we integrate it with our existing diagram?

 

UML provides for this with the 'include' relationship. This allows us to abstract common functionality, and 'include' it within multiple other use cases. When we looked at a use case being stimulated by an actor, we represented the interaction by drawing a solid line between the actor and the use case.

 

We are still representing a use case being stimulated, but this time another use case is providing the trigger instead of an actor. The UML notation for this is as follows:

 

 

 

 

 

 

 

 

 

 

Rectangular Callout: Note the dashed line, open arrow head and direction of the arrow - these are all part of the notation and important. 

 

 

 

 

 

 


So our revised diagram becomes:

 

 

 

But what are we actually saying with the <<include>> statement?

 

The <<include>> label means that each of the base use cases has some functionality that 'includes' the 'login' use case. We cannot therefore buy a product, check an account or request a catalogue without interacting with the login use case. In each scenario, to successfully complete the steps in the use cases, we must complete the login function.

 

In other words, an <<include>> relationship means that the included use case is mandatory if we are to complete the base use case. It follows that the included use case cannot function without the use cases (or actors) that call it. In fact there is no way that the included use case recognises whether it has been included by another use case, so it cannot be dependent on the including use case. However what is an included use case, to an including use case, may be a complete use case in its own right, and therefore might be stimulated by an actor.

 

Consider the scenario below. The Customer actor wants to check their account. Therefore a 'Check account' use case is provided.

'Login' has been identified as a use case that can be reused by other use cases, and is included within the operation of 'Check account'.

 

So 'Check account' is not a complete use case as it needs to <<include>> 'Login' for it to function properly. However 'Login' is a complete use case, and it is feasible that a Customer might want to Login as an independent interaction.

 

Although you can use <<include>> to specify as many levels of use case as you desire, beware of breaking use cases down to far - the further they are broken down, the more you will suggest sequence in your model. Use case models should not imply sequence in operation. UML provides other notations to explore sequence.

 

Sometimes though, we might have some common functionality, but we don't want to use it all the time. To model this, we need to look at <<extend>> relationships.