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

12.2.1 Decomposing Programs with Structure Charts

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

12.2.1 Decomposing Programs with Structure Charts

A large programming problem is easier to design when it is divided into smaller, clearly defined sub-tasks. A structure chart records this decomposition as a hierarchy of connected modules.

This section concentrates on deciding what the modules should be and how they are arranged. Parameter passing, interfaces, selection and repetition notation are developed in the next section.

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

  • Explain why structure charts are used during program design.
  • Use the terms module, sub-task, hierarchy, level and refinement accurately.
  • Decompose a problem into suitable modules.
  • Construct a simple structure chart from a problem description.
  • Identify weaknesses in a proposed modular design.

The Purpose of a Structure Chart

A structure chart is used to plan the organisation of a program before its detailed statements are written. Each box represents a module that is responsible for a particular part of the complete solution.

Structure chart: a hierarchical diagram that shows how a solution is divided into modules and how lower-level modules contribute to higher-level tasks.

A structure chart helps a development team answer questions such as:

  • What are the main responsibilities of the program?
  • Which parts of the problem can be designed separately?
  • Which module coordinates the complete task?
  • Which complicated modules need further refinement?
  • Where might procedures or functions be used?
Purpose How the chart helps
Manage complexity The complete problem is viewed as a collection of smaller responsibilities.
Support discussion Developers can review the organisation before detailed pseudocode or code is written.
Divide work Different modules may be designed or implemented by different developers.
Expose missing work The hierarchy may reveal that an important input, validation or output task has not been included.
Prepare for implementation Modules can later become procedures or functions in the algorithm.
Exam tip: A complete explanation should mention both decomposition and the relationships between modules.

From One Problem to Several Sub-Tasks

Decomposition: breaking a complex problem into smaller problems that are easier to understand and solve.

The designer begins with the overall task and asks what major jobs must be completed. Each major job becomes a candidate module. A module that is still too complicated can be divided again.

Consider a program for registering repair requests at a community repair café. The complete task is:

Register a repair request and produce a reference for the customer.

A first decomposition might identify four main sub-tasks:

  1. capture the customer's request;
  2. check that the required details are present;
  3. save the accepted request;
  4. display the request reference.

These become four Level 1 modules under one coordinating module: 

RegisterRepairRequest
├── CaptureRequest
├── CheckRequestDetails
├── SaveRepairRequest
└── DisplayReference
Common misconception: Decomposition is not achieved by splitting a task into arbitrary pieces. Each module should represent a meaningful responsibility.

Modules, Levels and Hierarchy

Module: a named part of a solution that performs one identifiable sub-task. In an implemented program, a module may become a procedure or function.

A structure chart is hierarchical. A higher-level module coordinates broader work, while modules below it provide more detail.

Chart position Meaning Repair-café example
Top-level module Represents the complete task being designed. RegisterRepairRequest
Level 1 Contains the main responsibilities needed by the complete task. CaptureRequest, CheckRequestDetails, SaveRepairRequest and DisplayReference
Lower level Refines one higher-level module into more specific tasks. Checks for customer contact details, item category and problem description

Parent and child modules

A module directly above another module may be described as its parent. The lower module is its child. The parent uses the child module as part of completing its own responsibility.

In the repair-request design, CheckRequestDetails can be refined as: 

CheckRequestDetails
├── CheckContactDetails
├── CheckItemCategory
└── CheckProblemDescription
Refinement: replacing one broad task with a set of more detailed sub-tasks.
Common mistake: Lower-level modules are not necessarily less important. They simply describe a more specific part of the solution.

Designing Useful Modules

A useful module has a clear purpose. Its name should describe an action or responsibility rather than using vague labels such as DoWork, ProcessStuff or Module1.

Design characteristic Helpful question Example
Clear responsibility Can its purpose be explained in one short sentence? SaveRepairRequest stores an accepted request.
Meaningful name Does the name describe the action performed? CalculateDailyTotal is clearer than Calculation.
Suitable size Is it too broad to understand or too small to be useful? ManageEverything probably needs further decomposition.
Limited overlap Are two modules trying to perform the same responsibility? Validation should not be repeated independently in several modules.
Appropriate level Are modules on the same level similar in scope? A tiny field check should not normally sit beside an entire reporting system.
Exam tip: Module names are usually written as concise action phrases, such as ReadSurveyFile, CalculateTotals or DisplaySummary.

Structure Chart or Flowchart?

Both diagrams support algorithm design, but they answer different questions.

Feature Structure chart Program flowchart
Main purpose Shows the decomposition and organisation of modules. Shows the operations and control flow of an algorithm.
Primary question How is the solution divided? What operation happens next?
Rectangles or boxes Represent modules or sub-tasks. Usually represent processing operations.
Connections Show hierarchical relationships between modules. Show the route followed during execution.
Level of detail Emphasises program organisation. Emphasises step-by-step algorithm logic.
Common misconception: The left-to-right position of modules in a basic structure chart should not be treated as a complete description of execution order. The chart's main purpose is modular organisation.

How to Construct a Structure Chart

  1. Identify the overall task. Write a short name for the complete problem.
  2. List the main responsibilities. Look for major input, processing, storage and output tasks where appropriate.
  3. Create the top level. Place the complete task in the highest box.
  4. Add the main sub-modules. Place the principal responsibilities beneath the top-level module.
  5. Inspect each module. Refine any module that is still too broad or contains several distinct jobs.
  6. Review the hierarchy. Check that all requirements are represented and that responsibilities do not overlap unnecessarily.
Problem phrase Possible module Reason
“Read the weekly observation file” ReadObservationFile A distinct input responsibility
“Count sightings for each species” CountSpeciesSightings A distinct processing responsibility
“Find the species with the highest count” FindMostObservedSpecies A separate calculation
“Display the survey summary” DisplaySurveySummary A distinct output responsibility
Exam tip: Begin by annotating the problem description. Underline the important actions and consider whether each action represents a suitable module.

Worked Example: Wildlife Survey Summary

A conservation group collects wildlife observations from several survey sites. A program must read the observation records, calculate summary information and display a weekly report.

Step 1: Identify the complete task

ProduceWeeklySurveySummary

Step 2: Identify the main responsibilities

Requirement Proposed Level 1 module
Load the observation records ReadObservations
Calculate the required statistics CalculateSurveyStatistics
Create the weekly output DisplaySurveySummary

Step 3: Refine the broad calculation module

CalculateSurveyStatistics still contains several distinct jobs. It can be refined into:

  • CountTotalObservations
  • CountSurveySites
  • FindMostObservedSpecies

Resulting hierarchy

ProduceWeeklySurveySummary
├── ReadObservations
├── CalculateSurveyStatistics
│   ├── CountTotalObservations
│   ├── CountSurveySites
│   └── FindMostObservedSpecies
└── DisplaySurveySummary

The chart does not yet show the parameters passed between these modules. That additional interface information is introduced in Section 12.2.2.

Exam tip: Refinement should add useful detail. Do not continue dividing modules merely to create more boxes.

Evaluating a Proposed Structure Chart

After drawing a chart, check that the decomposition is complete, clear and balanced.

Check Question to ask Possible warning sign
Coverage Is every important requirement represented? The chart has no module that produces the required output.
Responsibility Does each module perform a clear job? A box is labelled ProcessEverything.
Overlap Are responsibilities duplicated? Several modules independently perform the same validation.
Refinement Does a complex module need another level? One module contains input, calculation, storage and output.
Balance Are modules on the same level reasonably similar in scope? One box represents a complete subsystem while another checks one character.
Naming Can the responsibility be inferred from the module name? The chart uses labels such as PartA and Work2.
Common mistake: A chart is not improved simply by adding more levels. Every additional module should make the design clearer or easier to implement.

Interactive: Structure Chart Decomposition Workshop

Move from the complete repair-request task to its main modules, refine one complex module and then inspect an exam-style incomplete chart.

Scenario: community repair-café request system

Whole problem

Begin with the complete responsibility

The top-level module represents everything required to register one repair request.

Focus: identify the main jobs before adding detailed modules.

Module 1 of 1

RegisterRepairRequest

This is the top-level module. It represents the complete problem before decomposition.

Common Mistakes and Misconceptions

  • Drawing a flowchart. A structure chart shows modular hierarchy rather than every execution step.
  • Using one large module. A box such as CompleteProgram without meaningful children does not demonstrate decomposition.
  • Creating modules from nouns alone. Module names should normally describe responsibilities or actions.
  • Placing every box on one level. A complex sub-task may require further refinement.
  • Adding code inside boxes. A box should contain a concise module name, not several pseudocode statements.
  • Assuming connections show exact execution order. Their main purpose is to show hierarchical relationships.
  • Adding unnecessary modules. Extremely small fragments can make the design harder rather than easier to read.

Practice

Core questions

  1. Define the term structure chart.
  2. Explain two purposes of using a structure chart.
  3. Explain what a box represents.
  4. Explain the relationship between a higher-level module and its children.
  5. Distinguish a structure chart from a program flowchart.
  6. Explain why DoEverything is usually a weak module name.

Scenario A: Library Equipment Loan

A program records a request to borrow equipment, checks the item record, stores the loan and displays the return date.

  1. Suggest a suitable top-level module.
  2. Suggest four Level 1 modules.
  3. Choose one Level 1 module that could be refined further.
  4. Suggest two or three appropriate child modules.
  5. Draw the resulting structure chart.

Scenario B: Minibus Maintenance Report

A program reads maintenance records, counts faults by category, identifies vehicles that need inspection and displays a summary.

  1. Identify the complete task.
  2. Identify three or four major responsibilities.
  3. Decide which responsibility needs further decomposition.
  4. Draw a two-level or three-level structure chart.
  5. Explain why your modules form a sensible hierarchy.
Challenge: Review your chart using the six checks from the evaluation section: coverage, responsibility, overlap, refinement, balance and naming.

Review

Prompt A strong response should include
Purpose of a structure chart To show the modular decomposition and hierarchical organisation of a solution.
Module A named part of the solution with an identifiable responsibility.
Top-level module The module representing the complete problem or task.
Lower-level module A more detailed sub-task used to refine a higher-level module.
Refinement Dividing a broad task into more specific sub-tasks.
Structure chart versus flowchart Program organisation versus step-by-step control flow.
Good module design A clear responsibility, meaningful name and suitable level of detail.
Final exam tip: When constructing a chart, begin with the complete task, identify the principal responsibilities and refine only those modules that are still too broad.