Languages and programs:Fourth generation programming languages

Fourth generation programming languages

Fourth generation languages (4GLs, for short) have recently appeared. They are even further removed from the level of the machine than the third generation languages described above. With these, it is not necessary to specify how to carry out tasks, but what tasks need to be done. The detailed procedures - such as those in the rudimentary invoicing program shown in page 94 - are to a large extent generated by the language itself.

Fourth generation languages are invariably incorporated within database packages, and are used for record-keeping and other information management applications. For example, keeping records on d BASE, the world's most widely used database package, involves programming in a 4GL. Typical commands are:

LIST FOR AMOUNT > 10

which will display those records with more than £10 in the field labelled AMOUNT, and

SUM AMOUNT FOR DATE '020491'

which will add up the values of orders received on 2 April 1991.

Fourth generation languages have become popular as they cut down significantly the programming time.

Program generators

Programming is a time-consuming and skilled job, and the cost of writing program code can be very high. Furthermore, the programs will normally contain errors ('bugs'), and will require extensive testing to find and remove these. Program generators, which automatically produce the program code, are a solution to this problem.

If you use the latest version of d BASE, called d BASE IV, you can use its system of menus (the 'Control Centre') to produce record-keeping applications. You simply tell it

what tasks you want carried out by selecting options from the menus, and d BASE produces the code. It takes only a few hours to learn to use the Control Centre, compared to weeks to learn to use the d BASE programming language, and it takes only a few hours to create quite complicated (and bug-free) applications using this method.

However, the Control Centre suffers from defects which are common to other program generators:

• You can't do everything from it, so for some tasks a knowledge of dBASE programming is required.

• The Control Centre does not necessarily produce the most efficient programs.

Programming

In business, the purpose of writing computer programs is to automate information systems within the organization. In this context, producing a computer program involves the following steps:

1 Defining the problem.

2 Designing the logic.

3 Coding.

4 Testing and debugging.

5 Writing the documentation.

Let's look at each of these.

Defining the problem. This involves specifying the inputs and outputs of the system, and the data that must be stored in it. This has been dealt with already (see page 19 at the end of Chapter 1); in large organizations, problem definition is carried out by systems analysts.

Designing the logic. This involves producing an algorithm of some sort that specifies the tasks needed to produce the outputs from the inputs and the relationships between them. An important part of this algorithm will be the branching that has to take place when various conditions are met (see page 82). One way of producing an algorithm is the flow­ chart, described later.

Coding. This involves using a high-level language (or a program generator) to produce the source program. In the case of large applications, the proposed program will have been split into modules at the algorithm stage, and each module will have its own algorithm and will be programmed separately from the others. When these modules have been tested and debugged, they will be combined to produce the final program.

Testing and debugging. Each module- and the complete program - must be thoroughly tested to identify errors, and these must be removed. Sometimes, this process will take more man-hours than the original program writing. Initially, this will normally involve using the programs to process test data prepared by the systems analyst. The outputs produced are compared with the expected outputs, and any discrep­ancies investigated. When the program modules have been amalgamated to produce the final software, this will also need testing, to check that data is being correctly passed from one module to another. Modern software is so complex that extensive further testing is required, and users will be asked to try out the software over a period of several months and report back any problems they are experiencing. This second phase of testing is called beta testing.

Documentation. Various kinds of documentation are needed to support business software:

• Program documentation, which describes the logic of the program, its division into modules, and what each step in the program is doing. This is needed to aid debugging and to facilitate future revisions of the pro­ gram. Many languages allow much of this documenta­tion to be incorporated in the program itself, in the form of remarks, and, if good programming practice has been followed, the overall design of the program should be such that its structure is apparent.

• The systems overview, which outlines for the benefit of senior management what the system will do.

• The systems manual, which explains in more detail the facilities that the software offers and how to use them.

• The operating manual, containing a list of all questions that might be asked by the computer when running the software, together with an explanation of each question and the range of acceptable operator responses.

• The error manual, which lists the error messages that might be produced by the system and the appropriate operator responses.

In practice, some of these manuals might be combined. When you buy an application package for PCs, the manual(s) will normally be an amalgamation of the last three, together with a tutorial guide. The all-important program documentation will have been produced, but will remain with the software house.

Structured programming

One of the criticisms of BASIC in its original form was its weak control structures, which mainly depended on the use of GOTO to force branching. The GOTO statement is fine for small programs. Once the program gets beyond a certain size, however, a large number of GOTO loops will become necessary, resulting in a disorganized structure that becomes very difficult to unravel. This is sometimes called 'spaghetti programming'. Furthermore, the use of GOTO to force branching means that it becomes difficult or impossible to break the program down into self-contained modules.

The programming language PASCAL, favoured by many universities and colleges as a teaching language, avoids the use of GOTO by the use of statements such as DO ... WHILE and REPEAT . . . UNTIL. Later versions of BASIC also incorporate these statements, and so get round the problems caused by GOTO.

Breaking down a programming problem into a set of self-contained modules is part of what's called structured programming. Each module can be considered as a subsys­ tem of the wider system which is the program, and will take inputs (i.e. data) from other subsystems and will produce outputs (data) which in turn are used by other systems. The modules are therefore linked by the data that passes between them.

Flowcharts

I've said that flowcharts are one way of producing a program algorithm. In programming, the main flowchart symbols are

as shown in Figure 4.2. Figure 4.3 shows how they might be used to produce an algorithm for a simple invoicing pro­ gram. If you work through this flowchart, you will see that the program will:

• Input to the computer the price and quantity sold of an item.

• Multiply the price by the quantity to get the amount charged.

• Add this amount to the invoice total so far.

• Repeat this process for each item sold.

• When all the items have been input, add 17.5% VAT to the invoice total and print the result.

(This simple program could be easily extended to input the description of each item, and to print the description, price, quantity, and amount of each to produce something resem­ bling a proper invoice.)