The Use Case Diagram

A use case is a goal, not a screen or a step

The specification says a use case yields "an observable result that is of value for Actors or other stakeholders". Chapter 12 turned that into two tests: can the actor see the result, and would they call it worth the visit? "Place an order" passes. "Click Submit", "Validate quantity" and "Home page" do not: they are steps and screens, not goals.

Include and extend, and the direction of the arrow

Both are dashed arrows with a keyword, and students reverse them more than anything else in UML. The specification settles it with one idea: the arrow points from the use case that depends to the use case it depends on.

• Include. The base use case cannot be complete without the included one, which always runs as part of it. So the base depends on the included use case, and the arrow runs from the base to the included. Use it when two or more use cases share the same steps. The specification's own example is a cash machine, where "Withdraw" includes "Card Identification"; a "Check balance" use case would include it too.
• Extend. The extended use case is complete and meaningful on its own; the extension only adds behaviour to it, at an extension point, when a condition holds. So the extension depends on the base, and the arrow runs from the extension to the base.

The extended use case lists its extension points inside its ellipse, under the heading "extension points", each as a name with an optional explanation. The condition of the extend may be shown in a note attached to the arrow; the specification makes that note optional.

Lines, not flow

A use case diagram is not a flowchart. It says nothing about the order in which use cases happen. The specification goes further: two use cases of the same system cannot be joined by a plain association at all, because each describes a complete use of the system. Between use cases there are only three relationships: include, extend and generalisation.

The worked diagram

The worked team drew its diagram from Chapter 12's thirteen use cases:

Figure 20.1 The worked team's use case diagram, drawn by PlantUML from the source below

@startuml use-case
!pragma layout smetana
left to right direction
skinparam actorStyle awesome

actor Student
actor "Counter staff" as Staff
actor Owner
Owner -|> Staff

rectangle "Canteen Pre-order" {
  usecase "Register" as UC1
  usecase "Sign in / sign out" as UC2
  usecase "Browse today's menu" as UC3
  usecase "Place an order" as UC4
  usecase UC5 as "View my orders
--
extension points
cancel: an order
is still placed"
  usecase "Cancel an order" as UC6
  usecase "View orders by slot" as UC7
  usecase "Update order status" as UC8
  usecase "View kitchen list" as UC9
  usecase "Manage the menu" as UC10
  usecase "Set today's stock" as UC11
  usecase "View daily report" as UC12
  usecase "Create staff account" as UC13
}

Student -- UC1
Student -- UC2
Student -- UC3
Student -- UC4
Student -- UC5
UC6 .> UC5 : <<extend>>
Staff -- UC2
Staff -- UC7
Staff -- UC8
Staff -- UC9
Owner -- UC10
Owner -- UC11
Owner -- UC12
Owner -- UC13
@enduml

Reading it

Three actors. Student, Counter staff and Owner, the user classes of Chapter 5. All three are human, and there are no system actors: the one outside system a canteen might have, a payment service, is out of scope in this release (constraint C-5).

The owner is a kind of counter staff. The hollow triangle from Owner to Counter staff is a generalisation: the owner can take part in every use case the counter staff can, signing in, viewing orders by slot, updating an order's status and viewing the kitchen list, as well as in the four that are hers alone. The diagram does not draw those four lines again for the owner; the triangle says it.

Thirteen use cases, UC-1 to UC-13, each realising at least one functional requirement (Chapter 12's table).

One extend. Cancel an order extends View my orders. A student cancels only from the list of their own orders, and only while an order is still placed, so cancelling is optional behaviour added to viewing, at one point, under one condition. View my orders names that point in its ellipse: cancel: an order is still placed. The student has no line of their own to Cancel an order, because they reach it only through the use case it extends.

No include. Most of the use cases need the user to be signed in, and many textbooks would draw «include» from each of them to Sign in. The team did not, for the reason Chapter 12 gave: signing in is a goal of its own, UC-2, and a precondition of the others, not a shared fragment of them.

Who is not an actor. The kitchen staff read the kitchen list every day, but no cook signs in: the counter staff open the list on the counter's screen. The kitchen is a stakeholder that benefits from UC-9, not an actor that interacts with the system, which is why the specification's phrase is "of value for Actors or other stakeholders". And FR-4 shows the menu to everyone, signed in or not. The team drew only the Student against Browse today's menu: the people who look at the menu are students deciding what to eat, and a role is held before signing in as well as after.

The source, line by line

• actor Student draws an actor. actor "Counter staff" as Staff gives a name with a space a short alias to use in the lines below.
• Owner -|> Staff is the generalisation, with the triangle at the Staff end.
• rectangle "Canteen Pre-order" { ... } is the system boundary; everything declared inside it is drawn inside it.
• usecase "Register" as UC1 is a use case. UC5 is written the other way round, with its text in quotes after as, so that its text can run over several lines: the line -- draws the divider, and the lines after it are the extension points compartment.
• Student -- UC1 is an association: a plain line.
• UC6 .> UC5 : <<extend>> is the extend: a dashed arrow from UC6 to UC5, labelled.
• left to right direction puts the actors on the left, and skinparam actorStyle awesome draws each actor as a head and shoulders rather than a stick figure, which the specification allows: other icons may denote an actor.

Checking it

The diagram passes the first two of Chapter 19's checks. Every one of the seventeen functional requirements is realised by a use case, and every use case realises at least one, so the diagram is a complete index of the SRS's functional requirements (Chapter 34). And every actor is a user class of the SRS.

It also passes a check of its own: every actor has at least one association, and every use case has an actor, directly, through the owner's generalisation, or, for Cancel an order, through the use case it extends. A use case nobody can reach is a requirement nobody asked for.

Do this for your project

1. Draw the boundary first and name it after your system.
2. Put your actors outside it: roles from your stakeholder register, and any outside system your system talks to.
3. Put one ellipse inside for each use case from your use-case analysis, named verb first.
4. Join each actor to the use cases whose goals are theirs.
5. Draw a generalisation where one actor can do everything another can, and more.
6. Add include only for steps two or more use cases really share, and extend only for optional behaviour at a named point; list that extension point in the extended use case.
7. Check the arrows' direction: from the use case that depends to the one it depends on.
8. Check that every requirement has a use case, every use case has a requirement, and every use case can be reached by an actor.

Mistakes examiners circle

Include and extend reversed. The most common single error in student use case diagrams. Say the rule aloud before drawing each arrow.

«include» from every use case to Log in. Signing in is a precondition, or a use case of its own; it is rarely a shared fragment.

Use cases that are screens or steps. "Home page", "Click Submit", "Validate input".

Lines between use cases with no keyword, showing the order in which things happen. A use case diagram has no flow.

The system, or its database, drawn as an actor. Actors are outside the boundary; the database is inside.

Actors named after people. "Lata" is a person; "Owner" is a role.

Actors inside the boundary, or no boundary at all.

Forty use cases on one page. Split the diagram by actor or by part of the system.

Quick revision

• Actor: a role outside the system (human, hardware or another system); stick figure or «actor» rectangle.
• Use case: a goal with an observable result of value; an ellipse inside the system boundary rectangle.
• Association: a solid line between an actor and a use case. No plain lines between use cases.
• Include: dashed arrow from the base to the included use case, which always runs.
• Extend: dashed arrow from the extension to the extended use case, optional, at an extension point, under a condition.
• The rule: the arrow points from the use case that depends to the one it depends on.
• Generalisation: hollow triangle pointing at the general actor or use case.

Questions you must be able to answer

1. What does a use case diagram show? The actors outside the system, the use cases inside its boundary, which actors take part in which use cases, and the include, extend and generalisation relationships between use cases and between actors. It shows what the system does for whom, not the order in which things happen.

2. Which way does the arrow go for include, and for extend? Why? For include, from the base use case to the included one; for extend, from the extending use case to the extended one. In both cases the arrow points from the use case that depends to the one it depends on: a base needs what it includes, while an extended use case is complete without its extension.

3. What is an extension point? A named place in a use case at which an extending use case may add its behaviour. It is listed inside the extended use case's ellipse under the heading "extension points", with an optional explanation.

4. Why is the owner drawn with a generalisation arrow to the counter staff? Because the owner can take part in every use case the counter staff can, as well as her own. The generalisation says so once, instead of repeating four associations.

5. The kitchen staff use the kitchen list. Why are they not an actor? Because they do not interact with the system: no cook signs in, and the counter staff open the list for them. They are stakeholders who benefit from the use case, and UML's definition of a use case allows its value to go to stakeholders other than its actors.

6. Why is there no «include» to Sign in? Because signing in is a goal in its own right and a precondition of the other use cases, not a fragment of behaviour they share. Drawing an include to it from every use case that needs it adds an arrow to most of the diagram and no information.