Jackson Structure Diagrams (JSDs) are an effective technique for analyzing the logical structure of a procedural program. They are especially useful for logical flows that depend on a constant input source as often is the case in batch processing.
Jackson Structure Diagram Concepts
The concepts defined here are only those used in The JDS.
is an object (either physical or abstract) that causes activity in a system or is affected by the system activity, or both.
An action is an event that happens to an entity or that is carried out by an entity. Each action can be decomposed into smaller actions.
A sequence is a decomposition of an entity or action into one or more actions, in which these actions are to be executed in a certain order. In the JSDs the actions in a sequence should always be executed from left to right.
A selection is a decomposition of an JSD-component into two or more actions in which only one of the containing actions is executed. Which action is executed is based upon a certain condition. A selection can best be compared with an If Then Else-statement, where the Else-clause must be present.
An iteration is a decomposition of an JSD-component which contains only one action. Based upon a condition this action occurs (iterates) zero or more times. Thus the parent is formed of zero or more occurrences of the child.
JSD Actions for the Banking Application
The banking application procedural program can be modelled by decomposing the program into the following JSD actions:
- open input transaction file.
- open output files.
- write report header - date, time and title.
- write error report header - date, time and title.
- read first transaction record
- process transaction
- build and write error record if error
- accumulate subtotal
- accumulate master total
- read next transaction record
- write bank subtotal
- write report footer(s) with master total.
- close output files
The JDS should be read from left to right, top to bottom.
|
This diagram effectively describes the program logic flow for the banking application, albeit at a very high level. The symbols have the following meaning:
The * represents an iteration, accompanying it is normally text which defines the condition on which the iteration ends. This implies that all actions defined on the substructure below this box are performed for each iteration.
In the banking application you are performing actions for each bank. In the complete structure above you also iterate over all account transactions for each bank, this allows us to perform bank specific processing at the end of each iteration, for example, print totals for each bank.
The O symbol represents a branch of a logical condition. In the banking application you test if you are dealing with a current or savings account and define the actions for each separately.
COBOL and PL/I (Procedural) Approach
A program written in PL/I or COBOL based on this model would typically have an initialization and finalization section. The main body would be represented by one main loop comprising of an if branch for recording and dealing with bank specific actions. Importantly there might be one section or subprogram for executing the actual transaction regardless of whether it is a debit or credit on a checking or savings account. There could be separate modules for lodgment and withdrawal. Within these modules, database sources are freely accessed. If during a maintenance cycle, processing for current account debit changes, then the resulting regression testing must include savings account as well. This is because the implementation for both is physically in the same module and can be to some extent shared. There can also be an online version of this program, that is, running in IMS or CICS and serving a network of ATMs. There is no guarantee that the same modules for credit and debit have been used in this program. It could be the case that the credit and debit code in the online case is completely different to the batch case and that it makes updates to the underlying database in a different way. Generally this leads to a maintenance headache. This lack of separation of concerns is the major drawback of this model.