Use a structure chart to decompose a problem into sub-tasks and express the parameters passed between the various modules/procedures/functions which are part of the algorithm design

12.2 Programme Design – Structure Charts

Learning Objective

Use a structure chart to decompose a problem into sub‑tasks and to specify the parameters passed between the modules, procedures or functions that form part of the algorithm design.

1. What is a Structure Chart?

• Definition: A hierarchical diagram that shows how a program is broken into modules (or routines) and how data (parameters) flow between them.
• Purpose:

  • Logical decomposition of a problem (top‑down design).
  • Explicit definition of module interfaces.
  • Facilitates modular programming and independent testing.

• Key symbols

  • Rectangle – a module (procedure, function or sub‑program).
  • Arrow – a parameter (data) passed from a parent module to a child module.
  • Solid line – input or output parameter.
  • Dotted line – in‑out (read‑and‑write) parameter.

2. Relationship to Other Design Artefacts (Cambridge 9618)

3. Role in the Development Life‑Cycle

• Produced after problem analysis and before coding.
• Drives:

  • Module‑level design (AO2 – analyse the problem).
  • Implementation planning – each box becomes a routine.
  • Testing strategy – each module can be unit‑tested (AO3 – design & evaluate).

• Provides a reference for documentation and for the examiner when marking.

4. Steps to Create a Structure Chart

1. Analyse the problem statement. Identify the main goal and any sub‑goals.
2. Define the top‑level module. Usually called main or a descriptive name such as ProcessLoan.
3. Decompose the top‑level module. Keep breaking it into logical sub‑modules until each is small enough to be coded comfortably (≈10–20 lines of code).
4. Identify data items for each module.

   • What the module receives (input parameters).
   • What the module returns (output parameters).
   • What the module both reads and modifies (in‑out parameters).

5. Decide on scope and naming. Avoid global variables; pass everything a module needs as a parameter. Use lower‑case, self‑explanatory names (e.g., studentMarks, totalScore).
6. Draw the chart. Use rectangles for modules and arrows for parameter flow. Read from top (high‑level) to bottom (low‑level).
7. Validate the design. Check that:

   • Every required data item is passed exactly once.
   • No unnecessary dependencies exist.
   • The hierarchy matches the intended algorithm.

5. Parameter Types

6. Parameter Scope & Naming Conventions

• Local scope – a parameter exists only inside the module that receives it.
• Avoid globals – passing parameters makes dependencies explicit and simplifies testing.
• Naming guidelines

  • lower‑case, meaningful words (e.g., studentID, weightedScore).
  • Arrays: plural nouns (marksArray).
  • Direction hint (optional): inMarks, outGrade.

7. Illustrative Example – Grade Calculation

7.1 Problem Statement

Calculate the final grade for each student in a class.

Each student has marks for three assessments with different weights.

The final grade is the weighted sum, rounded to the nearest integer, and then classified as A, B, C, D or F.

7.2 Decomposition into Modules

7.3 Parameter Flow (single student)

1. ReadData → ProcessStudent: marks[3]
2. ProcessStudent → ComputeWeightedSum: marks[3], weights[3]
3. ComputeWeightedSum → RoundResult: rawScore
4. RoundResult → ClassifyGrade: roundedScore
5. ClassifyGrade → OutputResult: grade
6. RoundResult → UpdateRunningTotal: roundedScore (in‑out modifies totalScore)

7.4 Sketch of the Structure Chart

Note: In an exam you would draw the chart on paper. The text description below shows the hierarchy and arrows.

Main
│
├─ ReadData
│
└─ ProcessStudent
├─ ComputeWeightedSum
├─ RoundResult
├─ ClassifyGrade
├─ UpdateRunningTotal   (in‑out)
└─ OutputResult

8. Key Points to Remember

• Each module should have a single, well‑defined purpose.
• Pass only the data that is needed – keep the parameter list as short as possible.
• Use meaningful, consistent names for modules and parameters.
• Prefer parameter passing to global variables; this clarifies scope and aids testing.
• Identify and label in‑out parameters – they are frequently examined in the exam.
• When drawing, keep the hierarchy clear: parent modules above child modules, arrows pointing downwards.
• Validate the chart by checking that every required data item appears exactly once in the flow.

9. Alignment with Cambridge Assessment Objectives

• AO2 – Analyse: Decompose the problem, identify sub‑tasks and required data items.
• AO3 – Design & evaluate: Produce a structure chart, define module interfaces, justify design choices (e.g., avoiding globals, using in‑out where appropriate), and evaluate the design against criteria such as readability and testability.

10. Practice Exercise – Library System

Task: Design a structure chart for a library system that allows a user to search for a book by title, check its availability, and, if available, issue the book to the user. The system must also update the inventory and record the transaction.

Guidelines

1. Identify the top‑level module (e.g., ProcessLoan).
2. Break it into logical sub‑modules such as:

   • SearchBook
   • CheckAvailability
   • IssueBook
   • UpdateInventory
   • RecordTransaction

3. For each module, list:

   • Purpose
   • Input parameters
   • Output or in‑out parameters

4. Draw the hierarchy (top‑down) and indicate the direction of each arrow.
5. Check your design against the “Key Points” checklist and the AO2/AO3 alignment.

Suggested Module Table

Sample Parameter Flow (simplified)

ProcessLoan
│
├─ SearchBook ──► bookID
│
├─ CheckAvailability ──► available
│
├─ IssueBook (bookID, userID)
│
├─ UpdateInventory (bookID) ──► stockCount (in‑out)
│
└─ RecordTransaction (bookID, userID, date)

11. Quick Checklist for Exam Candidates

• □ Have I identified a clear top‑level module?
• □ Have I decomposed it until each sub‑module is simple enough to code?
• □ Does every arrow represent a parameter, and is the direction correct?
• □ Have I labelled each parameter as input, output or in‑out?
• □ Are all names meaningful and consistent with the naming conventions?
• □ Have I avoided global variables?
• □ Does the chart match the problem description and satisfy AO2/AO3?