HookHow your phone finds one contact among sixty thousand in about sixteen guesses
Type a name into a phone holding 60,000 contacts and it appears before your finger leaves the key. Scanning the list one entry at a time, a linear search, would take up to 60,000 comparisons. Instead the phone keeps the list sorted and jumps to the middle, throws away the half that cannot contain the name, and repeats. Each comparison halves what is left: 60,000 becomes 30,000, then 15,000, then 7,500. After about sixteen halvings there is nothing left to discard, because 2 to the power of 16 is 65,536. Sixteen guesses, not sixty thousand.
The leap from 'check every name' to 'halve the list each time' is the whole of Component 2 in one move, and it has a name: computational thinking. Before a single line of code is written, a good programmer reframes the problem — strips away detail that does not matter, breaks it into smaller parts, and works out the precise sequence of steps a machine can follow. Get that thinking right and the code almost writes itself; get it wrong and no amount of clever syntax will save you. This section is about that thinking, about turning it into algorithms you can draw and test, and about the handful of classic search and sort algorithms OCR expects you to trace by hand.
ModelComputational thinking — abstraction, decomposition and algorithmic thinking
OCR splits computational thinking into three habits of mind. Abstraction is removing detail that does not matter to the problem so you can focus on what does. A tube map is the classic example: it throws away real distances, road layout and the wiggle of every tunnel, keeping only the order of stations and where lines cross, because that is all a passenger needs. In a program, deciding to store a student as just a name, a date of birth and a form group, and ignoring their eye colour, is abstraction.
Decomposition is breaking a large problem into smaller sub-problems that can be solved one at a time. 'Write a quiz game' is overwhelming; 'load the questions, ask one question, check the answer, update the score, show the result' is five jobs you can build and test separately. Decomposition is what makes a big task finishable, and it is the reason real programs are assembled from subprograms rather than written as one enormous block.
Algorithmic thinking is working out the ordered sequence of steps — the logic — that solves the problem, independent of any programming language. It is the difference between knowing what you want and knowing exactly how to get it, step by unambiguous step. A genuine algorithm must always end, and every step must be precise enough that a machine could follow it without ever having to guess what you meant.
MechanismDesigning, creating and refining an algorithm
Every algorithm is a machine for turning inputs into outputs through a set of processes, and the first design step is simply to list those three things. OCR expects you to express a design in more than one form. A structure diagram shows the decomposition as a hierarchy: the whole task at the top, sub-tasks branching beneath it. A flowchart shows the flow of control using standard shapes — a rounded box to start and stop, a parallelogram for input or output, a rectangle for a process, and a diamond for a decision that splits the path in two. Pseudocode writes the logic in structured English that reads close to real code but without fussing over the exact rules of any one language.
Once an algorithm exists you must be able to check it and improve it. A trace table is how you check it: you draw a column for every variable and for the output, then walk through the steps one at a time, recording how each value changes. Tracing is the single most reliable way to expose a logic error — code that runs happily but produces the wrong answer — because it forces you to become the computer instead of assuming what the code does. Refining is the improvement that follows: correcting the errors the trace revealed, removing repeated blocks, handling inputs you had not thought about, or swapping in a faster method.
Trace this algorithm, which is meant to add the whole numbers from 1 to 5:
total = 0 FOR i = 1 TO 5 total = total + i NEXT i PRINT total
Work through it as a table, one row per pass, carrying the running values across. Start: 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. i = 5: total = 10 + 5 = 15. The loop ends and the program outputs 15. Now see why tracing earns marks: if a careless programmer had written FOR i = 1 TO 4, the trace would stop at total = 10, and that off-by-one error would be obvious on paper long before the code was ever run.
MechanismSearching — linear and binary
A linear search checks each item in turn from the start until it finds the target or reaches the end. It is simple, and its great advantage is that it works on any list, sorted or not. Its weakness is speed: in the worst case it must look at every one of the n items, so a linear search of a million records can take a million comparisons.
A binary search is far faster but demands one thing in return: the list must already be sorted. It looks at the middle item, and because the list is ordered it can throw away the entire half that cannot contain the target, then repeat on the half that remains. Because each step halves the search space, a list of n items needs at most about log2(n) comparisons — roughly 20 comparisons for a million items rather than a million. The trade-off is the whole point: binary search is dramatically faster, but only if you have paid the cost of keeping the data sorted, and for a single search of a short or unsorted list a linear search can be the better choice.
Binary search the sorted list 3, 8, 12, 19, 27, 34, 42, 55, 63, 71 (positions 0 to 9) for the value 34.
Step 1: low = 0, high = 9, so middle position = (0 + 9) DIV 2 = 4, holding 27. 27 is less than 34, so discard positions 0 to 4 and set low = 5. Step 2: low = 5, high = 9, middle = (5 + 9) DIV 2 = 7, holding 55. 55 is greater than 34, so discard positions 7 to 9 and set high = 6. Step 3: low = 5, high = 6, middle = (5 + 6) DIV 2 = 5, holding 34. Match found at position 5.
Three comparisons located the value. A linear search would have taken six. On this ten-item list the gap is small; on a million items it is the difference between about 20 comparisons and up to a million.
ModelSorting — bubble, merge and insertion
Sorting matters because binary search, and much else, depends on ordered data. OCR expects three algorithms. A bubble sort repeatedly walks through the list comparing each pair of adjacent items and swapping them if they are in the wrong order; after each full pass the largest remaining value has 'bubbled' to the end. It is the easiest to understand and to code, but it is slow, making a great many comparisons on a large list. An insertion sort builds a sorted section at the front of the list, taking each new item and shuffling it back into its correct place, exactly the way most people sort a hand of playing cards; it is efficient on small or nearly-sorted lists.
A merge sort takes a different, divide-and-conquer approach: it splits the list in half, then splits those halves again and again until every piece is a single item (which is trivially 'sorted'), then repeatedly merges pairs of pieces back together in order. Merge sort is far faster than bubble or insertion sort on large lists, but it uses more memory because it creates the sublists, so the choice is a classic speed-versus-memory trade-off rather than one algorithm being simply 'best'.
Bubble sort the list 5, 3, 8, 1 into ascending order.
Pass 1: compare 5 and 3 — wrong order, swap → 3, 5, 8, 1. Compare 5 and 8 — correct, leave. Compare 8 and 1 — wrong order, swap → 3, 5, 1, 8. The largest value, 8, has bubbled to the end. Pass 2: compare 3 and 5 — leave. Compare 5 and 1 — swap → 3, 1, 5, 8. Compare 5 and 8 — leave. List is now 3, 1, 5, 8. Pass 3: compare 3 and 1 — swap → 1, 3, 5, 8. No further swaps are needed, so the list is sorted: 1, 3, 5, 8. Note that every correct sorting algorithm would reach this same final order — they differ only in how much work and memory they use to get there.
VocabularyKey terms the mark scheme pays for
TrapsMisconceptions that cost marks
ExamWhat examiners want
Component 2 (J277/02) rewards process, not just the answer. When a question gives you an algorithm and asks for the output, do not eyeball it — draw the trace table, one column per variable, one row per pass, and carry the running values across. Marks are awarded for the intermediate values, so a correct final answer with no working can still drop marks, while a small slip in otherwise sound working can still earn most of them.
For search and sort questions, state the precondition before you describe the method: a binary search answer earns its first mark by noting the list must be sorted first. Comparisons are the currency of these questions — be ready to say that a linear search of n items takes up to n comparisons while a binary search takes at most about log2(n), and to justify which is the better choice in a specific situation. For sorts, know that all three give the same order and be able to weigh bubble sort's simplicity against merge sort's speed and heavier memory use.
The longer design questions target AO3 — design, refine and evaluate. Open by identifying the inputs, processes and outputs, then write in OCR Exam Reference Language or a consistent high-level language, indenting your selection and iteration so the structure is visible to the examiner. When a question asks you to refine an algorithm, name the specific weakness — an unhandled input, a repeated block that should become a subprogram, an off-by-one boundary — rather than rewriting the whole thing blindly.