Free A-Level Computer Science guide

Abstraction and procedural design: build a model, then connect the steps

Extend abstraction and decomposition beyond naming smaller tasks. Build a model for a new situation, decide what it leaves out, and specify how the solution's parts cooperate.

Content owner: Michael Print · Written for A-Level learners · Checked against official specifications

The idea to start with

Abstraction represents the information and behaviour relevant to a purpose while omitting other detail. A model is useful when its simplifications still support the decision being made. Its correctness depends on those assumptions.

Procedural thinking turns the problem into ordered, connected responsibilities. Each subprocedure needs a defined job, inputs and outputs. Dependencies explain the ordering: route calculation needs a validated network, and the final display needs a checked route.

OCR H446 · 2.1.1(a–d), 2.1.3(a–d); reinforces 2.2.2(c,e)

Before you start

Useful foundations

Variables, selection and functions
The existing abstraction and decomposition guide

By the end, you should be able to

Justify which details an abstract model retains or omits.
Explain how a correct result in a model can fail in reality.
Identify components of a problem and corresponding solution responsibilities.
Specify subprocedure interfaces and justify their execution order.

Start with the decision the model must support

An invented school needs a minibus route through six pickup points. It seeks the permitted route with the smallest estimated journey time, carrying no more than twelve passengers.

Represent stops as IDs, roads as connections, travel times as positive numbers and passengers as counts. Omit paint colour: it does not affect this decision.

Keep validity constraints: one-way roads control permitted travel, passenger counts control capacity and pickup durations affect arrival times. If a passenger needs an accessible entrance, accessibility becomes relevant too.

Abstraction chooses detail for a purpose. State the boundary: all passengers remain on board, each required stop is visited once and travel estimates stay fixed for this run.

If passengers can leave along the route, track changing load instead of one total. The same places can require a different model when the question changes.

Model choices for the minibus question
Real-world detail	Representation or omission	Reason
Junctions and permitted roads	Directed graph	Captures where travel is possible
Journey and pickup duration	Minutes on edges and stops	Determines estimated completion time
Passenger count	Non-negative integer per stop	Checks the twelve-seat limit
Bus paint colour	Omitted	Does not affect route validity or time here
Changing congestion	Fixed estimate for this run	Simplification that can make predictions inaccurate

A model and reality can disagree

The model predicts eighteen minutes, but a temporary closure blocks a road. Its route can be valid in the stored graph yet impossible on the day.

The calculation may be correct for outdated data. Distinguish an implementation error, a missing model requirement and a changed real-world input.

Compare predicted times with journeys, check restrictions and ask whether new stakeholder needs change the model. Too much detail makes it cumbersome; too little makes its answer unsuitable. State the consequences of each simplification.

Separate responsibilities and define their interfaces

Separate coherent responsibilities, rather than screens or equal-sized code blocks. Each part should have a purpose that can be reasoned about and checked independently.

Interfaces describe what crosses a boundary. Use shared stop IDs and pass results as parameters to make dependencies visible instead of reading unrelated global state.

Keep failure distinct from empty success. No pickups can give an empty route; unreachable required pickups need a separate no-route result. The signatures shown are a design, not an implemented planner.

Match each responsibility to its interface

Validate input: validate_stops(raw_stops) returns validated records or input errors.
Build permitted travel: build_network(roads, stops) returns a graph using the same stop IDs.
Choose a candidate: plan_route(graph, start, required_stops) returns a route or a no-route result.
Check constraints: check_route(route, graph, passengers, capacity) reports whether the route meets the rules.
Present the result: Communicate the checked route and its assumptions, or the reported failure.

Worked example

Order a complete planning attempt

Read the requested start, stop records, road records and capacity. Reject missing identifiers, negative passenger counts and impossible time values before doing route calculations.
Construct the directed graph from the validated records. Check that each road references known stops; otherwise report the inconsistency.
Check whether the total requested passenger count exceeds twelve under the stated everyone-stays-on-board assumption. A route cannot repair a capacity failure.
Calculate a candidate route using the validated graph. Report no route if required stops cannot be reached under the planner's rules.
Check the candidate's required-stop coverage and estimated time, then display the route with its assumptions. Presentation follows checking because an unchecked candidate is not a confirmed plan.
Some data entry work can occur independently, but graph construction depends on validated identifiers and route selection depends on the graph. Explain those dependencies when justifying the sequence.

The route-planning dependencies

Validate
Check stop/road records and capacity before calculations.
Build the graph
Use known, validated stop IDs and permitted roads.
Check capacity
Reject a total above twelve under the everyone-remains-on-board rule.
Calculate
Find a candidate in the graph, or report no route.
Check and display
Verify required-stop coverage and time before presenting the plan.

Independent data entry can overlap. The graph and route calculation still depend on earlier results.

Worked example

Transfer the method to equipment loans

For an invented camping club, the decision is whether a tent can be loaned for a requested interval. Represent tent ID, capacity, condition and existing loan intervals; omit fabric decoration.
Use intervals including the start and excluding the end. Existing [5, 8) and requested [8, 10) do not overlap; [7, 9) overlaps. The convention permits a return and a new loan at the same boundary.
Design validate_request, find_suitable_tents, check_overlaps and present_choices. Availability checking consumes validated dates and tent IDs, so it follows validation and candidate identification.
State the simplification: the model assumes an immediately reusable tent. If cleaning takes a day, reserve that extra interval or a model-available tent may be unavailable in reality.

Original A-Level practice

5 original questions total 22 marks. Attempt each before opening the independently written indicative marking guidance.

Question 1

4 marks

A flood evacuation planner chooses usable walking routes. Identify three details its model should retain and one it can omit, explaining each choice.

Show solution and marking guidance

Indicative answer

Retain permitted paths or connectivity because they determine possible routes (1), flood status because it can make a path unusable (1), and walking time or accessibility requirements because they affect the stated evacuation needs (1). Omit an unrelated detail such as building paint colour with a purpose-based justification (1). Accept other suitably explained choices.

Question 2

4 marks

The minibus algorithm calculates the cheapest route in its stored graph, but the bus cannot use a newly closed road. Explain why this need not be an algorithm error and propose a specific improvement.

Show solution and marking guidance

Indicative answer

The algorithm may correctly solve the represented graph problem (1). Reality has changed while the graph still contains the blocked connection (1). Update or verify road availability before planning (1), then recompute a route using the revised graph (1).

Question 3

6 marks

Design four subprocedures for a club room-booking checker. Give an input and output for each, and justify one dependency in their ordering.

Show solution and marking guidance

Indicative answer

One mark each for four coherent subprocedures, such as validate_request, find_rooms, check_overlaps and present_choices, with usable inputs and outputs (4). Identify a real dependency, such as overlap checking consuming validated intervals and room IDs (1), and explain why its predecessor must therefore run first (1). Equivalent designs are acceptable.

Question 4

4 marks

Use start-inclusive, end-exclusive intervals. An item is reserved for [12, 16). Decide whether requests [10, 12) and [15, 18) overlap and explain the boundary convention.

Show solution and marking guidance

Indicative answer

[10, 12) does not overlap (1), because time 12 is excluded from that request and begins the existing reservation (1). [15, 18) overlaps (1), with shared time from 15 up to 16 (1).

Question 5

4 marks

A route planner returns [] both when there are no requested stops and when a required stop is unreachable. Explain the interface problem and suggest a clearer design.

Show solution and marking guidance

Indicative answer

The same value represents two different outcomes (1), so the caller cannot reliably decide whether to display success or failure (1). Return a separate success/failure indicator or distinct no-route result (1), preserving an empty route as a valid result for no requested stops (1).

Specification and references

This guide addresses OCR H446 2.1.1(a–d), 2.1.3(a–d); reinforces 2.2.2(c,e). Check your examination year and the complete specification for the assessment scope.

OCR H446 specification, version 3.0 (April 2026)

These are independently written explanations and practice questions. CompSciTutoring.co.uk is not affiliated with or endorsed by an examination board. The marking guidance is indicative; always check the syllabus for your examination year.

Found an error? Email a correction.

Need help applying this to unfamiliar questions?

Use the free examples first, then explore one-to-one tuition if guided practice would help.

Explore tuition Email Michael

Free A-Level Computer Science guide

Abstraction and procedural design: build a model, then connect the steps

Extend abstraction and decomposition beyond naming smaller tasks. Build a model for a new situation, decide what it leaves out, and specify how the solution's parts cooperate.

Content owner: Michael Print · Written for A-Level learners · Checked against official specifications

The idea to start with

OCR H446 · 2.1.1(a–d), 2.1.3(a–d); reinforces 2.2.2(c,e)

Before you start

Useful foundations

Variables, selection and functions
The existing abstraction and decomposition guide

By the end, you should be able to

Justify which details an abstract model retains or omits.
Explain how a correct result in a model can fail in reality.
Identify components of a problem and corresponding solution responsibilities.
Specify subprocedure interfaces and justify their execution order.

Start with the decision the model must support

An invented school needs a minibus route through six pickup points. It seeks the permitted route with the smallest estimated journey time, carrying no more than twelve passengers.

Represent stops as IDs, roads as connections, travel times as positive numbers and passengers as counts. Omit paint colour: it does not affect this decision.

Abstraction chooses detail for a purpose. State the boundary: all passengers remain on board, each required stop is visited once and travel estimates stay fixed for this run.

If passengers can leave along the route, track changing load instead of one total. The same places can require a different model when the question changes.

Model choices for the minibus question
Real-world detail	Representation or omission	Reason
Junctions and permitted roads	Directed graph	Captures where travel is possible
Journey and pickup duration	Minutes on edges and stops	Determines estimated completion time
Passenger count	Non-negative integer per stop	Checks the twelve-seat limit
Bus paint colour	Omitted	Does not affect route validity or time here
Changing congestion	Fixed estimate for this run	Simplification that can make predictions inaccurate

A model and reality can disagree

The model predicts eighteen minutes, but a temporary closure blocks a road. Its route can be valid in the stored graph yet impossible on the day.

The calculation may be correct for outdated data. Distinguish an implementation error, a missing model requirement and a changed real-world input.

Separate responsibilities and define their interfaces

Separate coherent responsibilities, rather than screens or equal-sized code blocks. Each part should have a purpose that can be reasoned about and checked independently.

Interfaces describe what crosses a boundary. Use shared stop IDs and pass results as parameters to make dependencies visible instead of reading unrelated global state.

Match each responsibility to its interface

Validate input: validate_stops(raw_stops) returns validated records or input errors.
Build permitted travel: build_network(roads, stops) returns a graph using the same stop IDs.
Choose a candidate: plan_route(graph, start, required_stops) returns a route or a no-route result.
Check constraints: check_route(route, graph, passengers, capacity) reports whether the route meets the rules.
Present the result: Communicate the checked route and its assumptions, or the reported failure.

Worked example

Order a complete planning attempt

Read the requested start, stop records, road records and capacity. Reject missing identifiers, negative passenger counts and impossible time values before doing route calculations.
Construct the directed graph from the validated records. Check that each road references known stops; otherwise report the inconsistency.
Check whether the total requested passenger count exceeds twelve under the stated everyone-stays-on-board assumption. A route cannot repair a capacity failure.
Calculate a candidate route using the validated graph. Report no route if required stops cannot be reached under the planner's rules.
Check the candidate's required-stop coverage and estimated time, then display the route with its assumptions. Presentation follows checking because an unchecked candidate is not a confirmed plan.
Some data entry work can occur independently, but graph construction depends on validated identifiers and route selection depends on the graph. Explain those dependencies when justifying the sequence.

The route-planning dependencies

Validate
Check stop/road records and capacity before calculations.
Build the graph
Use known, validated stop IDs and permitted roads.
Check capacity
Reject a total above twelve under the everyone-remains-on-board rule.
Calculate
Find a candidate in the graph, or report no route.
Check and display
Verify required-stop coverage and time before presenting the plan.

Independent data entry can overlap. The graph and route calculation still depend on earlier results.

Worked example

Transfer the method to equipment loans

For an invented camping club, the decision is whether a tent can be loaned for a requested interval. Represent tent ID, capacity, condition and existing loan intervals; omit fabric decoration.
Use intervals including the start and excluding the end. Existing [5, 8) and requested [8, 10) do not overlap; [7, 9) overlaps. The convention permits a return and a new loan at the same boundary.
Design validate_request, find_suitable_tents, check_overlaps and present_choices. Availability checking consumes validated dates and tent IDs, so it follows validation and candidate identification.
State the simplification: the model assumes an immediately reusable tent. If cleaning takes a day, reserve that extra interval or a model-available tent may be unavailable in reality.

Original A-Level practice

5 original questions total 22 marks. Attempt each before opening the independently written indicative marking guidance.

Question 1

4 marks

A flood evacuation planner chooses usable walking routes. Identify three details its model should retain and one it can omit, explaining each choice.

Show solution and marking guidance

Indicative answer

Retain permitted paths or connectivity because they determine possible routes (1), flood status because it can make a path unusable (1), and walking time or accessibility requirements because they affect the stated evacuation needs (1). Omit an unrelated detail such as building paint colour with a purpose-based justification (1). Accept other suitably explained choices.

Question 2

4 marks

Show solution and marking guidance

Indicative answer

The algorithm may correctly solve the represented graph problem (1). Reality has changed while the graph still contains the blocked connection (1). Update or verify road availability before planning (1), then recompute a route using the revised graph (1).

Question 3

6 marks

Design four subprocedures for a club room-booking checker. Give an input and output for each, and justify one dependency in their ordering.

Show solution and marking guidance

Indicative answer

One mark each for four coherent subprocedures, such as validate_request, find_rooms, check_overlaps and present_choices, with usable inputs and outputs (4). Identify a real dependency, such as overlap checking consuming validated intervals and room IDs (1), and explain why its predecessor must therefore run first (1). Equivalent designs are acceptable.

Question 4

4 marks

Use start-inclusive, end-exclusive intervals. An item is reserved for [12, 16). Decide whether requests [10, 12) and [15, 18) overlap and explain the boundary convention.

Show solution and marking guidance

Indicative answer

[10, 12) does not overlap (1), because time 12 is excluded from that request and begins the existing reservation (1). [15, 18) overlaps (1), with shared time from 15 up to 16 (1).

Question 5

4 marks

A route planner returns [] both when there are no requested stops and when a required stop is unreachable. Explain the interface problem and suggest a clearer design.

Show solution and marking guidance

Indicative answer

The same value represents two different outcomes (1), so the caller cannot reliably decide whether to display success or failure (1). Return a separate success/failure indicator or distinct no-route result (1), preserving an empty route as a valid result for no requested stops (1).

Specification and references

This guide addresses OCR H446 2.1.1(a–d), 2.1.3(a–d); reinforces 2.2.2(c,e). Check your examination year and the complete specification for the assessment scope.

OCR H446 specification, version 3.0 (April 2026)

Found an error? Email a correction.

Need help applying this to unfamiliar questions?

Use the free examples first, then explore one-to-one tuition if guided practice would help.

Explore tuition Email Michael