Home A - Z
Page Index

An Otter Wiki

DRAFT — under teacher review.

Excalidraw Diagram Starters — C02

Hamilton College · Year 12 · 2026

Drawing from scratch each session costs 10–15 minutes of setup time and often produces inconsistent notation across the three diagrams. These Excalidraw starters give you pre-framed skeletons — correct shapes, correct labels — so you can focus on the content, not the canvas.

Why consistent notation matters

All three C02 diagrams use the same cast of external entities. If the entity is named "Student" on your context diagram, it must be named "Student" (not "User" or "Person") on your DFD. Starting from a shared canvas makes this consistency automatic.

At 9–10, the rubric requires "no errors, inconsistencies or omissions" across all three diagrams. Inconsistent entity names between diagrams is a named inconsistency — even if both diagrams are otherwise correct.

Getting started in Excalidraw

Excalidraw is available free at excalidraw.com. No account required. Your teacher may share a .excalidraw file directly — open it with File → Open.

Skeleton: Context Diagram

The context diagram has exactly one system circle. Everything else is an external entity (rectangle) or a data flow (labelled arrow).

[Entity A] ──── label ────▶ ( Your System Name ) ──── label ────▶ [Entity B]
                                      ▲
                                  label
                                      │
                               [Entity C]

Shape key:

Shape What it represents
Rectangle External entity (a person, organisation, or external system)
Circle / oval The entire system — one only
Labelled arrow Data flow — must carry a specific name (not "data" or "info")

Common setup errors to avoid before you start drawing:

  • Do not add any second circle — multiple circles make it a DFD, not a context diagram.
  • Do not add data stores (double lines) — they do not exist at context level.
  • Label every arrow with the specific data being exchanged, not a direction (wrong: "sends data"; right: "assignment submission form").

Skeleton: Level-1 Data Flow Diagram

The Level-1 DFD decomposes the single system circle into 3–6 numbered processes. Use the same external entities as your context diagram.

[Entity A] ──── label ────▶ (1. Process Name) ────▶ ║ Data Store ║
                                    │
                                 label
                                    ▼
                             (2. Process Name) ──── label ────▶ [Entity B]
                                    │
                                 label
                                    ▼
                             (3. Process Name) ──── label ────▶ ║ Data Store ║

Shape key:

Shape What it represents
Rectangle External entity — same names as context diagram
Circle / oval A numbered process (verb–noun phrase, e.g. "1. Verify Login")
Double-line rectangle Data store (named collection of stored data)
Labelled arrow Data flow

Minimum check before you submit:

  • Each process has at least one input AND one output arrow.
  • At least one data store is present.
  • Every entity name matches your context diagram exactly.
  • No entity ↔ entity arrows (all flows route through a process).
  • No entity ↔ data store arrows (data stores only connect to processes).

Skeleton: Use Case Diagram

The use case diagram shows who can do what with your system. Actors (stick figures) sit outside the system boundary; use cases (ovals) sit inside.

         ┌──────────────────────────────────────────┐
Actor A  │  (Use Case 1)      (Use Case 3)          │
  🧍─────┼──────────────────────────────────────────│
         │  (Use Case 2)  ──«include»──▶ (Use Case 4)│
  🧍─────┼──────────────────────────────────────────│
Actor B  │                                          │
         └──────────────────────────────────────────┘

Shape key:

Shape What it represents
Stick figure (outside box) Actor (a person or external system that uses the system)
Oval (inside box) Use case (a function the system performs)
Rectangle System boundary
Solid line Association (actor participates in use case)
Dashed arrow «include» Use case A always triggers use case B
Dashed arrow «extend» Use case B sometimes triggers optional use case C

Arrow direction rules (the most common exam mistake):

  • «include»: arrow points FROM the base use case TO the included use case. ("Login" includes "Verify Credentials" — arrow: Login → Verify Credentials.)
  • «extend»: arrow points FROM the extending use case TO the base use case. ("Display Error Message" extends "Login" — arrow: Display Error Message → Login.)

If in doubt: the arrow always points towards the use case that is being used or extended into.

Practice check — before the hand-drawn validation

Run through this list with your Excalidraw diagrams before the timed hand-drawing session:

  • Context diagram: exactly one system circle, no data stores, every arrow labelled.
  • DFD: 3–6 numbered processes, at least one data store, entity names match context diagram.
  • Use case diagram: all actors outside the boundary, all use cases inside, «include»/«extend» arrows pointing the correct direction.
  • All three diagrams use identical names for the same entities and data stores.

If you can redraw all three from memory using only these skeletons as a prompt, you are ready for the hand-drawn validation.

See also

← Back to VCE Software Development Hub