Blame
|
1 | > **DRAFT** — under teacher review. |
||||||
| 2 | ||||||||
| 3 | # What Is an Entity? (It's Not Just a Person) |
|||||||
| 4 | ||||||||
| 5 | Hamilton College · Year 12 · 2026 |
|||||||
| 6 | ||||||||
|
7 | On context diagrams and data flow diagrams, students frequently draw only the humans they can think of — *"Student"*, *"Teacher"* — and miss every external system their software talks to. Missing an entity is a rubric error at every level above 3–4, because the rubric rewards *"relationships between the existing system, entities and data flows"*. |
||||||
| 8 | ||||||||
| 9 | > [!TIP] |
|||||||
| 10 | > If your context diagram only has *people* as entities, you've almost certainly missed half of them. Every login, every email, every external API your project touches is its own entity. |
|||||||
|
11 | |||||||
| 12 | --- |
|||||||
| 13 | ||||||||
| 14 | ## The VCAA definition |
|||||||
| 15 | ||||||||
| 16 | > **Entity** — the users or external systems that interact with the system being created. |
|||||||
| 17 | ||||||||
| 18 | Two words matter: **users** (human roles) and **external systems** (non-human). Both go on your context diagram as rectangles. |
|||||||
| 19 | ||||||||
| 20 | --- |
|||||||
| 21 | ||||||||
| 22 | ## Types of entity — with examples |
|||||||
| 23 | ||||||||
| 24 | | Type | What it is | VCE SAT examples | |
|||||||
| 25 | |---|---|---| |
|||||||
| 26 | | **Human user (primary)** | The person the software is primarily built for | Student, Teacher, Administrator | |
|||||||
| 27 | | **Human user (secondary)** | A person affected by the system's outputs | Parent, School Principal | |
|||||||
| 28 | | **External software system** | An API, platform, or service your system sends data to or receives data from | Google Calendar API, Payment Gateway, Email Server | |
|||||||
| 29 | | **External data source** | A data feed or file system outside your application boundary | School database, CSV import, Government open data | |
|||||||
| 30 | ||||||||
| 31 | --- |
|||||||
| 32 | ||||||||
| 33 | ## A quick test: is it an entity? |
|||||||
| 34 | ||||||||
|
35 | ::: success |
||||||
|
36 | Ask three questions: |
||||||
|
37 | |||||||
|
38 | 1. Does it send data **into** my system, or receive data **out** of it? |
||||||
| 39 | 2. Is it **outside** the boundary of the software I am building? |
|||||||
| 40 | 3. Is it a **distinct role or system** (not an internal component of my software)? |
|||||||
| 41 | ||||||||
|
42 | If all three answers are *"yes"* — it is an entity. Add it to your diagram. |
||||||
|
43 | |||||||
|
44 | If it is *inside* your system (a function you are writing, a class in your code, a database table your code owns) — it is **not** an entity. It belongs on the DFD as a process or data store. |
||||||
| 45 | ::: |
|||||||
|
46 | |||||||
| 47 | --- |
|||||||
| 48 | ||||||||
|
49 | ::: danger |
||||||
| 50 | **Commonly missed entities — by project type** |
|||||||
|
51 | |||||||
|
52 | These are the entities students most often miss. Check whether *any* apply to your project before submitting. |
||||||
|
53 | |||||||
| 54 | | Project type | Commonly missed entity | Why it is missed | |
|||||||
| 55 | |---|---|---| |
|||||||
|
56 | | Any project with login | Authentication provider (e.g. Google OAuth) | Students think login is *"inside"* their app | |
||||||
|
57 | | Any project that emails users | Email server / SMTP service | Students don't model outgoing system calls | |
||||||
| 58 | | School management tool | Admin user or IT department | Students only think about the primary user | |
|||||||
| 59 | | App using external data | External database or API (e.g. weather API) | Students model the API as a feature, not an entity | |
|||||||
| 60 | | App with notifications | Push notification service | Treated as internal, but it is external | |
|||||||
|
61 | ::: |
||||||
|
62 | |||||||
| 63 | --- |
|||||||
| 64 | ||||||||
| 65 | ## User stories → entities: the reliable method |
|||||||
| 66 | ||||||||
| 67 | Your `data-collection-plan.md` user stories are the best source of entities. For each story: |
|||||||
| 68 | ||||||||
| 69 | - **"As a [role]"** → that role is probably an entity (if they interact with your system directly). |
|||||||
| 70 | - **"I want [goal] so that [benefit]"** → what external systems does achieving this goal require? Each one is a candidate entity. |
|||||||
| 71 | ||||||||
| 72 | Work through every user story before finalising your context diagram. |
|||||||
| 73 | ||||||||
|
74 | ### Going further: Gherkin scenarios *(optional but excellent)* |
||||||
| 75 | ||||||||
| 76 | ::: info |
|||||||
| 77 | **Not required by the VCAA curriculum** — but a powerful tool for surfacing entities you'd otherwise miss. Worth knowing if you want top-band detail. |
|||||||
| 78 | ::: |
|||||||
| 79 | ||||||||
| 80 | A Gherkin scenario expands a user story into concrete **Given / When / Then** steps. Every noun in those steps is a candidate entity. |
|||||||
| 81 | ||||||||
| 82 | {{Video|src=https://www.youtube.com/watch?v=bxeNxhOSGJg}} |
|||||||
| 83 | ||||||||
| 84 | *LitheSpeed — What Is Gherkin? (~1 min). The bare-bones intro; no need to learn the BDD tooling around it.* |
|||||||
| 85 | ||||||||
| 86 | **Example.** A user story like *"As an account holder I want to withdraw cash so that I have money for the day"* expands to: |
|||||||
| 87 | ||||||||
| 88 | ```gherkin |
|||||||
| 89 | Feature: Account Holder withdraws cash |
|||||||
| 90 | ||||||||
| 91 | Scenario: Account has sufficient funds |
|||||||
| 92 | Given the account balance is $100 |
|||||||
| 93 | And the card is valid |
|||||||
| 94 | And the machine contains enough money |
|||||||
| 95 | When the Account Holder requests $20 |
|||||||
| 96 | Then the ATM should dispense $20 |
|||||||
| 97 | And the account balance should be $80 |
|||||||
| 98 | And the card should be returned |
|||||||
| 99 | ``` |
|||||||
| 100 | ||||||||
| 101 | **Entities this scenario surfaces** (each underlined noun is an external system the ATM software talks to): |
|||||||
| 102 | ||||||||
| 103 | - **Account Holder** — the human user (you'd already have this). |
|||||||
| 104 | - **Card / Authentication system** — *"the card is valid"* implies an external check (bank network or token validator). |
|||||||
| 105 | - **Bank account database** — *"balance is $100 → $80"* means your software reads and writes to an external account store. |
|||||||
| 106 | - **Cash dispenser hardware** — *"dispense $20"* is a physical subsystem outside your software. |
|||||||
| 107 | - **Card reader hardware** — *"card should be returned"* is another physical subsystem. |
|||||||
| 108 | ||||||||
| 109 | A user story alone might surface only *Account Holder*. The Gherkin expansion forces you to confront every Given precondition and every Then effect — that's where the missing entities live. |
|||||||
| 110 | ||||||||
|
111 | --- |
||||||
| 112 | ||||||||
|
113 | ::: info |
||||||
| 114 | **Why VCAA cares** |
|||||||
|
115 | |||||||
|
116 | The C2-2 rubric at **5–6** requires *"illustrates the relationships between the existing system, entities and data flows"*. *"Some errors or omissions exist"* is still acceptable at 5–6. But at **9–10**, *"no errors, inconsistencies or omissions exist"* — a missing entity **is** an omission, and omissions cost you the top band. |
||||||
|
117 | |||||||
|
118 | The most common C2-2 omission flagged in past years: the **email server or notification service** that every project needs but few students draw. |
||||||
| 119 | ::: |
|||||||
|
120 | |||||||
| 121 | --- |
|||||||
| 122 | ||||||||
| 123 | ## See also |
|||||||
| 124 | ||||||||
| 125 | - [Context Diagram vs Data Flow Diagram](/sd/C02/Context%20Diagram%20vs%20Data%20Flow%20Diagram) |
|||||||
| 126 | - C02 Resources: [external reading and videos](/sd/Resources/C02-Resources) |
|||||||
| 127 | ||||||||
| 128 | --- |
|||||||
| 129 | ||||||||
| 130 | ← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
|||||||
