Technical requirements of fourth-generation languages by KEITH NELSON

S hort ease

and

development timescales, of application maintenance

reduction in the known ap-

plication backlog are the selling points

of fourth-generation languages

(4GLs). Synonomous with these is the methodology of an analyst using a

4GL to prototype an application, rather than produce a detailed system specification, and then to turn this straight into a full production system. However, to be able to achieve this

and benefit from the environment for all application development, the 4GL being used must have certain manda-

tory facilities and other desirable fea- tures. The latter add the flexibility which is required to allow across-the- board applications to be developed.

One of the consequences of the great flexibility of conventional pro-

gramming languages is the potentially different quality of one program from another. This applies not only in documentation, but also in format,

efficiency and functionality. Struc-

Abstract: The use offourth-generation languages (4GLs) makes possible the development of standardizedyetflexible applications. However, a 4GL must have a number of important facilities in each of the possible components of an application: file specification, online file maintenance, data entry, file processing, reporting, queries, data transfer tolfrom other computer and application packaging.

Keywords: data processing, software techniques, fourth-generation languages.

Keith Nelson is a senior consultant with Com- puter Sciences Company Ltd.

tured techniques can help here, but the problem is just as much caused by the procedural nature of program- ming languages. Generally, 4GLs are nonprocedural, but with a procedural capability. As one is specifying ‘what is to be done’, rather than ‘how’, and as systems analysts can use 4GLs to develop systems directly, it is possible for a concept of standardized yet flexible applications to be developed. This depends on having the right facilities within a 4GL.

Fourth-generation languages are offered as individual components

(screen generator, report generator, etc.) or as fully-integrated products. Enhancements introduced into inte- grated products are available through- out the product, while highly detailed enhancements can be made to specific parts of a component-based 4GL. Also, with an integrated product you buy everything, with a nonintegrated product you can choose components

as required.

Application components

Any application consists of a number or all of the following activities:

file specification, online file maintenance, data entry, file processing, reporting, queries, data transfer to/from other compu- ters, application packaging.

By taking these in turn we can define the requirements of a 4GL for each

area.

File specification

Most 4GLs are either based upon a DBMS, often relational, or at least

operate with related file structures. Data dictionaries are also prevalent. While it is not mandatory that a 4GL operate with a DBMS and data dic- tionary, the environment which these create make it an attractive proposi- tion. While these 4GLs have been developed specifically as add-ons to DBMS, others have evolved as pure application generators. The develop- ments in both types of product are now drawing them together and we are seeing the emergence of some extremely comprehensive products.

The mandatory features of a 4GL in file specification are:

l the following data types: alphanumeric, numeric, with perhaps a distinc- tion between integer and deci- mal fields, pictured, usually implemented as alphanumeric with an edit mask, date, with an edit mask. To be able to input and output dates in different formats is highly desir- able,

l potential for large records where required,

l only a physical limit to the size of a

file,

12 0011-684X/85/090012-04$03.00 0 1985 Butterworth & Co (Publishers) Ltd. data processing

systems

l key andlor index fields, 0 automatic file expansion.

Complementary to this is a utility to introduce or remove fields in a file automatically .

Online file maintenance

Here, the requirements are

operation on a single file, specification of screen layouts, either by painting or line/column notation, specification of left and right field justification, updating, adding and/or deleting

records, multiuser protection, record lockout protection,

log changes, skip/nonskip fields, validation of fields, performance of cross-field checks, specification of a conditional cursor

movement sequence, creation of single record screens, creation of multirecord tabulated screens with headings, printing of screens, record browsing by record for- wards and backwards (for single

record screens), page browsing by page forwards and backwards (for multirecord screens), and/or, possibly scrolling forwards and backwards (for multirecord

screens),

direct access of records by typing in a key or index value.

With a nonprocedural language, the above information is usually specified either by form-filling or by question and answer. The only area where procedural code may be required is with field processing, and a more detailed requirements analysis of this area is given in the next section. To operate a file maintenance screen, a default set of keystrokes is required, which can be redesignated as neces-

sary.

An extremely useful utility in some 4GLs automatically creates a file maintenance screen. The layout is created by the utility, with the field descriptions being either the field names or ‘row labels’ taken from the data dictionary. Field validations are also as specified in the data dictionary. The only possible feature not avail- able would be cross-field checks. Such a utility is of great use to the system developer for entering test data into files, patching files and viewing files which have been input from other computers or have been processed in batch.

Data entry

Keyboard data entry is either in batch (key-to-disc type operation) or by transaction, with online file update. A 4GL must be able to provide both options. With batch data entry, we are adding records to files, but we also delete and update previously keyed records. Hence, the requirements are identical to those of the previous section plus the capability to:

l enter batch header information,

l perform totalling operations and

report discrepancies at end of

batch, l join or link to other files for field

verification purposes.

Batch header information would be entered in via a screen separate from the transaction entry screen and then re-entered after the batch had been entered. There is then a need to ‘branch’ from one screen to another automatically, for common files of the two screens to be left open and for one screen to be able to pass a field or fields to another. The latter is the concept of ‘global’ fields being accessed and updated by a suite of screens. As well as a set of global

fields per terminal, there is also a requirement for ‘system’ fields to be accessed and updated by suites of screens from any terminal, necessita- ting automatic lockout facilities. The

latter can be achieved as a shared file, but some 4GLs have this as an inbuilt facility.

File joining is one of the funda- mental requirements of a 4GL and the flexibility here influences the flexibi-

lity of the product. In file joining, we are concerned with three areas:

l when a join is to occur, l direct and indirect file joins, l the processing of joined informa-

tion.

Joins are needed when a field value is changed and the new contents are used to access a record in another file.

The accessing could also be via this field and others forming a composite key, this field and others concatenated together, or by another field or fields alone.

Joins are also required when a record is about to be displayed on the screen. In both cases the developer should be able to perform multiple simultaneous joins.

A direct file join is a simple one-to- one linkage. An indirect join is where a field or fields from one joined record are used as the key to join to a further file, etc. A further requirement is that files can join to themselves. An ex- ample of this would be an animal bloodstock file where the animal’s name, its code, its sire’s code and its dam’s code would be included in each record. To find out the name of the sire and dam we need two links to the same file, using the sire and dam codes as keys.

In the case of a join failing (i.e. there is no record with the specified key) we require the option to join to a null record, or to the higher or lower

record. The joined information can be used

in a number of different ways. It can be:

l displayed on the screen for visual verification (e.g. a customer code has been keyed in and the customer name and address are linked in and displayed),

~0127 no 9 november 1985 13

processed with other data and the result displayed on the screen (e.g. an item price is linked in and multiplied by an entered quantity), processed with other data and the result written back to the joined file (e.g. a quantity in stock is linked in for an entered part number and an entered quantity received added to this).

The latter is specific to online data entry and file update, and other re- quirements of this type of screen are:

* the ability to add records to mul- tiple files,

l the ability to delete records in these files.

Again, we wish to specify when these operations are to occur.

It is within the processing of infor- mation, and possibly performing cross field checks, that the procedural capability of a 4GL is required, i.e. where conditional logic is handled. A 4GL procedural language is normally based on a nested IF. . .THEN . . . ELSE statement, and to be really effective it should allow:

multiple statements after the THEN and ELSE, IF . . .THEN IF . . ., the normal boolean operators (EQ, NE, LT, etc.), BETWEEN . . . AND (or equivalent), and IN- CLudes or CONTains,

the logical operators : AND, OR, NOT, the normal arithmetic operators, including divide and round, possibly a GOT0 statement plus labels and GOSUB, local fields, local arrays, cursor movement statement, automatic branching statement.

Complement~g these there should be a range of subroutines, such as field concatenation, field type conversion,

string handling and location, upper/ lower case conversion and date and time arithmetic.

Other miscellaneous facilities which should be available are:

specification of ‘split screens’, i.e. the coordinates of a rectangle of a screen. (These can remain on the screen when a branch is made to another split screen), field duplication, specification of 132 column wide screens, automatic cursor movement to the next editable field if a field is filled on data entry, passwords on screens, no echo-back of an entered field, ability to send messages to other terminals or screens.

Extremely useful facilities are:

l conditional field highlighting (double intensity, blinking, etc. plus colours),

l timeouts on screens (i.e. if a key is not hit for a specified period of time, the screen logic is automatic- ally activated).

File processing

File processing splits into three areas, as follows:

l update of a single file, * update of one or more files using

data in another, l creation of sub-files and sorting.

SingEe file update

This is where the procedural capabi- lity of a 4GL is again required, as facilities must exist to execute a pro- cedure against all, or selected, records of a file. An example would be effect- ing salary increases according to grade, experience and performance. Technical requirements in this area would be the option to perform serial or direct access, the ability to exit when required, the ability to add

records to a second file and operation of the facility in test mode. A useful extra is the ability to backward or forward space records from the pro- cedure.

This is the batch update of files where a file of records entered in batch is read serially, and fields in each record are used as the key to access a record in a second file. The accessed record is then updated with data held in the batch record, according to the logic of a procedure. An example of this would be updating a customer file with payments received.

This is a basic mandatory facility of a 4GL. Further extremely important requirements are the ability to update more than one file at the same time and the ability to update indirect files (i.e. perform indirect joins).

Sub-files

Mandatory requirements here are:

the ability to strip out a number of fields of a file into a new file which is to be processed elsewhere, pos- sibly offsite, the ability to directly or indirectly join two files and strip out fields from both files into a new file.

The ability to execute a procedure with these operations is an added bonus.

Reporting

There are two basic types of report: tabulated listings and cross tabulated summaries. Tabulations consist of page headings, subheadings, subtotals and detail lines. The mandatory re- quirements of a 4GL here are:

direct and indirect joins, plus join- ing one record to many records with the same key, creation of local fields, preferably via the procedural language,

14 data processing

systems

sorting into virtual records, selection of records for printing optionally through serial or direct

access, many levels of subtotalling, subtotalling operations to give total value, average, maximum, mini-

mum, number of occurences, first and last values of fields,

sub-totalling at sort field change, partial sort field change (e.g. month changes in a date), after n records, at bottom of page, and at end of file, omission of the detail lines, i.e.

subtotal lines only are printed, multiple detail lines (enabling let- ters to be output)., ability to specify right and left justification of fields, automatic page numbering, text and data on same line,

eject before or after printing totals, inclusion of data fields in page and subheadings, override capability of any default settings for page width, length and indentation,

ability to output a report to any printing device, VDU or magnetic tape or as a tex.t file (enabling letters to be printed via a word processing utility),

l parameterized reports, i.e. the

operator is prompted for values when the report is run,

l store parameterize’d reports for fu- ture execution.

For cross-tabulations we require a

4GL to:

produce row and column totals, perform any of the totalling opera- tions specified above at the row1 column intersections, perform multiple totalling at the

intersections, total locally created fields.

type of cross-tabulation, but with- out any totalling, is mailing labels, and again the facility must exist for these to be produced.

Desirable features of a 4GL report generator are:

suppression of totalling when there is only one detail line, no printing of text associated with data if they are on the same line and the data is blank, specification that numeric fields be printed as blank if they are zero, specification that numeric fields be printed with or without punctua- tion,

scaling and rounding of numeric fields, report prefacing.

Queries

Queries fall into two categories:

l fixed queries which are a specified

part of an application, l ad hoc queries.

Fixed queries normally take the form of screen-based tabular listings, with user selection facilities. A user should be able to move the cursor down a list, ‘point’ to a particular line and manu- ally branch off to another screen which displays more details of this line, as a single record display, as another tabulation or perhaps as a graph. Groups of these screens can be created, giving users the ability to browse through their files. This is

considered to be a mandatory require- ment of a 4GL. The ability to produce different types of graphs is also con- sidered desirable.

Ad hoc queries are normally handled via a special query language available with a 4GL, or by the report generator, if that is sufficiently user- friendly. As this paper is concerned with application development tools, the requirements of a query language are not covered, except to say that IBM’s SQL is emerging as a standard in this area.

External files

This is an area not often covered by a

4GL, as suppliers recommend that the facilities offered by the operating

system be used. The requirements here are:

copying of files to magnetic tape, reading of magnetic tapes, conversion of files from one format to another, reading of text files into data files.

The specific facilities required of a 4GL or operating system would be the ability to read and write magnetic tapes coded in ASCII or EBCDIC, which are blocked or unblocked, labelled or unlabelled, and handle variable length records.

Conclusion

In describing the technical require- ments of a 4GL no mention has been made of any specific application, other than references for explanatory reasons. Any application can be broken down into the components described above and a comprehensive 4GL is comprised of most or all of these components, all prebuilt. Such a 4GL can then be considered as an empty application shell, the holes being filled with data, input, output

and processing formats. This leads to the concept mentioned earlier of standardized applications and for this to be possible a conscious radical rethink by data processing profes- sionals is needed. Conventional

methods, using procedural languages, have rarely produced applications which meet user requirements. Com- prehensive 4GLs, especially used in a structured and planned environment, have rarely not produced the required results. 0

Computer Sciences Company Ltd, 21 The Arcade, The Octagon, High Wycombe, Bucks HP11 2HT, UK.

vol27 no 9 november 1985 15