Community resourceWorksheet
OCR H446 2.1.1 Devising and evaluating abstract models
Part 2 of 2 · H446 2.1.1 · Thinking abstractly
Beyond selecting detail, OCR H446 2.1.1 asks students to devise abstract models and then judge them. Racing-game opponents, two journey-time models and a venue queue make the model boundary and its assumptions the thing under evaluation.
Students will:
- state the entities, properties and rules a model needs to meet its purpose
- draw a model boundary and say what is deliberately left outside it
- tell a limitation of a model apart from a fault in its code
- compare two models on data required, processing complexity and likely accuracy, then recommend one
- devise a queue model and state the limitation its assumptions create
Inside: 7 explanation cells, 1 multiple-choice question, 1 fill-in-the-blanks cell and 3 written answers. 25 marks, about 25 to 35 minutes.
Series: H446 2.1.1 · Thinking abstractly, part 2 of 2.
Shared by Coding PathwayVerified teacher
- 12 cells
- About 30 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 15 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Designing and evaluating abstract models
A computer-controlled opponent in a racing game is not a real driver. It is a model that stores selected information and follows programmed rules. The model needs enough detail to behave believably, but including every feature of a real car and driver would add unnecessary complexity.
By the end, you will be able to
- describe the objects, data, rules, boundaries and assumptions in a model;
- state clearly how an abstraction differs from reality;
- explain how an omitted detail or assumption can limit a model;
- design and evaluate a model for a stated purpose.
Remember: the model's purpose determines which details are relevant.
Decide what belongs in the model
The model boundary separates the details represented by the program from the real details that have been left out. An assumption is something the model treats as true. In this example, the model assumes that one grip value is suitable throughout the race.
An omitted detail can create a limitation. The program might run exactly as designed, but its opponent will not change its cornering behaviour when it rains because real weather is outside the model. That is a limitation of the model, not necessarily a programming error.
Worked model: build from the purpose
Purpose: create a computer-controlled opponent that completes a short arcade race believably.
- An entity is an object represented by the model: the opponent's car.
- A property is stored information about that object: its position, speed, target lane and grip value.
- A rule controls behaviour: slow near a sharp corner and avoid an occupied lane.
- The boundary defines what this model covers: one race using the supplied track data.
- An assumption is treated as true: the same grip value applies throughout.
- A limitation follows from that assumption: wet or damaged surfaces cannot change the car's grip.
These headings are a useful checklist for planning a model. The key reasoning is the link between them: the model omits changes in the track surface, so it uses a fixed grip value, which can make its cornering less realistic.
Which option is a model limitation rather than necessarily a programming bug?
- AThe code uses an undefined variable.
- BThe model assumes every surface has equal grip.
- CA loop never terminates.
- DA function is called with the wrong number of parameters.
The same game adds a realistic simulation mode. State two ways in which the current model differs from a real race. For each difference, explain one change that would make the model more realistic.
Write each point as: in reality ...; the current model ...; therefore the improved model should ....
Students type their answer here.
Guided comparison
Model A predicts journey time using distance ÷ constant speed. Model B also includes time of day, route type and current closures.
Compare them on the same criteria: required data; processing complexity; likely accuracy; and situations in which each remains useful. More detail is not automatically better if the required data is unavailable or the purpose needs only a quick estimate.
Compare Model A and Model B for giving a cyclist a quick journey estimate. Reach a recommendation.
Compare both models using the same criteria, such as required data, processing, likely accuracy and usefulness. Then choose the model that best fits a quick estimate.
Students type their answer here.
Independent model: venue-entry queues
A venue wants a model that predicts approximate waiting time before an event. Available data includes number waiting, average checks per minute, number of open lanes, individual bag contents, staff experience and weather.
Design an abstract model that predicts the approximate waiting time. State its purpose. Then include three items of data to retain, one calculation or rule, two assumptions or omitted details, and one limitation caused by an assumption or omission.
Use the headings Purpose, Retained data, Rule, Assumptions or omissions, and Limitation. Make sure the limitation follows from one of your assumptions or omissions.
Students type their answer here.
Checkpoint
Complete the model explanation from memory. Use each technical term accurately; your teacher will review your answers.
Review your understanding
Before submitting, check that you can state exactly how a model differs from reality, explain a limitation caused by an omission or assumption, and judge whether a model is suitable for its purpose.