Key vocabulary

Why design comes before code

Once analysis has produced a set of functional requirements, the next job is to plan how the system will meet them — without writing any code yet. This is the design phase. Two techniques are used at Higher: structure diagrams (this lesson) and pseudocode (SDD4). Both express the same underlying design; a structure diagram shows decomposition as a hierarchy of connected modules, while pseudocode expresses the logic as numbered text.

Before drawing anything, a designer identifies the data types and structures the problem will need. Choose a concrete type that matches each value: an integer for a whole-number count, a real for a measured or calculated decimal, a string for text, and a Boolean for a true/false state. Then decide how related values should be organised. Parallel arrays can hold several matching lists, a record groups the different fields for one item, and an array of records groups many items that each have the same mixed fields. At this stage the task is only to identify and justify the choice; implementation belongs in SDD5 and SDD6.

Top level design

A structure diagram starts with one top-level module representing the whole program. Its major subordinate modules are placed below it and connected by branching lines. This vertical relationship means "the program is decomposed into, or calls, these modules"; it is not a top-to-bottom process pipeline. The subordinate modules can still be numbered to show their intended order. A well-formed top level design usually has three to five major modules — fewer may be too vague, while more suggests that some detail belongs in a refinement.

Data flow

Every module call in a structure diagram must show its data flow: what data goes IN to the subordinate module, and what data comes OUT of it. These annotations sit on the connecting lines, so the reader can trace what the parent supplies and what each child returns. The OUT of one module is often supplied as the IN of another call. An examiner checks whether that data genuinely exists and is passed to every module that needs it, not just whether the module names sound sensible.

Reading module shapes and markers

The diagrams below use recognised visual distinctions as well as clear text markers. A plain rectangle is a process module. A rounded module marks repetition, a pointed module marks selection, and a double-sided rectangle marks a subprogram call. The marker matters because it reveals the control structure without turning the diagram into code. Begin at the top-level box, follow the branches down to its children, read each IN/OUT annotation on the connector, and then follow any further branch to see which child module has been refined.

Refinements

Some subordinate modules are too complex to implement directly and need to be broken down further. This is a refinement. The module being refined becomes the parent box of another small hierarchy, with its own subordinate boxes connected below. A refinement of module 2 is numbered 2.1, 2.2, 2.3 and so on, so ownership stays clear. Not every module needs a refinement; only those that still hide significant logic such as a loop, selection, or subprogram call.

Worked examples

Task Set A — Core questions

Task Set B — Extension