Key Stage 3 computing · Computational thinking

KS3 computing: abstraction and computational models

At Key Stage 3, students learn to simplify a real-world problem or physical system, keeping only the details that matter, and to build a computational model of how it changes and behaves. They then use that model, test it and judge how well it matches reality. This is the thinking at the heart of computer science, and it is good preparation for students who go on to take GCSE Computer Science.

Abstraction and modelling, explained

The national curriculum asks Key Stage 3 pupils to design, use and evaluate computational abstractions that model the state and behaviour of real-world problems and physical systems. Abstraction means deliberately ignoring detail that does not affect the problem so that what is left is manageable. A railway or metro map is the classic example: it leaves out the true distances and curves because a traveller only needs to know the order of stations and where lines meet.

A computational model has two main parts. The state is what the model remembers at any moment, stored in variables, such as the number of free spaces in a car park or the speed and position of a falling ball. The behaviour is the set of rules that change the state when something happens, such as a car arriving or a second passing. Students decide which state to track, write the rules as an algorithm, and then run the model, either in a programming language or in a spreadsheet, to see what happens.

A useful model can be used to ask “what if?” without trying it out in real life. What happens to the queue if a shop opens a second till? How long does a ball take to land if gravity is weaker? Schools choose the examples, which commonly include simulations of queues, traffic, populations, bank balances, games or simple physics. Students learn that a model is not the truth, only a simplified copy that is good enough for a purpose.

This is why evaluation is part of the topic. Students compare the model’s output with real data or common sense, and look for where it breaks down. If a model of a car park never lets two cars arrive at once, that simplification may be fine for a small car park and risky for a large one. They also decide whether to add more detail, because each extra detail makes a model more realistic and also harder to build and check. You may hear related ideas such as decomposition (breaking a big problem into smaller ones) and generalisation (spotting that two problems have the same pattern).

Words your child will hear

Abstraction: Removing unimportant detail so that only what matters for the problem is left.
Model: A simplified representation of something real that can be used to predict or test what happens.
State: The information a model keeps at one moment, stored in variables.
Behaviour: The rules that change the state when events happen.
Simulation: Running a model over time to see how a system might behave.
Decomposition: Breaking a large problem into smaller parts that are easier to solve.
Validate: To check that a model’s results match real life or known data.

What the National Curriculum says

The programme of study for Key Stage 3 says:

Pupils should be taught to design, use and evaluate computational abstractions that model the state and behaviour of real-world problems and physical systems
Aim: pupils can understand and apply the fundamental principles and concepts of computer science, including abstraction, logic, algorithms and data representation.
Aim: pupils can analyse problems in computational terms, and have repeated practical experience of writing computer programs in order to solve such problems.

Objectives from the National Curriculum in England, © Crown copyright, used under the Open Government Licence v3.0.

Try it: modelling a car park

A car park has 50 spaces. Design a simple computational model that tells a sign how many spaces are free, then test and evaluate it.

Decide what to leave out. The colour of the cars, the weather and who is driving do not affect the number of free spaces, so the model ignores them. What matters is how many cars are in the car park.
Choose the state. One variable is enough: free_spaces, starting at 50.
```
capacity = 50
free_spaces = 50
```
Write the behaviour as rules for two events. When a car enters and there is space, take one away. When a car leaves, add one, but never go above the capacity.
```
ON car_enters:
  IF free_spaces > 0 THEN
    free_spaces = free_spaces - 1
ON car_leaves:
  IF free_spaces < capacity THEN
    free_spaces = free_spaces + 1
```
Test with chosen cases. Start at 50 and let 3 cars enter: free_spaces is 47. Then 1 car leaves: 48. Now test the edge cases: with free_spaces at 0, a car trying to enter should not push it to −1, and with 50 free, a leaving car should not push it to 51.
Evaluate. The model works for counting but ignores disabled bays, drivers who circle looking for a space, and cars that enter and leave at the same moment. It also trusts that every car is counted by a sensor. Decide whether the missing detail matters for the purpose: it is fine for a simple sign, but not for planning how many spaces the town needs.

A one-variable model (free_spaces) with two rules that never go below 0 or above 50 models the state and behaviour of the car park well enough for a sign. Its limits come from what was left out, and the purpose decides whether that is acceptable.

Common mistakes and how to help

Thinking abstraction means making something vague

In everyday English “abstract” means unclear, so students think they should be less precise.

What helps: Explain that in computing it means being precise about what matters and silent about what doesn’t. A good abstraction is exact within its purpose.

Adding every detail to make the model more accurate

Students equate realism with quality, so models fill up with details that make them slow to build, hard to test and no more useful.

What helps: Ask what question the model needs to answer. If a detail does not change that answer, leave it out. Start simple and add one detail at a time.

Treating the model’s output as the truth

Numbers on a screen look authoritative, and a simulation that runs smoothly feels convincing.

What helps: Always compare with something real, such as a measured result or what you would expect. Ask “what did we assume, and what could make this wrong?”

Forgetting the edge cases when testing

Students try typical values, see that it works and stop, so situations such as an empty or full car park, or a negative number, are never checked.

What helps: Test the smallest, largest and “impossible” values deliberately. Many bugs sit at the boundaries.

How to help at home

Spot abstractions around you. Look at a transport map, a floor plan, a recipe or a weather symbol, and ask what has been left out and why. Naming what is missing is the heart of the skill.
Ask “what if?” about a system. Pick something that runs in a pattern, like a queue at the school canteen or a household budget, and ask how a change would affect it. This is how real models are used.
Build a model in a spreadsheet. Ask them to model something simple, such as pocket money with weekly savings, and change one number to see the effect. It is a gentle way to see state and rules without writing code.
Let them explain their project. If your teenager is building a simulation or game at school, ask them to talk you through what the program remembers and what the rules are. Explaining it is great revision.
Challenge the output. When a prediction appears in the news, ask what it assumed. Learning to question models, from weather forecasts to polls, is a useful life skill, not only a computing one.

Leads on to

Key Stage 4: Computational thinking and programming
Key Stage 4: Design skills in computing

Everything in Key Stage 3 computing

Updated 20 October 2026.