Designing Computational Solutions

AQA 4.13.1 — Designing computational solutions

Retrieval: the previous lesson specified the badminton-booking problem completely without choosing any tool. This lesson asks: given that specification alone — not told which sequence's content applies — how do you actually decide?

Key vocabulary

• Design — deciding a solution's structure (data representation, algorithm, paradigm) before implementing it, typically recorded as pseudocode, a flowchart, or a class/structure outline.
• Stepwise refinement — designing a solution top-down, starting from an outline and progressively adding detail to each part.

Understand — a decision framework, not a lookup table

There is no single rule that maps a problem directly to "the right" data structure or algorithm — that's exactly why this is a genuine design skill, not something to memorise. A useful set of questions to ask of any new problem: What operations does the data actually need to support (lookup by key? ordered iteration? checking membership? modelling relationships between things)? How much data, and how persistent (a handful of values for one run, or thousands of records that must survive between runs)? Does state need to change over time, and does something need to protect that state from being changed incorrectly? Is there a natural mathematical/relational structure (a network of connections is often a graph; naturally tabular, relatable records are often a database's job) already implicit in the problem?

Design it — working through the badminton-booking problem

Applying those questions to the sub-problems decomposed last lesson:

• Representing bookings: does this need to persist between runs of the program (a real booking system obviously does)? That points toward SQL/database storage (Sequence 16), not just an in-memory Python structure that vanishes when the program ends.
• Checking for overlap: this is a lookup/filter operation (Sequence 4/5's dictionaries and searching) — or, expressed as SQL, a WHERE clause matching court and time range (Sequence 16's own querying content).
• Should courts and bookings be objects? A Court that knows its own bookings and can answer "am I free at this time?" bundles data and behaviour together — a genuine object-oriented candidate (Sequence 11), if the system will grow to need more court-specific behaviour later. For a system this small, a plain table of booking records queried directly may be entirely sufficient — object-oriented structure isn't automatically the "more advanced" or "better" choice (Sequence 17's own evaluation lesson made exactly this point).

The point is not that this is "the" correct design — a different, equally justifiable design might keep everything in-memory for a small single-session tool, or might use a graph if courts had complex adjacency/booking-dependency rules that don't actually exist here. What matters is that every choice above is reasoned from the specification's actual requirements, not picked because it's the most recently-taught topic.

Select it — three fresh scenarios, no hints given

For each, state which data structure(s), algorithm(s) and/or paradigm you would investigate first, and justify your answer using the decision-framework questions above — there is deliberately no single "correct" answer expected; a well-reasoned justification is what's being assessed.

1. A system that must find the shortest number of bus changes between any two stops in a city's transport network.
2. A utility, reused identically in several unrelated programs, that converts a temperature reading between three different units.
3. A system tracking which of a warehouse's several thousand unique product codes are currently in stock, needing near-instant lookup by code.

(1: a graph is the natural fit - stops and direct routes between them are exactly nodes and edges (Sequence 12), and BFS specifically finds the shortest number of "hops" rather than shortest distance (Sequence 13). 2: a small pure function is well-justified - no state to manage, reused identically everywhere, easiest to test in isolation (Sequence 17's own reusability/testability reasoning). 3: a hash table (Python dictionary) is well-justified specifically because near-instant lookup by a unique key is precisely what hashing is designed for (Sequence 12), in preference to a list that would need a linear or even sorted/binary search.)

Common mistake

Treating "we just learned X" as a reason to use X. A genuinely synoptic course makes this mistake easy to fall into by the time you reach this sequence — the tools from Sequences 10–17 don't expire, and a problem genuinely calling for a plain procedural function or a Year 12 dictionary is just as valid an answer here as reaching for the most recently-covered structure.

Check your understanding

A brief asks for a system to store and quickly search a large, frequently-changing list of unique student ID numbers, needing only to check "does this ID exist?" — no ordering matters. Justify, using the decision-framework questions, whether a hash table or a binary search tree is the more appropriate choice. (A hash table is generally more appropriate here: the requirement is membership-checking by exact key with no need for ordered iteration, which is precisely what a hash table's average O(1) lookup is suited to; a BST's main additional benefit - efficient ordered traversal - isn't needed by this specification at all, so it would add complexity without a corresponding benefit.)

Challenge

Produce a stepwise-refined design (an outline, then progressively more detail) for the "recording a new booking" sub-problem from the badminton system, stating explicitly which data structure and/or storage approach you are assuming and why.

Looking ahead: the next lesson takes a design like the one you've just produced and turns it into working, systematically-tested code.