Community resourceWorksheet
OCR H446 2.2.2 Decomposition and abstraction in solution design
Part 2 of 14 · H446 2.2.2 · Computational methods
Decomposition and abstraction are the paired design decisions H446 2.2.2 expects students to link, yet they are often answered with boxes on a diagram and nothing more. Here a venue-booking service is split into coherent responsibilities and students must state exactly what crosses each boundary and what a component should never need to know.
Students will:
- separate a mixed problem into components with coherent, distinct responsibilities
- specify the data received, the rule applied and the result returned for a named component
- name a detail a component should not need, and justify leaving it out
- explain how decomposition and abstraction support each other rather than being alternatives
- discuss problem recognition, decomposition and abstraction together against an unfamiliar library system
Inside: 7 explanation cells, 1 multiple-choice question, 2 fill-in-the-blanks cells and 2 written answers. 23 marks, about 20 to 30 minutes.
Series: H446 2.2.2 · Computational methods, part 2 of 14.
Shared by Coding PathwayVerified teacher
- 12 cells
- About 30 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 3 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Decomposition and abstraction in solution design
A venue-booking service mixes requests, capacity checks, allocation and messages. Computational thinking makes the problem manageable by separating responsibilities and representing only what each part needs.
By the end, you will be able to
- decompose a problem into coherent subproblems;
- define useful interfaces between components;
- apply abstraction within a decomposition;
- evaluate a proposed design in its context.
Reactivate: decomposition divides a problem; abstraction retains relevant detail for a purpose.
Two complementary decisions
Decomposition asks: what smaller responsibilities make up the solution? Abstraction asks: what does each responsibility need to represent, and what can it ignore?
The components are useful only if their interfaces are clear. check_capacity(event_id, requested_places) might return a Boolean or number of places. That named exchange allows components to be developed and tested separately.
Worked examination reasoning
Problem: allocate accessible places for several events.
- Recognise inputs and outputs: event, party size, access needs → allocation or rejection.
- Decompose by coherent responsibility: validate request; check capacity; choose an eligible place; store allocation; produce response.
- Define dependencies: allocation needs a valid request and current capacity; response needs the final status.
- Abstract: the capacity component needs totals and existing allocations, not an attendee’s favourite music.
- Evaluate: separation supports focused tests, but badly chosen boundaries can duplicate data or create excessive communication.
An exam answer gains strength when each point names what the component does and why that matters in the scenario.
Which statement correctly links decomposition and abstraction?
- ABoth mean removing every difficult detail
- BDecomposition creates smaller responsibilities; abstraction selects the details each must represent
- CAbstraction determines execution order; decomposition chooses data types
- DThey are names for selection and iteration
- responsibility
- inputs
- output
- colour
Guided checkpoint: expose the interfaces
For the component choose eligible room, write: data received → rule applied → result returned. Then state one detail it should not need. This is stronger than drawing boxes with no explanation of what crosses their boundaries.
Specify the interface and abstraction boundary for choose_eligible_room.
Name at least three inputs or stored values, the returned result, and one suppressed detail with a reason.
Students type their answer here.
Independent examination practice
A regional library wants an online system that accepts requests, checks whether an item can be borrowed, reserves copies, arranges collection and notifies users. Demand can be high and some items have restrictions. Plan before writing: inputs/outputs → subproblems → dependencies → abstractions → benefit and limitation.
Discuss how problem recognition, decomposition and abstraction could be used to develop the library system.
Write a structured response with explicit scenario application and a supported judgement.
Students type their answer here.
Closed-book checkpoint
Complete each sentence from memory. There is no answer bank and correctness is held for teacher review.
Review your understanding
Before submitting, check that you can explain the central distinction in your own words, expose the intermediate state that supports your answer and apply the method in an unfamiliar context.