Preview

The whole resource, exactly as a class sees it. Answers and marking are held back.

Thinking procedurally: decomposition and components

A student-run festival system has booking, programme and information responsibilities. Decomposition turns the large problem into coherent subproblems that can be understood, designed and tested.

By the end, you will be able to

distinguish components of a problem from components of a solution;
choose coherent responsibility and data boundaries;
interpret and complete a structure chart;
explain developed benefits for testing and team development.

Reactivate: a function or procedure should have one clear responsibility and interface.

From requirements to a structure chart

Problem components describe what must be solved: prevent timetable clashes, keep bookings within capacity and give attendees useful information. Solution components are designed modules/sub-procedures that perform those responsibilities.

Splitting code into arbitrary short sections is not useful decomposition. Each component needs a coherent purpose and named data flowing through its interface.

Worked responsibility table

Component	Inputs	Output or side effect
validate_slot	proposed start/end, existing slots	Boolean or clash details
check_capacity	requested count, capacity, booked	Boolean and remaining count
build_access_route	start, destination, access needs	route steps

Benefits become developed when linked: check_capacity can be tested with boundary values independently → capacity faults are found before integration. Separate components can be allocated to team members → work can progress with agreed interfaces.

Multiple choice1 mark

Which option is the best example of decomposition?

ADividing the festival problem into coherent booking, programme and information subproblems
BWriting every statement on a separate line
CRemoving all difficult requirements
DRunning every component at the same time

Written answer4 marks

Add two lower-level components beneath manage bookings. For each, state its responsibility and one input or output.

Choose components that together support safe booking.

Students type their answer here.

Guided boundary check

Poor design: one component called doEverything validates a request, changes capacity, formats an email and draws a venue map.

Ask: which data does each responsibility need? Which changes state? Which could be tested independently? A better boundary separates validation, reservation, route building and confirmation formatting.

Written answer6 marks

Explain two problems caused by the doEverything component and propose a better component boundary for each.

Use problem → mechanism → development consequence.

Students type their answer here.

Independent transfer: equipment loans

A community hub lends cameras, microphones and tripods. It must register items, find available items, create loans, accept returns and report overdue loans.

Written answer10 marks

Decompose the equipment-loan problem into four solution components. For each, state its responsibility and one interface value. Then explain one testing or teamwork benefit.

Keep data ownership and changes to availability clear.

Students type their answer here.

Checkpoint

Complete the distinction between problem and solution components. There is no answer bank, and correctness is withheld until teacher review.

Fill in the blanks4 marks

Decomposition breaks a larger problem into smaller checkpoint gap 1. Problem components describe what must be checkpoint gap 2, while solution components are designed modules with a coherent checkpoint gap 3. Named data should pass through each component's checkpoint gap 4.

Review your understanding

Before submitting, check that you can explain the main distinction in your own words, apply it in an unfamiliar context and justify the resulting behaviour or consequence.