Computational Thinking and Representing Algorithms

An algorithm is a sequence of steps that can be followed to complete a task. A computer program is one implementation of an algorithm — but the algorithm itself is independent of any programming language.

An algorithm is not a computer program. An algorithm describes what to do; a program expresses that algorithm in a specific language for a specific machine.

Three core concepts underpin computational thinking:

Concept	Definition	Example
Algorithm	A precise, ordered set of steps to solve a problem	A recipe; a search procedure; a sorting method
Decomposition	Breaking a complex problem into smaller sub-problems	Splitting "build a quiz app" into: display question, get answer, check answer, update score
Abstraction	Removing unnecessary detail to focus on what matters	A map shows roads but not every building and tree

Every well-designed program is built by decomposing a problem into parts, abstracting away irrelevant detail, and expressing each part as an algorithm.

Decomposition means breaking a problem into a number of sub-problems so that each sub-problem accomplishes an identifiable task. Each sub-problem may itself be further subdivided.

Worked example — decomposing a library system:

Each branch is an identifiable, manageable task that can be designed and tested on its own.

Why decomposition is essential:

• A problem that feels too large to tackle becomes a set of smaller, solvable tasks
• Each sub-problem can be assigned to a different developer and worked on in parallel
• Individual sub-problems can be tested independently before the complete system is assembled
• A sub-problem that appears in more than one place need only be solved once

In an exam, when asked to decompose a problem, identify the distinct responsibilities or stages of the system. Each sub-problem should have a single, clear purpose — not just "half of everything."

Abstraction is the process of removing unnecessary detail from a problem, retaining only the information relevant to solving it.

Example — a map: A road map shows roads, junctions, and place names. It does not show every building, lamp post, or kerb. Those details are real, but irrelevant to navigation — including them would make the map harder to use.

Example — storing student records: A school needs: name, year group, date of birth, contact email. The student's favourite colour and shoe size are real attributes but irrelevant to the school's purpose — abstraction means excluding them from the data model.

Example — a sorting algorithm: Bubble sort works on "a list of values." The algorithm does not need to know whether those values are exam scores, temperatures, or prices. The specific data type is abstracted away — the same algorithm works for any list of comparable values.

Without abstraction	With abstraction
A different system for every type of data	One algorithm works on any comparable values
Student records store dozens of irrelevant fields	Records contain only what the system needs
Maps are cluttered and unreadable	Maps show only navigation-relevant information

Abstraction is not the same as oversimplification. The removed detail is genuinely irrelevant to the problem — not just inconvenient to include.

Pseudocode expresses an algorithm using structured, language-independent statements. AQA exams use a standard pseudocode format — any exam question providing pseudocode will use this version.

Core pseudocode constructs:

# Assignment
total ← 0

# Input and output
name ← USERINPUT
OUTPUT "Hello, " & name

# Selection
IF score ≥ 40 THEN
    OUTPUT "Pass"
ELSE
    OUTPUT "Fail"
ENDIF

# Definite iteration
FOR i ← 1 TO 5
    OUTPUT i
NEXT i

# Indefinite iteration
answer ← ""
WHILE answer ≠ "quit" DO
    answer ← USERINPUT
ENDWHILE

# Subroutine
SUBROUTINE greet(name)
    OUTPUT "Hello, " & name
ENDSUBROUTINE

Inputs, processing and outputs — every algorithm can be described in these three terms:

Component	Meaning	Example: calculate class average
Input	Data the algorithm receives	A list of student scores
Processing	Operations performed on the data	Sum all scores, divide by the number of students
Output	The result produced	The average score

Being able to identify inputs, processing and outputs within a given algorithm is a direct exam requirement.

A flowchart represents an algorithm visually using standard symbols connected by directed arrows.

Standard symbols:

Symbol	Shape	Purpose
Terminator	Rounded rectangle (oval)	Marks the Start or End of the algorithm
Process	Rectangle	An instruction, calculation, or assignment
Input / Output	Parallelogram	Reading input from a user or displaying output
Decision	Diamond	A yes/no question — flow branches depending on the answer

Example — flowchart for checking if a score is a pass:

Rules when drawing flowcharts:

• Arrows must show direction of flow
• Every decision diamond has exactly two exits, each labelled Yes and No
• There is exactly one Start; every path through the algorithm must lead to an End

Exam questions may ask you to complete, correct, or interpret a flowchart. Read the decision labels carefully — the branch taken depends on whether the condition is true or false, not on intuition.

A trace table tracks the value of every relevant variable after each step of an algorithm. It is used to verify that an algorithm works correctly, or to identify where an error occurs.

Worked example — trace the following algorithm for n = 4:

count ← 0
FOR i ← 1 TO n
    IF i MOD 2 = 0 THEN
        count ← count + 1
    ENDIF
NEXT i
OUTPUT count

i	i MOD 2	count
—	—	0
1	1	0
2	0	1
3	1	1
4	0	2

Output: 2 (the number of even values in 1–4).

Exam technique for trace tables:

• Record a new row every time a variable changes
• If a variable does not change in an iteration, it can be left blank or repeated — follow the question's instructions
• Write the output separately, at the point the OUTPUT statement is reached
• Do not skip iterations or combine steps — each row represents one change in state

Algorithm efficiency: More than one algorithm can solve the same problem. An algorithm that solves a problem in fewer steps is more efficient. When comparing algorithms, AQA only requires informal comparisons based on time: for example, binary search is faster than linear search on sorted data because it halves the remaining search space on each step, whereas linear search checks every element in order. Choosing the more efficient algorithm matters when dealing with large amounts of data.

1. Stating that an algorithm is a program

An algorithm is a sequence of steps — it has no programming language and no syntax. A program is one way of implementing an algorithm. These are not the same thing, and confusing them in a definition answer loses marks.

2. Describing decomposition vaguely

"Splitting the problem into smaller parts" is not enough. A full answer names the specific sub-problems and states that each accomplishes a single, identifiable task. Examiners expect you to apply decomposition to the given scenario.

3. Treating abstraction as simplification

Abstraction removes irrelevant detail — detail that does not affect the solution. It is not about making things shorter or easier. The removed detail genuinely does not belong in the model.

4. Missing decision labels on flowcharts

Every decision diamond must have both exits labelled Yes and No (or True and False). An unlabelled branch is ambiguous — it cannot be followed — and will lose marks.

5. Skipping rows in a trace table

Every change in variable state requires its own row. Combining two iterations into one row, or jumping to the final value without showing each step, misrepresents how the algorithm executes and produces wrong answers for "state the output" questions.