Community resourceWorksheet

OCR H446 2.1.3 Procedural order and sub-procedures

Part 2 of 2 · H446 2.1.3 · Thinking procedurally

Correct components in the wrong order still produce an incorrect solution, which is the reasoning OCR H446 2.1.3 examines here. A digital escape-room booking workflow drives the ordering work, supported by a trace table, a Python admission function and a pseudocode design task.

Students will:

  • order sub-procedures using data dependencies, preconditions and state changes
  • explain why validation must come before any change to stored capacity
  • trace a workflow and record which route reaches confirmation
  • implement an ordered admission function that leaves external state unchanged
  • design pseudocode from named sub-procedures showing parameters and returned values

Inside: 7 explanation cells, 2 fill-in-the-blanks cells, 2 written answers, 1 Python task and 1 trace table. 21 marks, about 25 to 35 minutes.

Series: H446 2.1.3 · Thinking procedurally, part 2 of 2.

Shared by Coding PathwayVerified teacher

  • 13 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.

Procedural order and sub-procedures

A digital escape-room workflow must validate a booking, reserve capacity, calculate a price and send a confirmation. Correct components in the wrong order can still create an incorrect solution.

By the end, you will be able to

  • order steps using data and state dependencies;
  • explain why an invalid order fails;
  • identify parameterised sub-procedures and their interfaces;
  • trace and implement an ordered workflow.

Reactivate: a return ends a function call; parameters supply local input data.

Read arrows as dependencies

Dependency order for a booking workflowvalidate requestreturns validcalculate priceneeds valid requestreserve placechanges capacitysend confirmationneeds price + placeArrows mean “must provide information or complete before”.

calculate price and reserve place can begin after validation. Confirmation needs both a price and a successful reservation, so it must wait for both. Order is not personal preference: a later step may require data or state created earlier.

Not every application has one fixed start-to-finish order. In an event-driven program, a click or key press may call different components in an unpredictable order. However, the steps inside each response still have dependencies: payment cannot be confirmed before it succeeds, and a file cannot be processed before it is selected.

Worked correction

Invalid order: send confirmation → reserve place → validate request.

  • Confirmation has no confirmed reservation or price.
  • Reserving before validation can reduce capacity for an invalid request.
  • Correct core order: validate → calculate/reserve as permitted → confirm only after success.

If validation fails, return a rejection before any capacity-changing side effect. This is an early exit with a clear reason.

Guided practice

Cover the diagram and order these four labels: validate, reserve, calculate price, confirm. Draw an arrow only when one step needs another’s result or state; then compare with the model.

Fill in the blanks3 marks
A request must be gap 1 before capacity changes. Confirmation depends on a calculated price and successful gap 2. Data passed into a sub-procedure uses gap 3.
  • validated
  • reservation
  • parameters
  • abstraction
Trace table1 mark

Trace this OCR ERL workflow and record which route reaches confirmation.

Enter a value only when it changes. Follow the listing in order.

Use one row for each pass through the loop. Fill in a box only when that value changes on that row, and leave the rest blank.

AlgorithmExam reference language
  1. remaining = 3
  2. requested = 2
  3. confirmed = False
  4. if requested >= 1 AND requested <= remaining then
  5. remaining = remaining - requested
  6. confirmed = True
  7. endif
  8. print(remaining)
  9. print(confirmed)
Trace table with 5 columns
Rowremainingrequestedconfirmedrequested >= 1 AND requested <= remainingOutput
1
2
3
Written answer3 marks

Explain why the capacity update occurs before confirmed becomes True, and describe what would happen for requested = 4.

Use dependency and decision flow.

Students type their answer here.

Design sub-procedure interfaces

validate_request(requested, remaining) → Boolean
calculate_price(requested, price_each) → real value
reserve_places(requested) → changes stored capacity / returns success
build_confirmation(reference, price) → string

Parameters make dependencies visible. A sub-procedure should not secretly rely on unrelated global state when the needed value can be supplied.

Independent transfer: implement an ordered admission function

Return “rejected” for a count below 1 or above remaining. Otherwise return the new remaining capacity as an integer. Do not change external/global state.

Coding task4 marks
def admit(requested, remaining):
    # Validate before calculating the new remaining capacity.
    pass
Written answer7 marks

Design ordered pseudocode for the full escape-room booking workflow using at least three named sub-procedures. Show parameters or returned values and explain one dependency.

Validation must occur before any state-changing reservation.

Students type their answer here.

Checkpoint

Complete the procedural explanation from memory. There is no answer bank, and correctness is withheld until teacher review.

Fill in the blanks4 marks
When one step needs an earlier result, there is a checkpoint gap 1. A change to stored capacity is a checkpoint gap 2. Rejecting an invalid request before that change is an checkpoint gap 3. A function can pass its result back as a 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.