Computational Thinking

Computational thinking is the process of approaching a problem in a way that can be solved by a computer. OCR J277 identifies three core principles, each used at a different stage of problem-solving.

Principle	What it means	When you use it
Abstraction	Remove irrelevant detail; keep only what matters	Defining the scope of a problem
Decomposition	Break a complex problem into smaller sub-problems	Planning the structure of a solution
Algorithmic thinking	Design a precise, step-by-step solution	Writing pseudocode or flowcharts

These three principles work together: you decompose the problem into parts, abstract away unnecessary detail from each part, then apply algorithmic thinking to design the solution for each part.

All three principles are used to define and refine problems — not just to solve them. Recognising that a problem is poorly defined is itself a computational thinking skill.

Abstraction means identifying and keeping only the details that are relevant to solving the problem, and deliberately ignoring everything else.

The key question: Does this detail change how the problem is solved? If not, remove it.

Worked example — designing a route-planning app:

Detail	Keep or remove?	Reason
Road connections between junctions	Keep	Required to find a path
Distance or travel time between junctions	Keep	Required to find the shortest/fastest route
Road surface colour	Remove	Doesn't affect routing
Driver's name	Remove	Doesn't affect routing
Speed limits	Keep	Affects fastest-route calculation
Whether a café is nearby	Remove	Not relevant to routing

After abstraction, the problem becomes: find the lowest-cost path through a graph of junctions and weighted edges. The algorithm works on this simplified model — not on a full real-world description.

Abstraction: keeping only the details necessary to solve the problem, and ignoring everything else.

Abstraction is used constantly in computing. Every time a problem is turned into data, decisions are made about what to represent and what to leave out.

Worked example — a school allocates students to exam rooms:

Detail	Keep or remove?	Reason
Number of students per subject	Keep	Determines how many seats are needed
Room capacity	Keep	Constrains how students can be allocated
Student names	Remove	Individual identity doesn't affect allocation logic
Whether the room has natural light	Remove	Not relevant to seat allocation
Subjects requiring special equipment	Keep	Some rooms may only suit certain subjects

After abstraction the problem reduces to: assign groups of students to rooms such that no room exceeds capacity and equipment constraints are met. This simplified model is what the program actually works on.

Multiple layers of abstraction exist in every program. A programmer writing a sorting function does not need to know how the processor fetches instructions from memory — those details are abstracted away by the programming language and the operating system.

Decomposition means breaking a large, complex problem into smaller sub-problems that can each be understood, designed, and solved independently.

Why decompose?

• Large problems are too complex to tackle in one step
• Sub-problems can be worked on by different developers simultaneously
• Each sub-problem can be tested separately, making bugs easier to find
• Smaller components are easier to maintain and update

Worked example — decompose "build a quiz game":

Quiz game
├── Display question and answer options
├── Accept and validate player input
├── Check player's answer against correct answer
├── Update the score
└── Decide whether to continue or end the game

Each box is now a clearly scoped, independently solvable task. None of them requires understanding the others to be designed. Together, they make up the complete problem.

Decompose until each sub-task is small enough to write as a short algorithm.

Each sub-problem from the first decomposition can be decomposed further. Continue until every task is simple enough to write as a straightforward algorithm.

Worked example — expanding "Accept and validate player input":

Accept and validate player input
├── Display the four answer options (A, B, C, D)
├── Read a character from the keyboard
├── Check whether the character is A, B, C, or D
│   ├── If valid: return the character
│   └── If not valid: display error and repeat from step 2

This level of decomposition is concrete enough to turn directly into pseudocode.

Recognising good decomposition — each sub-problem should be:

• A distinct task (not just the original problem reworded)
• Small enough to design in isolation
• Something that produces a clear output or result

Good sub-problem	Poor sub-problem
"Read and validate a player's answer (A–D)"	"Handle the player"
"Compare answer to correct answer and return true/false"	"Do the answer stuff"
"Add 1 to score if answer is correct"	"Manage the score"

Algorithmic thinking means designing a precise, ordered sequence of steps that solves a problem — steps unambiguous enough for a computer to execute exactly.

A correct algorithm must be:

• Finite — it terminates after a defined number of steps
• Unambiguous — each step has exactly one interpretation
• Correct — it produces the right output for all valid inputs

Worked example — turn the "check answer" sub-problem into an algorithm:

PROCEDURE checkAnswer(playerAnswer, correctAnswer)
    IF playerAnswer == correctAnswer THEN
        score = score + 1
        OUTPUT "Correct!"
    ELSE
        OUTPUT "Wrong. The answer was " + correctAnswer
    END IF
END PROCEDURE

Each step is precise, ordered, and terminates. This is algorithmic thinking applied to a sub-problem produced by decomposition, working on a model produced by abstraction.

The three principles are a pipeline: abstraction focuses the problem → decomposition divides it → algorithmic thinking solves each part.

1. Describing abstraction as just "making it simpler"

Abstraction requires removing specific named details and explaining why they are unnecessary. "I simplified the problem" is unlikely to score marks. Write: "I removed the student's hair colour because it has no effect on room allocation."

2. Confusing abstraction with decomposition

• Abstraction = deciding what details to keep or discard
• Decomposition = splitting one problem into multiple sub-problems

These are separate skills and may be tested separately in the same question.

3. Listing the original problem restated as sub-problems

"Make the game" is not a sub-problem of "build a quiz game" — it is the whole thing again. Every sub-problem must be a distinct, concrete, independently solvable task.

4. Algorithmic thinking only means "write code"

Algorithmic thinking produces a precise logical process. This can be pseudocode, a numbered list of steps, or a flowchart. The form matters less than the precision and completeness.

Common mistake	What to do instead
"I used abstraction to simplify things"	Name the specific detail removed and why
Listing vague steps like "handle input"	Define exactly what input, what validation, what output
An algorithm with no exit condition on a loop	Check every loop terminates for all valid inputs