Program Design: Structure Charts and State Transitions
Design sits between analysis and coding. Its purpose is to decide the structure of the solution
before any code is written. Three tools are required: structure charts,
state-transition diagrams and decomposition into modules.
1. Decomposition and Modular Design
Decomposition breaks a problem into smaller sub-problems, each becoming a module — a self-contained procedure or function with one clear responsibility.
- Each module can be written, tested and debugged independently
- Several programmers can work on different modules simultaneously
- A well-named module is self-documenting
- Modules can be reused in other programs
- A change is confined to one module rather than spread through the program
Two design qualities worth naming in evaluation answers.
Cohesion is how single-purpose a module is — high cohesion is good.
Coupling is how dependent modules are on each other — low coupling is good. Aim for
modules that do one job and interact only through their parameters.
2. Structure Charts
A structure chart shows the hierarchy of modules and the data passed between them. It is read top-down: the whole task at the top, decomposed into sub-tasks below.
+---------------------+
| Process Payroll |
+---------------------+
/ | \
/ | \
+------------+ +------------+ +--------------+
| Read Hours | | Calc Pay | | Print Payslip|
+------------+ +------------+ +--------------+
/ \
/ \
+----------------+ +---------------+
| Calc Gross Pay | | Calc Tax |
+----------------+ +---------------+
Data flow: Read Hours --[Hours, Rate]--> Calc Pay
Calc Pay --[NetPay]-------> Print Payslip
| Notation | Meaning |
|---|---|
| Box | A module |
| Line downwards | The upper module calls the lower one |
| Arrow with a label | A parameter passed between modules |
| Diamond | Selection — one of the modules below is called |
| Curved arrow / asterisk | Iteration — the module below is called repeatedly |
A structure chart shows hierarchy, not sequence. It records which module calls which and what
data passes between them — not the step-by-step order of execution. Use a flowchart or pseudocode for
sequence.
3. State-Transition Diagrams
A state-transition diagram models a system that can be in one of a limited number of states, moving between them in response to events.
| Element | Shown as | Meaning |
|---|---|---|
| State | A labelled circle or rounded box | A condition the system can be in |
| Transition | An arrow between states | A change from one state to another |
| Event | The label on the arrow | What triggers the transition |
| Start state | Arrow from a solid dot | The state on starting up |
Worked example: a cash machine
start
|
v
+----------+ card inserted +------------+ correct PIN +---------+
| Idle |----------------->| Awaiting |--------------->| Menu |
| | | PIN | | |
+----------+ +------------+ +---------+
^ | |
| | 3 wrong attempts | withdraw
| v v
| +------------+ +--------------+
+----------------------| Card | | Dispensing |
card returned | Retained | | Cash |
+------------+ +--------------+
|
| cash taken
v
(back to Idle)
Each arrow is labelled with the event causing the change. Note that the same state can be reached from several others, and that some transitions depend on a condition being met, such as three failed attempts.
State transition tables
The same information can be tabulated, which is often easier to check for completeness:
| Current state | Event | Next state |
|---|---|---|
| Idle | Card inserted | Awaiting PIN |
| Awaiting PIN | Correct PIN entered | Menu |
| Awaiting PIN | Third incorrect PIN | Card Retained |
| Menu | Withdrawal selected | Dispensing Cash |
| Dispensing Cash | Cash removed | Idle |
When to use which tool. A structure chart suits a program decomposed into modules that process
data. A state-transition diagram suits an event-driven system whose behaviour depends on what has
already happened — a vending machine, a traffic light, a lift, a game character.
4. Choosing the Right Design Tool
| Tool | Shows | Best for |
|---|---|---|
| Structure chart | Module hierarchy and parameters | Planning a modular program |
| State-transition diagram | States, events and transitions | Event-driven or control systems |
| Flowchart | Step-by-step flow of control | Detailed logic of one module |
| Pseudocode | Language-independent detailed logic | Specifying an algorithm before coding |
5. Exam Focus
Label every transition with its event. An unlabelled arrow in a state-transition diagram earns
no mark. The event is what makes the diagram meaningful.
Show the parameters on a structure chart. Questions frequently ask specifically what data passes
between modules. A chart of empty boxes with no data flow loses those marks.
Use states, not actions, as state names. "Dispensing Cash" and "Awaiting PIN" are states;
"Press button" is an event. Mixing the two is a common structural error.
Justify decomposition with maintainability. When asked for the benefits of a modular design,
cite independent testing, parallel development, reuse and localised change — not merely "it is neater".
Quick self-check
- State three benefits of decomposing a problem into modules.
- Explain the difference between high cohesion and low coupling.
- What do the arrows and their labels represent on a structure chart?
- Draw a state-transition diagram for a light switch with states On and Off.
- Give one situation where a state-transition diagram is more suitable than a structure chart.
- Produce a state transition table for a turnstile with states Locked and Unlocked.