Home A - Z
Page Index

An Otter Wiki

DRAFT — under teacher review.

Hand-Drawing Cheat-Sheet

Hamilton College · Year 12 · 2026

This page is your single reference for what every symbol should look like when drawn by hand under timed conditions. It does not re-teach concepts — it shows you the right shape, the wrong shape, and what gets crossed off by the marker.

Tip

The C2-2 stake. The validation runs for a full lesson (~50 min) under locked conditions: no internet, no AI, no Excalidraw, no notes, no reference sheets. You draw all three diagrams — Context Diagram, Level-1 DFD, Use Case Diagram — from memory, for your own project. Band 9–10 requires no errors, no inconsistencies, no omissions across all three. One wrong shape or one unlabelled arrow and you cap at 7–8. This cheat-sheet is for home practice only — you cannot bring it to the validation.

Context Diagram — Symbol Reference

Shape key

Symbol What you draw Rules
System One circle in the centre, system name inside Exactly one circle — the whole system is one shape
External entity Rectangle, role name inside All entities outside the circle
Data flow Arrow with a label on the line Every arrow must carry a specific data label

Right vs Wrong — Context Diagram

Element Correct Common error
System shape Clean circle, labelled with the system name An oval squashed sideways, or a rectangle — the system must be a circle
Number of circles Exactly one Two circles (e.g. adding "Verify User" as a second circle) — that is a DFD, not a context diagram
Entity shape Rectangle clearly outside the system circle Rectangle drawn inside the circle — entities are always outside
Data flow label "Assignment submission form" "data" or "info" — these are not labels; name the actual data
Entity–entity arrow Not present — all flows touch the system circle Arrow drawn directly between two entities, bypassing the system
Data stores Not present at context level Double-line (data store shape) included — data stores do not exist at Level 0

Canonical shape — mermaid

flowchart LR
    E1[External Entity]
    E2[External Entity]
    S(("Your System<br/>Name"))

    E1 -->|specific data label| S
    S -->|specific data label| E2
    E2 -->|specific data label| S

Level-1 DFD — Symbol Reference

Shape key

Symbol What you draw Rules
Process Circle, numbered + verb-noun name inside 3–6 circles; each needs ≥1 input AND ≥1 output
External entity Rectangle — same names as context diagram Never connect to a data store directly
Data store Two parallel horizontal lines, name between them At least one in AND one out flow; only connects to processes
Data flow Arrow with a label Every arrow must be labelled with the specific data

Right vs Wrong — Level-1 DFD

Element Correct Common error
Process shape Circle (round), with a number and verb-noun name Oval so squashed it looks like a rectangle, or an actual rectangle — must be clearly circular
Process label "1. Verify Login" No number, or a noun only ("Login") — processes need a number and a verb-noun phrase
Data store shape Two parallel horizontal lines with a name between them Plain rectangle without the second line — the double-line is what distinguishes a data store from an entity
Data store connections Only to/from processes Arrow from entity directly to data store — illegal; data must flow through a process first
Data store connections Only to/from processes Arrow from one data store to another — also illegal
Data flow label "student login credentials" Unlabelled arrow — every arrow on a DFD must have a label
Entity names Exactly match the context diagram "User" in the DFD vs "Student" in the context diagram — inconsistency costs marks
Every process At least one input AND one output A circle with only outputs (or only inputs) — a process must transform data

Canonical shape — mermaid

flowchart LR
    E[External Entity]
    P1(("1. Process<br/>Name"))
    P2(("2. Process<br/>Name"))
    DS[("Data Store")]

    E -->|specific data| P1
    P1 -->|stored data| DS
    DS -->|retrieved data| P2
    P2 -->|output data| E

Use Case Diagram — Symbol Reference

Shape key

Symbol What you draw Rules
Actor Stick figure, outside the rectangle, role name below Role name (e.g. Teacher), not a personal name; non-human systems are actors too
Use case Oval, inside the system boundary rectangle Verb-noun label: "Submit Assignment", not "Login Page"
System boundary Rectangle labelled with the system name All use cases inside; all actors outside
Association Solid line, actor ↔ use case Every actor needs at least one
«include» Dashed arrow, arrow points TO the included use case Triggered always; arrow: base → included
«extend» Dashed arrow, arrow points TO the base use case Triggered optionally; arrow: extension → base

Right vs Wrong — Use Case Diagram

Element Correct Common error
System boundary shape Rectangle, labelled with the system name Oval or circle as the boundary — the system boundary must be a rectangle
Actor position Stick figure outside the rectangle Stick figure drawn inside the rectangle — actors are always external
Use case position Oval inside the rectangle Oval outside the rectangle — use cases describe your system's functions
Use case label "Submit Quiz" (verb-noun) "Quiz Submission Page" or "Database" — labels must be action phrases
Actor label Role name: "Teacher" Personal name: "Mr Smith" — use the role, not the person
«include» arrow direction Base use case → included use case Arrow pointing the wrong way (included → base) — this is the most common mistake
«extend» arrow direction Extending use case → base use case Arrow pointing the wrong way (base → extending)
«include» / «extend» line style Dashed line with the stereotype label Solid line with no label — dashed + label is required
Association line Solid line Dashed line for a plain association — save dashed for «include»/«extend»

Canonical shape — mermaid

flowchart LR
    A1(["👤 Actor A"])
    A2(["👤 Actor B"])

    subgraph SYS["Your System Name"]
        UC1(["Use Case 1"])
        UC2(["Use Case 2"])
        UC3(["Use Case 3"])
    end

    A1 --- UC1
    A1 --- UC2
    A2 --- UC3
    UC1 -.->|«include»| UC3
    UC2 -.->|«extend»| UC1

(In a hand-drawn version, actors are traditional stick figures. The mermaid icons above are just a stand-in.)

Arrow Direction Memory Aid

The «include»/«extend» arrows trip up nearly everyone. One rule covers both:

The arrow always points toward the use case that is being used or added to.

Relationship Who initiates Arrow direction Reads as
«include» Base use case (it needs the other one) Base → Included "Base use case uses Included"
«extend» The optional extension Extension → Base "Extension adds to Base"

Example:

  • Submit Quiz includes Validate Answers → arrow: Submit Quiz → Validate Answers
  • Display Error extends Submit Quiz → arrow: Display Error → Submit Quiz

Before You Flip the Paper — Final Check

Check Your Understanding

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

1. You're drawing a context diagram by hand and you've just drawn a second circle labelled "Verify Login" next to the main system circle. What's wrong?

A context diagram has exactly one circle — the whole system. Adding a second circle (like "Verify Login") turns it into a DFD. Cross out the second circle; "Verify Login" belongs on your Level-1 DFD as a numbered process.

2. On your Level-1 DFD, you draw a data store as a rectangle with no second line because you're drawing quickly. How will the marker read it?

As an external entity — a plain rectangle is the entity shape. Without the second parallel line, the marker cannot distinguish it from an entity. The double-line is not optional; it is the notation. Draw it even when rushed.

3. You draw «extend» as a dashed arrow pointing FROM the base use case TO the optional extension. What mark does this attract?

This is a notation error. «extend» arrows point FROM the extending use case TO the base. The wrong direction means the marker reads your diagram as saying the base use case triggers the extension — the opposite of «extend» semantics. At 9–10 this is a credited error; it caps you at 7–8 or below.

4. Your context diagram shows "Student" as an entity. On your DFD you've written "User" for what is clearly the same person. Is this a problem?

Yes — it is a named inconsistency. The 9–10 band requires "no errors, inconsistencies or omissions". Entity names must match across all three diagrams. Change "User" to "Student" on the DFD (and the UCD).

See also

← Back to C02 Home · VCE Software Development Hub