# Context Diagram The Hamilton and Alexandra College · Year 12 · 2026 A context diagram is the **highest-level** view of your software system: one shape for the whole system, the external entities it talks to, and the named data flows between them. Nothing inside, nothing extra. It is the diagram that defines the **scope** of what you are building — and it is the foundation every later diagram (Level-1 DFD, use case) must stay consistent with. > [!TIP] > Your **C2-2 validation** asks you to **hand-draw** a context diagram, a Level-1 DFD, and a use case diagram under timed conditions. The context diagram is the simplest of the three — but the entities and flows you choose here lock in what the other two must show. Get this one right and the rest become much easier. --- ## Watch first (≈5 min total) {{Video|src=https://www.youtube.com/watch?v=PKWCogQ8v7U}} *Mark O'Meara (Geelong High School) — 1½-min VCE-targeted revision. Frames the context diagram as a **Level 0 DFD** using the Yourdon-DeMarco notation you'll use in C2-2. Watch for: one circle in the middle, entities outside, no internals.* {{Video|src=https://www.youtube.com/watch?v=fWNrc6GNK14}} *Christopher Kalodikis (Maximum Education, HSC) — 3-min overview building the intuition. Watch for: the **purpose** (showing inputs/outputs at a glance), why every external entity must have at least one labelled flow, and what counts as "external".* --- ## Why a context diagram Think of it as a **satellite view** of your software. You can see the system's outline and everything crossing its boundary, but not what's happening inside. It does four jobs: - **Defines scope** — what's part of your system, and what isn't - **Identifies stakeholders** — every external entity that interacts with the system - **Visualises data exchanges** — every input and output, named - **Anchors later diagrams** — your Level-1 DFD must show the same entities and flows ::: info **The diagnostic test.** If you can't draw a clean context diagram for your project, you don't yet know what you're building. Coming back to it after a week of design work usually reveals an entity you missed — that's a feature of the diagram, not a failure. ::: --- ## The three elements | Element | Symbol | Rules | |---|---|---| | **The system** | One circle (Yourdon-DeMarco) | Exactly **one** — the whole system. Named after the system itself (e.g. *Sales Order System*, *Library Loans*). | | **External entities** | Rectangles outside the circle | People, organisations, or other systems that interact with yours. Examples: *Customer*, *Administrator*, *Payment Gateway*, *Email Server*. | | **Data flows** | Labelled arrows | Every arrow names the **specific data** crossing the boundary. Direction shows whether data goes in or out. | ::: warning **What's *not* allowed on a context diagram** - More than one process circle (that's a DFD — see [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md)) - Data stores (no parallel-line rectangles at this level) - Arrows between two entities (every flow must touch the system circle) These rules are *strict*, not stylistic. Breaking any of them turns your context diagram into a different (and incorrect) artefact in the marker's eyes. ::: --- ## Worked example: Sales Order System ```mermaid flowchart LR M[Managers] E[Employees] C[Customers] S(("Sales Order<br/>System")) M -->|New Employee| S S -->|Employee Lists| M S -->|Vendor & Product-vendors| M E -->|Updates Employee| S E -->|Product & Category| S C -->|Customer details| S C -->|Order & Order-line| S S -->|Order & Order-line| C S -->|Order Invoices| C ``` **Read it like this:** - **The system** (centre): *Sales Order System* - **External entities**: *Managers*, *Employees*, *Customers* — all rectangles outside the circle - **Data flows**: - **Managers → System**: New Employee - **System → Managers**: Employee Lists, Vendor and Product-vendor info - **Employees → System**: Updates Employee, Product and Category - **Customers → System**: Customer details, Order and Order-line - **System → Customers**: Order Invoices > [!IMPORTANT] > Notice what is **not** shown: how the system stores employees, how it validates an order, how it produces an invoice. Those are internal — they belong on the Level-1 DFD, not here. *Restraint is the diagram's whole point.* --- ## How to draw one 1. **Name the system.** What are you building? That name goes inside the single circle. 2. **List external entities.** Who or what interacts directly with the system? Include only **direct** interactions — if Entity A only talks to Entity B (and never to your system), A doesn't belong here. 3. **Name every data flow.** Walk through each entity in turn: what specific data does it send in? What does the system send back? Use specific labels (*"payment details"*, not *"information"*). 4. **Check completeness.** Every entity should have at least one arrow connecting it to the system. Every arrow should be labelled. No entity should connect directly to another entity. ::: success **Quality check before you move on** - Exactly **one** circle? ✓ - Every entity is a rectangle outside the circle? ✓ - Every arrow has a **specific** label (not *"data"* or *"info"*)? ✓ - No entity-to-entity arrows? ✓ - No data stores, no internal processes? ✓ Five ticks → ready for your Level-1 DFD. ::: --- ::: danger **Most common mistakes** 1. **Drift toward a DFD** — adding a second circle (e.g. *"Verify User"*) inside the system. If there's more than one circle, it's no longer a context diagram. 2. **Unlabelled arrows** — *"data"* or *"info"* is not a label. Name the actual data. 3. **Entity-to-entity arrows** — every flow must touch the system. If two entities exchange data without your system involved, that exchange isn't on this diagram. 4. **Missing entities** — forgetting downstream systems (email server, payment gateway, reporting tool) that your system sends data to. 5. **Inventing detail** — showing data stores or internal logic. Save those for the Level-1 DFD. ::: --- ## Check Your Understanding Answer in your head first, then click the spoiler to check. **1.** Which of these is **not** a component of a context diagram? *(a) process · (b) entity · (c) data flow · (d) data store* >! **(d) data store.** Data stores belong on the Level-1 DFD, not the context diagram. At Level 0 the whole system is a single black box — its internal storage is hidden. **2.** In a context diagram, which statements are correct? *(select all that apply)* *(a) Entities can connect directly to other entities · (b) Data flows can only connect entities to the system process · (c) Multiple processes can be shown · (d) All flows must be unidirectional* >! **Both (b) and (d) are correct.** >! **(b)** — Every arrow must touch the system circle. Entity↔entity flows are never allowed. >! **(d)** — Each data flow is a **single-headed (unidirectional) arrow** labelled with the data crossing that way. If data moves *both* ways between an entity and the system, you must draw **two separate arrows** (one each direction), each with its own label — *not* one line with arrowheads at both ends. >! **Why (a) and (c) are wrong:** (a) breaks the entity-to-system rule above; (c) describes a DFD — a context diagram has exactly one process circle (the whole system). **3.** You're drawing a context diagram for a Library Management System. How should *"borrowing a book"* appear? *(a) An entity labelled "Borrowing" · (b) A process inside the system · (c) A data flow labelled "Book borrowing request" from Borrower to the system · (d) A rectangle showing the book collection* >! **(c) A data flow labelled "Book borrowing request" from Borrower to the system.** Borrowing is an *action*, not an entity or a thing. On a context diagram, actions surface as labelled data flows. (b) would be a process — but the context diagram has only one process (the whole system). --- ## See also - [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — when you move to Level 1, what changes and what stays the same - [What Is an Entity](What%20Is%20an%20Entity.md) — entities aren't only people; non-human systems count - [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — pre-framed canvases for rehearsing all three diagrams under timed conditions