Decomposition, Composition & Automation

AQA 4.4.6–4.4.11 — Decomposition, composition and automation

Retrieval: Year 12's decomposition taught breaking a problem into manageable pieces; Year 12's evaluation-of-solutions taught judging a solution's genuine quality. This capstone lesson extends both — decomposition's necessary partner, composition, and a new object of evaluation entirely: whether automating a task is actually appropriate.

Key vocabulary

• Decomposition — breaking a complex problem into smaller, more manageable components.
• Composition — integrating those separately-built components back into a single, correctly working whole.
• Automation — using a computational system to perform a task that would otherwise require repeated human effort or decision-making.

Understand — decomposition, deepened

Decomposing a "library management system" might produce: a catalogue component, a member-records component, a loan-tracking component, and a notifications component. Each is genuinely more manageable to design, build and test in isolation than the whole system at once — this much is the familiar Year 12 skill, now applied to a genuinely larger, Year-13-scale system.

Reason about what composition genuinely requires

Decomposition is not the whole job — the components must eventually work together. This is harder than "putting the pieces back," because it requires every component's interface (Sequence 14's own earlier lesson) to genuinely agree with every other component that depends on it: the loan-tracking component needs to know exactly what data the catalogue component will provide about a book, and in what form. A mismatch here — one component expecting an ISBN as a string, another producing it as a number — is a genuine integration failure, entirely separate from any bug within either component individually. This is exactly why Sequence 11's multi-class programs needed each class's interface carefully designed, not just each class's internals.

Understand — automation, evaluated rather than assumed good

Automation replacing repeated human effort is genuinely valuable — but not universally. A task that is repetitive, well-defined, and high-volume (validating that a form field isn't empty, sorting a list, computing a total) is a strong automation candidate. A task that requires nuanced judgment, has frequent genuine exceptions, or carries a real ethical weight (deciding which hospital patient is treated first; moderating borderline content) is a poor candidate for full, unreviewed automation — not because computers can't execute the rules, but because the rules themselves may not be able to capture every case that genuinely matters.

Common mistake

Assuming decomposition alone solves a problem, and treating composition as an afterthought. In genuine software projects, individually correct components integrating badly — through mismatched interfaces or unstated assumptions about what another component provides — is a common, real source of failure, distinct from any single component's own internal bugs.

Why this matters for the NEA

An NEA project is, structurally, exactly this: a large problem decomposed into classes, functions and modules that must then be correctly composed into one working system. The genuine difficulty most NEA projects encounter isn't usually any single component in isolation — it's making sure every component's interface agrees with what every other component that depends on it actually expects.

Check your understanding

A hospital is considering fully automating triage decisions — which patient is seen first — with no human review. Evaluate whether this is an appropriate use of automation. (4 marks)

(Not appropriate as a fully automated, unreviewed system. Triage decisions require nuanced judgment about a specific patient's genuine medical urgency, including exceptional or ambiguous cases that a fixed, predetermined rule set is unlikely to reliably capture - and the ethical stakes of a wrong decision are severe. This doesn't mean computational tools have no role (a system could reasonably support or prioritise information for a human decision-maker), but full automation without human review fails the "task requires nuanced judgment / carries genuine ethical weight" criterion this lesson identifies as a poor automation candidate.)

Challenge

Decompose a "school timetabling system" into at least four genuinely separate components. For one specific part of the overall task (for example, "assigning a specific teacher to cover an absent colleague's lesson at short notice"), evaluate whether it should be fully automated, partially automated, or left to human judgment, and justify your answer.

Looking ahead: Sequence 15 (Theory of Computation II) moves from problem-solving and abstraction to formal computational models — finite state machines and regular languages — a different, more mathematically precise kind of abstraction from the ones covered in this sequence.