Program Design

Before writing a single line of code, a good programmer designs the solution. The key idea is decomposition: split a large, complex problem into smaller sub-tasks, each of which is easier to understand, solve and test on its own.

Each sub-task becomes a module — a self-contained block of code that does one clear job. In 9618 a module is implemented as either:

Subroutine type	Returns a value?	How it is called
Procedure	No (performs an action)	CALL DoSomething(...)
Function	Yes (returns one value)	inside an expression, e.g. x ← Calculate(...)

Why decompose?

• Each module can be written and tested separately.
• Modules can be reused in other parts of the program (or other programs).
• The program is easier to maintain — a change to one module rarely breaks the others.
• A team can work on different modules at the same time.

The two design tools in this topic both come from this idea: a structure chart records the modules of the solution, and a state-transition diagram records the behaviour of the system.

A structure chart is a diagram that shows the hierarchical decomposition of a problem. The single top module (the whole task) sits at the top; the sub-modules it calls hang beneath it, connected by lines. Sub-modules are read left to right in the order they are called.

Below, ProcessMarks calls three sub-tasks in order — input the marks, calculate the average, output the average:

The purpose of a structure chart is to:

• show how a problem is broken into modules;
• show the calling relationship (which module calls which);
• show the parameters/data passed between modules (next section).

It lets you plan and check a complete solution on paper before coding — and once drawn, it translates almost directly into pseudocode.

A structure chart does more than name modules — it shows the parameters passed between them. On each calling line you draw small labelled arrows:

• Arrow pointing DOWN (caller → sub-module) = data passed IN to the module.
• Arrow pointing UP (sub-module → caller) = a value returned to the caller.

In the chart below, ProducePayslip passes hours and rate down into CalculatePay, which returns pay up:

Why pass parameters instead of using global variables? Parameters keep each module self-contained — it depends only on the values it is explicitly given, so it is easier to test, reuse and maintain, and one module cannot accidentally corrupt data another relies on.

When you convert the chart to pseudocode, the down arrows become the parameter list and the up arrow becomes the RETURNS value.

Once a structure chart is drawn, turning it into pseudocode is mechanical. Use these rules:

1. A sub-module with an up (returned) arrow is a FUNCTION (RETURNS a value, called inside an assignment).
2. A sub-module with no returned value is a PROCEDURE (called with CALL).
3. The down arrows become the parameter list.
4. The up arrow becomes the RETURNS value.
5. The left-to-right order of the sub-modules becomes the order of calls in the main module; store each returned value so it can be passed on.

For the marks example in §2 (InputMarks returns marks; CalculateAverage takes marks, returns average; OutputAverage takes average):

FUNCTION InputMarks() RETURNS ARRAY
    // read marks into an array and return it
ENDFUNCTION

FUNCTION CalculateAverage(marks : ARRAY) RETURNS REAL
    // return the mean of the values in marks
ENDFUNCTION

PROCEDURE OutputAverage(average : REAL)
    OUTPUT "Average mark = ", average
ENDPROCEDURE

// Main program ProcessMarks
marks ← InputMarks()
average ← CalculateAverage(marks)
CALL OutputAverage(average)

Notice how every arrow on the chart appears in the code: marks produced then consumed, average produced then consumed, and the calls in left-to-right order.

A state-transition diagram is a different design tool. Instead of showing the modules of a solution, it documents how a system behaves over time by showing:

• States — the distinct conditions the system can be in (drawn as boxes/circles).
• Transitions — arrows from one state to another, each labelled with the event or condition that triggers the change.

Below is a state-transition diagram for a subscription account with states Inactive, Active and Suspended:

The purpose of a state-transition diagram is to document an algorithm/system clearly, so a designer can:

• see every state the system can reach and every event that changes it;
• check the design is complete (no situation left unhandled) and has no impossible transitions;
• communicate the behaviour to others before coding.

It suits event-driven systems — appliances, traffic lights, vending machines, embedded controllers — where the system reacts to events by switching state.

These two diagrams are both 'design' tools, but they answer different questions — a very common source of confusion in exams.

	Structure chart	State-transition diagram
Shows	the modules of the solution	the behaviour of the system
Boxes/circles are	modules (procedures/functions)	states
Lines/arrows are	calling relationships + parameters	transitions triggered by events
Answers	"How is the program broken up?"	"What can the system be doing, and what changes it?"
Reads	top-down hierarchy, left to right	follow the events from state to state

A handy way to remember it: a structure chart is about the code's organisation (modules and the data passed between them), while a state-transition diagram is about the system's life story (which state it's in and what events move it on).

Both are produced before coding, as part of program design, and both make the eventual implementation faster and more reliable.