> **DRAFT** — under teacher review. # Hand-Drawing Cheat-Sheet The Hamilton and Alexandra 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 ```mermaid flowchart LR E1[External Entity] E2[External Entity] S(("Your System\nName")) E1 -->|specific data label| S S -->|specific data label| E2 E2 -->|specific data label| S ``` ::: warning **Do NOT draw on a context diagram** - A second circle (any internal process) - Data stores (double-line shapes) - Entity-to-entity arrows - Arrows without labels ::: --- ## 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 ```mermaid flowchart LR E[External Entity] P1(("1. Process\nName")) P2(("2. Process\nName")) DS[("Data Store")] E -->|specific data| P1 P1 -->|stored data| DS DS -->|retrieved data| P2 P2 -->|output data| E ``` ::: warning **Do NOT draw on a Level-1 DFD** - Entity-to-data-store arrows (must go through a process) - Data-store-to-data-store arrows - A process with no input, or no output - Unlabelled arrows - Entity names that differ from your context diagram ::: --- ## 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 ```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.)* ::: warning **Do NOT draw on a Use Case Diagram** - Actors inside the system boundary rectangle - A circle (oval) as the system boundary — boundary must be a **rectangle** - «include» / «extend» arrows on solid lines - «include» / «extend» arrows pointing the wrong direction - Use case labels that are nouns only (*"Login Page"*, *"Database"*) ::: --- ## 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 ::: success **Run through this list before you put your pen down.** **Context Diagram** - [ ] Exactly one circle, labelled with the system name - [ ] All entities are rectangles, drawn outside the circle - [ ] Every arrow has a specific data label - [ ] No entity-to-entity arrows - [ ] No data stores, no internal circles **Level-1 DFD** - [ ] 3–6 numbered processes (circles), each with a verb-noun label - [ ] Every process has at least one input AND one output arrow - [ ] At least one data store (two parallel lines, not a plain rectangle) - [ ] No entity-to-data-store arrows - [ ] No data-store-to-data-store arrows - [ ] Every arrow labelled - [ ] Entity names match the context diagram exactly **Use Case Diagram** - [ ] System boundary is a rectangle, labelled with the system name - [ ] All actors (stick figures) are outside the rectangle - [ ] All use cases (ovals) are inside the rectangle - [ ] Actor labels are role names, not personal names - [ ] Every actor has at least one solid association line - [ ] At least one «include» (dashed, arrow to included use case) - [ ] At least one «extend» (dashed, arrow to base use case) - [ ] Arrow directions are correct for both «include» and «extend» **Cross-diagram consistency** - [ ] Entity and actor names are identical across all three diagrams ::: --- ## 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 - [Context Diagram](Context%20Diagram.md) — concepts, worked example, and notation rules - [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — what can appear on each level - [Use Case Diagram](Use%20Case%20Diagram.md) — the four relationships and arrow-direction rules - [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — skeleton canvases for pre-validation practice --- ← Back to [C02 Home](C02-home.md) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)