- What decomposition means: splitting a problem into smaller parts.
- What abstraction means: focusing on the important details and ignoring the rest.
- How both techniques help you model real-world situations.
- How to explain why they make problems easier to analyse, understand and solve.
In Computer Science, problems often begin as real situations: running a school lunch queue, booking a cinema ticket, checking whether a password is valid, or planning a route.
Real-world situations contain lots of details. Some are important for the computer system. Others are not. Before you can design an algorithm or program, you need a way to simplify the problem.
Model
A model is a simplified representation of a real-world situation. It includes enough detail to help solve a particular problem, but it does not try to copy everything perfectly.
For example, a lunch-ordering system does not need to model the colour of the canteen walls, but it probably does need to model menu items, prices, allergies, payments and stock levels.
This diagram shows the basic idea: use decomposition to split the situation into smaller jobs, and abstraction to choose which details matter.

The main idea
Decomposition reduces the size of the problem. Abstraction reduces the amount of detail. Together, they make a real-world problem easier to model, analyse, understand and solve.
Decomposition
Decomposition means breaking a complex problem, system or process into smaller, more manageable parts.
Each smaller part is called a subproblem: a smaller problem that can be understood or solved separately.
For example, “create a school lunch ordering system” is a large problem. You could decompose it into smaller parts such as:
- taking the pupil’s order
- checking allergy information
- calculating the price
- taking payment
- updating stock levels
- printing or displaying a receipt
This helps because each part has a clearer purpose. A programmer can work out what that part needs to do without being distracted by the whole system at once.
Decomposition helps you:
- analyse the problem by identifying its separate parts
- understand what each part is responsible for
- solve the problem one part at a time
- test smaller parts more easily
- share work between team members
- reuse parts in other systems if they are designed well
Decomposing a homework-planner app
-
Start with the overall goal: the app should help a student keep track of homework tasks and deadlines. This is too broad to solve in one go.
-
Split the goal into jobs with clear responsibilities: adding a task, storing the task, showing all tasks, sorting by due date, marking a task as complete, and reminding the student about overdue work.
-
Check what information each job needs. For example, sorting by due date needs each task to have a due date, while marking a task as complete needs each task to have a completion status.
-
The problem is now easier to solve because each subproblem can be designed separately: task entry, task storage, task display, deadline sorting, completion tracking and reminders.
Making the parts too vague
A weak decomposition uses vague parts like “make the app” or “deal with homework”. Good subproblems should have clear jobs, such as “store the homework task” or “sort tasks by due date”.
Abstraction
Abstraction means removing or ignoring unnecessary details so you can focus on the important features of a problem.
Abstraction does not mean “throw away random information”. It means choosing details based on the purpose of the model.
For example, if you are designing a route-finding app for a school, important details might include:
- classroom locations
- corridors
- staircases
- blocked routes
- walking distance or estimated walking time
Unimportant details might include:
- wall displays
- carpet colour
- how noisy the corridor is
- what pupils are wearing
Those details exist in the real world, but they do not help solve the route-finding problem.
Abstraction helps you:
- reduce the amount of information to think about
- avoid being distracted by irrelevant details
- create a simpler model of the real world
- identify the important inputs, outputs and rules
- design an algorithm that solves the intended problem
Abstracting a school route-finding problem
-
Decide the purpose of the system: it needs to find a sensible walking route between two rooms in school.
-
Keep details that affect the route: room names, corridor connections, stairs, locked doors and approximate walking times.
-
Ignore details that do not affect the route: poster colours, teacher names, floor texture and background noise.
-
The simplified model can now compare possible routes because it contains the details needed for that purpose, without unnecessary real-world clutter.
Purpose controls abstraction
A detail is not always important or unimportant forever. It depends on the problem. “Background noise” is irrelevant for a route-finding app, but it might be important for an app measuring safe noise levels in a classroom.
In real problem solving, decomposition and abstraction are usually used together.
You might first decompose a system into smaller parts. Then, for each part, you use abstraction to decide what information that part really needs.
For example, in a lunch-ordering system:
- the payment part needs the amount owed and payment method
- the allergy check part needs ingredients and allergy information
- the stock update part needs item quantities
- none of these parts needs to know the colour of the table or the weather outside
Algorithm
An algorithm is a finite, ordered set of steps that can be followed to solve a problem.
Decomposition and abstraction help you design better algorithms because they make the problem clearer before you start writing steps or code.
Combining decomposition and abstraction for a ticket machine
-
Decompose the ticket machine problem into smaller parts: choose ticket type, calculate price, take payment, print ticket and give change if needed.
-
For the “calculate price” part, abstract away irrelevant details such as the passenger’s clothing, the machine’s colour and the time the button was pressed if those do not affect the price.
-
Keep the details that do affect the price: ticket type, passenger category, destination zone and any discount.
-
The “calculate price” part can now be solved with a clear rule because it has the necessary information and is not mixed up with unrelated parts of the machine.
Analysis
Analysis means examining a problem carefully to work out what is needed, what information is involved, and what smaller tasks must be completed.
A large problem is hard to analyse all at once. Decomposition lets you ask, “What smaller jobs make up this problem?” Abstraction lets you ask, “Which details are relevant to each job?”
A smaller, simpler model is easier to explain.
For example, it is easier to understand “check whether the entered password has at least eight characters” than “handle all possible user account security features”. The smaller version has a clear focus.
Once the problem is split into parts and simplified, each part can be solved using a suitable method.
For example:
- a search feature might use a search algorithm
- a list of scores might need sorting
- a login form might need validation checks
- a stock system might update stored quantities
You are not expected to model every real-world detail. You are expected to show that you can choose useful parts and relevant information.
Confusing decomposition and abstraction
Decomposition is about splitting a problem into smaller parts. Abstraction is about hiding unnecessary detail. If an answer says only “make it simpler”, it may be too vague unless you explain how.
In GCSE answers, try to link the technique to the benefit.
Instead of writing:
Write something more precise:
- “Decomposition makes the problem easier to solve because each subproblem can be designed, coded and tested separately.”
- “Abstraction makes the model easier to understand because irrelevant details are removed, leaving only the information needed for the task.”
Use because
When explaining a benefit, use the word because. It forces you to connect the technique to the reason it helps.
In the exam
-
If asked about decomposition, say that it breaks a complex problem into smaller, manageable subproblems, then explain a benefit such as easier testing, understanding or team working.
-
If asked about abstraction, say that it removes unnecessary detail and focuses on relevant information, then link this to creating a simpler model.
-
If asked about modelling a real-world situation, mention both ideas: split the situation into parts and keep only the details needed for the purpose of the system.
Check yourself
- What is the difference between decomposition and abstraction?
- Why might a route-finding app ignore the colour of classroom walls?
- How could decomposition help a team build a large program more easily?