12.2 Program Design

2026 Syllabus Objectives

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

  • use a structure chart to break a problem into smaller sub-tasks
  • show the parameters passed between modules, procedures, and functions in a structure chart
  • describe the purpose of a structure chart
  • construct a structure chart for a given problem
  • derive equivalent pseudocode from a structure chart
  • show understanding of the purpose of state-transition diagrams to document an algorithm

Structure charts

A structure chart is a diagram used during program design. Its job is to show how a large problem can be broken down into smaller parts. Each smaller part does one clear task.

This is helpful because big problems are often too hard to solve all at once. A structure chart helps the programmer work in a clear, organised way. Instead of trying to write one huge program, the programmer can design a set of smaller modules.

A module is a separate part of a program that carries out one job. In exam questions, modules may also be described as procedures or functions, depending on what they do.

The main idea behind a structure chart is decomposition. This means splitting a problem into smaller sub-problems. The top of the chart shows the main task. Under that, the chart shows the smaller tasks needed to complete it. If needed, those smaller tasks can be broken down even more.

So, the purpose of a structure chart is to:

  • break a problem into manageable parts
  • show the relationship between the main task and the smaller tasks
  • show which module calls another module
  • show what data is passed between modules
  • help turn a design into pseudocode

A structure chart focuses on the overall design of the program. It helps you see the structure before writing the full algorithm.

Features of a structure chart

A structure chart has some common features.

Module boxes

Each module is usually shown as a box with the name of the task inside it. The name should make the job of the module clear.

For example, in a temperature conversion program, modules might be named:

  • InputTemperature
  • ChooseConversion
  • ConvertToCelsius
  • ConvertToFahrenheit
  • OutputResult

Each module should do one clear job. This makes the program easier to understand, test, and change.

Top-down design

A structure chart uses top-down design. This means the main task is shown first, and then it is broken into smaller tasks underneath it.

For example:

  • the main task might be Temperature Conversion Program
  • below that might be Input Temperature, Choose Conversion, Convert Temperature, and Output Result

This lets you move from the general idea to the details step by step.

Vertical lines

Lines between the boxes show control flow. This means they show which module uses or calls another module.

If one box is below another, it usually means the higher-level module uses the lower-level module as part of the whole solution.

Parameter arrows

A very important part of this syllabus point is showing parameters.

A parameter is a value passed into a procedure or function so that it can do its job. In simple words, it is the data a module needs to work with.

For example:

  • a conversion function may need the temperature
  • a password-checking function may need the entered password
  • an output procedure may need the final answer

In a structure chart, arrows are used to show data being passed between modules. These arrows may show:

  • data sent into a module
  • data returned from a function
  • values needed for a decision

For example, if a function called ConvertToCelsius needs a Fahrenheit value, the chart should show that the temperature value is passed to that function.

This is important because the structure chart is not only showing tasks. It is also showing the data links between those tasks.

Why programmers use structure charts

Structure charts are useful for several reasons.

First, they make large problems easier to understand. When a problem is split into small tasks, each part becomes less confusing.

Second, they support stepwise refinement. This means adding more detail one stage at a time. You start with the main task, then split it into sub-tasks, then split those again if needed.

Third, they help when writing pseudocode. Once the modules are clear, it becomes easier to write procedures, functions, and the main algorithm.

Fourth, they encourage good program design. If each module has one job, the program is usually easier to test and maintain.

Constructing a structure chart

To construct a structure chart for a given problem, follow a clear method.

Step 1: Identify the overall task

Start by asking, “What is the program trying to do?”

For example, a problem may ask for a program that:

  • converts temperatures between Celsius and Fahrenheit
  • keeps repeating until the user enters 999

The overall task could be called Temperature Conversion Program.

Step 2: Break the task into sub-tasks

Next, identify the smaller jobs the program must do.

For the temperature example, the jobs might be:

  • input the temperature
  • check if the sentinel value 999 was entered
  • input the conversion choice
  • carry out the correct conversion
  • output the result
  • repeat the process

A sentinel value is a special value used to stop a loop. Here, 999 is not a normal temperature to convert. It is used as a signal to stop the program.

Step 3: Decide which parts should be procedures or functions

A procedure carries out a task. A function carries out a task and returns a value.

For example:

  • GetTemperature could be a procedure if it stores the input directly
  • ConvertToCelsius could be a function because it returns a converted value
  • DisplayResult could be a procedure because it just shows output

Step 4: Show the hierarchy

Put the main module at the top. Place the lower-level modules underneath it.

This shows the order of breakdown from the main task to the smaller tasks.

Step 5: Show parameters being passed

Now add the data that moves between modules.

For example:

  • the input temperature may be passed to a conversion function
  • the choice of conversion may be passed to a decision-making module
  • the converted result may be passed to the output procedure

This part is very important in 12.2 because the syllabus specifically says you must express the parameters passed between modules, procedures, and functions.

Example: structure chart for a temperature conversion problem

Suppose the problem says:

  • input a temperature
  • allow conversion from Fahrenheit to Celsius or Celsius to Fahrenheit
  • keep repeating until 999 is entered

A sensible structure might be:

Main module: TemperatureConversionProgram

Sub-modules:

  • GetTemperature
  • CheckForStop
  • GetConversionChoice
  • ConvertToCelsius
  • ConvertToFahrenheit
  • DisplayResult

The data passed could be:

  • Temperature from input to the conversion module
  • Choice to decide which conversion to use
  • ConvertedTemperature to the display module

This is a good example of decomposition because each part of the problem has been separated into a clear task.

From structure chart to pseudocode

One important exam skill is turning a structure chart into equivalent pseudocode.

A structure chart gives the design. Pseudocode gives the step-by-step algorithm in a form that looks like programming logic.

Before writing the pseudocode, it is often helpful to create an identifier table.

An identifier is the name of something used in a program, such as a variable, constant, procedure, or function. An identifier table helps you list:

  • the identifier name
  • the data type
  • what it is used for

For the temperature conversion problem, an identifier table might include:

  • Temperature : REAL — stores the number entered by the user
  • Choice : STRING — stores whether the user wants C to F or F to C
  • ConvertedTemperature : REAL — stores the answer after conversion

Then you can write the pseudocode.

A suitable design could look like this:

DECLARE Temperature : REAL
DECLARE Choice : STRING
DECLARE ConvertedTemperature : REAL

REPEAT
    OUTPUT "Enter temperature (999 to stop): "
    INPUT Temperature

    IF Temperature <> 999 THEN
        OUTPUT "Enter CtoF or FtoC: "
        INPUT Choice

        IF Choice = "FtoC" THEN
            ConvertedTemperature ← (Temperature - 32) / 1.8
        ELSE
            ConvertedTemperature ← (Temperature * 1.8) + 32
        ENDIF

        OUTPUT ConvertedTemperature
    ENDIF
UNTIL Temperature = 999

This matches the structure chart because it includes:

  • input
  • decision making
  • calling the correct conversion process
  • output
  • repetition until the sentinel value is entered

How to recognise good pseudocode from a structure chart

When you derive pseudocode from a structure chart, make sure the pseudocode keeps the same logic.

Check these points:

  • the main task in the chart should become the main algorithm
  • each module should appear as a clear section, procedure, or function
  • parameters shown in the chart should appear in procedure or function calls
  • repetition shown in the chart should appear as a loop
  • decisions shown in the design should appear as IF statements

A common mistake is to write pseudocode that ignores the data passed between modules. If the structure chart shows a value being passed into a module, the pseudocode should also show that value being used as a parameter or variable.

State-transition diagrams

A state-transition diagram is used to document an algorithm when the system moves between different states.

A state is the condition or situation the system is currently in.

For example, a door lock system can be in different states such as:

  • locked and waiting for the first digit
  • waiting for the second digit
  • waiting for the third digit
  • unlocked

A transition is the change from one state to another.

The system changes state because of an input or event. For example, entering a correct digit may move the lock from one state to the next. Entering a wrong digit may send it back to the locked state.

A state-transition diagram is linked to a finite state machine, or FSM.

A finite state machine is a model of a system that can only be in one of a fixed number of states at a time. “Finite” means the number of states is limited, not endless.

Purpose of state-transition diagrams

The purpose of a state-transition diagram is to show how an algorithm behaves when different inputs happen.

This is useful because some systems do not just follow one straight sequence of steps. Instead, they react differently depending on their current state.

A state-transition diagram helps you document:

  • what states exist
  • what input causes a move from one state to another
  • what happens after each input
  • what outputs or actions happen during the transition
  • where the algorithm starts
  • where it stops

This makes it easier to understand systems such as:

  • door locks
  • vending machines
  • traffic light controllers
  • login systems
  • menu systems

In this syllabus, the key point is understanding their purpose for documenting an algorithm. They are especially useful when the behaviour of the system depends on previous inputs.

Features of a state-transition diagram

A state-transition diagram has several standard parts.

States

States are shown as circles. Each circle is labelled with the name of the state.

For example:

  • Locked
  • Waiting for 2nd digit
  • Unlocked

Transitions

Transitions are shown as arrows between states. An arrow shows how the system can move from one state to another.

Event labels

The arrows are labelled with the event or input that causes the transition.

For example:

  • 2 entered
  • not 2 entered
  • Button-Y pressed

Conditions

Sometimes a condition is written in square brackets after the event label. This shows that the change only happens if the condition is true.

Initial state

The starting state is shown by an arrow coming from a black dot or by a clear incoming arrow to the first state.

This tells you where the system begins.

Stopped or final state

A stopped state is shown as a double circle. This means the algorithm has reached an end point.

Example: door lock with a three-digit code

A simple example is a door unlocked by entering a three-digit code.

The door has four states:

  • locked and waiting for the first digit
  • waiting for the second digit
  • waiting for the third digit
  • unlocked

Now imagine the correct code is 2, then 5, then 9.

The behaviour is:

  • if 2 is entered first, the system moves to the state waiting for the second digit
  • if any other digit is entered first, the system stays locked
  • if 5 is entered next, the system moves to the state waiting for the third digit
  • if a wrong second digit is entered, the system goes back to locked
  • if 9 is entered third, the system reaches the unlocked state
  • if a wrong third digit is entered, the system goes back to locked

This is a good example of state-based behaviour. The same input may lead to different results depending on the current state.

For example, entering 5 only helps if the system is already waiting for the second digit. If the system is still in the locked state, 5 does not unlock anything.

State-transition tables

A state-transition table is a table form of the same idea. It usually shows:

  • current state
  • event or input
  • next state

Sometimes it also includes the output.

This is useful because some students find tables easier to follow than diagrams.

For the door example, a state-transition table could show that:

  • from locked, input 2 leads to waiting for second digit
  • from locked, input not 2 leads to locked
  • from waiting for second digit, input 5 leads to waiting for third digit
  • from waiting for second digit, input not 5 leads to locked
  • from waiting for third digit, input 9 leads to unlocked
  • from waiting for third digit, input not 9 leads to locked

The diagram and the table show the same logic in different ways.

How to understand a state-transition diagram in an exam

When you are given a state-transition diagram, work through it carefully.

First, find the initial state. This tells you where to begin.

Next, look at the current state and follow the arrow that matches the input. Read the label carefully.

Then, record:

  • the output, if there is one
  • the next state

If there is no output, you may need to write none.

Be careful with loops. Some states may have arrows that go back to the same state. This means the system stays in that state after the input.

Also be careful with reset paths. In many systems, a wrong input sends the system back to the start state.

Structure charts and state-transition diagrams compared

These two diagrams are both used in program design, but they do different jobs.

A structure chart shows how a program is broken into modules. It is about the organisation of tasks.

A state-transition diagram shows how a system changes state in response to inputs. It is about behaviour over time.

So:

  • structure chart = decomposition of the program into parts
  • state-transition diagram = movement between states caused by events

Both are useful for documenting algorithms, but they describe different things.

Common mistakes to avoid

One common mistake is to confuse a structure chart with a flowchart. A structure chart is not mainly about the exact sequence of every step. It is mainly about breaking the task into modules and showing the links between them.

Another mistake is forgetting to show parameters on a structure chart. In this topic, the data passed between modules matters.

A third mistake is writing pseudocode that does not match the chart. The modules in the chart should appear clearly in the algorithm.

For state-transition diagrams, students often forget to check the current state before following an input. The same input can produce a different result in a different state.

Another common mistake is missing the start state or the final state.

Exam advice

In exam questions on structure charts:

  • identify the main task first
  • split it into clear sub-tasks
  • keep each module focused on one job
  • show the data passed between modules
  • make sure any derived pseudocode matches the design

In exam questions on state-transition diagrams:

  • start at the initial state
  • follow arrows carefully
  • read every input label exactly
  • record outputs if shown
  • watch for loops and reset paths
  • remember that a final state may be shown by a double circle

Key Terms

Structure chart — a diagram that breaks a problem into smaller modules to help design a program.

Decomposition — splitting a large problem into smaller, easier parts.

Module — a separate part of a program that performs one task.

Top-down design — starting with the main task and then breaking it into smaller tasks.

Parameter — a value passed into a procedure or function so it can do its job.

Procedure — a named module that performs a task.

Function — a named module that performs a task and returns a value.

Identifier table — a table listing the names, data types, and purposes of variables and other identifiers used in a program.

Pseudocode — a simple way of writing an algorithm using programming-style statements without following one real programming language exactly.

Sentinel value — a special value used to stop a loop.

State — the current condition or situation of a system.

Transition — a change from one state to another.

State-transition diagram — a diagram showing how a system moves between states when inputs or events occur.

Finite state machine (FSM) — a model of a system that has a fixed number of possible states.

State-transition table — a table showing the current state, input, and next state, and sometimes the output.

Initial state — the state where the system starts.

Final state — the end state where the system stops.

Exam-Style Questions & Answers

Question 1 (4 marks)

Describe the purpose of a structure chart.

Model Answer:

  1. A structure chart is used to break a large problem into smaller sub-tasks, so the program is easier to design.
  2. It shows the relationship between the main task and the lower-level modules that help complete it.
  3. It helps the programmer see which parts of the problem should be written as separate procedures or functions.
  4. It can also show the data passed between modules, which helps when turning the design into pseudocode.

Question 2 (4 marks)

A program must input a temperature, choose whether to convert it from Fahrenheit to Celsius or Celsius to Fahrenheit, display the result, and repeat until 999 is entered. State four suitable modules that could appear on a structure chart for this problem.

Model Answer:

  1. InputTemperature — this module would ask the user to enter the temperature value.
  2. GetConversionChoice — this module would ask the user which type of conversion is needed.
  3. ConvertToCelsius / ConvertToFahrenheit — these modules would carry out the correct calculation depending on the user’s choice.
  4. DisplayResult — this module would output the converted temperature to the user.

Question 3 (4 marks)

Explain how pseudocode can be derived from a structure chart.

Model Answer:

  1. The main module in the structure chart becomes the main part of the algorithm in the pseudocode.
  2. Each lower-level module can be turned into a procedure, a function, or a clearly separated part of the pseudocode.
  3. Any parameters shown on the chart must appear in the pseudocode as values passed into procedures or functions.
  4. Loops and decisions shown by the design must be written using suitable pseudocode structures such as REPEAT...UNTIL or IF...THEN...ELSE.

Question 4 (4 marks)

Explain the purpose of a state-transition diagram.

Model Answer:

  1. A state-transition diagram is used to document how a system behaves when different inputs happen.
  2. It shows all the possible states the system can be in at different times.
  3. It shows the transitions, which are the changes from one state to another caused by events or inputs.
  4. It helps the programmer understand the logic of systems where the result depends on the current state, such as a door lock or login system.

Question 5 (4 marks)

A door lock uses the three-digit code 2, 5, 9. The states are: locked, waiting for second digit, waiting for third digit, and unlocked. Explain what happens when a user enters the sequence 2, then 4.

Model Answer:

  1. When the user enters 2 in the locked state, the system moves to the state waiting for the second digit.
  2. The next correct digit should be 5, because that is the second digit of the code.
  3. When the user enters 4 instead, the input is incorrect for that state, so the system does not continue forward.
  4. The lock returns to the locked state, ready for the first digit to be entered again.

Sign in to view full notes