Thinking Procedurally: Decomposition, Order & Sub-Procedures (OCR A-Level CS 2.1.3)

Free Thinking Procedurally revision resources (OCR A-Level Computer Science, 2.1.3)

We’ve made exam-style practice for this exact topic, free to download: Thinking Procedurally question sheet, mark scheme and cheat sheet. Grab them, have a go, then read the full guide below.

Once you've abstracted a problem, you have to break it down and put the pieces in order. That's thinking procedurally, and spec point 2.1.3 wants you to identify the components of a problem, identify the components of a solution, work out the order of the steps, and identify the sub-procedures needed. In the exam this shows up as "identify the sub-procedures" and "complete the structure diagram" — easy marks once you know the moves.

Let's break it down (literally).

Decomposition: breaking a problem into components

Decomposition means splitting a big problem into smaller components that are each easier to understand and solve. You keep breaking sub-problems down until each piece is small enough to turn into a single routine.

Take "process an online order". Its components might be: check the items are in stock, take payment, update stock levels, arrange delivery, and send a confirmation. Each of those is a self-contained chunk you can tackle on its own — and some break down further (taking payment = validate card → authorise → record).

Identifying the components of a problem (what needs doing) and the components of a solution (the routines that will do it) is the first procedural-thinking skill.

Sub-procedures and structure diagrams

A sub-procedure (or subroutine) is a named block of code that does one part of the job. Decomposition naturally produces a list of sub-procedures — and the standard way to show them is a structure diagram (also called a hierarchy chart): the whole problem at the top, broken into sub-tasks below, broken again until each box is a single routine.

For the online order, the top box is processOrder, with children checkStock, takePayment, updateStock, arrangeDelivery, sendConfirmation. takePayment might split again into validateCard and authorisePayment. A favourite exam task is to complete a structure diagram or identify one more sub-procedure that's needed.

Determining the order of the steps

Breaking the problem up isn't enough — the steps must run in the right order, because some depend on others. You can't take payment before you know the items are in stock, and you can't send a confirmation before the order is placed.

Working out what must happen before what (the dependencies, or sequence) is spec point 2.1.3(c). Some steps are strictly ordered; others could happen in any order (or even at the same time — that's concurrency, which is the next topic).

Worked example: a library self-service loan

Decompose "borrow a book on the self-service machine":

• Components / sub-procedures: scanLibraryCard, scanBook, checkBorrowingLimit, recordLoan, printReceipt.

• Order: scan card → scan book → check the member hasn't hit their loan limit → if OK, record the loan → print a receipt. The check must come before recording the loan; the receipt must come last.

• Structure diagram: borrowBook at the top, the five sub-procedures beneath, with checkBorrowingLimit perhaps splitting into countCurrentLoans and compareToLimit.

That's procedural thinking in full: components → sub-procedures → correct order.

Common exam mistakes

• Listing actions, not sub-procedures. Name them like routines (checkStock), each doing one job.

• Ignoring order/dependencies. Some steps must precede others — say which and why.

• A flat structure diagram. Show the hierarchy: top problem → sub-tasks → smaller sub-tasks.

• Confusing decomposition with abstraction. Decomposition = break into parts; abstraction = remove irrelevant detail.

• Over- or under-splitting. Each sub-procedure should be one clear task — not the whole program, not a single line.

Quick recap

• Thinking procedurally = break a problem into components, identify the sub-procedures, and put the steps in the right order.

• Decomposition splits a big problem into smaller, solvable parts.

• A sub-procedure is a named routine doing one part of the job; show them on a structure diagram (hierarchy chart).

• Order matters: work out which steps depend on which (you can't pay before checking stock).

• Don't confuse it with abstraction (remove detail) — this is about structure and sequence.

Frequently asked questions

What does thinking procedurally mean? Thinking procedurally means breaking a problem into its components, identifying the sub-procedures needed to solve it, and determining the order in which those steps must run. It turns a large problem into a structured set of smaller routines that can be written and tested individually.

What is decomposition? Decomposition is breaking a large problem down into smaller components that are each easier to understand and solve. You keep splitting sub-problems until each piece is small enough to become a single routine, such as breaking "process an online order" into checking stock, taking payment and arranging delivery.

What is a sub-procedure? A sub-procedure, or subroutine, is a named block of code that carries out one part of a larger task. Decomposition produces a set of sub-procedures, which are commonly shown on a structure diagram with the whole problem at the top broken down into smaller sub-tasks below.

What is a structure diagram? A structure diagram, also called a hierarchy chart, shows how a problem is decomposed. The whole problem sits at the top, broken into sub-tasks on the level below, which are broken down further until each box represents a single routine. It is the standard way to show the sub-procedures of a solution.

Why does the order of steps matter? The order matters because some steps depend on others. For example, you cannot take payment before confirming the items are in stock, and you cannot send a confirmation before the order is placed. Determining these dependencies — what must happen before what — is part of thinking procedurally.

What is the difference between decomposition and abstraction? Decomposition means breaking a problem into smaller parts that can be solved individually, while abstraction means removing or hiding irrelevant detail to focus on what matters. They are complementary computational-thinking skills, but decomposition is about structure and abstraction is about simplification.