AS Computer Science 9618: Applying Abstraction to a Real System

A city bike-rental app needs a way to help a user find the nearest bike station that currently has at least one bike available. In the real world, each physical bike station has many attributes, including: its GPS coordinates (latitude and longitude), the number of bikes currently available at it, its total docking capacity, the date it was installed, the name of the company that maintains it, and the colour of its signage.

(a) State the computational thinking technique used when a systems designer builds a simplified model of a bike station for this "find the nearest station with an available bike" feature, keeping only the details relevant to that specific feature and leaving out the rest. [1]

(b) State which two of the six attributes listed above should be kept in this simplified model for the "find the nearest station with an available bike" feature, and explain why the other four attributes can safely be left out of this particular model. [4]

(c) Explain, in general terms, why using this technique, rather than including every real-world attribute of a bike station in the app's model, is beneficial for a system like this one. [2]

Part (a): Identifying the technique

Building a simplified model of a real-world object by keeping only the details that are essential to the current problem, and ignoring or hiding everything else, is the computational thinking technique known as abstraction. [1 mark]

Part (b): Choosing which attributes are essential

The feature being built is specifically “find the nearest station that currently has at least one bike available”. Checking each of the six real-world attributes against that specific task:

GPS coordinates. Essential, because the app cannot work out which station is nearest to the user without knowing where each station actually is.
Number of bikes currently available. Essential, because the app must check a station actually has at least one bike free before suggesting it.
Total docking capacity, not needed: how many docks a station has in total does not affect whether it is nearby or currently has a bike available.
Date it was installed, not needed: when a station was installed has no bearing on its location or on how many bikes are free right now.
Name of the maintenance company, not needed: who maintains the station does not affect where it is or whether it has a bike free.
Colour of its signage, not needed: purely cosmetic, and irrelevant to finding a nearby, available bike.

So the two essential attributes are GPS coordinates and number of bikes currently available; the other four can be safely excluded from this particular abstracted model, because none of them affects the answer to the specific question the feature needs to answer.

[4 marks]: [1] for GPS coordinates identified, [1] for number of bikes currently available identified, [1] for a valid justification of why these two are needed, [1] for explaining that the other four attributes do not affect this specific feature and so can be excluded.

Part (c): Why abstraction is beneficial here

Leaving out attributes that are irrelevant to a given feature, rather than including every real-world detail of a bike station, keeps the model smaller and simpler. This makes the app easier and faster to design, and there is less data to store and process for this feature, which also reduces the chance that irrelevant detail causes confusion, bugs, or unnecessary work elsewhere in the system. Crucially, none of this simplification costs the feature anything: the task of finding the nearest station with an available bike is still solved exactly as well, because the four excluded attributes never actually affected the answer to that task.

[2 marks]: [1] for identifying reduced complexity/less data to store and process (a simpler, more efficient model), [1] for explaining this still solves the given task equally well since the excluded details are irrelevant to it (and/or reduces the chance of errors from handling unnecessary detail).

Final answers

(a) Abstraction
(b) Keep GPS coordinates and number of bikes currently available; total docking capacity, installation date, maintenance company name and signage colour can all be excluded, as none of them is needed to find the nearest station with a free bike.
(c) A simpler model with only the relevant attributes is easier to design, store, process and maintain, and still solves the specific task equally well, since the excluded details do not affect the answer to it.