Program Design Using JSP

Frontmatter

1. The Importance of Program Design

Abstract

The importance of properly designed software of any kind, from the trivial application program to the most complex operating system, cannot be overstressed. In these days when software production and maintenance costs are escalating in relation to total system costs and there is a shortage of skilled software producers, the computing profession can ill-afford to produce substandard software. Yet, much poor software is produced, mainly due to poor problem definition and poor program design.

M. J. King, J. P. Pardoe

2. Data Structures

Abstract

For any programming problem (not involving parallel activities) structure diagrams may be drawn consisting of just 3 basic construct types:

• ❏ Sequence
• ❏ Iteration (loop)
• ❏ Selection (choice)

M. J. King, J. P. Pardoe

3. Data Structures for Particular Problems

Abstract

A physical data structure fully describes some data without taking into account any particular use to which the data may be put; that is, without taking into account the problem under consideration.

M. J. King, J. P. Pardoe

4. Program Structures

Abstract

A correct program structure will ‘mirror’ the data structures of its input and output. So we now consider how to produce a program structure by combining the logical data structures (at this stage we will assume a maximum of one input and one output structure).

M. J. King, J. P. Pardoe

5. Elementary Program Operations and Conditions

Abstract

When we are happy with our program structure, we are then in a position to think about the elementary program operations that must be included within the structure, and the conditions that control the iterations and selections. First we identify and list the conditions.

M. J. King, J. P. Pardoe

6. Schematic Logic

Abstract

Schematic logic is a pseudo-code representation of the program structure with allocated operations and conditions. We will first produce schematic logic, then code the program in a high level programming language. Most programmers find it easier to translate the pseudo-code, rather than the program structure diagram, into the target language. Furthermore, when using one of the more advanced JSP techniques (covered in chapter 10), we shall find it necessary to amend the schematic logic, by introducing additional operations and conditions, without changing the program structure.

M. J. King, J. P. Pardoe

7. Implementation in a High Level Programming Language

Abstract

The production of schematic logic, an elementary program operation list and condition list, essentially concludes the design stage. It remains only to translate these into a high level programming language. This involves:

1.

Coding the declaration part of the program (as required by COBOL and Pascal for example).

 

2.

Implementing the schematic constructs — SEQ SEL and ITER — using control constructs provided by the target language.

 

3.

Translating each elementary operation and condition into the target language, bearing in mind that certain operations will require more than one program statement.

 

M. J. King, J. P. Pardoe

8. More Than One Input File

Abstract

If we are to process more than one input file simultaneously, then very often the input files will have to be sorted into a specific order and, at the top level, will have very similar logical data structures.

M. J. King, J. P. Pardoe

9. Structure Clashes and Inversion

Abstract

We briefly mentioned the idea of structure clashes at the end of chapter 4. Structure clashes occur when it is not possible to combine logical data structures to produce a single program structure, because.the logical data structures contradict or clash with each other.

M. J. King, J. P. Pardoe

10. Recognition Problems and Backtracking

Abstract

For most problems we can ‘find our way’ through the program structure by reading one record ahead. By inspecting the next record to be processed (that is, the record just read), we can determine whether or not there is a further occurrence of the iterated part of an iteration and which part of a selection is to be executed.

M. J. King, J. P. Pardoe

11. Procedurisation

Abstract

We shall use the term ‘procedure’ in a general sense to include triose parts of a complete program variously called subprograms, functions, subroutines and segments. In general, procedurisation is used to break the problem down into more manageable parts to facilitate detail design, testing and maintenance. However, the programmer is often faced with the dilemma of deciding which parts to procedurise. In addition to run-time overheads and the problems of interfacing, the ill-advised use of procedures can lead to implementation and maintenance problems rather than reducing them. The programmer should therefore always have sound reasons for procedurising and, in doing so, should ensure that the principles of JSP are not contradicted. For example, in chapter 9 we used a subprogram, with good reason, to solve the structure clash problem by considering two simpler problems instead. The purpose of this chapter is to provide some general guidelines on procedurisation within the context of JSP.

M. J. King, J. P. Pardoe

12. Interactive Systems

Abstract

Many systems allow individual users to interact with the computer directly. This involves the use of a dialogue between a terminal user and the computer. The most common basic types of interactive dialogue are:

(a)

menu selection

 

(b)

form filling

 

(c)

question and answer

 

(d)

interrogate or command.

 

In this chapter we develop program structures with allocated operations and conditions for each of the above. Each example is considered to be part of a larger problem — in practice it could be a self-contained procedure — and therefore we include only the structure, operations and conditions relevant to the dialogue.

M. J. King, J. P. Pardoe

13. Testing, Documentation and Program Amendment

Abstract

By now you should appreciate that the main feature of JSP is the way in which we proceed from data structures to program code, through well-defined manageable stages (please refer to section 1.4.). You should also have realised that if we make a mistake, then certain errors may become apparent at an early stage. For example, if data structures without clashes cannot be combined easily, then the structures should be carefully checked to see if they are correct. If you cannot find an obvious position on the program structure for a certain operation, then you should first ascertain whether or not that operation is necessary and then, provided it is, check the program structure. Having taken due care in applying the principles and rules of JSP, you should always be reasonably confident that the program is correct.

M. J. King, J. P. Pardoe

Backmatter