Representing Algorithms: Pseudo-code, Flowcharts and Trace Tables
Three Ways to Write an Algorithm
Once you have designed an algorithm using decomposition and abstraction, you need a way to write it down clearly. There are three standard representations: pseudo-code, flowcharts, and actual program code. Your exam may ask you to read, complete or write in any of these forms — always check what format the question requires before answering.
Standard flowchart symbols: oval/rounded rectangle (start or stop), rectangle (process or action), diamond (decision — has yes/no exits), parallelogram (input or output). Arrows show the direction of flow.
Flowcharts
A flowchart gives you a visual picture of how an algorithm flows. Every step is drawn as a shape; arrows connect them in order. The diamond shape is particularly important — it represents a decision with two exits (usually labelled Yes and No). Decisions are used to model selection (if/else) and the loop condition in iteration. A flowchart for a loop has an arrow that curves back to an earlier step. That arrow can leave the “Yes” exit or the “No” exit of the diamond, depending on how the condition is worded.
In an exam you might be asked to trace through a flowchart and state its output, add a missing shape, or correct an error. Always follow the arrows carefully — it is easy to take the wrong branch from a diamond.
AQA Standard Pseudo-code
Your exam will always present pseudo-code questions using the current version of the AQA standard pseudo-code. You must be able to read and write it confidently. The key constructs are shown below. Note that AQA uses ← for assignment (not =), and keywords such as THEN, ENDIF, ENDWHILE, ENDFOR, UNTIL that clearly mark where structures end.
Assignment:score ← 0
The arrow means “assign the value on the right to the variable on the left.”
Output:OUTPUT score
Input:name ← USERINPUT
Selection (IF):IF score ≥ 50 THEN
OUTPUT “Pass”
ELSE
OUTPUT “Fail”
ENDIF
Count-controlled loop (FOR):FOR i ← 1 TO 5
OUTPUT i
ENDFOR
Condition-controlled loop (WHILE):WHILE answer ≠ “quit”
answer ← USERINPUT
ENDWHILE
Condition-controlled loop (REPEAT…UNTIL):REPEAT
answer ← USERINPUT
UNTIL answer = “quit”
The condition is checked after each iteration, so the body always runs at least once.
AQA pseudo-code uses ← for assignment and requires closing keywords: ENDIF, ENDWHILE, ENDFOR. The REPEAT…UNTIL loop always executes its body at least once because the condition is tested after the body runs — unlike WHILE, which tests the condition first.
Trace Tables
A trace table is used to track the values of variables as an algorithm runs. Each column represents a variable (or the output); each row records the variable values after one execution step. Trace tables let you check whether an algorithm produces the correct output and are the standard method for finding logic errors.
Trace-table questions carry different numbers of marks, so check the tariff before you start. They are easy to lose marks on. Two common errors are: adding extra rows (tracing steps that didn’t actually happen), and forgetting to update a counter or comparison variable on every iteration.
Consider this AQA pseudo-code algorithm:
total ← 0
FOR i ← 1 TO 4
total ← total + i
ENDFOR
OUTPUT total
Trace table (columns: i, total, OUTPUT):
Before loop: total = 0
i = 1: total = 0 + 1 = 1
i = 2: total = 1 + 2 = 3
i = 3: total = 3 + 3 = 6
i = 4: total = 6 + 4 = 10
Loop ends (i would be 5, greater than 4). OUTPUT: 10
The algorithm adds the integers 1 to 4 and outputs their sum. Its purpose: sum the integers from 1 to n (here n=4).
Determining the Purpose of an Algorithm
After completing a trace table, you should be able to describe what the algorithm does. Rather than just listing the outputs, identify the pattern: is it counting, summing, searching, filtering? A well-worded purpose statement names the inputs, describes the processing, and states the outputs.
For example: “The algorithm takes a list of names as input, searches through them one by one (processing), and outputs the position of a target name if found.” This is clearer than “it finds a name.”
For simpler algorithms, visual inspection — reading through the code and reasoning about what it does — is faster than filling a full trace table. Look for: the loop condition (to know when the loop stops), which variables are updated in the loop body, and what is outputted. Visual inspection saves time on short sequences; trace tables are safer for anything involving nested loops or complex conditions.