Jackson Structured Programming (JSP) and decomposition
When developing programs in a third-generation language, the traditional way of approaching the problem has been to use a top-down approach. This is where the problem is written down very simply. Then it is split up into a number of smaller modules. Each of those smaller modules is then broken down into ever-smaller modules until each module does one and only one job. They are then given to the programmers to code.
Jackson Structured Programming (JSP) diagrams
Top-down diagrams in programming are often drawn using Jackson Structured Programming (JSP) diagrams. These seek to break down problems into manageable chunks, to help people better understand a problem and to help them plan a solution.
An example of top-down design using JSP diagrams
Consider the following problem. You need a program that calculates the checkout total for a customer at a cash-and-carry. To shop at this cash-and-carry, you need to be a member and memberships come in three types: bronze, silver and gold. Each membership type gets its own discount! A customer at a checkout first gives details of their membership card. The checkout assistant then scans in each item. The price is retrieved from the stock database. All the items are added up and the appropriate discount subtracted from the total. The checkout assistant then tells the customer how much is due. They receive cash from the customer, then calculate and give out the change as well as an itemised receipt.
Define the problem simply. If you initially start by breaking down every problem into the four modules shown above, initialise, input, process and output, it will help you get started!
Break the problem down into smaller modules. You read this diagram by reading the top level of the diagram first, from left to right in sequence. Then read the second level of the diagram, left to right in sequence, then the third level and so on.
Break the problem down into further modules wherever possible.
Before we can go any further with this, we are going to have to introduce some drawing conventions. Consider for a moment the module 'Final bill'. The final bill will be worked out by taking the total from the 'CalcTotal' module, taking the discount due from the 'InputMemType' module and then subtracting a discount from the total. We can represent this in the following way:
Showing ‘selection’ in JSP.
You can read the above as "If the customer has a bronze membership, then do the module Bronze. Else if they have a Silver membership, do the module Silver, Else if they have a Gold membership, do the module Gold." Note the little circle in the top right hand corner of each of the possible modules that could be done. That is how you show choice!
There is one other drawing convention we need to know about. To do the 'CalcTotal' module, you will need to read in an item, add it to a running total, then read in the next item and add it to the running total and keep repeating this until there are no more items. How do we show a repetition (otherwise known as an iteration)? We show it like this:
Notice the use of what appears to be an extra box with a star in it! Omitting it is a common mistake when you are first learning about this design method. Don't forget the comment just outside the box, in this case "Until no more items".
Back to STEP 3
We can now show the final JSP diagram, including the structures that are needed to show selection and iteration.
The diagram you have produced is called a JACKSON STRUCTURED PROGRAMMING diagram, or JSP diagram for short. It is only made up of three types of constructs: SEQUENCE, SELECTION and ITERATION and you have seen examples of how to represent each type in the above diagram. You will need to do two or three examples yourself before you are confident at representing problems using this method.
More examples of JSP – sequence
On the first level is the problem. This is represented by one box. The one box has been broken down into three modules. These are each represented by a box and are all in line on the next level. We read these three boxes in sequence, starting on the left.
We can break down some of these boxes further, as shown in the diagram. These are shown on the next level. Again, we read the boxes in sequence from left to right. In this JSP diagram, we have only used the construction sequence.
More examples of JSP – selection
Another example of selection.
In this example, we can see how selection is represented in part of a program that deals with age verification. You must be 18 or older to vote. If you are less than 18 then the block of code on the left is run. If you are 18 or older then the block of code on the right is run. There is a little zero in the top left of each choice to indicate that the box is one choice of a number of choices. This is how selection is represented using JSP.
More examples of JSP
In this diagram, we can see that iteration has been used. We should note the use of what appears to be an extra box with a star in it. The star denotes that there is an iteration going on and the iteration should continue until the condition that is written just under the box is met. In this case, it’s ‘Until there are no more bills’. This JSP diagram also shows the sequence construction in use and there is one example of a selection construction.
The benefits of JSP diagrams
Once you have got a top-down design, you can then write a program. There are a number of benefits associated with the production of a JSP diagram:
- One benefit is that you can see the whole program as one diagram.
- JSP diagrams give you a tool (the diagram) to discuss the program with other designers and programmers, for example, to see if there are any improvements that can be made.
- The diagram helps the management of building a program because a team leader can see what modules need to be distributed.
- JSP diagrams can help with the identification of the more complicated modules. These can be given to the more experienced programmers.
- One important advantage JSP diagrams have is that they are language-independent although they are really meant for programs that will be written using procedural languages. Once a design has been done, it can be implemented in any procedural programming language.
You may also hear about problems being solved using a ‘bottom-up approach’. This simply means that you start by programming lots of smaller modules before considering the overall design. Once you have a set of individual modules, you then think about the design of a program. You take modules ‘off-the-shelf’ and stick them together into a larger program. You test that as if it were a working system. Then you add in more modules to the system so far and get that working. This is repeated until all of the modules you need have been recombined into one program.
An analogy for bottom-up programming
Consider making a computer, the best computer there has ever been! You might start by designing and building various components such as the motherboard, the DVD drive, the hard drive, the monitor and so on. Once you have the design for all of the components, you then consider the design of your PC. You select the first few components you want, connect them together and test them together. You then have a basic, but working computer. You then add another component and test your system again. You keep adding components and testing them, one at a time, until you have a final system. This is an example of you building a computer using a ‘bottom-up’ method.