A use case diagram shows **who** can do **what** with your system. Actors (the *who*) sit outside the system boundary; use cases (the *what*) sit inside. It is the third of the three C02 analytical diagrams and is hand-drawn under timed conditions in the C2-2 validation.

---

A use case diagram answers two questions in one picture:

- **Who interacts with the system?** (Actors — people *and* external systems)

- **What can each one do?** (Use cases — functions the system performs for them)

It is **not** a flowchart. It says nothing about the order of actions, the user interface, or how a function is implemented. Save those for other diagrams.

---

| Element | Symbol | Rule |

|---|---|---|

| **Actor** | Stick figure, *outside* the system rectangle | A person *or* external system that interacts with yours. Examples: *Teacher*, *Student*, *Payment Gateway*, *Email Server*. |

| **Use case** | Oval, *inside* the system rectangle | A function the system performs *for* an actor. Named verb-noun: *"View Timetable"*, *"Generate Report Card"*. |

| **System boundary** | Rectangle around the use cases | The labelled scope of the software you're building. Actors live outside; use cases live inside. |

One actor, one use case, one system. *"A Teacher can generate a student report card."*


Same notation, more actors and use cases. Each actor has at least one solid line to a use case (an *association*).


---

Different lines mean different things. Master these four and you have everything C2-2 needs.

**Solid line** between an actor and a use case. *"This actor participates in this use case."* This is the most common relationship — every actor needs at least one.

**Solid line with a hollow triangle pointing to the parent.** The child inherits everything the parent can do. Useful for role hierarchies (an Administrator can do everything a Teacher can, plus more).


In this example, *Student* is associated only with *View Timetable* and *Receive Notifications* — but because *Teacher* generalises *Student*, a Teacher inherits those associations too. The diagram only draws the **new** associations at each level.

**Dashed line with `«include»` label**, arrow pointing **TO the included use case**. *"The base use case **always** does this other use case as part of its work."*


You can't edit a user without first loading them — so *Edit User* **includes** *Load User*. Every time *Edit User* runs, *Load User* runs.

**Dashed line with `«extend»` label**, arrow pointing **TO the base use case**. *"This other use case **sometimes** runs as an addition to the base."*


Help is optional — most users register without ever opening it. So *Display Help* **extends** *Register User*. The base use case (*Register User*) doesn't know or care whether the extension fires.

::: warning

The `«include»` and `«extend»` arrows point in **opposite** directions. Easy way to remember:

- **«include»** — arrow points to the use case that's being **used by** the base.

- **«extend»** — arrow points to the use case that's being **added to**.

In both cases, the arrow points *toward* whatever the relationship is *named for*: *include* points at the included; *extend* points at the extended.

:::

---

::: danger

1. **Actor inside the system boundary.** Actors are *external* — they always sit outside the rectangle. If your stick figure is inside, you've made a notation error.

2. **Use case outside the system boundary.** Use cases describe what *your* system does. If an oval is outside the rectangle, it's not part of your system.

3. **Pointing «include» the wrong way.** Arrow goes *from* the base use case *to* the included one (Edit User → Load User), not the other way.

4. **Pointing «extend» the wrong way.** Arrow goes *from* the extension *to* the base use case (Display Help → Register User). This trips up nearly everyone — practise it.

5. **Use cases as nouns or UI elements.** *"Login Page"* or *"Database"* is not a use case. Use cases are **verb-noun phrases** describing what the system *does*: *"Login"*, *"Save Profile"*.

6. **Forgetting non-human actors.** A payment gateway, an email server, an external API — all actors. See [What Is an Entity?](What%20Is%20an%20Entity.md) — the same logic applies here.

:::

---

::: success

1. **Identify your actors** — work from your *user characteristics* and your data-collection findings. Don't forget non-human external systems.

2. **List your use cases** — translate each *functional requirement* into a verb-noun use case.

3. **Draw the system boundary** — a labelled rectangle. Use cases go inside; actors stay outside.

4. **Connect actors to use cases** with solid lines (associations). Every actor needs at least one.

5. **Add «include» and «extend» relationships** between use cases — only where they genuinely apply. Don't force them.

6. **Check arrows.** Walk through every dashed line and confirm direction.

:::

---

::: info

The C2-2 rubric at **5–6** asks for *"illustrates the relationships between the existing system, entities and data flows"* on the use case diagram. *"Some errors or omissions"* is acceptable at this band.

At **9–10**, it requires *"no errors, inconsistencies or omissions"*. The notation rules above are the difference between 7 and 10 — every wrong arrow direction, every actor inside the boundary, is an error that costs you the top band.

:::

---

Answer in your head first, then click the spoiler to check.

**1.** A login system always verifies credentials before granting access. How should this appear on a UCD?

>! **(b) Login includes Verify Credentials.** "Always" is the trigger word for **«include»**. Arrow goes from *Login* to *Verify Credentials* (Login → Verify Credentials).

**2.** A registration form *optionally* shows a tooltip if the user clicks a help icon. How should this appear?

>! **(b) Show Tooltip extends Register.** "Optionally" is the trigger word for **«extend»**. Arrow goes from the *extending* use case (Show Tooltip) **to** the base (Register): *Show Tooltip → Register*.

**3.** Which of these is **not** a valid use case label?

>! **(c) Login Page.** Use cases are **verb-noun phrases** describing what the system *does*, not UI elements. *"Login"* would be valid; *"Login Page"* describes a screen, not a function.

**4.** An Administrator can do everything a Teacher can, plus extra admin tasks. Which relationship best models this?

>! **(d) Generalisation.** Administrator generalises Teacher — meaning Administrator inherits all of Teacher's associations and adds its own. Drawn as a solid line with a hollow triangle pointing to the parent (Teacher).

---

- [What Is an Entity?](What%20Is%20an%20Entity.md) — same actor-discovery logic; non-human entities count as actors too

- [Context Diagram](Context%20Diagram.md) and [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — the other two C02 diagrams; entity/actor names should match across all three

- [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — pre-framed UCD canvas you can use to rehearse before the timed validation

- [Essential Terms](Essential%20Terms.md) — definitions of *actor*, *use case*, *system boundary*, *include*, *extend*, *generalisation*

---

← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)