AIDA's fourth-generation software functionality

Computer Methods and Programs in Biomedicine 25 (1987) 245-258 245 Elsevier

CPB 00894

AIDA's fourth-generation software functionality

Berend Franken 1,, Joop S. Duisterhout 1, , Frans S.C. Witte 2 and Jan H. van Bemmel 1,

I Department of Medical Informatics, Erasmus University, Rotterdam and 2 Dutch Information Consultingo Maarssen, the Netherlands

Aspects characterizing typical, office-like environments are described and common procedures are extracted. These are used to derive the requirements of fourth-generation software packages. Typical fourth-generation software packages are discussed, and a presentation is given of a fourth-generation software package called AIDA, including all its functional aspects.

DBMS; Information system; Fourth-generation software; MUMPS

1. Introduction

Fourth-generation software (4GS) packages are successors of the 2GS and 3GS packages~ also called source programs. There are two different views on dividing software into so-called software generations.

In the most frequently used view, the first generation is concerned with the programming of computers at the lowest possible level: machine code. All instructions are directly fed into the computer, and are ready for direct interpretation. The second generation is the group of assembly languages. These languages use mnemonics, which are easier to memorize than (numeric) machine code. The third generation introduces the concept of source languages. Examples of these languages are COBOL, FORTRAN, ALGOL-60, MUMPS, BASIC, PL /1 , Pascal, PROLOG, R T L / 2 , C, Forth, etc. These languages enable the user to structure his programs in terms of algorithms and let the compiler do the re-coding into machine

Correspondence: AIDA Group, Department of Medical Infor- matics, Erasmus University, P.O. Box 1738, 3000 DR Rotter- dam, The Netherlands. * Formerly at the Free University, Amsterdam.

code. The third generation operates on the level of programs (or functions, or (sub-)routines), in con- trast to the level of complete systems or applications. A nice overview of especially the third generation (plain programming languages) is presented in [1].

In the area of development of complete systems, it was quickly realized that, if strict project management is not available, programmers will generate time and again their own functions, routines and programs, instead of using program parts developed previously by others. Data created by one person can only be used by another person if strictly formal agreements are made: when a change is made by the first party, the second party has to make changes as well. A way to develop complex systems by source languages was offered by Dijkstra's structured programming [2].

The fourth generation is concerned with applications as a whole. It deals with the overall environment of an application, and not parts of it. Therefore, program generators are not necessarily 4GS.

The second explanation of the four generations puts machine code and assembly language at the same level: generation one. This is because assembly language typically does not add any function-

0169-2607/87/$03.50 © 1987 Elsevier Science Publishers B.V. (Biomedical Division)

246

ality to machine code, but just makes it easier to read; the programming concepts for both are the same. Traditional (source) programming languages now drop to the second generation. The third generation, however, in this view is software packages, used for a broad general purpose. Ex- amples are statistical packages such as BMDP [3] and SPSS [4]. The fourth generation remains the same in both explanations.

In this paper, the insides of 4GS are discussed. In Section 2 it is elucidated that 4GS is used in interactive environments, by a mixed group of end-users, where the quality and security of data is of considerable importance. In Section 3 the various functions in these (potential) environments are discussed. They concern data acquisition, data storage, data processing, selection, formatting and data security. These functions are used as a description for the functionality of a 4GS package. Based on this, a description of the fourth-generation software package AIDA is given.

2. 4GS environment

4GS packages are used at places where dedicated standard software cannot be used. The personal computer (PC) greatly contributed to the prolifer- ation of standard software packages, that are gradually becoming more powerful. Standard software is software aimed at a limited but common work .area. Nowadays it is generally in the category of financial packages, statistical packages, simple graphics and limited database activities. When such standard software suffices, there is no need for 4GS packages. Also, 4GS packages are not commonly used in dedicated, not generally spread work areas, such as process control, or computer-assisted design, manufacturing, en- gineering and instruction (CAD, CAM, CAE and CAI, respectively). This leaves an intuitively well- defined area for applicability of 3GS packages, characterized by several features: (1) If the area to which the system is to be applied is standard, a standard package can be chosen. (2) If the area is highly specialized, a 4GS does not suffice, and a tailor-made system must be made.

(3) When there is not a considerable common data flow, there is no need for computerized support. (4) When there is only one user at hand, a simpler approach would show a better cos t /benef i t ratio. (5) The 4GS approach can be relatively cheap, as expensive programming experts are not needed, or needed for a shorter period of time. Lack of funds may dictate the choice of a simplified system made using 4GS tools, rather than a fully dedicated system, which is too expensive. (6) While previous software generations have their programmer interface at the level of programs (being less flexible to change), 4GS has its interface at the level that defines all underlying concepts (the complete application), so a change in definition will automatically be transferred to all applicable places in the system. (7) Interactive systems more often require different user-views of the database (the DBMS is one of the main characteristics of a 4GS package). (1) The area is not standard. (2) The area is not highly specialized. (3) Within the work area there is a considerable common flow of data. (4) There is a relatively large number of users of the same data. (5) It is too expensive (or funds are simply lack- ing) to have a tailored system made. (6) The environment is changing dynamically, and these changes are reflected in the application, which is to be adapted continuously to the new situation. (7) The degree of user-interaction is high. These points are also pictorially illustrated in Ta-

TABLE 1

Comparison between 3GS (from the second definition) and 4GS, in terms of applicability in the work area (H = high, M = medium, L = low)

Software features Packages 4GS

(1) Standardization H L (2) Specialization H M / L (3) Data flow L / M H (4) Number of users L / M M / H (5) Tailoring L M / H (6) Adaptability L H (7) User interaction L / M H

ble 1. This list is probably not complete, nor are the points mentioned of equal weight, but it gives some idea in what kind of an environment 4GS packages can best be expected or used. The different examples of systems in this issue speak for themselves.

The product of a 4GS package is an application (generally called a system). Within this application, data can be entered, checked, stored, retrieved, maintained, reported, formatted, etc. Data are basically available for anyone as far as protection schemes allow. In other words: data are shared. Data may be related to any subject: per- sonnel files, medical records, debtors, open orders, test results, etc.

The manual way of processing such data is recording them on cards, or on sheets of paper kept in folders, and alphabetically stored in file drawers. The storage itself can be a drawback in the common situation: everything is stored at one location only, can be traced back through one key, and when different accesses are required, separate index files must be maintained manually. Another disadvantage of the manual procedure is that there is usually only one copy. When somebody has borrowed it, it is inaccessible for others. More- over, when it is lost, it is lost permanently. Solu- tions such as providing extra copies are expensive and space- and time-consuming. A centralized archive (e.g. departmental or hospital-wide) collects basically all (original) data available. Various users keep their own archive, sometimes deriving data from the central archive, modifying it and keeping it to themselves. This aspect has two potential dangers: data redundancy and data pollution. With data redundancy is meant that data are stored several times at different locations. When its actual value is changed, it should be changed at all these locations; needless to say, this is seldom the case in reality. Data pollution takes place, for instance, when data are used for further calculations. Often, when computing is done by hand, errors are introduced. The number of errors made by professional nurses in computing a patient 's age on the basis of a birth date is one such an example. In such situations, a central procedure could better be performed by a computer for the benefit of those who want to use it. The reliability

247

of computer-stored data is, for instance described in Komarof f [5], Van Hemel [6] and Westerhof [7].

This brings us to another aspect of data collec- tion and its further use. Higher executives normally are not bothered with details; manual files, however, contain all data on a subject, on a de- tailed basis. The executive is therefore required to scan the file and pick up what is considered important: the data has to be interpreted. This is done at practically every level in a working environment. In short, whereas paper archives are static, computer-based archives (such as in a 4GS environment) can more easily be presented in various ways: a different view for every user.

Last but not least, there is a physical problem (a logistic one, to be more precise). Besides the fact that paper, or even microfilm archives con- sume space, the distribution of (parts of) a file is a serious problem. Even electronic archives do not always offer a solution, but with the 4GS approach it can more easily be handled, as it views upon an application as a whole.

3. Data processing procedures

There are general comments that can be made on the procedures that can take place on data: data are acquired and stored; transformed to suit a certain goal (that representation may be modified, or new data are derived from original data); data are displayed or printed. This output may be of a simple structure ("give me all data on patient X, or on supplier Y"), or of a more complicated one ("show the names and ages of all surgeons who performed appendectomy on patients which stayed in the hospital for longer than one week"). The accessibility of data should be safeguarded against abuse. Common procedures must use the same path to ensure that the same activity on the same data at different places show identical results.

We will briefly comment on these activities on data, in order to be able to see the consequences for the 4GS approach.

3.1. Data acquisition

Data are acquired from a large variety of sources. They may come from subjects (people); from a

248

unit responsible for the subjects (goods from a supplier); acquired during a test (laboratory data); derived from other data; received from another institution (governmental data), and so on. The reliability varies with the responsibility the data supplier feels for giving correct data, and the gain he would have or not have when supplying erro- neous data. The reliability also depends on the process of transcribing the data into the (machine-readable) files.

3.2. Data storage

Storing data may look simple. (Manually docu- menting a folder and inserting the folder at the appropriate place in a file drawer.) However, the 'appropriate location', also when automating, is not as obvious as it may seem. As mentioned before, various users have different views on the data. (Management in health care is interested mainly in data for planning and reporting; professionals (physicians, nurses) in medical data, pre- ferably on a subset for their own purposes; and service departments (laboratories) want to access the data in a third way, related to production, efficiency, etc.) The frequency of changing data needs increases with the hierarchical position of the data requester, and aggregation of data and storage thereof is usually required at higher levels of authority (management overviews).

3.3. Data processing

Most data are collected with a distinct purpose in mind and not just for having them available for a future, as yet unknown use. Data processing can comprise various aspects, such as simple calculations, trends, or statistics. Often data are used in conjunction with other data. Sometimes data have to be pre-processed before calculations can take place. Often, computed data must also be stored for later use. Standardization and checking (quality control) are important processing features that should be performed in daily practice.

3.4. Data retrieval

When all data have been acquired, stored and processed, they need to be retrieved from wherever

they are stored. The user needs to select data, which have to be presented to him in a user- friendly manner. In a manual system only selections can be made that were previously taken into account: from index files that are maintained on various subjects. In automated databases, query languages are often available for retrieval purposes. Even today, data selection is not always as flexible as it should be; certainly not for research, where only in the course of a project does it become clear which tests should be done. Some- times the data retrieval facilities are so flexible that many users are to be protected against retrie- ving too much data in a too complex way at one time, and too easily connecting conclusions to them.

3.5. Data presentation

When the data have been extracted from the files or databases, the data are offered in a distinct format. Typical examples of data output are summaries (aggregated data), compact data sheets (recorded or abnormal data values only) or graphical representations.

4. Software functionality

4GS tools need to meet the requirements discussed above, as will be discussed briefly in this section.

4.1. Input

A 4GS package should be able to perform data input tasks. These tasks should at the same time perform basic error checking. With them, it should be possible to catch impossible values and trigger unlikely ones. Values which are impossible in relation to the values of other available data, should also be trapped, if at all possible (e.g. male patients cannot get pregnant). Basically, data-input processes should perform validation checking. All of this should be possible using various user-views. This implies the possibility of adapting screen layout, and sometimes the use of different types of input (e.g. optical mark sense form readers, mag- netic badge readers, or bar-code readers).

4.2. Storage

When 4GS packages perform data storage, the internal storage can be kept invisible to the user. Each user should be allowed to have his or her own 'external' view of the database. When the structure of the database is changed, all different views should be altered automatically by the 4GS package. The internal structure is called the conceptual model, and the user's view is the external model. The data storage part of a 4GS package takes care of the mapping between conceptual model and the external model (and vice versa).

One of the most important features of a database management system is the protection against disasters, corrupting the database or its structure, and hence making the stored data inaccessible. The classical approach, called logging and recovery, keeps an up-to-date report (log) of all activities which have changed the database (new data stored, data modified, data removed, struct- ural changes). This log may be used to update an older but correct copy of the database, up to the moment just prior to the database corruption, and thus recover the database. In this way, no or hardly any data will be destroyed. Another approach is the use of two identical disc drives, which are written to simultaneously. This is called the mirrored database; usually, the hardware should have this capability, rather than the soft- w a r e .

4.3. Basic operations

A 4GS package should feature certain operations which may be performed on the data. For example, it should be possible to calculate the time between two distinct days (age = t o d a y - birthdate). Sometimes, time-oriented recordings are made, and only the mean value and the standard deviation are stored. Here the original data are lost, which might be regrettable if one desires to make a trend analysis afterwards. Here, an easy-to-use facility to calculate the mean and standard deviation could prove helpful.

4.4. Data selection

The selection of data for output is an essential part of a 4GS package. The functionality can be

249

described at three distinct levels. The lowest level is an absolute necessity and

the other two are helpful. At the first level, it should be possible to make comparisons between stored data values and 'hard figures' (NAME = "Johnson" or SALARY > 24000) and between stored data values themselves ( T E L _ E M P L = T E L B O S S or P A T I E N T _ W A R D = SPECIALIST_WARD). The processing of such questions is relatively simple, as stored data can be compared directly. At the second level, more complex questions can be asked, where the computed value is used in comparisons. An example was already given above: "show the names and ages of all surgeons who performed appendectomy on patients who stayed in the hospital for longer than one week". Here the length-of-stays for all appendectomy patients have to be computed before a comparison with the figure 7 (7 days = 1 week) can be made. These selections are likely to be more time-consuming. Finally, at the third level, comparisons are made, based on the availability of stored data. An example might be: "show all customers which have not ordered anything this year", or an example in the medical area: "show all patients over 55 years of age, who have had no blood pressure recorded this year".

4.5. Output

Historically, output formatting is one of the oldest activities in automatic data processing. The language RPG (report generator) [8] exists since the early sixties. Data structures of the more classical languages are derived from the capabilities of recording and printing devices (viz. the 'common' maximum record length of 80 (punch cards) or 132 bytes (line printers)). Report generators can, theoretically, produce two types of reports. The first type is a tabular output form where all values of selected attributes are produced in columns. Such reports are typically dumps of complete sets of stored data, such as overviews of treated patients, where each line represents one day in the month, and the columns represent the figures for the various treatments or tests. The second type is a more extensive overview of a smaller amount of data, for instance of one line of the previous

250

tabular output; this output more resembles standard correspondence. One page of output could, for example, contain all data of a patient's ex- amination to be sent to the general practitioner.

5. Functionality of AIDA

In the previous sections, the typical environment of the use for a 4GS application was described, followed by a discussion on the common procedures in such an environment, and the requirements for 4GS.

In our department, a 4GS package has been developed. The package is named AIDA (Auto- mated Interactive Design of Applications). In this section, the functionality of AIDA will be described, starting with an introduction and then discussing separate parts of AIDA.

5.1. Introduction

The development of several parts of AIDA started already in 1978. In 1983 it was decided to con- verge all developments into one direction, thus leading to AIDA. AIDA is in use at several locations both within the Free University and out- side, some of which are commercial.

In the following sections, the separate parts of AIDA will be discussed. We distinguish between seven groups of tools; four primary and three secondary (Fig. 1).

AIDA is entirely written in MUMPS, and ex-

AIDA/Input

AIDA/query

I AIDA/repor t

Pr imari,, Toois

A I D A / m e n u ]

A I D A / s o u r c e [

AIDA/util ity ]

Secondary T o o l s

Fig. 1. The constellation of AIDA tools. The primary tools handle data (arrows indicate the 'normal ' data-flow), while the

secondary tools are necessary as support.

cursions to the host language are extremely simple, as AIDA is not a closed tool-kit, like some other 4GS packages. Excursions are often used to increase flexibility and sometimes speed, and to implement certain non-general functions in a standard way (i.e. at places where they may be expected, and hence can be found later).

AIDA features self documentation, implying that the vast majority of all application building by AIDA is readily documented, once it has been defined. The backlog in writing application documentation is thus significantly reduced.

5.2. AIDA / dbms

The group A I D A / d b m s is the core of AIDA. A I D A / d b m s consists of four tools: DICAID, DI- RAID, TRAID and IOAID, for data dictionary, data directory, transaction definition and database I /O , respectively, plus two other tools for logging and recovery (LOGAID and RECAID).

The data model used in AIDA is the relational data model [9]. This may be conceptually viewed as multiple tables, in which the data are stored in various tables. All data of some instance (e.g. patient administrative data) are stored in one line of the table. Each line is uniquely addressable by a (combination of) attribute(s) in the line. For instance, a line may contain PATIENTNUMBER, PATIENTNAME, PATIENTADDRESS and PA- TIENTTOWN. Such a line is addressable by PATIENTNUMBER (given that no two patients have the same number). We call the attribute which can be used to identify one line the key attribute. A table (or relation) may have a combination of key attributes; in this case the key is called composite key. With DICAID, the attributes are defined (data dictionary), and with DIRAID the structure of the tables is defined (data directory).

With TRAID, it is possible to define mappings between the external and conceptual models. The transaction definitions of TRAID are u s e d by IOAID to do the actual database I /O. The I / O routines can either be table-driven, for prototyping purposes where only a change in a transaction definition will cause the system to react differ- ently, or can be used as generated code, which

operates faster in the production environment. The logging and recovery tools (LOGAID and

RECAID) were available under a earlier version of AIDA, and are currently under re-construction, in order to operate with the newest structures.

5.3. A IDA / input

A I D A / i n p u t consists of one tool, FRAMAID, which is a flexible and interactive user interface, with which dialogues can be put together. As is common with most AIDA tools, it consists of two steps: definition and usage. Screen definition is fully interactive. Screens can be filled with as many question and answer fields as are necessary. Positioning of the question and answer fields on the screen is done with the arrow keys nowadays found on any keyboard, and does not require calculation of field coordinates by the user. ,The text for the question and the length of the answer field are copied from the data dictionary, and hence do not have to be entered here. The se- quence in which the questions have to be answered can be left free or defined in any desired order. Fields can be specified as output-only, so that the user cannot enter data, or even be mandatory, meaning that the user cannot pass without giving an answer; by default, fields are optional and for both input and output. At any instance, a call to a custom function can be made, in order to, for instance, do a database access, validity check, etc., or display on-fine help text on the field in question.

The result of a user dialogue is generally an array with answers which may be used for any kind of action, such as a database I / O operation.

Pre-release versions of AIDA also had another tool in the A I D A / i n p u t group, with which optical mark-sense forms could be read (OMRAID).

5.4. AIDA / query

A I D A / q u e r y consists of one tool. It is estimated that the retriever (RTRAID) is capable of carrying out about 95% of all queries. It enables the user to specify a list of attributes he wants to see (the target list) and a criterion, with as many as ten concatenated sub-criteria, using brackets, ANDs

251

and ORs. At the moment, RTRAID can be queries of the first level (see above), but in the future the second and third levels will also be covered.

Another tool, strictly speaking not part of AIDA but related to AIDA/que ry , is QUAID. This tool can be used for searchers in large databases, as it selects by itself the optimal access path based on statistical information on the data in the database. It is hoped that it can be used to solve those queries that RTRAID could not, or only could with great difficulty. For the user, RTRAID is easier to use but not very efficient; Q U A I D is more difficult to get acquainted to, but more efficient in terms of speed.

5.5. AIDA /report

When all data have been entered and stored, A I D A / r e p o r t can be used to produce output. A I D A / r e p o r t consists of one tool, REPAID, which produces tabular output of selected rela- tions. Which attributes are selected for output is determined during definition of the report. The order of the columns is defined by the user. Sim- ple statistics (total, mean, variation) are supported. In terms of layout, options exist to skip one or more fines or generate a new page when one of the key attributes changes of value. This change of value can also be used to trigger the above-mentioned statistics (sub-totals, statistics per sub-group). When output is too wide for one line, REPAID Will jump to a new line. Column headers are copied from the data dictionary and printed on top of every page. Also, column widths can be manipulated to customize the output.

5.6. AIDA / m e n u

Selection in the multitude of available functions in an application is done with the COMAID tool, of the A I D A / m e n u group of tools. This tool resembles a menu-driven structure (see above), but also has the advantages of conventional command language approaches. Pure menu systems show menus from which a choice must be made. This choice then leads to another menu where, again, a choice must be made. This may be repeated over and over. Navigating through menus resembles travers-

252

ing through a tree. Quite often, it is hard to see how one got to some menu, and how the next function must be called.

This process may become rather tedious for the experienced user. Especially the fact that users no longer know where they are in the tree of menus, can be quite frustrating. The conventional command language approach enables the user to select the desired function in one pass only. A disadvantage of this approach is that users tend to forget the existence of infrequently used functions, because they had to memorize all available choices.

COMAID has combined those two approaches in a command tree interpreter. Commands are structured in a hierarchical form (like a tree), and the system shows at any level the list o f available choices on request. Commands can be given in one pass, but selections can also be made by traversing through the tree, step by step. The usually unlimited depth of structures in most menu systems has been reduced to four levels at maximum. This restriction increases the chance that users can memorize the more frequently used selections; longer 'paths' are harder to remember, no matter how often they are used. In our daily experience, the restriction to a maximum of four levels is no problem (in fact, it took a year and a half before anybody used all four levels, as only then did an error in coding the fourth level surface, showing that nobody had used a four levels).

5. 7. AIDA / source

The AIDA/source group features several functions for the AIDA user who wants to build an application. Three tools are available in this group, all dealing with manipulation and control over routines that can be called from various parts of AIDA. In fact, they provide a full environment for programming in MUMPS, AIDA's host language.

The first tool in this group is the source editor EDAID. This tool enables the programmer to create, manipulate or control his program sources. It has multi-file editing capabilities and features a full-line editor.

The next tool in this group is LOADAID. This is the program loader of AIDA. Though MUMPS programs are basically interpreted, implying that

no compilation of the source text should have to take place to run-time module, AIDA has a series of loader directives, by which it is possible to copy complete parts of other sources into the source file (include files and macro inclusion with parameter substitution). Load-time string substitution is also a frequently used feature of the AIDA source control tools.

The last tool in this group is the program lister PLAID. This tool gives a complete listing of selected programs in various available output for- mats.

5.8. AIDA /ut i l i ty

The 'remainder group' of AIDA is named A I D A / utility. Two tools are currently available here: TERMAID and UTILAID. The former handles settings for several types of terminals that can be used in conjunction with AIDA. With TERMAID other terminals can also be defined. These definitions are then used by various tools to perform the input and output in a proper way: AIDA is termi- nal independent. The second tool, UTILAID, con- tains utilities, such as date and time conversions and similar actions. This is a typical tool that is continuously expanding.

6. How AIDA is used in practice

Table 2 shows the various AIDA tools, and the medical applications which have been built with (parts of) the AIDA package.

6.1. Comparison with other 4GS

Comparing software products is difficult, since the degree of experience and perception in the various products may differ significantly, and if one of the packages is one's own product, objectivity is practically always biased. However, when discussing with outsiders the benefits of AIDA, they always require the outcome of some comparison with other packages they know themselves better; no doubt, the reader will also require such a comparison.

In an attempt to preserve some objectivity, we

253

TABLE 2

Inventory of the use of AIDA tools by medical applications discussed in this issue (0 = intensively used, O = moderately used, • = (almost) not used)

Groups/tools Application

Pharmacy General Neonatology ICU Expert Quesion- Training Fertility practitioner ward systems naire and edu- department

cation

AIDA/dbms DICAID DIRAID TRAID IOAID

AIDA/input FRAMAID •

AIDA/query RTRAID

AIDA/report REPAID

AIDA/menu COMAID •

AIDA/source EDAID 0 PLAID 0 LOADAID •

AIDA/util i ty UTILAID TERMAID •

• • • • 0 • •

• • • • 0 • •

• • • • 0 • •

• • • • 0 • •

0 • 0 •

0 0 •

0 • • • 0 0 • • • • • • • •

• • • 0 0 0 • • • • • • •

have taken the results of a comparative market survey, done by an independent body, and added to that the comparable values for AIDA. We were surprised when AIDA did much better than we expected.

Before we show the comparison, we will briefly introduce the various 4GS packages we have taken into consideration (most of this material stems from [11] and [12]).

6.2. The Application System

The Application System (AS) is IBM's primary strategic product for end-user computing. The product enables a business professional to access data in a relational database and to manipulate

those data using a variety of tools. AS can be used to produce exceptionally attractive graphic charts. The product includes tools for many functions, including the following: data management, information retrieval, report generation, chart generation, business communication, project management, statistical analysis and forecasting, financial modeling, business planning and programming by end-users.

AS operates in the VM/CMS, MVS and M V S / X A on IBM and IBM-compatible mainframes. Support is also provided for the SQL/DS and DB II relational database management systems. AS was originally a mainframe facility designed for the 3270 family of display terminals and has been extended to support high-

254

resolution graphics using the 3179, 3279 and 3270PC devices. AS began as part of a time-sharing service offered on the IBM Information Net- work, a data communication value-added network that has been marketed by IBM since 1982 and is still offered on the Information network.

6.3. Focus

Focus, from Information Builders Inc., is a versatile fourth-generatioff language for the IBM environment. Focus provides an impressive range of integrated functions, including report generation, database query, screen generation, graphics, financial modeling and general application development. A full-function version of the tool, known as PC/Focus, is also available for IBM and IBM-compatible personal computers and for the Wang and Texas Instruments professional computers. In its manuals, Focus is accurately described as a "comprehensive information control system", the main purpose of which is to control the entire application-development process and replace conventional computer programming wherever possible.

Focus supports a broad range of users. Non-technical professionals can use either the personal computer or the mainframe version of Focus to access database, produce reports and graphs and build simple applications. Data processing professionals can use the full power of Focus to build complex, multi-user, on-line applications.

Focus provides excellent human factoring and supports many different types of end-user interfaces. The user has the choice of natural English via an interface to Intellect, menu structures or a command language with procedural statements. Focus is a product that has had significant success in the market place, with over 1000 installations.

Focus is designed to run on IBM and IBM- compatible mainframe computers in any of the major IBM operating system environments. In addition to supporting all the various teleprocessing monitors. Focus can also run in batch mode. The product is also available on the TYMSHARE time-sharing network under VM and on many other major service-bureau machines under TSO. As mentioned earlier, a full-function

version of Focus, known as PC/Focus, is available for various personal computers.

6.4. Linc

Linc, developed by Burroughs Corp., is an application generator, primarily for data processing professionals. It is designed for use on the Burroughs B1000 through B7000 running under MCP 11, MCP IX and MCP VI.

The Linc product is a high-productivity tool that operates exclusively in the Burroughs environment. Linc provides an integrated application development environment, consisting of a DBMS, a command language, communication facilities, network management facilities and a database query language. Unlike other 4GSs, Linc builds on a base of COBOL. It uses COBOL as its procedural language and augments COBOL with higher-level commands and non-procedural functions. The objective of Linc is not to replace COBOL but to augment its capability by providing high-level access to commonly used functions.

Linc is composed of an integrated package of major Burroughs software facilities, including also the customized communication facilities provided by NDL (Network Definition language), CANDE (Command and Edit) and GEMCOS (Generalised Message Control System). The user interfaces to the system via the Linc Definition Language (LDL), a high-level command language. LDL commands are compiled on-line and are allocated to resident software modules. Linc is a high-productivity tool for the data processing professional. The product builds on the programmer's knowledge of COBOL and provides many functions that greatly speed up routine development operations.

6.5. Mapper

Mapper (actually Mapper 10), developed by the Sperry Corp., is an application generator suitable for end-users, for use only on the Sperry Series 1100. Mapper enables non-technical end-users to develop routine information processing applications. Major components of Mapper include a DBMS, a report writer, a word processor and a

graphics generator. Mapper uses a data model composed of a simple indexed flat file structure with quasi-relational properties. JOIN and SELECT operations are not supported, although information can be merged through the use of a union operator. An on-line language permits data to be searched, updated and manipulated.

The product incorporates extensive word processing, graphics and financial modeling facilities. Text manipulation functions include full document generation capability. Additional executive support functions provide accounting, mail and calendar maintenance operations. Integrated graphics capabilities include the generation of five chart types using a wide variety of styles and colours. An optional financial modeling extension to Mapper, called SUFICS, provides a large number of pre-programmed financial calculations and decision support functions.

Mapper does not incorporate the range of capabilities supported by full-function 4GSs, such as Focus and others. Its command language is complex and has a relatively unforgiving syntax. A challenge for Sperry is to extend the functions of Mapper and to improve the human factoring of the command language.

6.6. Na tu ra l

Natural, a product from the German-based Soft- ware AG, is a versatile fourth-generation language that supports a wide range of integrated functions including database query, report generation, screen generation, graphics and application generation. Natural is an integrated product within the Soft- ware AG product line. Its components include a DBMS, a data dictionary, a security system, a teleprocessing monitor, an application development tool, a graphics system, a simplified menu- driven reporting system and an interface to IBM or IBM-compatible personal computers. Users in- teract with the various components of the system using a common command language and syntax. Natural supports the following facilities: database inquiry using Adabas, non-Adabas file processing, on-line transaction processing, batch applications, report generation, screen design, data entry, graphics applications, interfaces to conventional

255

languages and a menu-driven end-user communication.

Application programs written in Natural require far fewer statements than programs written in conventional languages; in some cases only one-tenth the number of statements in an equivalent COBOL program. Natural allows programs to be written, tested and modified quickly using on-line facilities. The Natural procedural language is complex and oriented towards data processing professionals who are willing to learn its intricacies. In a major effort to simplify the human interface, Software AG has developed SU- PER/Natural, which provides a much more user- friendly front-end.

Natural and its companion product Adabas operate on IBM and IBM-compatible mainframes. Operating environments include VSE, OS/BS1, MVS and VM/CMS. Natural(VMS) and the companion Adabas(VMS) are available on the DEC VAX systems under the VMS operating system. Natural(VMS) does not contain all the features available in the IBM environment.

6. 7. Oracle

Oracle, developed by Oracle Corp., stems from the IBM research development project on System-R. Oracle, as a relational DBMS, offers for simple applications a facility to keep the data up-to-date, even when the underlying structure changes or the usage changes. Changes in data structure can be applied in a simple way, and often the applicable programs need not be altered. With Oracle: (1) programmers need not worry about opening files, search methods, complex iterative procedures, storage methods, etc.; (2) programmers and managers can use high-level development aids, including report and application generators; (3) managers can use SQL for posing ad-hoc questions to the DBMS in a simple manner.

Oracle consists of the following components: structured query language (SQL) for inquiry, definition, alteration and maintenance of the database; user-friendly interface (UFI); interactive application facility (IAF) for application generation; and host language interface (HLI), for calling 3GS

256

program and report writer facility (RPF). As utilities are available: a table-driven application generator for prototyping, a data loader for batch-wise conversion of non-Oracle data files and back-up and recovery and journaling tools.

The Oracle Tool Package (OTP) includes, in addition to the kernel Oracle described above, the workbench for creating user-oriented function selection, the data dictionary extension (DDE) for optimal control over entities and tables, the dy-

namic menu utility (DMU) for programmer-oriented function selection and the source file management (SFM) for an easy means of control over the various files/bases.

Oracle is available for the IBM and IBM-compatible mainframes under VM/CMS, MVS or UTS, various types of hardware under the UNIX operating system, DEC VAX series under VMS and DEC PDP series under R S X / l l M + , Data General MV series under AOS/VS, Harris 700,

T A B L E 3

C o m p a r i s o n o f A I D A wi th o t h e r 4 G S p a c k a g e s (based o n [10])

A I D A A S F o c u s L inc M a p p e r N a t u r a l O r a c l e

How is the software used C o m m a n d d r iven

Sc reen i n p u t

In te rac t ive

Act ive d a t a d i c t i o n a r y ( D D )

D D for all c o m p o n e n t s

U s e r views of files

Operating principle I n t e r p r e t e d

C o d e g e n e r a t i o n

C o m p i l e d

T a b l e d r iven

Capacities~possibilities All c o m p l e x i t y w i thou t 3 G S

M a i n l y r e p o r t i n g

M a i n l y quer ies

M a i n l y d a t a - e n t r y

B a t c h p roces s ing poss ib le

C o m p l e x d a t a s t ruc tu re s

Additional possibilities G r a p h i c a l p r e s e n t a t i o n

F i n a n c i a l m o d e l i n g

Sta t i s t ica l p roce s s ing

Database/file handling O w n D B M S i n c l u d e d

If so, r e l a t iona l R e a d s o the r files U p d a t e s o the r files

Special characteristics 3 G S ca l l ing 4 G S 4 G S ca l l ing 3 G S

I n t e n d e d for:

e n d - u s e r p ro fes s iona l

yes yes yes yes yes yes yes

yes p a r t yes yes p a r t p a r t n o

yes p a r t yes yes yes yes yes

yes yes n o yes n o n o yes yes - yes - no o p t i o n a l n o

yes yes yes n o yes '~ yes

yes yes yes - yes yes yes

yes - - yes - - - n o - yes - p a r t poss

yes . . . . .

n o n o yes yes yes n o

a lso yes - - ex t r a -

a lso yes - - ex t r a yes

a lso - - - yes yes

yes yes '~ yes yes yes n o


n o yes yes no yes yes yes

n o yes yes n o n o n o -

n o yes yes n o n o n o -

yes n o yes n o yes yes yes

yes - p a r t - n o p a r t yes

yes D B II yes D M S I1 n o some n o

yes n o p a r t n o n o some n o

yes n o yes yes n o yes n o yes - yes ? n o n o yes

p a r t yes yes n o p a r t p a r t yes


800, 1000 under VOS, Honeywell DPS-6 under GCOS, Prime under PRIMOS, IBM-PC and com- patibles under P C D O S / M S D O S , and many other systems.

6.8. Comparison

Table 3 has been derived from a similar table by Datex, which appeared in [10]; several columns for other 4GS packages have been left out and the column for AIDA has been added. Only one row concerning extra additional possibilities (e.g. PC link, electronic mail, etc.) has been left out. Note that some discrepancies exist between the above table (from [10]) and the preceding text (mainly from [11] and [12]).

Some basic remarks: seven 4GS products from seven suppliers are compared; of these firms, five are American and two are European; also, three of them are primarily hardware vendors, three are software firms and one is a university; finally, four software packages are dedicated to one type of hardware (IBM twice (AS and Focus), Burroughs (Linc) and Sperry (Mapper))- -exclud- ing the PC m a r k e t - - a n d two serve, besides IBM mainframes, also DEC VAX (Oracle and Natural); only two are available for a wide variety of computers (Oracle and AIDA).

When we study the table, with especially AIDA in our mind, some aspects draw our attention. (1) Application generation does not require separate compilation. This has the advantage that development speeds up, as compilation generally is a time-consuming business. (2) Not all complexity can be solved with AIDA only. It was a deliberate choice to use MUMPS as a language available to the application developer. It is a simple-to-use language and offers a great deal of flexibility due to the fact that it is an interpreted language. At one level, MUMPS can be regarded as the procedural application development language of AIDA. However, in a ready-to- use application, an end-user is never confronted with MUMPS. (3) No graphical presentation, financial modeling or statistical processing is offered. Concerning the latter two, we are convinced that ' the wheel should not be invented twice'. Means are therefore cur-

257

rently being prepared for interfacing AIDA with specialized packages that do this job far better than we ever may hope to achieve. The graphical presentation, however, is something we are still working on. (4) AIDA is not intended fully for the end-user for the development of applications, though significant parts of an application may be defined by the end-user. A programmer is then required for linking the separate parts together. This approach, we believe, speeds up development and generally provides a very high degree of flexibility.

7. Summary and discussion

In the Section 2 it was shown that 4GS packages are used in interactive environments by a mixed group of users, where the quality and security of data is of importance. The diverse functions in these - -a t least potent ia l - -environments were then discussed. They concerned data acquisition, storage, processing, selection, formatting and security. These functions were then used as a description for the functionality of a 4GS package. This description was compared to what normally can be expected from 4GS packages.

On the basis of these expectations, a 4GS package called AIDA was presented. The tool groups of AIDA were described separately.

Data acquisition and input of AIDA is highly interactive, and gives an opportunity to perform data validation at any given instance. DBMS shields users from more technical matters. The data retrieval facility is easy to use and can quickly give results. The formatting can be customized to a great extent. The secondary tool groups feature especially the c o m m a n d / m e n u structure, which present the benefits of two widely used approaches. The source control facilities, finally, give the programmer the possibility of creating applications with a minimum of effort and overhead. After informally comparing AIDA with over 30 other 4GS packages, we feel that AIDA can easily compete with all of them, and that it presumably outruns most of them in terms of flexibility, speed of development, performance, low resource usage, and user interface. We hope to present the results

258

of a more formal investigation shortly. The future direction of A I D A development is

the appliance of expert knowledge at the level o f the programmer. This implies that the ultimate product will use stored knowledge in order to assist the user in building and modifying his application. The skill to construct medical information systems is apparent ly not present in most medical environments. Also, as is commonly known, the number of programmers available for development and maintenance is too low. Stan- dard solutions (3GS of the second definition) will not always be available for a certain type of user and, when it is available, it will probably not suit his requirements.

8. Conclusion

We have shown that A I D A is a true fourth-gener- at ion software package. It has proven its quality over a number of years. Small, but also very substantial applications have been built with it, and the great majority of reactions on the use of A I D A were positive (see the applications articles in this issue). Its applicability for use as the basis for new and advanced developments strengthens our trust in A I D A and its underlying concepts, and presumably makes us more commit ted to development of the 4GS level itself.

References

[1] E. Horowitz, Fundamentals of Programming Languages (Springer Verlag, Berlin, 1983).

[2] J. Dahl, E.W. Dijkstra and C.A.R. Hoare, Structured Programming (Academic Press, New York NY, 1972).

[3] W.J. Dixon and M.B. Brown (eds.), BMDP: Biomedical Computer Programs; P-series (University of California Press, Berkeley, 1977).

[4] N.H. Nie, et al., SPSS: Statistical Package for the Social Sciences (McGraw-Hill, New York, 1975).

[5] A.C. Komaroff, The variability and inaccuracy of medical data, Proc. IEEE 67 (1979) 1196-1207.

[6] O.J.S. van Hemel, An Obstetric Database; Human Fac- tors, Design and Reliability, PhD thesis (Free University, Amsterdam, 1976).

[7] H.P. Westerhof, P.C.G.M. Sollet and J.H. van Bemmel, Computerised history taking for training medical stu- dents, in: Comp. Biomed. Res. 19 (1986) 596-605.

[8] J.E. Sammet, Programming Languages: History and Fundamentals (Prentice-Hall, Englewood Cliffs NJ, 1969).

[9] D.C. Tsichritzis and F.H. Lochovsky, Data Models (Pren- tice-Hall, Englewood Cliffs N J, 1982).

[10] A. Mulder, Invoering vierde generatie software betekent een lange weg te gaan, De Automatisering Gids 16 April (1986) 21 (in Dutch).

[11] J. Martin and J. Leben, Fourth-Generation Languages, Volume II: Representative Languages (Prentice-Hall, En- glewood-Cliffs N J, 1986).

[12] J. Martin and J. Leben, Fourth-Generation Languages, Volume III: 4GLs from IBM (Prentice-Hall, Englewood- Cliffs N J, 1986).

Documents

AIDA's fourth-generation software functionality