- [Craig] In this video, we take a look at a common diagram created during the process of problem decomposition, a structure diagram.
(uplifting piano jingle)
As covered in a previous video in this series, decomposition simply means breaking a problem down
into smaller, more manageable parts.
This is because dealing with many different stages of a problem at once
is much more difficult than breaking a problem down into a number of smaller parts
and solving each of those one at a time.
A common tool to us when decomposing a problem is that of a structure diagram.
We create structure diagrams using an approach known as step-wise refinement.
Let's work through an example now.
So, at the very top level of our structure diagram, we have the name of our overall program.
So, for the purpose of our example, let's assume we're writing a program which will
deal with handling wages for a company, calculating and paying them out, for example.
After some initial analysis, we would start to break down the overall problem into its main tasks you need to perform.
Now, there's no right or wrong way to do this.
With practice over time, you will get better.
We might decide, for example, that this program has three distinct main parts.
Inputting all the employees' details, calculating their pay and producing their payslips.
These will all go into the next level down in our structure diagram.
Now, bear in mind that some of these modules broken down into the first layer
might not actually need breaking down any further.
Others might still be quite complex and require breaking down into smaller parts.
For example, we might decide that calculate pay should be broken down into two distinct parts.
Calculate gross pay, that's all the money coming in, and calculate total deductions or money going out.
These would go underneath calculate pay at the next level down in our structure diagram.
You would carry on this process,
breaking down any stage which is still too complex into smaller, more manageable chunks.
So again, you might decide that calculate pay actually has far too much complexity in it
and needs breaking down into four separate problems to tackle,
e.g., calculate income tax, calculate national insurance, calculate non-paid sick days
and calculate pension contributions.
Once again, these would all need to go underneath calculate deductions at the next level down of our structure diagram.
As you can see from the example we've been building up on the right,
different sections of your program will end up being broken down to different levels.
It all depends how complex they are.
The end result though is always the same and that is that every lowest-level node on your structure diagram
should be trying to achieve a single task.
This means they can then easily be coded as a single module or sub-program.
So, just to recap, one method of designing a solution to a problem is by creating structure diagrams.
Structure diagrams illustrate problem decomposition.
They can be used for developers to understand a problem to code and to share with users during systems analysis.
They are produced using a method known as step-wise refinement.
We break the problem down using decomposition into smaller and smaller components.
Some areas of the program will need breaking down more than others,
and the lowest-level nodes should achieve a single task.
These can then be coded as a single module or sub-program.
(uplifting piano jingle)