Decomposition and Abstraction
The two thinking skills the whole course rests on, what each one actually does to a problem, and how to write about them in a way that scores.
Decomposition: breaking the problem up
Decomposition means breaking a large, complex problem down into smaller sub problems that can each be solved on their own.
The reason this works is worth understanding properly, because the exam asks for it. A large problem is hard to hold in your head all at once. Once it is split, each sub problem is small enough to be understood, solved and, crucially, tested in isolation. If the finished system is wrong, you can test each part separately to find which one is at fault instead of staring at the whole thing.
What decomposition buys you
- Each part can be solved separately. A sub problem that fits on one screen is a problem you can actually finish.
- Work can be shared out. Several programmers can write different sub programs at the same time, which is impossible if the program is one enormous block.
- Faults are easier to find. If the total is wrong but the input and the sorting are right, the fault is in the calculation. You have narrowed a whole program down to a few lines.
- Parts can be reused. A sub program that validates a date works in every system that needs a date.
- Maintenance is cheaper. Changing the way discounts are worked out means editing one sub program, not hunting through a thousand lines.
A worked decomposition
Take "write a program to run a school library". That is far too big to start coding. Decompose it:
- Store the details of every book.
- Store the details of every borrower.
- Issue a book to a borrower.
- Take a book back in.
- Work out whether a book is overdue and calculate the fine.
- Search the catalogue by title or author.
Each of those is now a sub problem you could genuinely sit down and write. Numbers 5 and 6 could even be given to two different people on the same afternoon.
Decomposition breaks a complex problem into smaller sub problems, each of which can be solved, tested and maintained independently.
- Start with the whole problem at the top.
- Split it into a few main parts.
- Keep splitting until every part is small enough to solve.
- Why bother: parts can be built in parallel, tested separately and reused.
Abstraction: deciding what to ignore
Abstraction means removing or hiding unnecessary detail so that only the information needed to solve the problem is left.
The word "unnecessary" is doing all the work in that definition. Abstraction is not simply "making things simpler". It is a judgement about which details matter for this particular problem and deliberately throwing the rest away.
Why hiding detail helps
- The problem becomes easier to understand, because there is less to think about.
- The solution becomes quicker to design and program, because there is less to represent.
- The program needs less memory and less processing, because it is not storing or calculating things nobody will use.
- The same solution can then be applied to similar problems, because it is no longer tied to one set of irrelevant specifics.
Abstraction in practice
| Real situation | Kept | Removed | Why |
|---|---|---|---|
| Sat nav routing | Junctions, road lengths, speed limits | Building colours, hedges, road surface | None of the removed detail changes which route is shortest |
| Chess program | Piece type, square, whose turn it is | The weight of the pieces, the wood grain | The rules of chess do not depend on them |
| School register | Name, tutor group, present or absent | Eye colour, favourite subject | The register only has to record attendance |
| A racing game | Position, speed, direction, grip | Real tyre chemistry, exact engine thermodynamics | A believable feel matters more than physical accuracy, and full physics would be too slow to compute |
Compression squeezes data so that the same information takes fewer bits. Abstraction throws information away on purpose because it was never needed. Saying "abstraction makes the file smaller" scores nothing.
Abstraction inside a program
Every time you call a sub program you are using abstraction. When you write total = calculate_fine(days_late) you do not care how the fine is worked out at that moment. The detail is hidden inside the sub program, so the part of the code you are reading only shows what happens, not how.
- The real thing is full of detail: most of it is no use for the job in hand.
- The abstraction is a simple model that keeps only what the job needs.
- What stays: the stations, what connects to what, and the lines.
- What goes: the detail that does not help, such as houses, exact distances and street names.
Using both in an exam answer
Almost every question on this part of the specification gives you a scenario and asks how decomposition or abstraction would be used in that scenario. General definitions on their own score badly.
The two step answer
- Give the definition in one clean sentence.
- Apply it to the scenario using nouns from the question.
Take: "A company is writing an app that tells cyclists the safest route across a city. Explain how abstraction would be used when designing this app."
A weak answer says "abstraction removes unnecessary detail to make the problem simpler". True, and worth about one mark.
A strong answer says: "Abstraction means keeping only the detail needed to solve the problem. The app would store the junctions, the length of each road, whether there is a cycle lane and the accident history of each road, because all of those affect which route is safest. It would leave out the names of the shops on each street, the colour of the buildings and the exact shape of every bend, because none of them change the answer. Removing that detail means less data has to be stored and the routing calculation runs faster on a phone."
The single quickest way to lift a scenario answer is to say which specific things are kept and which specific things are discarded. Examiners cannot award application marks for an answer that would fit any scenario at all.
Telling the two apart under pressure
Ask yourself: has the problem been split into parts (decomposition), or has detail been left out (abstraction)? Splitting a shopping app into login, basket and payment is decomposition. Deciding the basket only needs the product code, quantity and price is abstraction.
Step 1 of 3 Decomposition: break the problem into parts small enough to solve one at a time.
Key terms you must be able to define
- Decomposition
- Breaking a large, complex problem down into smaller sub problems that can each be solved and tested separately.
- Abstraction
- Removing or hiding unnecessary detail so that only the information needed to solve the problem remains.
- Sub problem
- One of the smaller, self contained problems produced when a larger problem is decomposed.
- Computational thinking
- The process of analysing a problem so that it can be solved by a computer, using decomposition, abstraction and algorithmic thinking.
- Algorithm
- A precise sequence of steps that solves a problem or completes a task.
- Model
- A simplified representation of a real system that keeps only the features relevant to the problem being solved.
- Subprogram
- A named block of code that performs one task and can be called from elsewhere, hiding its internal detail from the caller.
- Maintainability
- How easily a program can be understood and changed later, which decomposition improves by keeping each task in its own block.
Flashcards
Say the definition out loud before you flip the card. Retrieving it from memory is what builds recall, reading it again is not.
Reach the top grade on this topic
Average answers define the words. Grade 9 answers use them on the scenario in front of them.
Say what is removed and why it does not matter. "Abstraction removes unnecessary detail" is a definition. "The app ignores the colour of each building because it has no effect on the length of a route" is an application, and application marks are where the grade is won.
Give the consequence. Every point should end in a benefit: easier to test, faster to run, less memory needed, several programmers can work at once, one change fixes every use. A point without a consequence is half a point.
Do not mix the two up. If your answer to an abstraction question contains the phrase "split into smaller parts", you have written about decomposition and you will get nothing for it.
- Be able to define decomposition and abstraction in one sentence each, without using the other word in the definition
- Be able to decompose any given scenario into at least four named sub problems in under a minute
- Be able to name three specific details you would keep and three you would remove for any given scenario
- Be able to state a consequence for every point you make, such as faster processing or independent testing
Mistakes that cost marks here
- Defining abstraction as 'making something simpler'. Say what is removed, that it is unnecessary detail, and that what remains is what is needed to solve the problem.
- Using the words decomposition and abstraction as if they mean the same thing. One splits a problem into parts, the other removes detail from it.
- Writing a definition with no reference to the scenario in the question, which loses every application mark.
- Claiming abstraction makes a program more accurate. It usually makes it less accurate on purpose, in exchange for being faster and simpler.
- Saying decomposition 'makes the code shorter'. It usually does not. It makes the code easier to test, reuse and maintain.
Harry Beck's 1933 London Underground map is the most famous abstraction ever drawn. He threw away the true distances and the real geography, kept only the order of the stations and which lines meet where, and produced something far more useful for the one job passengers actually have.
Knowledge check
Exam-style questions
Five written questions in the style of the real paper. Write a full answer, then let the marker check it against the mark scheme.
- LBreaking a large or complex problem into smaller parts or sub problems
- LSo that each part can be solved, tested or understood separately
Decomposition means breaking a large and complex problem down into a number of smaller sub problems. Each sub problem is small enough to be understood, solved and tested on its own, and the solutions are then combined to solve the original problem.
- LThe overall problem is broken into smaller sub problems
- LNames sensible sub problems for this scenario, such as scanning a barcode, keeping a running total, taking payment or checking the customer out
- LEach sub problem can be written and tested independently
- LDifferent developers can work on different parts at the same time, and a fault can be traced to a single part
Decomposition would be used to break the whole app down into smaller sub problems that can each be tackled on their own. Sensible sub problems here would be reading a barcode from the camera, looking that barcode up to find the product and its price, keeping a running total of the basket, applying any offers, taking a card payment and producing a digital receipt. Each of these can be written and tested independently, so the payment code can be proved correct before it is ever joined to the scanning code. Splitting the work this way also allows several developers to build different parts at the same time, and if the finished app produces a wrong total the fault can be traced to a single sub program rather than searched for across the whole system.
- LRemoving or hiding detail that is not needed to solve the problem
- LOnly the information relevant to the problem is kept
- LSo the problem is simpler to solve, or the solution needs less storage or processing
Abstraction means removing or hiding the detail that is not needed to solve a particular problem, so that only the information that is genuinely relevant remains. It is used because a problem with less detail in it is easier to understand and quicker to design a solution for, and because the resulting program stores and processes less data, so it runs faster and uses less memory.
- LNames a relevant detail that is kept, such as location, rainfall amount, time or temperature
- LJustifies keeping it because it affects the forecast or the output the user needs
- LNames an irrelevant detail that is removed, such as building colours, street names or the shape of individual clouds
- LJustifies removing it because it does not change the result and would waste storage or processing
The developers would keep the location of each measurement and the amount of rain recorded there, because the whole purpose of the app is to tell a user how much rain is expected at a place, so neither can be removed without breaking the app. They would also keep the time of each reading, since a forecast is meaningless without knowing when it applies. They would remove details such as the colour of the buildings in each town and the exact shape of individual clouds, because neither changes the rainfall figure a user is shown. Storing and processing that extra detail would use more memory and slow the forecast calculation down for no benefit at all.
- LDecomposition splits a problem into smaller sub problems
- LAbstraction removes or hides detail that is not needed
- LBoth reduce the complexity the programmer has to deal with at once
- LThey are usually used together, with a problem first broken up and detail then removed from each part
Decomposition and abstraction are both ways of making a large problem manageable, but they act on it differently. Decomposition splits the problem into smaller sub problems, so a library system becomes separate tasks for issuing books, returning books and calculating fines. Abstraction does not split anything: it removes detail from the problem, so the book record keeps the title, author and ISBN but not the colour of the cover. What they share is that each reduces how much a programmer has to hold in mind at one time, which makes the solution quicker to design and easier to test. In practice they are used together, because a problem is normally decomposed into parts first and then unnecessary detail is stripped out of each part.