2.1.1 - Abstraction and models
A program cannot represent every detail of the world. You will choose the details that matter to a particular problem, build a model from them, and recognise when its simplifying assumptions stop being useful.
Choose detail according to the purpose
Abstraction removes unnecessary detail while retaining the features needed to solve a problem. What counts as unnecessary depends on the purpose; it does not mean deleting as much information as possible.
A college wants to recommend a walking route between classrooms. For that purpose, retain room identifiers, connections between rooms, whether a connection is open, and a walking-time estimate. The colour of a door and the posters on a corridor wall do not help choose a route, so omit them. However, stairs matter to a wheelchair-accessible route: removing that detail would simplify the model at the cost of an incorrect recommendation.
This reduces the number of properties the programmer must store and process. Searching a small set of connections is easier to reason about than analysing a detailed three-dimensional building. The learner-facing route can also be simpler to interpret. These benefits arise from removing irrelevant detail; a badly chosen abstraction can hide something essential instead.
An abstraction is not the same operation as decomposition. Abstraction decides which details to represent. Decomposition divides a problem into manageable subproblems, such as finding a route and displaying it. Both can be used in one design.
Turn the retained detail into a computational model
An abstract model specifies the entities, properties, relationships and rules used to represent a situation. A list of things to ignore is only half of a model: the computer also needs a usable representation of what remains.
For the classroom route problem, represent rooms as nodes and usable direct connections as edges. Assign each edge an estimated duration in minutes. Assume travel is possible in both directions and times are fixed during a search. The following complete small model has no other connections:
| Connection | Time in minutes | Step-free? |
|---|---|---|
| A–B | 2 | Yes |
| B–D | 3 | Yes |
| A–C | 1 | Yes |
| C–D | 2 | No |
A route from A to D through C takes minutes. Through B it takes minutes. The fastest route in this model is A–C–D; the fastest step-free route is A–B–D. This is model use, not a claim about measured real travel time. You can read these two candidate routes directly; no knowledge of a shortest-path algorithm is needed here.
Different purposes need different models. To estimate a printer queue's waiting time, represent each pending job by its page count and arrival order, plus the printer's pages-per-minute rate. Font colour may be irrelevant to a monochrome page-count estimate. If the purpose changes to estimating colour-ink consumption, colour coverage becomes essential. An attendance system instead needs student identifiers, session identifiers and attendance states, not edges or page counts.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account