Thinking abstractly

Abstraction is the deliberate removal of detail that does not matter, so that what does matter can be reasoned about.

• Representational abstraction — a model that throws detail away on purpose. The London Underground map is geographically wrong, and that is precisely why it works: it keeps the order of the stops and the interchanges, and discards distance and direction, which a passenger does not need.
• Abstraction by generalisation — grouping things by shared characteristics, as a superclass does.
• Procedural abstraction — a subroutine you can call without knowing its internals.
• Data abstraction — an ADT defined by its operations, not its storage.

Every abstraction is a choice about what to lose. The skill lies in knowing which details are safe to discard: a flight simulator that abstracts away turbulence is a fine game and a dangerous training tool.

Reality vs an abstraction of reality: a model is never the thing itself. A road-network graph with weights for distance cannot answer questions about roadworks unless you built that in. When a model gives a stupid answer, the fault is usually in what the abstraction omitted.

Thinking ahead

Deciding in advance what a program will need and what it must guarantee.

• Inputs and outputs — identify them before writing anything. What arrives, in what form, and what must come out?
• Preconditions — what must already be true for a subroutine to work? A binary search has the precondition that the list is sorted. Stating it means the caller is responsible for it, and the routine need not waste time re-checking.
• Caching — store the result of an expensive operation in case it is needed again. A browser caches images; a program memoises a recursive function so f(3) is computed once, not fifty times.
• Reusable components — write a general subroutine once, use it everywhere, and fix a bug in one place rather than twenty.

The cost of caching is not zero: cached data can become stale — the cached page is no longer what the server holds — and the cache consumes memory. You trade space for time, and you accept the risk of serving something out of date. Naming that trade-off is what earns the marks.

Your turn — caching a recursion

Thinking procedurally

Decomposition breaks a problem into sub-problems, and those into sub-problems, until each piece is small enough to solve directly. This is top-down design, and it is what a structure chart shows.

Why it works:

• each subroutine can be written, tested and debugged independently;
• work can be shared between programmers;
• modules can be reused in other projects;
• the order of execution can be reasoned about clearly.

Thinking logically means identifying every decision point — every place the flow of a program can branch — and being certain what happens in each case, including the ones you did not expect. Every unhandled branch is a bug waiting to happen.

The order of the sub-problems matters. Decomposition is not just chopping the problem up; it is working out which pieces depend on which. You cannot sort before you have read the data, and you cannot validate before you know the rules.

Thinking concurrently

Concurrent processing interleaves tasks so they appear simultaneous — on a single core, the OS rapidly switches between them. Parallel processing runs them genuinely at the same time on multiple cores.

That is Amdahl's law, and it is the single most important thing to say about parallelism in an exam. The speed-up is capped by the part of the task that cannot be divided, no matter how many cores you throw at it.

Your turn — parallel speed-up

Concurrency

Preconditions

Abstraction

Thinking logically

Thinking logically means finding every point at which the program can branch, and being certain what happens on every path — including the ones you did not plan for.

• Identify each decision point (every IF, CASE, WHILE condition).
• Work out the conditions that lead down each branch, and make sure they are exhaustive and mutually exclusive.
• Ask what happens on the branch you consider impossible. If the answer is "nothing", you have a bug.

The missing ELSE is a classic: the code above leaves grade undefined for any score of 30 or below. Every chain of conditions needs a final ELSE that catches everything else — even if all it does is raise an error.

Reusable components and performance modelling

Reusable components are written once and used many times — a library, a class, a subroutine with well-chosen parameters. The gains are compounding: less code to write, one place to fix a bug, and behaviour you have already tested. The discipline it demands is generality: a routine hard-coded to one file name is not reusable.

Performance modelling simulates how a system will behave before it is built — the load on a server at peak, the length of a supermarket queue, the throughput of a network. It is used where testing the real thing would be too expensive, too slow, or too dangerous (you cannot crash a real aircraft to see what happens).

The limit of any model: it inherits every assumption of the abstraction beneath it. A queue model that assumes customers arrive at random will be badly wrong at 5 p.m. on a Friday. When a model gives an absurd answer, suspect the assumptions, not the arithmetic.

Your turn — caching

Caching

Which element of computational thinking?

Tap the activity, then tap the kind of thinking it shows.

Match the idea to its name

Tap an item on the left, then its partner on the right.

The big ideas to know

That is the whole of OCR 2.1. Press Finish to see your score.