Designing, creating and refining algorithms: Structure diagrams

The idea

A structure diagram is a top-down design tool that breaks a whole problem into successively smaller sub-problems until each part is simple enough to code as a module. The top box names the overall system; each lower level shows a decomposition of the box above it. For example, a 'Quiz Game' box might split into 'Load Questions', 'Ask Question', 'Check Answer' and 'Update Score', and 'Check Answer' might split again into 'Compare Input' and 'Award Mark'. Reading downwards shows decomposition; reading upwards shows how modules combine. Structure diagrams show hierarchy and sequence of refinement, not the order in which code runs, so they differ from flowcharts, which show control flow. They help plan modular programs, support testing of separate modules and make large problems easier to divide among a team.

What earns the marks

• A structure diagram decomposes a problem from a single top-level box into progressively smaller sub-problems at lower levels.
• Each box represents a module or task, and boxes on the same level are sibling sub-tasks of the parent box directly above them.
• The diagram shows hierarchy and decomposition, not the order of execution, so it is not a flowchart and has no decision diamonds or flow arrows.
• A well-formed diagram stops decomposing when each leaf module is simple enough to be written as a single subroutine or small block of code.
• Structure diagrams support modular design, so modules can be written, tested and maintained independently and work can be shared across a team.
• Interpreting a diagram means tracing from the top-level task down to leaf modules and explaining what each module must do and how it contributes to the whole.

Common mistakes and how to put them right

• Drawing a flowchart with arrows and decision symbols instead of a hierarchy.

  Put it right: Is to use only boxes connected by plain lines showing parent-child decomposition.

• Putting steps in time order across a level.

  Put it right: Is to treat boxes on one level as independent sub-tasks, because a structure diagram does not show sequence.

• Decomposing forever or stopping too early.

  Put it right: Is to stop when each leaf module is small enough to implement as one subroutine, and to check every parent is fully broken down.

Exam tips

• Read the question wording: 'decompose' or 'break down' signals a structure diagram, while 'sequence', 'selection' or 'iteration' signals a flowchart or pseudocode task, so check whether the question asks for a diagram or code.
• When completing a partly drawn diagram, match the level of detail of the boxes already given and keep sibling boxes at a similar size.
• When interpreting, name the top-level task, then state what each lower-level module does and how it combines to solve the whole problem.