Computer-aided design of engineering software*
G E O R G E RZEVSKI
Kingston Polytechnic
MARION WELLS
Chelmer Institute of Higher Education
The paper describes the development of an interactive
Computer-Aided Software Design System. The
system checks entered software design decisions for
correctness and provides fast visual feedback for
software designers. It also generates all software
design documentation.
INTRODUCTION
A methodology for systematic design of engineering
software was described at the 1st International
Conference on Engineering software in Southampton.
The benefits which have been obtained by the use ofthis
methodology in an industrial environment are
numerous 2. The major benefits are summarised below.
(1) The occurrence of human errors which cause
software faults is minimized. This cuts dramatically
the time normally required for the removal of
software bugs and thus reduces software
development costs.
(2) The time required for understanding, testing or
modifying software by a person other than the one
who has written the program is considerably
reduced. This reduces software maintenance costs.
(3) The reliability of software is much higher. For
example 3, one can find evidence that by the
strict application of systematic methods the number
of residual software faults can be reduced from 1
fault per 100 lines of statements to 1 fault in 10,000
lines of statements.
(4) The scheduling of software development tasks,
estimation of resources required for the software
development and progress control are greatly
facilitated. Thus the costs of software development
management are cut.
(5) The time required to train and to introduce a new
member into a software development team is much
shorter. This reduces personnel training costs.
(6) Finally, organizations which apply similar methods
have built, over a period of years, a useful library of
standard software modules. The use of such
modules in new projects further reduces the cost of
software development.
This paper describes how such a systematic software
design methodology has been used as a basis for the
development of computer aids for software development.
* Paper taken from the proceedings of the 2nd International
Conferenceand Exhibitionon EngineeringSoftware,April 24th-26th
1981.
0141-1195/82/040032-0252.00
~) 1982 CML Publications
32 ,Ado. Eng. Software, 1982, Vol. 4, No. 1
Experience with a pilot Computer-Aided Software Design
System is also described.
DEFINITION OF REQUIREMENTS
Requirements for a Computer-Aided Software Design
System were defined following a thorough analysis of
Kingdom software design methodology.
Several major features of the methodology were singled
out as the most relevant.
(1) The methodology imposes certain constraints on
the software design process. The aims of these
constraints are:
-tO control the complexity of software design tasks,
and
-to control the complexity of software modules.
(2) Within these constraints considerable freedom is left
to software designers to exercise their ingenuity. No
attempt is made to reduce software design to
unskilled work.
(3) The control of the complexity of tasks is achieved by
the following means:
-software design process is decomposed into a
number of simple steps,
-each step is defined in terms of its input
documentation, the set of activities which are to be
performed and its output documentation,
-a desirable sequence of design steps is determined,
-the transition from one step to the next is allowed
only after the completed work is checked in
accordance with predetermined criteria and
established to be correct.
(4) The control of the complexity ofsoftware modules is
achieved as follows:
-each module performs a clearly defined function;
the independence of one module from all others is
maximised,
-the interface of each module is limited to a certain
number of variables,
-the number of constituent modules (or statements)
in each module is kept within prescribed bounds,
-the choice of control structures is limited,
-the format of design documentation is such that
the independence of one page from other pages is
maximised.
A careful analysis of these features showed that
software could be designed by an interactive man-
machine system. In such a system the man would make
the design decisions whilst the machine would
(1) provide the required'design information in a proper
format whenever requested,
(2) ensure that design tasks were performed correctly command-driven. Its design is based on the dialogue
and in a correct order, described in the previous section of this paper.
(3) ensure that the complexity of software modules was Correctness checking facilities are at present limited.
within specified limits, The system checks, for example, that: (1) all input
(4) produce all required design documentation. variables to constituent modules are either inputs to the
In order to depict as clearly as possible how a computer parent module or outputs from another constituent
would be used as an aid to software designers, typical module (i.e. internal variables); (2) all output variables
man-machine dialogues were devised. One such dialogue, from constituent modules are either outputs from the
which describes the design of a software module, is shown parent module or inputs to other constituent modules (i.e.
below: internal variables); (3) only permissible control structures
are used; (4) no module has more than 10 constituent
Man Machine modules. Design guidelines are displayed for the user
1 displays format for module whenever requested. Error messages are comprehensive.
specification Since the format of design documentation is displayed on
2 enters module specification
3 displays and checks entered the screen before each design step, design is carried out by
data means of a "form filling" process.
4 displays either an error The pilot system has been implemented in BASIC on a
message of format for data P E T microcomputer and is currently used for
structure design (1) design of simple programs in BASIC,
5 enters data structure details
6 displays and checks data (2) teaching of systematic design methods to beginners
structure and experienced programmers.
7 displays either an error Although the facilities implemented at present are
message or format for module rather modest, the response of users has been very
decomposition diagram
8 enters module decomposition positive. Students are particularly delighted that the
diagram system has eliminated the need to produce manually a
9 displays and checks diagram rather extensive design documentation. Teachers, on the
10 displays either an error other hand, are now free from the tedious task of checking
message or format for module students' work for correctness.
control structure
11 enters module control However, a systematic evaluation of the pilot system
structure has yet to be undertaken and, hence, the fmal judgment of
12 displays and checks control its success must wait until this has been completed.
structure (e.g. as a flow chart)
13 displays an error message or
14 prints module specification,
data structures, decomposition F U T U R E RESEARCH
diagram and control structure.
Resources have been obtained to continue with this
research with a view to developing a full-scale computer-
At any time software designers can interrupt the design aided software design system on the DEC 20 machine.
and return to a previously designed module and make any A raster-scan graphics terminal will be used as a m a n -
modifications. Designers are not, however, allowed to machine interface. Other features of the new system will
miss a prescribed design step, e.g. to design a flow chart include: command language driven dialogue,
before a module specification is satisfactorily completed. comprehensive correctness checking facilities and a code
generator.
A PILOT SCHEME
Based on the requirements definition a formal
specification for the Computer-Aided Software Design REFERENCES
System was formulated. 1 Rzevski, G., (1979), On the Design of Engineering Software, in R. A.
However, before a proper design began the decision Adey (ed.), Engineering Software, pp. 428-440, Penteeh Press.
was made to develop a simple pilot system which would 2 Rzevski, G., Woolman, D. and Trafford, D. B., (1980), Validation of
Design Methodology, Design Studies, 1, 4.
test the feasibility of the project. 3 Yourdon, E. and Constantine, L. L., (1979), Structured Design:
For reasons of simplicity the pilot system has a Fundamentals of a Discipline of Computer Program and Systems
conversational man-machine interface rather than Design, Prentice-Hall.

Adv. Eng. Software, 1982, Vol. 4, No. 1 33