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

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

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

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

1. Problem analysis – identify repeated or logically independent tasks.
2. Design (stepwise refinement) – replace self‑contained tasks with procedure call placeholders.
3. Specification – write a formal description of each procedure (purpose, parameters, return type, pre‑/post‑conditions).
4. Implementation – code the procedure body.
5. Testing & debugging – unit‑test procedures, then integrate and perform system testing.
6. 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

1. Problem Analysis

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

2. 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
   

3. 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.

4. Implementation – Procedure Body

   Write detailed steps, using the chosen parameter‑passing method and respecting scope rules.

5. Integration into Main Algorithm

   Replace the placeholder with the concrete call, ensuring data dependencies are satisfied.

6. Testing & Debugging

   • Unit‑test the procedure against its specification.
   • Perform integration testing with the main algorithm.

Typical Situations for Using a Procedure

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

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.