Computational thinking
Three ways to think about a problem
Before anyone writes code, they think about the problem.
There are three techniques.
- Abstraction: remove the details that do not matter, so you can focus on the ones that do.
- Decomposition: break a big problem into smaller problems that are each easier to solve.
- Algorithmic thinking: work out the exact steps, in order, that solve the problem.
Abstraction leaves things out. Decomposition splits things up. Algorithmic thinking puts steps in order.
For example:
- A railway map is an abstraction. It shows which stations are on each line and where lines meet. It leaves out the bends in the track, because a passenger does not need them.
- A quiz app decomposes into smaller tasks: store the questions, ask them, check the answers, keep the score.
- Checking a password is algorithmic thinking: "Check the password is at least 8 characters, then check it has a digit, then..."
A structure diagram draws a decomposition: the whole problem in the top box, its subsections in a row below, and the smaller tasks of each subsection below that.
Each box can be planned, written and tested on its own, often as its own subroutine.
Writing an algorithm down
An algorithm is a sequence of steps that solves a problem.
You can write one in three ways: numbered steps in plain English, a flowchart, or code (pseudocode or a real programming language).
A flowchart draws an algorithm as boxes joined by arrows. Pseudocode is code written for people to read, not for a computer to run.
Flowcharts use five symbols. You need to recognise all of them.
- Start or stop (also called a terminal) is a rounded rectangle: a box with curved ends.
- A process is a plain rectangle. It holds an action or a calculation, such as "total = total + price".
- A decision is a diamond. It holds a question with a yes or no answer, and has two arrows out of it, labelled Yes and No.
- An input or output is a parallelogram: a box with sloping sides.
- A subroutine is a rectangle with a double line at each side. It runs another part of the program, then comes back.
Inputs, processes and outputs
Most programs take something in, do something with it and give something back.
- Input: the data that goes in (typed, read from a sensor, loaded from a file).
- Process: what the program does to it (calculations, decisions, sorting).
- Output: what comes back (shown on screen, printed, sent, saved, a sound).
A program that asks for a room's length and width, multiplies them and shows the area: the inputs are the length and width, the process is the multiplication, the output is the area.