Cambridge Syllabus Notes

11.3 Structured Programming – Procedures (AS) & 20.1 Programming Paradigms (A‑Level)

Learning Objective

Explain where in the construction of an algorithm it would be appropriate to use a procedure, and relate this to the stages of the Program Development Life‑Cycle.

Syllabus Alignment Checklist

Topic (9618)	Covered?
11.1 Programming basics (declaration, assignment, I/O, built‑in functions)	✅
11.2 Structured constructs (IF, CASE, loops)	✅
11.3 Structured programming – procedures	✅
12.1 Program Development Life‑Cycle (design → implementation → testing)	✅
12.3 Program testing & maintenance	✅
A‑Level 20.1 Programming paradigms (functions, recursion, exception handling)	✅ (introductory)
A‑Level 19.2 Recursion (basic understanding)	✅ (preview)

Why Use Procedures?

**Eliminate duplicated code** – write a block once and call it many times.
**Improve readability** – a well‑named procedure tells the reader what the block does without exposing the details.
**Facilitate independent testing** – a procedure can be unit‑tested in isolation.
**Encourage reuse** – the same procedure can be called from different parts of the same algorithm or from other algorithms.

Key Concepts

Procedures vs. Functions

Procedure: performs an action; may modify variables but does not return a value that can be used in an expression.
Function (returning procedure): performs a calculation and returns a single value (or a record) that can be used directly in an expression.

Example (pseudocode)

PROCEDURE displayMessage(msg)          // procedure – no return value
    OUTPUT msg
END PROCEDURE

FUNCTION square(x) RETURNS INTEGER      // function – returns a value
    RETURN x * x
END FUNCTION

Parameter‑Passing Mechanisms

Mechanism	How it works	Typical use	Pros / Cons
Pass‑by‑value	A copy of the argument is passed.	Simple data types (INTEGER, REAL, CHAR, BOOLEAN).	Safe – original variable cannot be altered; uses extra memory for the copy.
Pass‑by‑reference	A reference (address) to the original variable is passed.	Large structures, arrays, or when the procedure must modify the caller’s data.	Efficient – no copying; but the procedure can change the caller’s variable.

Nesting, Scope and Visibility

Local scope: variables declared inside a procedure are visible only within that procedure.
Global scope: variables declared outside any procedure can be accessed by any procedure (use sparingly).
Nested procedures: a procedure defined inside another can see the outer procedure’s locals, but not the reverse.

Recursion (preview – A‑Level)

Recursion is a technique where a procedure calls itself. It is useful for problems that can be defined in terms of a smaller instance of the same problem (e.g., factorial, Fibonacci, tree traversal). A recursive procedure must have:

A base case that stops the recursion.
A recursive case that reduces the problem size and calls itself.

Simple example

FUNCTION factorial(n) RETURNS INTEGER
    IF n = 0 THEN
        RETURN 1
    ELSE
        RETURN n * factorial(n‑1)
    END IF
END FUNCTION

Exception Handling (introductory – A‑Level)

Some exam questions may ask you to anticipate an error (e.g., division by zero). In pseudocode you can indicate the handling with a TRY … CATCH style block, or simply with an IF‑check before the risky operation.

PROCEDURE divide(a, b) RETURNS REAL
    IF b = 0 THEN
        OUTPUT "Error: divisor cannot be zero."
        RETURN 0          // or a sentinel value
    END IF
    RETURN a / b
END PROCEDURE

Refresher: Core Structured Constructs (11.2)

Selection
- IF … THEN … ELSE … END IF
- CASE … OF … END CASE
Repetition
- Count‑controlled: FOR i FROM 1 TO n DO … END FOR
- Condition‑controlled (pre‑test): WHILE condition DO … END WHILE
- Condition‑controlled (post‑test): REPEAT … UNTIL condition

Program Development Life‑Cycle (12.1) – Where Procedures Appear

Problem analysis – identify repeated or logically independent tasks.
Design (stepwise refinement) – replace self‑contained tasks with procedure call placeholders.
Specification – write a formal description of each procedure (purpose, parameters, return type, pre‑/post‑conditions).
Implementation – code the procedure body.
Testing & debugging – unit‑test procedures, then integrate and perform system testing.
Maintenance – modify, adapt or perfect procedures as requirements change.

Testing & Maintenance (12.3)

Testing strategies
- Dry‑run (manual trace of values).
- White‑box (check each branch of the procedure).
- Black‑box (test based on input‑output specifications).
Maintenance types
- Corrective – fixing bugs discovered after deployment.
- Adaptive – modifying the procedure for a new environment or requirement.
- Perfective – improving efficiency or readability.

Stages of Algorithm Construction Where Procedures Are Introduced

Problem Analysis
- Spot repeated calculations, I/O blocks, or complex decision logic.
- Ask: “Can this task be isolated and given a name?”

Design – Stepwise Refinement (Pseudocode Draft)

Write the high‑level algorithm.
Insert a procedure call placeholder wherever a self‑contained task appears.

READ numberOfStudents
FOR i FROM 1 TO numberOfStudents DO
    READ name, mark1, mark2
    CALL processStudent(name, mark1, mark2)   // placeholder
END FOR

Procedure Specification

Document before coding.

Item	Description
Purpose	What the procedure does.
Parameters	Name, type, and passing mechanism (value/reference).
Return value	Type of value returned, or “none”.
Pre‑conditions	Conditions that must be true before the call.
Post‑conditions	What is guaranteed after the call.

Implementation – Procedure Body
Write detailed steps, using the chosen parameter‑passing method and respecting scope rules.
Integration into Main Algorithm
Replace the placeholder with the concrete call, ensuring data dependencies are satisfied.
Testing & Debugging
- Unit‑test the procedure against its specification.
- Perform integration testing with the main algorithm.

Typical Situations for Using a Procedure

Situation	Why a Procedure Helps	Example
Repeated calculations	Write the formula once; call it wherever needed.	Area of different shapes (square, circle, triangle).
Complex decision logic	Encapsulate nested IF/CASE statements, keeping the main flow clear.	Validating a student’s mark against several criteria.
Data manipulation on collections	Single point of change if the algorithm (e.g., sorting) needs to be altered.	Sorting a list of names, searching a record set.
Input/Output handling	Separate I/O from core processing, improving portability.	Reading a file, formatting a report.
Error handling / validation	Centralise checks, making the algorithm more robust.	Ensuring a score is between 0 and 100 before processing.

Illustrative Example – Procedure Returning a Record

This example shows a procedure that receives two marks, calculates the average, determines the grade, and returns both values as a record.

MAIN
    READ numberOfStudents
    FOR i FROM 1 TO numberOfStudents DO
        READ studentName, mark1, mark2
        result ← CALL analyseStudent(mark1, mark2)   // result is a RECORD
        OUTPUT studentName, result.average, result.grade
    END FOR
END MAIN

/* Procedure specification
   Purpose   : Calculate average of two marks and assign a grade.
   Parameters: m1 (INTEGER, pass‑by‑value)
               m2 (INTEGER, pass‑by‑value)
   Returns   : RECORD { average (REAL), grade (CHAR) }
   Preconditions: 0 ≤ m1 ≤ 100, 0 ≤ m2 ≤ 100
   Postconditions: average = (m1+m2)/2,
                   grade follows the table below
*/

PROCEDURE analyseStudent(m1, m2) RETURNS RECORD
    avg ← (m1 + m2) / 2.0
    IF avg ≥ 80 THEN g ← 'A'
    ELSE IF avg ≥ 70 THEN g ← 'B'
    ELSE IF avg ≥ 60 THEN g ← 'C'
    ELSE IF avg ≥ 50 THEN g ← 'D'
    ELSE g ← 'F'
    END IF
    RETURN { average: avg, grade: g }
END PROCEDURE

Returned record fields

Field	Content
average	Real number representing the mean of the two marks.
grade	Character ‘A’‑‘F’ based on the average.

Procedure Documentation Template (Paper 4)

/*------------------------------------------------------------
   Procedure name : ______________________
   Purpose        : ______________________________________
   Parameters     : name1 – type – passing mechanism (value/reference)
                    name2 – type – passing mechanism
   Returns        : type (or “none” for a procedure)
   Preconditions  : ______________________________________
   Postconditions : ______________________________________
------------------------------------------------------------*/

Using Standard Library Procedures (Practical Note)

Cambridge exam environments provide built‑in procedures such as READ, WRITE, OPENFILE, SORT, etc.
In the IDE these appear in the “Procedures” palette and can be inserted automatically – a useful shortcut for Paper 4 programming questions.
Even when using a library procedure, document its purpose and the parameters you pass to it.

Key Take‑aways

Introduce a procedure when a task is logically independent, repeated, or sufficiently complex to merit its own name.
Decide early whether the block should be a procedure (no return value) or a function (returns a value or record).
Specify the procedure (purpose, parameters, return type, pre‑/post‑conditions) before writing the body.
Choose the appropriate parameter‑passing method – value for safety, reference for efficiency or when the caller’s data must be altered.
Test procedures in isolation (unit testing) before integrating them into the main algorithm.
Remember the broader PDLC: design → implement → test → maintain. Procedures support each of these stages.
For A‑Level extensions, be aware that procedures can be recursive and may need simple exception handling.
Clear naming, proper documentation, and awareness of scope make pseudocode easier to read, maintain, and grade.

Explain where in the construction of an algorithm it would be appropriate to use a procedure