How do I construct a use case diagram?

Use case diagrams in UML require that we have identified some actors and use cases, and are able to describe them using the correct notation.

We can forge ahead even if we haven't identified all of the actors and use cases; we should use the diagrams as a means of recording our thoughts and communicating our findings as we progress.

The design of a system is an iterative process and we must gradually refine our descriptions and models as we acquire more knowledge of the system.

Fortunately use case diagrams are easy to draw and therefore we can use them as a discussion tool.

Actors are represented by a stick person, with a description of the role underneath.

Use cases are represented by an oval, with a descriptive name inside.

Some people find it difficult to 'name' use cases - as a general rule the use case name should be a verb and noun phrase. What this means is that the name must describe an action on a particular thing.

Example use case names are:

Return product Deliver packages Borrow book Fulfil order

Produce accounts Write review Replenish stock

Now that we have some notation, we can construct our diagram. Here is an example of an online shop.

We haven't identified every use case, but this is sufficient to obtain an overall view of the system. Of course for each use case name, we have a written description of the underlying system behaviour.

Each use case is associated with an actor by using a plain line. This illustrates which actors interact (or stimulate) which use case. For instance, it is clear that the 'Stores' role interacts with the 'Maintain stock' use case, and the 'Customer' role interacts with the 'Order Product' and 'Browse Store' use cases.

As actors are by definition external to the system, we can simply draw a border around our internal use cases and use this to define the scope of our system. Use case diagrams are a powerful method of demonstrating the system boundary to a customer, and are much easier to construct and understand than written use case descriptions.

As we analyse and explore the system requirements, we will start to identify particular use cases that are used in different parts of the system. If we can generate use cases that provide common functionality, that can be re-used in several scenarios, then we will save ourselves some work in the future.

To do this we will need to look at use case relationships.

Review Question

Test your understanding of this topic with the following question:

Consider the purchase of some food from a fast-food outlet. Identify the actors and use cases and construct a use case diagram. Indicate on your diagram the system boundary.