systems

Fourth-generation languages - how to choose the right one by RICHARD WATTS

I t is not sensible to go out and buy

a fourth-generation language with- out a proper evaluation of all the

factors concerned. The needs of dif- ferent organizations are unlikely to be exactly the same, though there will be many similarities; for this reason

there can be no ‘best buy’. In this paper, it is intended to

describe some of the productivity gains that can be made, showing how some of these can pull in opposite directions, according to the require- ments of the organization. This will serve two purposes; on the one hand it will introduce some of the ways in which this productivity should be measured and on the other it will lead

on into a discussion of the best way to choose a fourth-generation language

(4GL).

Abstract: Fourth-generation languages need paper evaluation before purchase. Although increased productivity is one benefit, each product must be measured and evaluated correctly. Since there is no ‘best buy’, by setting down a number of questions covering the needs of the department, it is possible to make a rational decision.

Keywords: data processin,g, programming, fourth-generation languages.

Richard Watts is senior consultant, Methods Division at the National Centre for Information Technology

Application generator

James Martin, who invented, or at any rate popularized the term 4GL, uses it to cover a wide range variety of productivity aids including report generators and query languages; his criterion is the saving of code to be

written’. Most people however use a more limited definition, They use 4GL to mean application generator, which is screen based, interactive and includes a large non-procedural ele- ment. It is in this sense it is used here. It is important that it should allow ‘dynamic generation’ whereby one can run the generated systems with- out a full intermediate compilation stage. Compilation may however be an additional facility to provide great- er efficiency in production systems.

Some of the claims that are made for 4GLs talk only about savings of programming effort. When it is re-

alised how little this produces in the way of savings overall, since coding is perhaps only lo-20% of the total effort, it will be seen that one must look for savings elsewhere in the development life cycle.

In fact, there will be savings in the testing as well as the coding phase both because there are fewer lines of 4GL code than of COBOL or PL/l and because the 4GL logical structure will be the same in all cases. When this has

been tested properly, it can be trusted

on subsequent systems. Much more significant is the effect

on maintenance. There are a number of ways in which 4GL systems will be

more productive in this area. The reasons for this are first, that the 4GL framework constrains programmers, which leads to a greater degree of standardization. This can be made even greater by the adoption of stand- ards within the 4GL so that it is easier for one person to understand (and amend if need be) another person’s

code. The reduction of the number of lines of code will reduce the mainten- ance needed. But the effect of another factor on maintenance which needs to be discussed here may be even greater.

This is the effect of the involvement of the user in the design process. Where the 4GL is used within the earlier stages of the design, whether one calls it ‘prototyping’ or ‘evolu- tionary design’, it will be found that:

there will be fewer design faults and thus fewer surprises in the final system, the speedier completion brought about by the use of the 4GL means that the system as a whole will be more acceptable.

This is because there has been less chance for the computer system to get

~0127 no 9 november 1985 001 l-684X!85/09000%03$03.00 0 1985 Butterworth & Co (Publishers) Ltd. 9

out of step with the needs of the business as can happen with (tradi- tional) longer development times.

The savings in lines of code that contribute to the productivity in the programming, testing and mainten- ance areas are likely to be in the ratio of 5: 1. This figure is based on results from a number of organizations.

Reasons for purchasing 4GL

So far these observations are general and might apply to any 4GL develop- ment. More divergence comes when considering the necessity of getting a 4GL; which of the following is re- quired?

The development of major sys- tems, where efficiency could be more important than sheer speed of development . Getting information (for display or report) which is ‘locked up’ in existing files; here one will want access to the required files or data- bases and may want friendly inter- faces so that users can make simple inquiries. Producing ‘one off systems, for which speed of development might be the main requirement.

is also necessary to decide whether the main aim is to support the ‘infor- mation centre’ or the ‘development centre’. The former comprising end user development encouraged and supported by the DP experts, the latter being development within the traditional data processing depart- ment.

With this background, it is possible to see how the evaluation process should proceed. In outline it should be first: decide what is wanted from the 4GL and examine what particular constraints there are. This can be put in the form of prerequisites or essen- tial conditions which must be catered for. (This is further explained below).

This will be used to select a shortlist of products.

Second, assess each of the products against a series of questions sub- divided into groups such as:

0 functionality 0 file handling l security l efficiency l support l reputation of software and supplier l portability l price

Not only will these groups vary, but so will the questions within each group. Another way to look at this is to put the same questions, but alter the emphasis. If desired one can have weighted rankings within each group and then set weights for each group as a whole. From this point it is often advisable to set up a pilot study comparing perhaps the top two 4GLs. They should each be tried out in the same environment given the same amount of time and the results com- pared. Unless this covers bulk data and a reasonable throughput of use, one cannot be sure about efficiency. It may be possible to ‘prototype’ part of this application to find out the infor- mation required.

First level requirements

The following questions form part of a two part evaluation carried out recently. The first level requirements were:

directly executable application sys- tems, support for specific database and software products still in use, ability to include high-level lan- guage routines (e.g. for optimiza- tion of heavily used components), suitable screen and report genera- tion, query language usable by end users, no prohibitive overheads on system throughput,

l access security, 8 still being enhanced.

These points enabled a short list to be drawn up which was further evaluated:

l functionality (30% of total weight) 0

0

0

0

0

0

0

0

0

0

0

ease of set up ease of screen design validation, including range checks and tables ability to carry out logical pro- cedures comprehensive reporting links to other languages immediate execution flexible processing rather than fixed framework ability to navigate between screens (designer decides what to do next.) suitable for prototyping

ease of learning l files (20%)

o all files available to outside sys- tems

o relational file capabilities 0 access to files from external sys-

tems o ISAM or direct access

0 security (20%) 0 file access o field level o data dictionary o satisfactory control over dump-

ing, backup, recovery etc l efficiency (10%) (in other circum-

stances this would be rated much more highly) o use of machine resources 0 use of files 0 response times

l support (5%) o documentation 0 training

0 reputation (5%) 0 supplier o product

l portability (5%) o availability on other (specified)

hardware 0 pc version

0 price (5%)

10 data processing

systems

‘3 compared to other possibles for a given number of copies

The questions themselves can be answered in a variety of ways, such as the use of consultants or other con- tacts who may have direct knowledge of the products under evaluation. A study of the suppliers’ sales material and if necessary of the reference manuals for the products will be useful to the person who knows one product and can see whether another is similar or not. Direct questioning of the suppliers may only reveal the presence or absence of a given feature

rather than its value.. The value may then be checked by reference to users of the product. Sometimes an article

in the press can contain the required information. Murphy’s Law will tell you however that the said article will be published the week after your final decision.

Each point is given a mark out of ten. Thus the first section on func- tionality has a minimum score of 11 bringing the total to 110. To get from

the total mark to the required mark out of 30, multiply by three and divide by 11. For a simple example of

how internal weighting within the

section would work, suppose the first question is twice as important as the rest, giving a minimum score of 12.

Double value is given to the whole section so the marks are out of 20 rather than out of ten, this brings the total to 120 and the factor to 3 divided by 12. This can be formalized by the use of the Kepner-Tregoe method which carries out the necessary cal- culation for each individual question, and shows the value which has been put on each question. It is not worth- while doing this unless one is particu- larly interested in these low level

values. This is likely to be where variable weighting is used to give prominence to particular aspects of the evaluation.

This enabled the shortlist to be whittled down to two, both of which competed in producing a pilot system, in two and a half days. The final choice depended on a successful volume test using a prototype system.

This can only be an outline account of one particular evaluation, but it shows that this evaluation method works.

It is hoped that this description of a

method for choosing a fourth-genera- tion language will give some hope to those who do not know how to start looking. It really is possible to make a rational choice - and given the pro- ductivity gains which can be made it is certainly a choice which every organization should at least consider.

References

1 Martin, J, Fourth Generation Lan- guages Savant Institute (1984,1985)

Further reading

Application Generation IT in the Civil Service. IT Series no 3, HMSO (1983)

Lobell, R F, Application Program Generators NCC Publications (1983)

Watts, R A, Application Generators using 4GL NCC Publications (to be published 1986) q

The National Computing Centre Ltd, 4th floor, Bracken House, Charles St, Manchester Ml 7BD, UK

~0127 no 9 november X985 11