Decomposition

AQA 4.4.2 — Thinking ahead: decomposition

Retrieval: the previous lesson used abstraction to decide what matters about a problem. Decomposition is the next step: breaking that problem down into smaller, more manageable sub-problems, each of which is easier to design, build and test than the whole.

You already know decomposition from a different angle: Sequence 3's procedures and functions are exactly what decomposition looks like once it's implemented in code — a big program broken into small, named, reusable pieces. This lesson is about the thinking that comes before that code exists.

A decomposition diagram

For a food delivery ordering system, a decomposition diagram breaks the overall problem into its major components, and can break those down further:

Food Delivery System
├── Menu Management
│   ├── Display available items
│   └── Update prices/availability
├── Order Processing
│   ├── Build a customer's basket
│   ├── Calculate the total cost
│   └── Apply any discounts
├── Payment
│   └── Process payment and confirm
└── Delivery Tracking
    └── Update order status (preparing, out for delivery, delivered)

Each branch can be designed, built and tested largely independently — this is the same principle Sequence 3 called "modular programming," just applied before any code is written.

Common mistake

Decomposing into pieces that are still too broad to actually design or build directly — "Order Processing" on its own is still too big a task to sit down and code in one go; it needs breaking down further, as shown above, until each piece is small enough to tackle on its own. Stopping decomposition too early is one of the most common mistakes at this stage — if a "sub-problem" still feels like a whole project by itself, it isn't decomposed enough yet.

Apply it — decompose a new system

Produce a decomposition diagram (in the same nested-list style as above) for an online food delivery ordering system's payment component alone — go one level deeper than the diagram above's single "Process payment and confirm" line, identifying at least three genuinely separate sub-tasks payment handling actually requires (think about what could go wrong, not just what happens when everything works).

Challenge

Choose a different real-world system entirely (a library book-loan system, a hospital appointment booking system, a school timetabling system) and produce a full decomposition diagram with at least three major branches, each broken down into at least two sub-tasks. For one sub-task, justify why you stopped decomposing at that point rather than breaking it down further.

Looking ahead: the next lesson (Pattern Recognition) looks across problems you've already decomposed and asks whether any of their sub-problems are actually the same underlying problem in disguise.