B1.1.2 · Approaches to computational thinking
The four pillars
By the end you can
Describe decomposition, pattern recognition, abstraction and algorithmic design, and tell which one a situation is using.
is not programming, and it is not thinking like a computer. It is the way computer scientists think about a problem so that it becomes something a computer can help with, and it works for problems that have nothing to do with computers at all. It has four parts. They are usually listed one at a time, but in practice you move between them constantly.
Decomposition#
means breaking a complex problem into smaller, more manageable parts. A part that is small enough can be understood, solved and tested on its own, and parts that do not depend on each other can be given to different people. Afterwards the solutions are put back together. In programs this shows up as the functions, methods and modules that make up a larger system.
There is no formula for decomposing a problem, but some questions help:
- Can the problem be split into steps or phases that happen in a natural order?
- Are there repeated parts that could be grouped together?
- Which parts are independent of each other, and which have to wait for another?
- What does a sketch or a mind map of the problem look like?
- How would you explain it to a five-year-old? Simplifying it that far forces you to find the essential pieces.
A bicycle breaks into a frame, a drivetrain, wheels, steering, brakes, seat, gear mechanism, suspension, lights and mudguards. A smartphone breaks into screen, battery, charging circuit, processor, memory, storage, buttons, cameras, sensors and software. A video-game character that behaves realistically breaks into sensing the world, deciding what to do, carrying out the action and finding a path. In each case no part is the whole thing, and each part has one clear job.
Pattern recognition#
is spotting similarities, repeats and regular changes, in the data or in the problem itself. Once you see that two sub-problems are alike, you can solve one and reuse the solution for the other. That is why programmers write a function once and call it many times, and why code that has already been tested is reused rather than rewritten.
Take the sequence 2, 4, 6, 8. Each term is 2 more than the one before, so the next term is the current term + 2, and that rule works however long the sequence grows. A harder example is a program that reads handwritten digits. Each image is a grid of pixels, and the digits have characteristic shapes: 1 is mostly a vertical line, 0 an oval, 8 two joined loops. A shape with a closed loop is probably a 0, 6, 8 or 9, which narrows the choice before any other check is made.
Useful questions are: what are the parts of the system, which actions or structures repeat, and how does the system change over time?
Abstraction#
is filtering out the details that do not matter so that you can concentrate on those that do, and then representing the problem with a simpler model. The hard part is deciding which is which. The colour of a car does not affect how fast it goes, but the engine does; the colour of a footballer's boots does not affect the result, but a serious injury might. Useful questions are: what is the core purpose of the system, what are the essential inputs and outputs, would the system still work if I removed this part, and can I replace a specific value with a variable?
A map is an abstraction of the land, and the best-known example is a metro map: it shows the stations and how the lines connect, and ignores real distances and the bends in the track, because for planning a journey that is all you need. The same idea runs through programming. You use a library function without knowing how it was written, and you work with a “customer” made of a few fields and not a real person. Abstraction makes software smaller and quicker to write, and users get what they need without clutter.
Abstraction always throws something away, so a model can fail when a discarded detail turns out to matter. That is the risk to mention in an evaluation or discussion answer.
You are writing a program to predict the winner of a car race.
Tick the details your model needs. Leave the rest out.
Algorithmic design#
An is a finite sequence of clear instructions that solves a problem. “Finite” means it must end; “clear” means that anyone, or any computer, can follow it without having to guess. Designing one comes before coding, and begins with questions: exactly what is the problem, what are the inputs, what output is wanted, where are the decisions, where do steps repeat, and can it be broken into smaller steps?
For “add two whole numbers and show the sum” the algorithm is: ask for a number and store it; ask for another and store it; add them; store the result; display it. For the sequence 2, 4, 6, 8 it is: get the current number, add 2, output the new number. The same algorithm can be written as numbered steps, as pseudocode, as a flowchart (B1.1.4) or as a program.
The order of the steps is part of the design. To find the average of three numbers you must add them up before dividing by 3, and the running total must be set to 0 before any number is added to it. Reset the total to 0 after the numbers are added and the algorithm gives the wrong answer, though every individual step is fine.
Using them together#
Real problems need all four, usually in a loop. Say a hospital must schedule staff, rooms and beds. An engineer abstracts first: staff, equipment and beds are the core elements, and breaks and maintenance can wait. Pattern recognition in the past records shows that trauma cases peak at night and elective surgery in the morning. She then decomposes the problem into staff scheduling, equipment scheduling and bed allocation. Finally she designs algorithms: a quick heuristic that gives a good-enough schedule, or an optimising method that is slower but finds the best one. A new fact can send her back to an earlier step, which is normal.
A team splits a timetabling system into: collecting teacher availability, assigning rooms, detecting clashes and printing the result.
A developer sees that every shape drawn in a game needs the same steps (pick a colour, set a position, draw the outline) and writes one reusable routine.
A tube map shows only the stations and the connections, not the true distances or the curves of the track.
Numbered steps are written for the task: ask for two numbers, store them, add them and display the sum.
A programmer calls a library function that sorts a list and never reads how it works inside.
An analyst notices that sales rise every December and fall every February across five years of figures.
A drone is split into frame, motors, battery, flight controller and camera, so each can be designed on its own.
An engineer decides where a loop and a decision are needed, puts the steps in order and checks what happens for each input.
0 of 8 matched
Check yourself
The four pillars
Quick questions, made fresh every time and marked here. Do a few until they feel easy.
Exam practice
Paper 1-style questions
6 questions · 20 marks
Write your answer as you would in the exam, then show the mark points and tick each one your answer made. These are our own questions in the style of the exam, not past-paper questions.
1.Describe decomposition.
[2]Describe: A detailed account: say what happens, step by step if it is a process.
2.Explain why pattern recognition is useful in solving a problem, using an example.
[2]Explain: Give reasons: say what happens AND why, or how one thing causes another.
3.A map of a city’s underground railway shows only the stations and how the lines connect. Explain how this is an example of abstraction.
[2]Explain: Give reasons: say what happens AND why, or how one thing causes another.
4.Describe the process of algorithmic design.
[4]Describe: A detailed account: say what happens, step by step if it is a process.
5.A school wants a system that lets students pre-order lunch. Explain how decomposition, abstraction, pattern recognition and algorithmic design could each help in building it.
[4]Explain: Give reasons: say what happens AND why, or how one thing causes another.
6.A team is building a navigation app that finds the quickest route between two places. Discuss how decomposition and abstraction help the team, and what risks each brings.
[6]Discuss: Look at the question from more than one side, weigh the points against each other, and come to a conclusion.
In a nutshell
- Computational thinking is a toolkit for framing problems so that a computer can solve them. It rests on four ideas: decomposition, pattern recognition, abstraction and algorithmic design.
- Decomposition breaks a complex problem into smaller parts that can be solved separately, then combined. The thing broken down is the problem, not a program.
- Pattern recognition spots similarities, repeats and trends, so one solution can be reused: this is where functions, loops and reusable code come from.
- Abstraction keeps the details that matter for a purpose and leaves out the rest. The map is not the territory: every model leaves something out.
- Algorithmic design writes the solution as precise, ordered, finite steps with the decisions and repeats worked out. The order of the steps matters.
- The four are used together. In an exam, name the idea and tie it to the situation: what exactly was broken up, what repeated, what was left out, and what steps were written.