Structured programming techniques

Structured programming is an approach to writing software that makes programs easier to understand, test and maintain. AQA GCSE expects you to understand four core techniques: top-down design, modularity, abstraction and decomposition.

Top-down design

Top-down design starts with the overall problem and breaks it into smaller, more manageable sub-problems — then breaks those down further until each piece is small enough to code directly.

Example — a quiz game broken down:

Quiz Game
├── Initialise game (set score to 0, load questions)
├── Play round
│   ├── Display question
│   ├── Get user answer
│   └── Check answer and update score
└── Display final score and grade

Each box eventually becomes a subroutine (procedure or function).

Decomposition

Decomposition is the process of splitting a complex problem into smaller, simpler sub-problems that can each be solved independently. It is essentially what top-down design does at each level.

A problem is fully decomposed when each part:

• Has a single, clear purpose
• Can be implemented and tested in isolation
• Fits in one screen of code (roughly)

Modularity

Modularity means organising code into separate, self-contained modules (subroutines, classes, files). Each module:

• Does one thing well (single responsibility)
• Has a clear interface (parameters in, return values out)
• Can be developed and tested independently

AQA pseudocode — modular quiz:

SUBROUTINE displayQuestion(questionText)
  OUTPUT questionText
ENDSUBROUTINE

SUBROUTINE getAnswer()
  USERINPUT answer
  RETURN answer
ENDSUBROUTINE

SUBROUTINE checkAnswer(userAnswer, correctAnswer)
  IF userAnswer = correctAnswer THEN
    RETURN TRUE
  ELSE
    RETURN FALSE
  ENDIF
ENDSUBROUTINE

Benefits of modularity:

• Reuse — a sorting subroutine can be called from many parts of the program
• Team working — different programmers can build different modules simultaneously
• Easier testing — test each module in isolation before combining
• Easier maintenance — fixing a bug in one module doesn't require changing others

Abstraction

Abstraction means hiding unnecessary detail so that the programmer (or user) can focus on what matters at a given level.

Two flavours at GCSE:

Type	What's hidden	Example
Procedural abstraction	Implementation of a subroutine	sortList(myList) — caller doesn't need to know if it uses bubble or merge sort
Data abstraction	Internal representation of data	Using score as a variable; the bit pattern in RAM is irrelevant

Abstraction is what makes top-down design work: at the top level you write playRound() without worrying about the details inside that subroutine.

How the techniques fit together

1. Decompose the problem into smaller chunks.
2. Design top-down — major modules first, details later.
3. Implement each chunk as a separate module (subroutine).
4. Use abstraction so each module's caller ignores internal details.

Real benefit: A 5,000-line program broken into 50 subroutines of ~100 lines each is far easier to debug, extend and hand to another developer than 5,000 lines of sequential code.

Common exam question angle

Examiners often ask you to:

• State one benefit of using subroutines (modularity / reuse / easier testing)
• Identify where abstraction is being used in a given program
• Draw or extend a structure chart (top-down decomposition diagram)