Use case diagram: definition and example

The vocabulary

• An actor is a role using the system: a customer, a seller. It is drawn as a stick figure. Another system (a payment service) is an actor too, drawn as a «system» box.
• A use case is a goal of the actor, named with a verb: place an order, track an order. It is drawn as an ellipse.
• The system boundary is a frame around the cases. Actors stay outside.
• An association links an actor to the cases it uses.

Include, extend and generalisation

• «include»: a case always uses another. Place an order includes Pay. The arrow starts from the including case.
• «extend»: a case adds to another, only sometimes. Apply a promo code extends Place an order. The arrow starts from the optional case.
• Generalisation links two actors: a premium customer is a customer, and inherits its cases.

A common trap: using include and extend to split a case into steps. The diagram is not a flowchart; the steps belong in the case's scenario, or in its user stories.

An example

The online shop of the MCD page.

The customer browses the catalogue, places orders and tracks them. Paying always happens when placing an order, hence the include, with the payment service, a system actor. The promo code is optional, hence the extend.

How to go about it

• List the actors: who uses the system, and which other systems it calls.
• For each, write down their goals. A goal that brings the actor nothing is not a case, it's a step.
• Group the cases by module (catalogue, orders, account) if the system is big.
• Add include and extend only where they avoid repeating something.
• Describe each case with its user stories, then move on to the MCD for the data it handles.

In the macgram editor, the Use cases screen draws actors, cases, include, extend and generalisation, frames the cases by module, and Rearrange tidies it all with as few crossings as possible. Actors and modules are shared with the user stories and link to the entities of the MCD.