44 total
By the end of this subtopic, you should be able to:
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:
A structure chart focuses on the overall design of the program. It helps you see the structure before writing the full algorithm.
A structure chart has some common features.
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:
InputTemperatureChooseConversionConvertToCelsiusConvertToFahrenheitOutputResultEach module should do one clear job. This makes the program easier to understand, test, and change.
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:
This lets you move from the general idea to the details step by step.
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.
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:
In a structure chart, arrows are used to show data being passed between modules. These arrows may show:
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.
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.
To construct a structure chart for a given problem, follow a clear method.
Start by asking, “What is the program trying to do?”
For example, a problem may ask for a program that:
999The overall task could be called Temperature Conversion Program.
Next, identify the smaller jobs the program must do.
For the temperature example, the jobs might be:
999 was enteredA 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.
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 directlyConvertToCelsius could be a function because it returns a converted valueDisplayResult could be a procedure because it just shows outputPut 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.
Now add the data that moves between modules.
For example:
This part is very important in 12.2 because the syllabus specifically says you must express the parameters passed between modules, procedures, and functions.
Suppose the problem says:
999 is enteredA sensible structure might be:
Main module: TemperatureConversionProgram
Sub-modules:
GetTemperatureCheckForStopGetConversionChoiceConvertToCelsiusConvertToFahrenheitDisplayResultThe data passed could be:
Temperature from input to the conversion moduleChoice to decide which conversion to useConvertedTemperature to the display moduleThis is a good example of decomposition because each part of the problem has been separated into a clear task.
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:
For the temperature conversion problem, an identifier table might include:
Temperature : REAL — stores the number entered by the userChoice : STRING — stores whether the user wants C to F or F to CConvertedTemperature : REAL — stores the answer after conversionThen 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:
When you derive pseudocode from a structure chart, make sure the pseudocode keeps the same logic.
Check these points:
IF statementsA 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.
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:
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.
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:
This makes it easier to understand systems such as:
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.
A state-transition diagram has several standard parts.
States are shown as circles. Each circle is labelled with the name of the state.
For example:
LockedWaiting for 2nd digitUnlockedTransitions are shown as arrows between states. An arrow shows how the system can move from one state to another.
The arrows are labelled with the event or input that causes the transition.
For example:
2 enterednot 2 enteredButton-Y pressedSometimes a condition is written in square brackets after the event label. This shows that the change only happens if the condition is true.
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.
A stopped state is shown as a double circle. This means the algorithm has reached an end point.
A simple example is a door unlocked by entering a three-digit code.
The door has four states:
Now imagine the correct code is 2, then 5, then 9.
The behaviour is:
2 is entered first, the system moves to the state waiting for the second digit5 is entered next, the system moves to the state waiting for the third digit9 is entered third, the system reaches the unlocked stateThis 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.
A state-transition table is a table form of the same idea. It usually shows:
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:
locked, input 2 leads to waiting for second digitlocked, input not 2 leads to lockedwaiting for second digit, input 5 leads to waiting for third digitwaiting for second digit, input not 5 leads to lockedwaiting for third digit, input 9 leads to unlockedwaiting for third digit, input not 9 leads to lockedThe diagram and the table show the same logic in different ways.
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:
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.
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:
Both are useful for documenting algorithms, but they describe different things.
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.
In exam questions on structure charts:
In exam questions on state-transition diagrams:
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.
Describe the purpose of a structure chart.
Model Answer:
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:
Explain how pseudocode can be derived from a structure chart.
Model Answer:
REPEAT...UNTIL or IF...THEN...ELSE.Explain the purpose of a state-transition diagram.
Model Answer:
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:
2 in the locked state, the system moves to the state waiting for the second digit.5, because that is the second digit of the code.4 instead, the input is incorrect for that state, so the system does not continue forward.Sign in to view full notes