A-Level Computer Science / Unit 12: Software Design, Testing and Evolution

12.2.1 Structure Charts and Module Interfaces

🔒 Lesson slides are available to signed-in users. Sign in

12.2.1 Structure Charts and Module Interfaces

Structure charts are used during program design to show how a large problem is divided into smaller modules. They can also show the important values passed between those modules and indicate where selection or repetition affects which modules are used.

The aim is to describe the organisation of the solution before writing detailed pseudocode or program code.

By the end of this section, you should be able to:

  • Explain the purpose of a structure chart.
  • Decompose a problem into suitable modules and levels.
  • Show parameters passed between modules.
  • Interpret selection, repetition and updated-value notation.
  • Construct a structure chart from a problem description.

Purpose of a Structure Chart

Structure chart: a hierarchical diagram showing how a solution is divided into modules and how those modules are related.

A structure chart helps a programmer see the overall design without becoming distracted by the detailed instructions inside each module.

What the chart helps show Why it is useful
Major modules The complete problem can be divided into manageable responsibilities.
Hierarchy Broad tasks can be refined into more detailed sub-tasks.
Module relationships It becomes clear which higher-level module uses each lower-level module.
Parameters The design records which important values cross module boundaries.
Exam tip: Do not describe a structure chart only as “a diagram”. Explain that it shows modular decomposition and the relationships between modules.

Decomposition and Hierarchy

Decomposition: breaking a complex problem into smaller sub-problems that are easier to understand and design.
Module: a named part of a solution responsible for one identifiable task.

The top-level module represents the complete problem. Modules beneath it show the major sub-tasks. A module that is still too broad can be refined again.

Example: Theatre Rehearsal Scheduler

A program must read rehearsal requests, check room availability, store accepted bookings and produce a daily schedule. 

ManageRehearsals
├── ReadRequests
├── CheckAvailability
├── SaveBookings
└── ProduceDailySchedule

If CheckAvailability is still too broad, it could be refined further: 

CheckAvailability
├── CheckRoomFree
├── CheckTimeSlot
└── CheckEquipmentNeeds
Common mistake: More boxes do not automatically mean a better design. Each module should have a clear and useful responsibility.

Designing Good Modules

Characteristic Good design Weak design
Responsibility One clear task Several unrelated jobs combined together
Name CalculateTicketTotal DoStuff
Scope Large enough to be useful, small enough to understand Either too broad or unnecessarily tiny
Hierarchy Lower modules refine the task above them Modules are placed on levels without a clear relationship
Module names are usually clearest when written as concise action phrases such as ReadSensorData, CalculateAverage or DisplayResult.

Parameters and Module Interfaces

Parameter: a named value passed into a module or returned from it.
Interface: the defined connection through which modules exchange the values they need.

A module should receive only the information needed to perform its task and return the results needed elsewhere in the program.

Example

CalculateHireCost
    receives: Hours, HourlyRate
    returns: HireCost
Direction Meaning Example
Downward A higher-level module supplies a value to a lower-level module. Hours and HourlyRate
Upward A lower-level module returns a result. HireCost
Both directions A value is supplied, changed and returned. An available-seat count that is reduced after a booking
Only values that cross a module boundary need to appear as interface parameters. Local working variables normally remain inside the module.

Selection, Repetition and Control Values

Some structure charts also show control information that affects which modules are called or whether a group of modules is repeated.

Flag: a Boolean value used to represent one of two states, such as TRUE/FALSE, Valid/Invalid or MoreData/NoMoreData.

Selection

A returned flag can determine which module is used next. 

IF BookingAccepted = TRUE
    call SaveBooking
ELSE
    call DisplayFailure
ENDIF

Repetition

A group of modules may be repeated while or until a condition is satisfied. 

WHILE MoreRequests = TRUE
    ReadRequest
    ProcessRequest
    CheckForMoreRequests
ENDWHILE
A control symbol should always be interpreted together with its condition. It does not replace the modules that are selected or repeated.

Worked Example: Observatory Visit Booking

An observatory accepts evening-visit requests. The program reads a request, checks whether the requested session has enough places, stores an accepted booking and displays either a confirmation or a rejection message.

Step 1: Choose the modules

ProcessVisitRequest
├── ReadRequest
├── CheckCapacity
├── SaveBooking
├── DisplayConfirmation
└── DisplayRejection

Step 2: Identify the important parameters

Module Receives Returns / updates
ReadRequest — SessionID, GroupSize
CheckCapacity SessionID, GroupSize BookingAccepted
SaveBooking SessionID, GroupSize BookingReference, updated PlacesRemaining
DisplayConfirmation BookingReference —
DisplayRejection SessionID —

Step 3: Add the control decision

BookingAccepted determines whether the program calls SaveBooking and DisplayConfirmation, or instead calls DisplayRejection.

A strong structure chart connects three ideas: module responsibility → parameter flow → control decision.

Structure Chart or Flowchart?

Feature Structure chart Flowchart
Main purpose Shows how a solution is divided into modules Shows the sequence and control flow of an algorithm
Boxes represent Modules, procedures or functions Operations or processing steps
Connections show Hierarchy and communication between modules The route followed during execution
Main question answered “How is the program organised?” “What happens next?”
Do not interpret the left-to-right position of modules in a structure chart as a full description of execution order.

How to Construct a Structure Chart

  1. Identify the overall task. Give the complete problem a clear module name.
  2. Find the major responsibilities. Turn each meaningful sub-task into a module.
  3. Refine broad modules. Add another level only where it improves clarity.
  4. Identify required inputs. Decide what each module must receive.
  5. Identify returned results. Decide what each module produces for its parent.
  6. Add control information. Show relevant selection, repetition or flags.
  7. Check the design. Look for missing tasks, duplicated responsibilities or unnecessary parameters.
Start by underlining the important actions and data in the problem description. These often suggest candidate modules and parameters.

Common Mistakes

  • Drawing a flowchart instead. A structure chart focuses on modular organisation, not every execution step.
  • Using vague module names. Names should describe a clear responsibility.
  • Forgetting parameters. Important values passed between modules should be shown.
  • Reversing parameter direction. Decide whether the child receives the value or returns it.
  • Showing every variable. Only values crossing module boundaries belong on the interface.
  • Adding unnecessary levels. Refinement should make the design clearer, not merely larger.

Practice

Core questions

  1. Explain the purpose of a structure chart.
  2. Define the terms module and parameter.
  3. Explain what a downward parameter arrow represents.
  4. Explain what an upward parameter arrow represents.
  5. Explain how a Boolean flag can control selection.
  6. Give one difference between a structure chart and a flowchart.

Scenario: Music Practice-Room Booking

A program reads a student ID, requested room and start time. It checks whether the room is available. An accepted request is stored and produces a booking code; otherwise, an error message is displayed.

  1. Suggest a suitable top-level module.
  2. Identify four or five suitable lower-level modules.
  3. List the important parameters passed between the modules.
  4. Identify a suitable Boolean control flag.
  5. Explain which modules are selected when the request is accepted or rejected.
  6. Draw the completed structure chart.

Review

Concept Key idea
Structure chart Shows the hierarchical modular design of a solution.
Module A named part of the solution with one identifiable responsibility.
Refinement Dividing a broad task into more detailed sub-tasks.
Parameter A value passed into or returned from a module.
Interface The defined communication between modules.
Selection A condition determines which module or branch is used.
Repetition A module or group of modules is called repeatedly under a condition.
Updated value A value enters a module, is changed and is returned.
Final exam tip: When constructing a chart, think in this order: overall task → modules → refinement → parameters → control.