University of Pennsylvania ScholarlyCommons

Technical Reports (CIS) Department of Computer & Information Science

January 1974

Research on Automatic Program Generation

Jesus A. Ramirez University of Pennsylvania

N. Adam Rin University of Pennsylvania

Maxine Brown University of Pennsylvania

Noah S. Prywes University of Pennsylvania

Follow this and additional works at: https://repository.upenn.edu/cis_reports

Recommended Citation Jesus A. Ramirez, N. Adam Rin, Maxine Brown, and Noah S. Prywes, "Research on Automatic Program Generation", . January 1974.

University of Pennsylvania Department of Computer and Information Science Technical Report No. MS-CIS-74-05.

This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_reports/682 For more information, please contact [email protected]. Research on Automatic Program Generation

Abstract Automatic Program Generation Research has been conducted under Contract N00014-67-A-0216-0014, since 1971. The objective of the research has been to provide software generation directly from user specifications.

Initially, the research concentrated on a specific application, of generating file conversion programs. A first eporr t on this subject was authored by Diane Pirog Smith, in December 1971, titled, "An Approach to Data Description and Conversion". Subsequently, a software system for automating this function was implemented by Jesus A. Ramirez and described by him in a report titled, "Automatic Generation of data conversion-programs Using A Data Description Language (DIL)". Currently, the objective of the research has been broadened to develop a user language and a software system for automatic generation of business oriented programs.

This technical report contains a collection of three papers intended to summarize the results of past research and the direction of current research. The first paper, by Ramirez, Rin and Prywes is a summmary of Dr. Ramirez's report and dissertation cited above. The second paper, titled, "An Overview of a System for Automatic Generation of File Conversion Programs " by. N. Adam Rin and Maxine Brown is intended to provide a more user oriented view based on their experience in utilization of the system developed by Ramirez.

There have been many research activities and a large number of papers in this area. The third paper, "Automatic Generation of Software Systems: A Survey," by N. Prywes serves to relate the research underway at the University of Pennsylvania, to the many recent and current activities in this field. It also aims to clearly define short and long term objectives and methodologies.

Comments University of Pennsylvania Department of Computer and Information Science Technical Report No. MS- CIS-74-05.

This technical report is available at ScholarlyCommons: https://repository.upenn.edu/cis_reports/682 ~IVETSITYOF pmsnm The -re School of Electrical Engineer* Departnrent of Qnputer and Informtion Sciene.

Project Supervisor Noah S. Prywes

Prepared for the Off ice of Naval Msearch Infonmtim System Arlington, Va. 22217

under Contract N00014-67-A-0216-0014 Project No. NR 049-153

Reproduction in whole or in part is permitted for any pe of ti?e United States Govenunent

more Scfiool Rego* # 74-05 (Sorurtcr ~I~msflkalh~01 f111.. body 01 aba#mCI and Indonlng mnolrtim murt k onlend when It10 owrall VOport I* rlrrmllled) t. OR!~IWA?ING A~TIVITV (C-ro uk) a. RLPOIT SECUR~TV CL AS~ICICATIOW Uruverslty of Pennsylvania WCLASSIF'IED The Eibore School of Electrical Engineering ab. CROUP Dept. of Ccmputer Information Sciences, Phila. , Pa.

3 RFPORT TITLC

I Jesus A. Rarnirez, N. Adam Rin, Maxine Brawn and Noah S. Prywes I 8 REPORT DATE I?.. TOTAL NO OFPACES I7b. NO. OF IEVS Januaq 1974 103 I U. CMTULCT OR GRANT NO. U. O*lQINA TOR'S REPOlT MUYmCWlSt N00014-67-A-0216-0014 &ore School Report 74-05 b. LIOJCCT NO. I

Repruductian in whole or in part is pMnitted for any p.pqmse of the United States Q-t

s11. BUP~LPMCNTARVNOTES Mfice of Xaval &search Infonuation Systgns Arlington, Virginia 22217

IS AmsTRAcT Au-tic Program Generation Wearch has been mnducted under contract Na0014-67-A-0216-0014, since 1971. ?he objective of the resear& has been to provide software generation directly fmuser specifications. Initially, the researdn. concentrated on a specific applicatian, of generating file conversion programs. A first report on this sbject was authored oy Diane Pirog Smith, in Decarber 1971, titled, "An -roach to Data Descripti.cn and Cbnversion. " SSsequently a so£Ware systen for autcaMting this function was implemnted by Jesus A. FGdmz and described by him in a report titled, "Autcmtic Generation of IBta Cbnversion-Program Us* A Data Description Language (Dl&) ". Currently, the abjective of the research has been broadened to develop a user language and a software sysbm for autcanatic generation of business oriented programs.

This technical repart omtains a mllecction of three papers intended to smrize tne results of past research and the directicn of current research. he first paper, by Ramirez, Rin and Prywes is a sumnary of Dr. Ramirezls report and dissertation cited above. ?he second paper, titled, "An Overview Of A System For ' Au-tic Generatim of File Qnversim Prograns, 'I by N. Adam Rin and Maxine Brcrwn 1 is intended to provide a mre user oriented vim based on their experience in 1 utilization of hesystem developed by Rgnirez. 1 (Continued on next page) I DD pornw ,, ., 1473 (PAGE 1) SF( 0101 -007-sa1i Srcuritv Clas~ification 1-51401 I. Kt* womos

mil-, Generators, Prablem Oriented Languages, Syntax Andly~is,Lexical Analysis, Data Description bquage~,~ata Manipulation Language, Conversion Program, Jutmatic Progranrnjng, I/O Utility, -tic Program -ation

13. continued

There have been many research activities and a large nuher of pap8 in this area. Ihe thkd paper, "Autcmtic Generation of Software Sysh - A Samey, I' by N. Prywes serves to relate the research undemay at the University of Pennsylvania, to &e myrecpnt and current activities in this field. It also aims to clearly define short and long term abjecti- and mthodoloqies. Automatic Prcgrarn Generation -ear& has been oondmted under contract ~VO3014-67-A-02160014, since 1371. The cb jective of the research has been to provide software generation directly from user specifications.

Initially, the research concentrated on a specific application, of generating file anversion programs. A first reprt on this sbject was authored ~y Diane Pirog Smith, in Deerher 1971, titled, "An Approach to Data

&scription and Conversion." Sbsequently a software system for aukmating

this function was implemented by Jesus A. Ramirez and described by him in a

report, titled, "Autmatic Generation of Data Cbnversion-Prograns Using A

Data Description Language (ML) .I' Currently, the cbjective of t~eresearch has been ~roadenedto develop a user language and a sofmare system for autmatic

generation of business oriented programs. Tnis teamica1 reprt contains a collection of three papers intad& to

smizetiLe results of past research and the direction of current research.

Tiie first paper, by Ramirez, Rin and Prywes is a sumnary of Dr. Ramirez's report

and dissertation cited hve. The s-nd wper, titled, "An Overview Of A

System For AutaMtic Generation Of File Conversion Progrmrs ," by N. Adam Rin and Maxine Brown is intended to provide a mre user oriented view based on their

experience in utilization of the system developed by Ramirez.

fiere have been myresearch activities and a large n* of papers in

this area. The tnird paper, "Autolmatic Generation of Software System5 - A Suwey,"

by S. Pxywes serves to relate the researall undemay at the University of

Pennsylvania, to the rmy recent and current activities in this field. It also

aims to clearly define short and long term cbjectives and methodologies. TABLE OF (JNIEV'

Page

I. AUIWX'IC QJER?iTICN 0d DA!I'A ~~~ICNPTr>GWS LEE'JG A EA DESC~O~~7~3~~23, J.A. ~EZ, N.A. m AND N.S. PFWES

1. Introduction

2. Smmcy of Language Processing Facilities Of The UUL/DML Processor 4

3. Infomtion Flm In The DF&/DML Processor 7

3.2 Overview Of ?he DE/D4L Processor 7

3.3 The Syntax Analysis Program Generator (SAPG) 10

3.4 The clca Qmpiler 13

3.5 Data Conversion Processor 18

11. &IOVERVIEW OF A SYmEOR AUIUWI"I'C GENERATIO:iI OF FlLE a3iWEION P#X;RAMS, N. Adam Rin and Maxine Brawn

1. An Overview Of me KIL Processor System 1

B. Rze DRL Language as a Data Descxiptim Language 3

C. Capabilities and Applications of DC& and Its Processor 5

2. Usage and Capabilities Of The DDL Processor An Illustrative Exrmple 7

A. Usage and function of the M& Processor 7

C. Features and Capabilities of the Lanwe and Processor 36

D. Evaluation 39

3. Current =search 41 11. AN OVERVIXW OF A SYSTEM FOR ATJIWATIC ON OF FILE Page 05NVEIZSICEJ PRXWMS, N. Adam Rin and Maxine Bm

4. Other Possible Future Work 41

111, ~~ICG3NERATIOi'J 9F SOFIWAIE SYSTW - A Sm,iJ .S. P~s 1. lbtroduction 1

Part I Current Problem In Software Developznt 2

2. Overview Of Historic and ~03mmicConsiderations 2

3. Analysis Of ?he Software Develo~tProcess 7.

Part I1 Future Advances In AutaPMtion Of Software Develo~ano~lt 14 4. AutxmMtic Design and Implementation Of Programs 14

5. Awtic Gaeration Of Nan-Procedural Specifications 25

6. Cbnclusions 31 IffJIvESIWOF PENNSYLvzwXA The &boreSchool of Electrical Ebgineering Department of Wter and Infomation Science

Project Supervim Noall S. Prywes

January 1974

Prepared for the Office of Naval Msearch Infonratian System ArluagtDn, Va. 22217

under -tract N00014-67-A-0216-0014 Project No. NR 049-153

F&producticm in whole or in part is permitted for any purpose of t%e united States CovermEnt

-re SwlReport # 74-05 "AUTOMATIC GENEMTION OF DATA CONVERSION PROGWlS IlSIhTG A DATA DESCRIPTION LANGUAGE"

J.A. Ramirez, N.A. Rin and N.S. Prywes

The Moore School of Electrical Engineering, Lhiversity of 'Pennsylvania, Philadelphia, Pennsylvania 19174

ABSTRACT :

Costs and development times involved in computer software have been exceedingly large. Programming and testing cons titute the major component of total software cost and account for most of the slippages that have been widely experienced. It has also been found exceeding>] difficult for management to control the progress of programming and testing

of software. Therefore the research program described here aims initially

at reducing and controlling these components of the costs , particularly

in the Business Application Programming Area.

Historically it has been necessary to employ the computer itself to

reduce programming costs through use of high level programming languages,

such as COBOL or PL/I, or use of Data Base Management Systems. The

increasing costs indicate the need to employ even a higher level of

automation than employed so far, and automate the programming in high level

languages; namely automatically produce ad hoc proprams in languages such

as COBOL or PL/I.

The paper describes a methodology to automatically generate programs

and the application of the methodology in a Processor for generating file

conversion programs. The Processor, accepts as input descriptions of

source and target files in a Data Ecscription Language (DDL) and data

manipulation specifications in a Data Flanipulation Langungc (Db11,). It

produc~s'i:; an oiitput a cnnvc~rsionpro>-ram in I'l./T c:~~~?bltaof rc7!iv~1.L i t13~

tl~csource f i 1~.a~ld prodi~cing tl1c8 tar2:t.t f ilc.. 1. INTRODUCTION :

The ultimate goal of the research reported in this paper is the automatic generation of programs to perform data processing. The design objectives have been as follows:

1. Input to the automatic programming system should be largely

(but not completely) derived directly from the functional

specifications for the program to be developed. (A number of

languages for functional specifications are in use [I]).

2. Control, input/output and data definition code is to be generated

automatically.

3. Data manipulation not specified in the input to the system, can

be added in a modular manner without requiring concern with input/

output, or control or data definition code.

4. A methodology for debugging, test and proofing of program

components that is extensible to the entire end product program.

The paper describes a step toward this goal, a Processor which has been developed to generate programs for the limited application of data

conversion. The Processor accepts as an input functional descriptions of

source and target files in a Data Description Language (DDL) . To specify

validation criteria, data security, summaries and reports, the Processor

accepts inputs in a Data Manipulation Language (Dm). It produces as an

output a conversion program in PL/1 capable of converting the source file

and producing the target file. The advantage of using the Processor over

programming directly in PL/1 are, briefly, the much simpler data definition

in DDL, especially for variable length fields and records, and the automatic -

generation of JCL statements and ad-hoc PL/1 code for data declaration, input/

output control logic and for calls on the DML procedures when appropriate. The Processor generates the top levels of the program, performing the program design and producing documentation and cross referencing.

The emphasis in this paper is on the methodology used in constructing

the DDL/DML Processor. The methodology is directed to implementing processors for automatic generation of programs for specific areas of

data processing applications. It is also directed toward maximum ease

In modification of the functional specification input language, as such

languages are considered experimental until considerable experience has

been gained in their use. This direction of the work, reported in the

paper, is reflected in the discussion of languages used and information

flow in the DDLIDML Processor in Sections 2 and 3 below, respectively.

The DDL/DML Processor automatically produces conversion programs

in PL11; i.e., PL/1 is used as an intermediate object/source language in

the compilation process of DDL statements into machine code. The main

reason for the use of PL/1 code is easier debugging and documenting of the

compiler and the respective applications.

The Processor itself has also been programmed in PL/l, to facilitate

ease of programming and to allow for better documentation. The processor

is programmed for IBM 360/370 computers. It has been used in several

applications to determine its computer usage, reliability and dependability.

A report on the Processor design and a User Cuide to its applications

and use are available as part of the Ph'.D. Dissertation of the first

Author [23. The application of DDL/DML and the Processor consist of the following: (1) A Language for communication between humans about data structures: For example, for an analyst to describe a data base to an applications programmer. (2) Pestructuring and conversion of files: As a utility, the Processor enables the user to convert files.

(3) Interfacing files with different programs and programming languages:

The Processor, can convert files into a structure which can be processed by another program. (4) Validating and editing of a file: By defining a file in DDL, one can validate it according to user-provided criteria written in DML. (5) Report generation: By defining the source file to be a data base and defining the target file to be a report, the DDL/IIML

Processor facilitates report generation. (6) Generally, single file to single file processing with intermediate manipulation of data.

2. SUMMARY OF LANGUAGE PROCESSING FACILITIES OF THE DDL/DML PROCESSOR

The processor has external as well as internal languages. The external user-oriented language used for input is DDL/DML. The internal

languages are used to specify the syntax of DDL and some of the semantics.

Based on these latter specifications various portions of the processor are

automatically generated. The main aspects of both types of languages

are summarized below. DDL has extensive facilities for describing data files, covering both logical and physical structures of the data. There are facilities

to describe such concepts as repeating fields, mandatory or optional

fields, fixed or variable length fields. There are built-in functions

to produce summaries, giving information on length of fields or the

number of repeating fields. Code for editing and reformatting is

generated automatically. The syntax of DDL is similar to the data

descriptive facilities of COBOL, PL/1 or the DDL designed by the CODASYL

Data Base Task Group [3]. The DDL used in the Processor is based on

a subset of the DDL design by Smith [43. In the course of the implementation

and use it was found advantageous to make modifications to make DDL

easie~to implement and use. A more detailed description of the facilities

of DDL accompanied by many illustrative examples of its use can be found

in the User Guide Appendix of 121.

DML is used for specifying validation criteria for the data, for

specifying complex conversions not built-in the Processor, for producing

summaries, and for producing reports. DML is, in fact, a subset 'of

PL/1, and therefore, has general manipulative capability. The Processor

may be also regarded as an adjunct to a PL/1 Compiler, adding, in fact,

the facilities of DDL to PL/1.

The syntax of DDL is easy to change. The specification of the syntax

of DDL itself and its internal encoding is used as an input to a portion

of the Processor, from which the Syntactic Analysis Program (SAP) for

DDL is generated. The language used to specify the syntax of DDL is

an &tended BNF (EBNF). To convey some of the semantics, the specifying language was extended further by allowing the specific -calling for subroutines. The

Extended BNF With Subroutine Calls is referred to in the following as EBNF/WSC. It was used for specifying processing and encoding of

the DDL Statements into internal tables, and thus also to reduce the work in programming the code generation.

The specification of DDL is used as an input to a program called

Syntactic Analysis Program Generator (SAPG) . This program then

generates SAP, which is used to syntactically analyze and encode the

input DDL/DML statements. This aspect of the processor was considered

most important, as it was realized that the DDL being used, as well as

other functional specification languages, are experimental and extensive

&anges may be necessary before even a near optimal language is

obtained. This facility was indeed used to change the language. For

instance, a change from the DDL designed by Smith [4] to a modified

DDL was accomplished in less than a week. Another advantage was the

ease in inco~poratinginput error analysis, as experience was gained

with use of the DDL P~ocessor. It was also found that automatic

generation of the SAP, via SAPG, greatly speeded and reduced the work

required to implement the processor.

Transition Matrfces were used in Lexical Analysis of the DDL

as well as the EBNF/WSC statements following the ideas in [5], and [6].

It fs, howwer, noteworthy that techniques for automatic

generation of the Processor's code generation routines were not used.

This was because the DDL processor is specially designed to generate conversion programs and the research to date [7] on automatic generation of code for general purpose language compilers is not applicable. Therefore, the code generation of the DDLIDML processor was hand coded in PL/l. Thereby, better efficiency was also achieved in the generation of the conversion programs. All the hand codes, as well as automatically generated parts of the system, including the

SAPG, were written in PL/1 for reasons of facilitating programming, maintainability and limited machine independence.

3. INFORMATION FLOW IN THE DDLIDML PROCESSOR

3.1 LWTRODUCTION

The information flow in the DDLIDML Processor is illustrated in

Figures 1 through 6. Figures 1 and 2 give a progressively somewhat wedetailed werview of the entire processor. The remaining four

Figures, give a further detailed information on the three major

components, the Syntax Analysis Program Generator, the DDL Compiler

and the generated Conversion Program, respectively.

3.2 OVERVIEW OF THE DDL/DML PROCESSOR

The DDL/DML Processor is actually a set of three processors.

These are shown in Figure la as follows: The first is the Syntactic

Analysis Program Generator (SAPG). It accepts as an input the EBNFIWSC

syntax specifications of the DDL and produces the Syntax Analysis Pro-

gram (SAP) for the DDL. This product is then joined with inputs consisting

of routines providing additional semantics, code generation logic, etc.

to make the second processor, the DDL Compiler. The second processor

accepts the DDLIDML statements and its product is the third processor, SYNTAX FEFINI'!Tflr7 COMPILER- COMP I LER SYNTACTIC ANALYSIS I I SSPIEMTICS AND CODE SYNTAX PROGRAM I I GENERATION RULES GENERATOR (SAPG) TN EKiF/WSC

LEXICAL & SYNTAX ANAL. nOUTINES FOR

CIJW C;L;JERATION ROUTINE FOR DDL

V I v

DDL-COMPILER STMTS)

USERS PROGRAM INPUT DATA I

SOURCE DATA CONVERSION DATA PROCESSOR I OUTPUT DATA

lb COMPILER-COMPILER SYSTEM

TARGET DATA la TIT, DDL/~I:L PJ?.OCESSnR the Data Conversion Program, which is used to convert the source data into the target data.

An analogy with existing computer programming language systems is illustrated by comparing Figure la with Figure lb. The SAPG

(in la) is analogous to a compiler-compiler's syntax analysis generation module (in lb) which is used to produce syntax analysis programs for the specific language. The DDL Compiler (in la) is analogous to a programming language processor, (in lb) such as COBOL, FORTRAN or PL/1

compilers. The Data Conversion Processor (in la) is analogous to an

executeable user program (in lb). The relationship between the use

of the three processors in the DDL system is readily seen from the

ana logy.

The SAPG is a program used to create the syntax analysis program

which in turn, becomes part of the DDL Compiler. The "generator" is a

very -valuable tool in the development of the DDL Compiler. Furthermore,

it could be a "stand-alone!' valuable tool in writing any language syntax

analysis program.

The DDL Compiler and the Data Conversion Processor are the only

components of the DDL Processor that most users will need. To produce

a Data Conversion Processor, a user writes a data definition, a series

of statements in DDL, for each of the source and target files. These

statements are basically descriptions of the formats of the source and

target files- and of transformations from the former to the latter.

If data -manipulation is needed, a series of routines are written in DML.

These statements are used as inputs to the DDL Compiler. The compiler in turn produces a data conversion program. Just as it is not necessary to compile a conventional program each time it is used, it is not necessary, also, to create a new data conversion program, each time it is used. The same object module could be re-used (either as PL/1 source or in object code form).

A somewhat more detailed view of the three major components of the DDL Processor is given in Figure 2. In Figure 2-6, the three processors are identified by being surrounded by broken lines. A rectangle with the 'missing top represents an input, and with a missing bottom an output. Outputs which are programs, are shown in trapezoids.

When the output is a program, double lines are used to show where it is later used. Figure 2 shows an overview of the information flow wirh some additional detail. In particular, syntax and lexical analysis p,rogram makes up the DDL Compiler.

The discussion in the following three sub-sections (and in Figures 3

through 6) provides a more detailed view of the components, in the

order of top to bottom of Figure 2.

3.3 TlB ~~ ANALYSIS PROGRAM GENERATOR (SAPG)-

The top left of Figure 2 is expanded in Figure 3. The SAPG is

a compiler in its own. It consists of kxical Analysis (a) Syntax

Analysis (b) and Code Generation (c) modules, all hand coded in PL/1.

They are compiled into IBM/370 machine code using the PL/1 compiler,

and form the SAPG. The input to SAPG is the DDL syntax specification, in EBNF/WSC - . The output (f) is a Syntax Analysis Program (SAP) - in PL/ll which ROUTINES FOR LEXICAL CODE GENERATION AYALY SIS F.OCTIMES FOR DDL SY:.r'TA?( Ai'JALYSIS FPR EBNF/KSC can perform the syntax analysis on statements written in DDL.

The SAPG has all the components of a compiler. The lexical analysis consists of processing the EBNFIWSC statements to form tokens. The syntax analysis further processes the EBNFIWSC strings of tokens to perform various checks, generate error comments and organize the information in accordance with the internal tables.

Finally this information is analyzed and the SAP PL/1 code is generated for processing subsequently (in Figure 4) the DDL Statements.

3.4 THE DDL COMFILER

Figure 4 shows the components that are used to make up the DDL

compile^. They are as follows:

(1) The Lexical Analysis Subroutine for DDL - hand coded in PLI 1.

(2) The Syntax Analysis Program (SAP) - produced by the SAPG

m PL11. (3) Supporting subroutines - written in PL/1, perform services required by the SAP. Services include recognition of syntactic elements,

diagnosttcs of syntax errors, creation of Internal Tables (symbol and

data tables) and, if specified, a cross-reference table of the identifiers

used in the DDL program. These subroutines can be called in the

EBNF/WSC statements. (4) Code Generation Program - written in PL/~,forming the

basis of the code generation phase of the DDL compiler. In it is

contained the logic required to interpret the information stored in

the internal tables and to generate PL11 statements which will perform

the data conversion indicated by the analysis of DDL statements. 0 0 LEXICAL SYNTAX ANALYSIS SYNTAX SUPPORTING CODE ROUTINE FOR I PROGYM. FOR DDL IN I ROUTINES, CROSS- GENERATION DDL IN REFERENCE ROUTINES PL/1 It1 PL11

PL/1 COMPILER + DDL COMPILER (IBM/370 CODE)

0 r--"""'------..----- DDL & DML I DDL COMPILER S TATBrnNT5- - - I '- ,- ,, - ,, , a - - ,, -- - -,-- - --,---J c.P I DATA CONVERSION @ PROGRAM (PL/l)

r"" "-'"-""------I I PL/1 COMPILER D-; L - - ,- - ,, , , - - - ,- - _-_,____-__-___I

DATA CONVERSION PROGRAM (IBM 370 CODE) 0 8 SOURCE ,------FILE -- 2: DATA CONVERSION PROCESSOR -@I - TARGET I FILE L------I (5) & (6) The PL/1 Compiler (5) produces the DDL Compiler

(6) in IBM/370 machine code.

The remainder of the system is also summarized in Figure 4, as f ollaws :

(7) The DDL statements given by the user describe the structure of his source and target files and mappings from the former to the latter. The DML statements describe the file manipulations to be performed on the source file, such as editing, complex specialized conversion formulas, security testing, report generation and statistical gathering of data.

(8) & (9) The Data Conversion Program, in PL/1 is the input to

the PL/1 compiler (9) this produces the Data Conversion Program (10)

fn ma&-ine code for the I8M/370.

UO), (11) and (12) Finally the Data Conversion Program (10)

accepts as input the source file (11) and outputs the target file (12).

The compiling process is further expanded in Figure 5. It is per-

formed in two phases, as described below.

PWE 1 OF THE DDL COWIUR

In phase 1, DDL statements are read by the Lexical Analysis Pro-

gram (LEX) that forms tokens which are in turn the input to the SAP.

The SAP examines the string of tokens to determine whether or not the

string obeys certain structural conventions explicit in the syntactic

definition of the language. Should an error be discovered, the error-

diagnostic routines will be called to output a message informing the user

of the location and nature of the misconstruction.

Concurrent with this error detection is the internal table generation.

At this time, routines are called whose functions are the capturing of information contained in the DDL source statement and the building of tables to preserve this data in coded form for use during code generation, as well as in the detection of global syntax errors. The internal tables that are formed are the Symbol and Data Tables. If no errors were detected and if a "XREF" option was specified to the DDL Compiler, then the

cross-reference table is generated and output for the user's reference.

PHASE 2 OF THE DDL COMPILER

Phase 2 is code generation. The first part of Phase 2 is the execution

of a series of programs which steps through the Data Table and generates

PL/1 declare statements. When compiled, these will produce a Description

Table that contains the following for each field of the source record:

(1) data descriptor information, and (2) space for placing pointers to the .

field at execution time.

After the compiler has produced the Descriptor Table, a call is made

to the Data Parsing Code generation routines. These routines generate the

code which will set the field pointers in the Descriptor Table entry to point

to the fields in the input buffer of the source file at run time.

The second part of Phase 2 is a program which uses the Data Table

entries for the target file and generates the data movement code, which moves

the source data into the target file. This completes Phase 2 of the

DDL compiler. At this point the DML statements are read by the DDL compiler

and they are merged with the code produced during the code generation phase.

The creation of the data conversion program in IBM/370 machine language,

is performed by the PL/1 compiler. The input to the PL/1 compiler is the

PL/1 text produced in Phase 2. 3.5 DATA CONVERSION PROCESSOR

The Data Conversion Processor is composed of the set of programs and data which was produced by the DDL compiler and the DML routines supplied by the user. This is illustrated in Figure 6, it is composed of:

(a) a Data Conversion Program

(b) a Data Structure for the source file, and

(c) a set of DML subroutines

The Data Structure for the Source File, which was produced by the DDL Compiler from the DDL statements, is used by the generated

Data Conversion Program to aid in parsing the source data. The other component of the Data Conversion Processor, the user-supplied DML sub- routines, perform functions such as character set conversion, extension

or truncation of fields, data type conversion, criteria testing, security d testing, report generators and gathering of statistical data.

The information flow in the Data Conversion Processor, shown in

Figure 6, in fact is a representation of a generalized strategy for data

conversion. In terms of a program this strategy is represented by two

parts. The first consists of the data definition and control code which

is required in a program to allocate buffers, input/output of blocks

and Teco~ds,Tdentify the location of data elements in accordance with a

specified data structure and finally perform standard conversion functions.

The "flow chart" for the pnerated.code Is illustrated in Fig 7. In a

"top-down" [8 1 concept of a pro Faq .the first part constitutes the "top ."

The second part, which consists of data zanipulation routines in DML

constitutes the "botto n " level of a pro park This pneral strate eg has - -''- - -"~'--""-""""'"-""""-~"~-- - S OL'RCE I FILE TARGET DATA CONVERSION PROGRA?I t w- 2 0 I FILE t 1 - 1, ,------,- - - ,, , - ,- - ,------

Y @ DATA '0 STRUCTURE DML FOR ROUTINFS SOURCE FILE

4 ,

* FIGITRE 6 DATA CONVERSION PROCESSOR DDL GENERATED PROGRAM PROTQTYPE Declare Internal "Housekeeping"+ Variables Declare Input buffers for source file

Declare structure of+ pointers and lengths for every field and group in the source file

Declare Output buffers+ for target file 4 end of file +call -READ a user-defined record ------FrRAPW call LOCK routine if any I procedure I if any Set all pointers of source record initially to null 4 close files 1 I 1 ----For each field in source record: STOP+ 1) Call criterion procedure, if any, to test existence 2) Determine starting position of field and set pointer to it 3) Determine length of field as (a) a given constant (b) by scanning for a delimeter (cJ by einga routine that computers length (dl by referring to the value of another field or (e) by using the length or count of another field

Any more source fields? 1 - --For each target field: 1) Find field in source record or constant to be moved to target 2) Call the appropriate conversion routine, if specified 3) Concatenate source field to the output buffer being built

Anymore target fields? - WRITE Output Record been adopted from the beginning in the supporting and code generation routines. It is this type of strategy that is envisaged to change from one class of potential applications to another.

4. CONCLUSION

The Version 1.0 DDL/DML Processor has been found to be an effective and efficient tool, by the users, in several applications, although it has limited functions and capabilities. Additions of

functions and use to gain additional experience are progressing. The

authors tnvite those interested to communicate with them regarding

receipt of the system for wider experimentation. Presently, the

subjective impressions are that effectiveness in program development,

efficiency in processing and reliability are gratifying. However, there

have not been a systematic approach to measuring these aspects so far.

The authors however feel that in this study of development, an

equally important outcome is the availability of the system as a

.research tool and backbone for expansion to accept other functional

specification languages and to perform for wider classes of data

pcocessing applications.

ACKNOWLEDGEMENT

The authors acknowledge with thanks the participation in design

and prog~ammingby Messrs. H. Solow, P. Gross and A. French, and the

preparation of the documentation and this manuscript by Miss B. Weber. REFERENCES :

[I1 Teichrow, D. : Survey Of Languages For Stating Requirements For Computer Based Information Systems, Proc. of the Fall Joint Computer Conference, 1972, pp. 1203-1244.

Ramirez, J.A. : Automatic Generation Of Data Conversion-Programs Using A Data Description Language (DDL), Ph.D. Dissertation, University of Pennsylvania, 1973.

Conference On Data Systems Languages. Data Base Task Group. Report to the CODASYL Programming Language Committee. Association for Computing'Flachinery

Conference On Data Systems Languages. Data Base Task Group. Report to the CODASYL Programming Language Committee. Association for Computing Machihery, New York, New York, April 1971.

Conference On Data Systems Languages, Systems Committee. Feature Analysis of Generalized Data Base Management Systems, Association for. Computing Machinery, New York, New York, May 1971. 511p.

Smith, D.P.: An Approach To Data Description and Convem~bn,Ph.D. Dissertation, University of Pennsylvania, 1971.

Floyd, R.W. : The Syntax Of A Programming Language - A Survey, IEEE Trans., 1964.

Conway, M.E.: Design Of A Separable Transition - Diagram Compiler. Comm. ACM., Vol. 6, No. 7, 1963.

Fang, Isu.: A Declarative Formal Language Definition System, Ph.D. Dissertation, Stanford University, 1972.

H.D. Mills, Top Dm-Pxogramming In Large Systems , Debugging ~echniques, Editor, Prentlie Ball, 1971, pp . 41-55. ALq OVErnETJ OF A SYSTEM FOR AUrO~ICGmErnIOiI OF F'ILE 026wE~IQUPFoGRac6

N. Adam Rin and Maxine Brown

&is paper describes a processor which aumatically produces file oonversion program based on mn-procedural user specifications. Tne Processor accepts, as input, descriptions of a source file and a desired target file with sa~auxilliary descriptions of associati. between the m. Tnis is specified by a user in a Data Description Lampage (DL&). To specify validation criteria, qlex, conversions not built-in to the system, security criteria, or sumnary p~ocesses,the system also accepts specif icaticns in a Data Manipulation Language (IML) . It produces, as an output, a oonversion program in PL/1 capable of con- the described source file into tne desired target file. me paper describes the structure, system design, capajilities, and applications of the Dm- larquage and processor, including an illustrative exanple. I?. Adam Xin and Maxine Bmm

I. Pui OlEWD3J CF THE DDL PRXESSOR SYSTEM

A. lhtroduction This paper is concerned with research done in the field of aukmatic generatim of data conversion program; it provid.5~an overview of an existing software systemwhi& produces file conversion programs fran a user's

specification in a data definition language and it discusses possible future work in this area. The systm was designed and implemmted with support from

the Office of Naval Reseaxch by a group of graduate students under the

swision of Dr. N. S. Prywes at the ,-re Schwl of Electrical Engineering 1 A at the University of Pennsylvania.

lrne system -loped is a step towards the actzzztic generation of data

processing programs. The class of data processing program which the existing processor can aubnatically generate is file canmion prqrarns;.i.e., the system is able to produce a pmdural program based on non-procedural user

oriented specifications to translate an existiq file of knm structure into

a ~&IJdesired formit. i-n-procedural specificatio~sas used here are descriptive staterrents defining the source and target files and -41at- transformations are to be performd be.tk;em the .two, but do not relate -hc~ t!!ese transfomtions will be constructed. Tke procedural program produd Sy the srccessor is

1 For detailed documtntation of the system, its ixplmntation and use, see J.A. Rmnirez, "Automtic Seneration of Data Canversion Programs Using a Data Description Language (DDL)," Ph.D. Dissertation, Moore School of Electrical Engineering, University of Pennsyl.vania, Philadelphia, Pennsylvania, 19174; 1973. a PL/1 mversim program oomplete with input/output related instructions, logical sequencing and control, and invocation of specialdpulative routines peculiar to th3 prcblem.

Figure 1 shows a Slock diagram of the processor which accepts, as input, descriptions of a source file and a desired target file with scarre auxilliary associations be- the two specified in a Data Description Language (DDL). %bspecify validation criteria, c~n~1exconversions not built into tlne system, security criteria, and sumnary processes, the system also accepts as input prescriptive statexrents in a Data Manipulatim Language (m),a s*et of

PL/I with general manipulative capabilities. The processor produces, as oulqut, a pmcedural PL/l program capable of wnverting the source file in- the desired target file. The generated program is the? conpiled into machine language, yielding a tailored-to-need conversion pmgrm. The processor can

therefore be regarded as an adjunct and enhancerent to the PL/1 cmpiler, adding

tbe facilities of DCIL to it.

B. The ElDL Language as a Data Descriptim Language

The DDL tit has been developed aontains all the data definitim

facilities of and PL/l plus other unique capabilities for describing

data structures aad organization not found in these languages. For exanple,

Ule WB; language and its processor have the ability +a -Ute the length

of a data item at -cution tire and to accept a variable rider of occurr- of variable length data item. The actual syntax of the' DDL developed is not extrely crucial to

pinpoint; the way tile processor was impl-ted makes it easy to clnange

the DL syntax. Namely, the specification of the syntax of MZ is itself an input to a meta-processor, developed by this project, which generates a

syntax analysis program for DC& (or any other language specified to it). As

sesn in the mre refined block diagram of the LDL processor in Figure 2, t3j.s

eta-proassor, cdllsd a Syntax Analysis Program Generator (SAPG) , accepts

descripticms of a formal lmguge sud~as DL& in a mta-language whi& is

essentially an -ion of F3NF. It generates a Syntax Analysis Program (SAP)

for that language (Wiria'I, in our case, is Dm) and invokes manually-written

processing routines. me SAP for DL& together with manually written code

generation nudules form the bulk of the DIlL processor which, in turn, accepts

the WE@lL statemmts and generates a PL/1 program.

The inplmtation of the SAPG and its use to inplmt the MZ Systan

allows &anges to the syntax of KIL to be made relatively easily and in a short

period of tine. Thus, this processor muld accomodate o*er Data Description

Iaquages with relatively little effort. This is a crucial fact, for su& languages are considered -tal until experience is gained on their use and dfecti-.

C. Capibilities and Applications of CDL and Its Processor Actually, any a~licationinvolving one input seqmqtial file and one output

sequential file is a candidate for use in the present DiZ System. Sore eqles of tile uses of the DiZ language and its processor are th.r follcwing:

A Language for Ommmication aetween Eumans Pbut Data Structure

One inportant application of IXL is as a mans of ammmication between

htmms about the structure of data. For exanple, using a MZ, a designer of a data base can describs precisely to an applicaticm programer the exact structure of the data the programer is to use. Furthemre, even non-technical

personnel could learn a Dm-like language to describe data. (2) Restructuring and Conversion of Files

As a utility, tle DDL processor in axjunction with llML enables the user to redefine the structure of his file, reformat it and convert it accnrdingly. Furthmre, anversion of a file can be done selectively; i-e., tbse portions of a file that met a user's criteria can be selectively mvertd or copied to a new file.

Interfacing Files with Different Program and Programing Languages

Frequently files created by one program mnnotbs processed by another program or by another program in a different programing language or mnputer

facility. With the DIZ processor, files can be mnverted into a structure or

forrat which can be processed by amther program or machine. In this manner

files can be interfaced across programing languages and cmputing facilities.

(4) Validatim of a File By defining a file in DCIL, one can validate it amording to user - provided criteria written in DiL. II. US= AND CAPABZCTIES OF THE DC& P-R WIPI IlUETRATISE EXAMPLE

A. Usage and function of the DIL processor Figure 2A S;IC~JSa block diagram of aeusage and function of the

DC& processor. A file canversian pdlm using ae DL& system passes throw bra states; tne user is responsible for fodating and describinq the data definitias, mappings, and dpulations in the DXL/DML language, and the DDL processor wiles and executes these descriptions .to pruduce *e desired file.

mumrating W process, the user is responsible .for producing the following:

(1) a EK& descriptim of the source file,

(2) a description of the target file with the associated mappings frva the source file, and

(3) the DlL routines for qecifyhg criteria, special amputaticm, and ampla conversions not built-in to the systan.

The IX& processor, in turn, will generate the f olhing program and listings : (1) the desired generated PL/1 pmgram that perfom the canversions (this program declares appropriate variables, allocates and opens Suffers for ti.le meand target files, issues input ummnds for reading the source file, issues output amormds for rniting the target file, .

and in* the user provided CT4L routines at the appropriate locations) ;

(2) a listing of the user's DB&/DML statmats; (3) diagnostics for user errors;

(4) a cross-reference table which has an al&abetical listing of all the narrres which appear in the user's WZ desaiption along with its attribute

(field, -up, -rd, etc. ) and the line neof all the statenmts in which it appears;

(5) a listing of the wedJab Cbntrol Language (JCL) cards which des- cribes the input and output files and are needed to run the generated program

under the 05 360/370 operating system. WILL BE I LUSTRATED DDL PROCESSOR IN -L USER WTA DEFINITION DDL/PL AND MAPPING / FIG, 5~ 4cRI PTIoN LISTING -Ic - OF SOURCE FILE / 4 a3MPI LATI ON "DIAGNOSTICS FIG, 5 /+ 4iscRIPTIoN LOF TARGET L, FI LE f4 . CROSS-REF --_.. - TmLE FIG, 5C . A

WTA DFlL ROWINES - 1\ PW I PULATI ON "'- REQUIRED FIG, 5~ J - JCL

L WI FIG, 5~ ,GENE RATED ----- EXECUTION OF GENERATED FIG, 6 PROGRAM

(ILLUSTRATEDIN FIG, 4)

FIGUR 2A: USAE A0FMCTIQ'i OF THE DlL4'4GUAdE AD PRIES334 generat& pIogram, integrated with the userprovi~DML routines, is input inta the PL/1 cmpiler, onpiled in- ma-e language, and e)~~cuted to pmduce ~e desired target file. The above listings will be illustrated later in Figures 5a - 5e. B. Statenent of Prablem

In order to present a brief discourse on haw .to use the IXX system, a sanple prcblem was devised, irrplenented, and reproduced in this section for illustrative purposes.

It is desired to mnvert a given tape amsisting of text of nem articles

into one wficx;e records are of a mre legible format. The format of the source records have the hierard~icalstructure as sham in Figure 3a.

The iWM field contains a 5 digit nrnrber v&i& is the nwer of bytes

amtained in the field Iil!EXT.

IXZtPSEQ is a Mgit field which contains a serial number assigned to the news article found in IN- m. If tkbe article is mre than 1 record in length, the sare document nmber appears on all related reoords. UQE is a 8-character field containing the date the news event tDok place. TUE is a 5-character field containing the th of the event.

lTlZE is a yiablelenw~field whose length is to be amputed by a user

provided routine called EWEDJ.

IN-?Em is a field whid.1 contains the actual news article. It has a variable length of up to 4088 bytes and wntains either the entire article or a portion bereof. In the latter case, the article is amtined in the next

recprd, but in no case is there ever mre than one article per reoord. The desired program is to perform the follwing conversions:

(1) the beginning of each article is prefixed by a collection of fields, FIGURE 3~ SOURCE REKIRD STRUCTUE

r OUT-RECORD

I I OUT- I NFO OUT-TEXT * b

# I 1

. TITL~

FI GUE 3~ TARGET E00m STRUCTUE mtedas INF~WPITIUN, fm which we wish to extract DRTE, 'ITME, and TmZe.

(2) Zhe body of the news article oontains special sequences of daracters, which shall be referred to as break &aracters, in-persed throu$~~utthe mws article. These are to be scanned for and eliminated.

(3) The desired target tape is to mntain records with fields WCE, TnE, and TlXU3, if apropos, and an OUT - field, as depicted in Figure 3b, which mnsists of the presesved text without the special break

&amctem and intnxluction. 'Be target texhral mrds are to output with

a nraximunn of 75 characters per line for the purpose of legibility when the tape is printed at a later time. For efficiency dderations, hwever,

the 75-byte logical remrds are blocked to 7KlO characters on the output tape.

Figure 4 shms the dmp of the first few records of the original tape,

while Figures 5a through 5e show the listing produced by the DDL compilation

for this sarrp?le prcblan. A dmp of the first few records of the desired

taxyet tape is given in Figure 6. - - -XT, TFCCifjO null 72 (1 i:r)fi i::!fi : !: l F:J~I~T~?~)==, XXX C@C;STDERC\TTOPiS OF SYP'PAT 4 HYe==, (: AC1.t rTL) .CLIF-;''LL.;i: I JS THE SIG!;~~FICL\~JCC:OF rYC. I[:TF~!SIVE 2 - - - s}tlP,.,!-..r: ( Y ;ij;,'fi? 1.t. ,'.r; Ti-j cb (? f7==- ;if.!S!.i~i<: i<:>T '3.- ALL.9 -- . - - - . - - . i) tEr:. - - -. -. cpr --EX-..<-..r --.---.- Th r ; ;'.I. , - r*jic~ -~t:~lC'f->fi~==- 1 JSIST~iJT IN TtIXS Vltt'lTtl H ST'liE 1367. I J i Tt+Iq==, IS ALSO A riLACTID:.l TO TFJF liELL-K*j-J1..j:J FAC - - . - - - ,*-(,; :, ..zy.. '. - . - .- .. TI): i l5r:i~EL +';. 1.. ' T --- n-',l,,:3i-i\ rtt---dSS !? - Fff,-f s--i 7"3 I~IFLLIT'!cE-' I:., E: SyPT ?,;t-jT PC. ?:E-,rct rr;=z- 1 T k4F.5 "O? kCilJ Gf(tr4T f\ct!IEVE?lE.I'JTS FOR 1 TS PRO TCL.':: -r- ALL TL5. :- ' ==, ~"'IIJT~LI'.~:,CLbL? p,5r?: ".jiiAT !jOF?T OF bLLY \\kF Yo U? fl; i'i *,.;E P.tcc ==- .*f.nl ( I~I.I:I..G it'r F 1~1~YFA~:. ,IP:C@ r'gT A srrL!cLr ccjLr.IF:f; .. . - -.. ... - ti;.j?.Lrj.==, LIT~IFT<.YL.C.:rl:r.f #!C 1 Tiilll!" 1-C1 i-tiLP 1:s. ill(- ~OUF

CClS;!i\!.T: r Ti :-a T I TS i f LL,~;i t I i k F1fJl ILL C0f.17 1:ilJE T@ I-.E CC;IJ~I~JFKA[:LE.

----- I I:t I . ' 1 1 -a I. I I Tri Sl i\tr;G iflF F.1 11s STbTljs F.".rrl; [.'Kf'ST[bc 1t: TtiC==, C:) FJ: Z b' F.d..:Y ,;Y SiiFt)P!r.!G API~IS;. 1 GELIEVL TIicRE IS ALSO==, n 7F-S IRE-TQ-T-~FC;TFi -- ~;:~J'-?;,-[S$~!j"t--'"''A -. &r-LT, 1<~~~-~-14 - -u i ~~~~~~fi-~-~xfcSF--- €I Y SAY T",,: "IF YC1.i !!3 ! TI'.YT. ;.IF !:?; E irrTG r\CCGLJF;'l r kkh RAY &fitl\K==, OUT- -1 -- -7;F \ I t ;t t 5 fi \ITT~~TFTIL*-FmS rSTflS=, AAR UF IGE KVES IlE3L. --_-- T : :J :r IT' LC l.i:,.~tH 1PtSt COiJI)ITIOr;S TkAT YOU t~fiVE==, - Fe:-L+ i VLLI r".tt-{r 1 b 1 rlt 1 if- -25'L ;.lL !?t.l:;(; Str:T TL, LCYC'TIA~J~?==, AN SUED: LF CCttliiSF'. ALTiinL:;cl I r,l c,.OT cAi-'At.LF OF ~LIJYIMG--;\s==,-- I AM NOT C ~~APb~\l.~-C~~CO~;FIkrr.i!- -,":k7-FriCT*cHb~ P';L~\TE-$T'~F~H~~s ==, TYPE'I-IAvF, AR~TIUE 0 .==, CLJrST i:ir.: Y3Ci C.Ft. 'KT CrfJC\t3L€~ OF? YO11 LiO I'.:.OT wA;rT Tn?==, - ArJsi.erxi-'--T--T?. ~~FFil:--iTtt~ Jl.~ljrl4~ATI~!~. I t',)cSFSS TCT~S~JI)T-ETT~E~FI~:~O==, scvw ITH CCYTAIijTY t nrTt4f fc Oh JUT jGCh FLAT;ES riAVL AEHIvLUe I.JI~A~==, IS CLEAR 1s I !-:AT iVifii?:rr'1a.t-I- .L.;,L i ry i.,Lr~f'bI.S1:rivL lii(fll\ltli AiJd 1 HAT==, TI:F RATE C!F StIIP?+.ni:I:T IS HlGII, T1-,LiPc I,JilkTl:.Eh A t.;EPOH'I AUC)UT TIiIS==, cjH /\Ply---- OfwL14 TYP -TO~- FLCGL~~-F~~~.~T'-(~~k.5'~CT -7~7 ----c ACT A-IIYTHI~.IG. TF FA~TT 3 THE r T!irl:E i s 6: cnr, ~Tr.bi.UrRE 1iat G?CE~-YE~.'I==, OF TI;€ EGYPTIAP: MIL: -~~~r\~v--7~~m~"tr~~rUP:= :;Ts;:. CIS kc:{ THL ri.i-TxX~r==, . I A r? S~;~TL-TTK~-TI~F: PHO'?T!l~.f,CE6ILE.i 13 'T 1:; LI.jl,.FL 13 T~EtFFUH1 PUTH==, TO CkLX FBYPT AOO 1 1 I 1 i . L 1i.J i.SLl.'i:1_ L,SgCtL==, i\!117TI+E IJ:rITt:l FTATLS, H ERE. T ?'!:

ft==, ~i~r,t.. :r I o;~+~ 4.q~f;il~c .s~f!c pub FUI~ b:t GO 1r1 T&JS ~:ATTEI{...... ------7 --- - ..----.------k.%id7. T I,: \ .I 1. ----T7TTm= = - ~:s~'ET+~-'I-.-)c F,OT T11lt:K t,IST[)HIi,"S d11.1- :;c3y ,--F r~i::~:-tI;!; T ?T:;==- . ?:t 7Vf~t,r,\lt CELT.: ,.~Ffih I}LIRI!'.~CTtll. CAST FEi;'

yt J-.. iil I . ;i I t r ==- '.;I &!Jut l.k-l'rt~ t-t AFT) SlrLt! I\ C:)IJPI-C.1I.T 1. ;{i).; CJf'llt r!~I < I., ,I- ,*11r5 (I!-,==- - t i Fir,; 1 tlf L~lli~.~CfS JF C;GVIT T I!ilf:tiVi >!T .. -. ------r--j- T-c,;-:..-,7-- ... ---.- - ~CI!.. j il)==, - i sn- 1-, r\T !.,i--TGi?O-~.-'-I:IU t? S E L V 1- 5 1 pi ' 1,- i-JI\ I.. . J C T d '- f t l C E' x T E.JT==, T':nT 1, l I 'it t',qiJi:L\ .-)! I. -AI'uU l!'JC1~FCCT FuliCtii 70 :.JITt!lJI?fiL'. TLiERl ==, .- Artr --;\F'Ez -~~.LI~~~-SEVZS~;L--OIIS~ACLES 1i.K TliE - f'i\Tti OF SO\'I ET- I'hTI. Hut Y f'l[.)I!.== . . --- f JJSf , r- ',I L , 2Ciii iJF!.'t.f, I,.. rt-li f.*?t;\ 15 I;[IT Ir..C-j:F,II:F,:{I\:;L'. rt;'[, TifL ==, , kTsP-5 5

C (729$ZO? ?;.';il I i-' CTk1 -is,-T'CT' tll,~I;;iITEOe STC31,ilr THI [If Sit ATTAC~~LS''itIGi;T==---- Ti, lilt. i': ! ii'liiTy I.!F ~J.S, I.1LViTIc~. I ThZl\tFni

-- Oriitl,' STt I TIIT'; /.L-bD f.~'t'LlLs TC1 CC??I:-;Tf CC.l~;dTtiIts FClriT}!tH A\nli\Y FtioF: TI!L URLF. ql1Ii==-- EFFul

N: *?.{ E:ijt\rr 9 Ljfl v~L!i \lrtx f k-2.: lt-.;iT 1 HE PULI TICAL OPTllrldS==, AT OtJt( [)ISPO

SAl. LIrdIT.T US F iit~~1tiL i\LT SF-T? Il-iL: tlSYPTlb\rJS SMILL==, sOMtTIMCS 0% VGqCO--. --.- -.-- -- - ~ - -- gr.~r!I GET w firm SUI~~CTII*I~Sr;,l J;;.F'~,. r1.d~ HE SP.'O~.JSLS==, FRO[.! RUTH SIDES* rJtiIL- - b~fiVF- k;C)I4', iljtl I. \l=tJ .-I\'ft! Frtlt.'~CL)r==, E WF: --TC t -- THE IJidITED STATES.==, APIs!-IEF: I?+IU~:LLYTill% b1FI C.H€IJCL EXISTS- BUT TF T kCHt TtiE==, E GyP~?i\:lF3::ETGId rr.I;;Ts~~t~1 *,,.r!rLLI r:C~t3L: GREATLY CORFORTEP OY IT,==, FOR Ai-l?? r\LL TIit F'I2::k 1T 1. ... L L J,I.J~ ,-i.T r_F THL [;HEAT OI3T1O~iS, Ir:HPT HA3==, Tt4f RESIIl-T iiCtAll? 7 :-itiat, St'L.T [c T!-.A1 '.'b: ~ili'?AIl,I LXAC)rLy UriE.HE==, WE UE6E O?d -.- --. ------.--- THE r)AY AFTER Tlic VCF fir,.'] IJf) UPdt YI\S SUCCEE~J~~JITJ PIOVIPIG==, A ST1.IGLE ISR- --- AELT---- C;r)LDIER Fft~~lfP sTr.CLC P:j>:IIi?!i.==, 3UEsTIOtd: hAvE bk EVE~TRIFC TO OPF?J A uII\LOG LITI? TI r iJsSr?==, bH OTHEF EAST EUtiOFEAyl CUUBTHIES?==, 4"Sb!EH: YE:~I lJfiilK T!

FIGURE 4: CONTINUED 1 :G?JVFPT( 5FiLi YXT? TsILS):

. .- ... --- .a- / tt*****~kffir*:*h*$+~r+*txri:.~i(*i*.:dr~ghh**hkhi:f *tt.*.t*htd(f.t;64~hi,tf*f:t3:+%,- /* " / f -,-e /" ,b..>C)T37!p'J -+? Cn(JnCE FILt +/ I* "/ /*t*r**1.t:* **n k..r***nft *t.t.pirf:r.*xi:-kk*r+:':*f n~t:h1**+t~*f:~~:*?4*t*~*~*ht+=c~$h+'/ 2 sFf~f1s CIL~(!:.; -?i---l..'" ,g~?.".~;-=~r;.~-rr pr ) ; ... .3...... IhJ,h?C3~D !S 3 :t3<7 ('td" x 4 - LCF~~T~. r\7 CF 'IY-TFYT' +/ .... 3 , J /* rc!: T?L h~.&FS?C,\l(r? ~7 :S'T rrr. L. c r 3 . . , !hrF'7R*bJfI 11.1 (3:l) ,2OC: -CQTT=@ INTPT* /* !\i?::~3l)~f!3:. 77 TCXT -/ 3 Trl-TrXf /* ACTUAL T=XT */ 3 ,':~f=va:! rs~~(4nsc) ); ...... - 4 -.- ...... -..- .... y!l,? If P? :L7(\!!J'l,D!fTg?C= lQ?'?CC, 1) ; 5 n"~l‘\?‘!f1 5 =!:;L?(CU?.~'(~)); .6. -. - FIT.! I ( J'It!KOl 6 9 C;TGV!C, . -- 6 .... J'.l'lU:32 6 9 9CTE ,..-... .6-. .... ----...... JUr!Y03 . . 6 , TIM= . . 6 - . .- .- .- - 9 JIJn.!K34 - 6 9 =?If -..---.. 6...... - 9, Z=Y 6 TITLF) ; ,..... ,...... --.--...--....,.,-,, . JUQK31 IS FIEL9 ((CHA?!6)); ...... -. . . 8 MSGN3 IS FIcLD (CH3FI111); -..-- 9 .. .-. JUqK32 IS =IEL? (CHPa(23)): ..... 10 04TE 15 Fl=LD (fY!,Q(8)); ..II ..... - ...... JUFJK03 15 =ICL3 (CHCiD(3) 1; 12 TT'AE TS FIELP (CHcQt5)):

,.,,.,, ,.,,.,, 13 ,,...,., ..,.-u-,,,-..- JUbJt(3'i I 2 FIELD (C!it:? (24) t ,. ,-.. . - 14 C9Is 1s FI?Lr' (CHI!: ( ,=8!CLrF4')) : . 15...... ZF.4 t 5 F!4L9 (CYt'=(lZ?"tFh!r 1); 16 T!TL: ! S '?:L3 (CYCo,('TyXTLFC'I) ); 17 - ... I.bl,T=XT TS r!=~n(c,uhs(co?nr31 1); 19 ~AG-T$P= IS TI??=(vA?~?~LY (4c)9b) ,V!~L,?!~.~;'\F:=XO~~,?~) ; ..... --- ....-. /*k*t:.?:+tk**+~*~k?~****;k~*ie;+~.C*r?*~rlY~~f*.t+t:-r:t.(L*f: ht:*4$:4+?:ef htf.t?t;.1C:?:i-fkC: / /* *c / ... ./" gESC.71PT?FbJ flF TCKGFT f:L=-. ?/ /* / . . /***%#*a$&%+%kf: Chk .':i:+rc?fra ~ttj~f%:rr~**tn~rart:kr:i~9:~~:+*?;.c.*$<**)?*?L(~+*+-. *+$.i:J:k.I.I / 19 TF ILE IS F! ~=f?'.I'-?"=.~Rc, ,ST~C E~~=YA(,s? 7 1;: ; .. 20..... 3UT-QrtcSD IJ2Ci?2n( ruT-Iy"7 (2: 1) ,trc- ra?.r=*IJcri>fc 1 20 , ~:~~-TCXT 2 0 9 $!Zr=V~F!riL:: (47'50)): /t EACH 'Q'.IT-RET')SI>' 1s 5' *!?ST 4790 ztJC?C 1-7\IG. THE 'fTII2L ~~\lr,f~T s T)~T'?:

....- - ...... -. - . . -- - .- . -- . - -. -- .- - ..- . - - . -. . - -. . - -. - .. -- .- -.-- . ------.- - -- -.- 7clJal-?'1: ~..l,i.i: /*------'------'------. - - . - .. . .- 1 ~i,~?.-.i:;.. ~7~-i'j Er~*;

1 ..;[):Jl.i.-iF-':l.-l 'zl:?i'. I .... -. ------"'-"'------* / rbcL ZE*-;I 1 TI.,-.-: (611 I I-GSL!; ( ZE.,:.PTP I : ... - .. -*-, .- - . .- -.-- -- -. -. ... --- /* I : ,,Jr ''5:t- 1,-1I1.[r.!j I:)' THE' -c[{l\-f:Acif kt * =( r" ;;'T,t;r .:l:L I=\. !:.X(Z<"',FL?, *=*)+qi .-- ...... - -- .. - - .. -- .------.-----.------:*.k.-l !I\ i : I i. zer I }-: ; - . - . . - - ...... - . - .... - --. -.. -. - .. .-

- . -.. - . -. .- ...... - . .- -. - . .- - -. -. . -. .- . .-. - -.. TY;.'ra-!Ir : ;:t,k,c; /*------... - - ! .- {j~;,, , j,.,-c kiy: ,.[.ii ~,:i~L~~~-,-~-<7.~~[,i--'-.!;I ~;~rf-~,T[~--Ti~~-~! r:TG.T[T-L-rTj.ir--i- ! : F!.t-!i 1l'jI~F'. I . . ------* / !'ti \I?[.',FL'\ c -!:ii?(7~:'?);?PqE[.l(TI I'! E .[:TI.) : ,. .- /* 1-7 1 :. :.vkr.iT;.i..'T: i.lF Tu Titi LC:i(L. * (TXCtif T;;)* cli; * (lL..T)* L/

(',p;.,:i'-: -.:I L i= p,;:(l:LL> i'riT~Z-l-L"+l (-* ), 1 I,~EK(TITLF-FLL~,*(T*) )-1 ; .- - .- /t !I' i. , [,-.1-~ .; c.( , ':~~';;3T';"~.t''-"~::[ 1.!I-, 17~, r:Qt==.,S;.--:-7---- IF r;, .'. r-8'1 :-*'I 2

FIGUFE 54 - 0:iTINIED * == ' 1 Or: ...... -. - --. -- .- 9 =- *. */ 1 OC-i>: J=X: i Lf(~ciTq'='): - .. -- - .- .- - - - - F ii.: If- .J=L~ Tk;; BJ ,.,'\ . -- .-" * L r :.E=TFTT: Car \I,FL.. ,Cti;,r\=CC'i\',FLC',CP.'? I i!.i If:: ..... - ....-...... - ... --. . .- .- ..... - -- - -..-.- - .. -- --- .-- .- - Rt,Tcl~-l: f. I~ r; ; t r L:. t.,: + : L 1 I ) : /*-----,------,------J9=------.- -- i TI,~,-, i < -ciT'.?Lki i ;-i,~Lil(T) ; - .- -. -- .. -, CC .....;.. ;-,. :- -

! fl Ll: f:,'..(?I<): . - . - .. -.. -...... - .------.- ... -- f CL 1 cce; f r-*, $'-I:! -1- I , = * * : -. ,'+ , '1 ;.i( .. .T7- 77 i;V 'T:T~.E* T7l Ti:r LC(lAL. 'TTC'. . */-.-....--- I!- : t :: d..L :..: * :.7!z.;,.\-k-lt); ... .-., w-...- ...... -.-.---- ' -. /x, ni\-TT". t'~.:-.?j.-~CGr"c-.~at;T~-~!TET-nT-f-~C~l . c. .. *z=- ' t

. ~ ...... -...... --.... -- ...... - .. == '1- 0% -- * = - ' . */ ..... - . -...... -- ... 1 r*[-c:,j=l ~f : (yl~.*=* : --..--. -- .-.-- 1 : IF ..I=< T!.F:: .... ----.- * - - - .-I , - ...... ------I.'" . L I ' ,:=TTL : -. , ,-ril,,i.;- , , -- .-.. 1F (:

.::l:,-l-gq,;Lf: ------.-'..---.--.----. If: [.S',-<-STT(-TTL ,-..*I ,2, .= ' =,.",-~- (Sllf STt (TTl-r,J+ls2)='= '1 L --.- . ----- .------.------. . -. ----..- (SilI,STi (T?L, ~+lr?)=*, ' 1 Tiff~~ FIGURE 5~:DDL COMPILER DIAGNOSTICS - - CDNVERT

"-...... - ...... -... - ....-- -..-. . .-.- . - . < . . - . " -- - 1R YGG-TAPE TAPE . . 2 r

FIGURE k: CROSS-REFERENCE TABLE FILE 11

...... FIELD

FIGURE 5~:CONTINUED . . REQuTPED DD-CARDS NEEDED TO RUN THE OBJECT (PL/l) PROGRAM: -23-

--- ...... --- .--...... - Figure 5d. Required JCL Needed to Run the Generated Program.

4 1 I

i I I , *- 'LI C i r. ..I -0 I- n 1.4 - ; + " =' ! -a < 8-1 3 I- 5 J w 1 U r I - =: i LC' LL - 2 ;+ uit i 2 *- 0- J c L O'r t l-8, z. re L,t --0 12: - -L P. - 3- -J - = L? < 1. It 0- - -., - -. t L L Y. i L,"- v' *- t .-, x A - - -- r- L *. L: , I It k- T /- L >' J- - 1 !>I C 5 2 ,"- -- C.' .,. -' Y --'I L-

I

I ?-, .. :

FUM m F

'c -- C G, Q z r r lc F' r

i I 1 I I i I/. ;1 I W I: lGI- J L I,> 11 Ill It I; L? I!Z I L I d I 1 !'J I.= :I' 11" I - ;12 :1s' L: 11I I r: I U . I l=q; I, I 'r ; IL, I I;CwI : I+ : II. I 'i II 1x2 I 13 i I1 'd 4 I I IS , IL5I4: I2 I I- I I In It' I :f 1, 1'3 i It I II i I c I I 'C : IZ I I2 I -I I I 8 i2 I j 1 --' - ' , IL- :,c c: It- J 117- .* , ti-li t- , *- I LI CII : '- 1 -.: -I&-- .- ,, ,, I -I--- .- I . .- - I :'. 1L+, L '2-I - L- I I :.- -. , -.0- I I ' 1,' L'l .- I 'Z .- 1 c '- -:. .-+, ,aI - - t 'T7 11": -7 1 tL ,, I I -. - - --. L.. Ic' I c " t V. r: k I Ili .-r-- :I, +,,. - .C- rt , 4 --.- , - - - I -. \ *L A i-:

I

I I 'm

I

, , 'Z i: i: I

I I - -!\ +, I IL: I I2 I - I. t 11 I I u , I ' m !I I ,- 1 I., I :z .- it I If: -- rc 1. Z I I ;3 + - -I> r i I+ 1 - !f; .t ! I:, I ;r: - I I .- -:)I,- i lL I - L. : I, I - *e It I I - c4-lI! i I I&* 1 :,- - , , - 1 I, I )- Lit. - s I+ I 5 Ii; t I I I - Lly - , It: I ;I ;I - I* I "i 11- I % h'- - la I it!~ -i I, 1 - -a +' i I r >.'Lw Id I L', t I, I ,a:/I- - I< I .- ::,w x9 ICi ,I - Z *IF id I I I zi;r I', C- L -IL 3 -l* I! +- iL + It' I.II &=- +' - t- * k -.: I I r -A'; 1 ;1 I IzI'U !: IC ,I 183 : I I'3 I :s - + v.. 'I <~ix-I :I= ,I 7- ,u,= - IS- I e L;: Ikrl - 1 I ,_' SC I GrPCZ[ I-L' I r+u. i: I;&C I . . d ,; Id II Y&,L;iF' I ZI I ,i l " >MIL l ZC l I-- I IJ' I I 1- I I; I is, 1 1.c 3 1 -- I , I I i'I ;.I PC!I Jl -.*t ! .- .- 1 G.4 1 -1 -1 --:-A&: L I -:I L Ib. ,t ,I L -./( I-:. 1 5 '1 A - 1. , :.. 1 b I-, 1 1 b- ,L! *'I LI y -, C-, t GI r C. 5- I- Ai f L' ,. I -C I ! t: .. lh,=tl i -t-:;- ri - I 1 - I ,,';--L'r I C I &LC. 1 .a :p.- - a;; - .dl : I . + * I - \ - '. -- L .L.. - \ - --. I : I

! i ! j 1 c.' C, t%tv fitI i t I 1 1. 1 I 1

I b ; Jet\ r, L L-:<'<. ,'- r F C/CF C I i I I i I11 I I 1: ! ii ! I 11 . I

I I - --'. Icr: r ' ICL. I I I I t:L I IuiC I I I- I I Yl 1 1 -,I I,, I I-!- I I I

I I Is, I I-'+ 1 I Y! t 131 I I lCL I IrL I IUIC I I I I, I I u. u, I ICI I : !?'-!i I 1e:k I I LI,, . I I

t .-,sz I I -/- I I : i I . - - 1 I t I (04TE) 06/03/71 (TIYF .JQ :15 -34- ( TlTLC) SZC7417 :in7 39 ( i -'q&h( ?h'TFPVT-,J) XXX C3'J t I?'? 3T I7FJS 3F SYFIDt THY, (TXfF3P?s ) C)(JFST:r):I: lNl~lfT ?S TlJE STCqlTCTf. . pF fc~f !~Tc~sI~5 ~CHIDWL:VTS qc ;nVtFT ~2~5~:iFC~PT? ZyCdE': C!3ST "\ ?LL, 7 1: d--lT'wi\~(; **:,-* LJ . ~CIVT'-T "?L!'Y LJC.~ SEE?.: CC"$J jTFb.jT I?' rt-l! 5 '"TT "2 ;!?:Cr 1357. fq?[J"JF 'H:C 15 1LS' g 2-err; >?i r.7 74.: ..{r~t-~(r,l'-.t.! F$CT TWJT ?>-AT ;c~l~~VT'~-\T~=-U 1-5 P=fr:r.-c ~3 :,LL!::. TM: -ruy,@T!:'l~ r C:L.!L? :SF:: ~I:+,+T----.. - -r CLLY :-'y-IJ? k!:?:,: L.JC 3:~ A ran ,...,T fi CI'.'Gt = 5"nTX bl.?s *4nVE'>. -nDPnntrhtI%r$ ~14~CICTF, y '.:, .. 1Tr'-3 Yi:j L2;- 'YT';; ' 7 "LL.' tryr rip yril~I~;.CP 5 41.3~ ?,~C~!~JL.~?LV:Ci.-z-?\/:: ,W T:';ri ;*. fi;: P-?C~>F.L~31 _c?~:c, :~,Y(JI TL(- L?Df,t :IV!CT pzE';:~!r,F. Tu:R-F.'J::r Tclr 9s;" \JI!'T CC~:TT~I,E HI^ ?T t,l\l GIJLDL~T~:TYAT ITS ;"= ~t':.:.: 1.r :CYPT :~:LL ~~PIT;$'J=T!? 3; ~ty~JL?F?~~9~7. Tcrc 9EfT Tz 3'' T~!<1s '-7 SfC:,''i~Tt~-~l ITS ~T!TIIS rht? FEFST?:;-: 1% TMr FGYDT!finJ LR'fiY PY SYIPDI?k!r, &RRIV'I3. QI)CSTI)'j: Y?!J 3QE \I@T CAPj3LEl 32 Yp't cn '..j(JT \.Ii?JT T3? bYSWER: 1 MEPr.4 THZ !''!t!'~~Y4TII7%1 P9S jES$ "q 'J3T F6J?\q(_E$12 Tc SbY NIT4 tZt2TA!sTY dHfTaiP '3Ti IinT SUCq PLt.hFE Hb\lt AZR1tJFC. WHAT !S T_LF??R IS Tt-tC,T ?-'hP4Y t?!C,tt-3[1ALITy k'k4D?YS Fl!VF ti;CI\tc3 dVT THAT THE QATE nc SHIP\'IE:!T 1s q1~4. TS-ICIS, WYET~IFPA ~EPC!~:C~TUT THIS np ~41~17959 TYD~J= PL~\I=:,z FG~:JD 711 PF TD(J~~rlct. . -- \!~JT A~D?R . OFTACT :&Yr~Ix!~, fk45 "CT I? TU,;T fu=Q= IS 5 fT\yT!P!!j;?!.IS QcIvf37Sfwf PIT 9F: TilE EGY3T14'4 '4ILIThQy ~~PL~Y1.'~hiT5)' rq" U5cG, C92. Tp7 95P77' 9 ! Av 5tJ2 Tf-4.fT TUF 3:- ,lI.!Z*.!ci :iV'"' 7.3 IT ?!: Ll\lK?? Tr; THC 5FF')ST s;7Tr TO CALV EGYPT &P.SUT SrlV!TT ?YT=!vTITihl': 4N3 TC PPESSIJGF !2?AEL AY3 71-4: UIyITE3 STdTt5. -!??,? I '1~15~5:y TV~TTW" .. ~vr!?n~~?;- Q~,~cT~~-+~ T? Tw:';? 2c3JPTs PY U.S. 3"''\1?- 3."';rTF2Y LtyQr. W65 V':CY RFY=FIc.I PL, WE 5113 THESE Q=PQ1TS bf? d SCU?C= ?F b,t';n@Y AP!T\ !!TF 1;FLL-FQ(,Jhj?rn 4Y3 THtT 74: :J\!IT::> STifts :.!:LL VJ~TFjll?GF ~"l'!ITS Pf?L: CY 12' PcFV=.IT 15JG A,PJ (JCSrT 3XSG?,EL IS !>?S PiLt&jC-, QUf STIC''.J: T'.{r ;(J,SS!&'jz ?-ILVr Ps,zVE? p.."Cr Typhl r,?\JfC TL(:.f TLlTY QFTE\? C?f.t9JT '432' 3.4 Ttj-!: 'j>Ji"Cc.- b~-bK >.??'-!Tf TH;.\~ nr?~H$V?W~ !! c='d[t?\T: CFSlaC TO DtJT TH,:?; TLdnZATS !vTr) ?.?/ICTlcE, 'GpcV TFC Fjq\I=:.!Y ::l4:4t!.!"; I+,! ?\ C:F]IT Tr T:{' yT=\(j T,4,!!7 Wf t:r ;>.ARfi,LYZ,p .I\;?1 q '"C'C' FI~;C :? T:? IJTTI-I~:' **, T us:?7 ARE, AFT>:. 4LL, SE_V-c?.L 7F.STACL'S 141 tH- pATk8 CF yQV!pT ~?.T~;VC~T!(?~, FIQcT 2s LLL, 9!J3 P']W== ?\iTbI: AQCb IS '(77 !yC3VS;?F

C. Features and Capa;Jilities of the DaL Language and Processor (1) DRL language - data definition A descriptive staten-ent is of me £om -nmne IS attribute (description); where -narrrt is an identifier given to a particular attribute, attribute can be a FILE, REmRD, GEOUP, FIELD, TAPE, DISK, or CARD, and description is a statemnt of the characteristics peculiar to that 1 I particular attribute name. 1

To categorize and illustrate these points, examine the follawing table: I

ECRIPTI 3i

FILE STATES ME NAME OF THE SFILE (LINE 2) IS T~E STORAGE M€DILIM ON WHI Cn ITIS STORED 3iriE FILE IS FOLJND ONso%k . fhl AND IS COMPRISED OF RE~RB1?4-8EDm8 STATES THE NAME OF T~E RECORDS WHICH COMoRISE

TiE FILE, OF FIELDS CALLED ~ dm, mmfl, AND I:I-TEflt EQRU LISTS WE NAMES OF WE G UP CALLED COWONENT I'BBERS OF f.ibh86:i8RP T HAS A THE RECORD, 0 IC4L RECORD LENGM OF 43b BYTES I GIVES THE LENGTH, IN BYTES OF A LOGICAL (USER) RECORD,

LISTS ALL THE SUS-GROUPS IIUFOWTIr3~4 (LINE 6) IS A AND FIELDS S4HIa-I COMPRISE IT, GROUP COMPOSED OF 10 F IEU)S 1 ~)ESCRIBESME ATTRIBUTES KG'S3 (LINE 8) IS A FIEID U OF THE FIELD, CHARACTERS LONG

STORAGE MEDIA THESE STATEMENTS GIVE A TflGGT/$'E (11~~18)IS ME NAME DESCRIPTION OF TAE STORAGE OF A DESCRIPTION OF A TAPE MEDIUL? AND THE PHYSICAL WIM ARIIULE BLOCK LEGM CHARACTERISTICS OF THE FILEI OF 43 6 BYTES AN3 EXTERJAL SUCH AS BLOCK SIZE, RECORD NAME OF m2Bm~LL OTHER LENGTH, MELS EXTERNAL ATIRISUTES FOR THIS TAPE ARE NAMES, ETCt DEFAULT TO WE SYSTEM; . (-2) DlE language - data ma13ping-s

LLISTR9TI @I SEE FIGURE 5~) MAPS A CONSTANT INTO A TARGET FIELD MAPPED THE CONSTANT ' (DATE)'

MPS A SOURCE FIELD OUT DATE (LINE 23 IS A TAR5ET INTO A TARGET FIELD FIE^ INTO 'MICH IS r4APPED THE CONTENTS OF THE SOURCE FIELD DATE

;UTE: THE DDL PROCESSOR MAKES IT VERY EASY TO ELIMINATE FIEDS FOUND IN THE SOU~CE FILES WHEN CONSTRUCTING THE TARGET FILE, SEVERAL OF THE SOURCE FIED I SWAS El) AND BIs HAVE 3EEN EXTFtACTED BUT ARE NOT C9PI CD ONTO THE TAffiET FILE, AS SEEN IN ME TARGET FILE DESCRIPTION IN FIGURE k. -38- (3) IT& routines - data manipulation LUST WT I @4 SEE FIGURE 5d

LOCK MIS TYPE PROCEDURE DETERMINES WETHER OR NOT A PARTI CUM RECORD IS TO BE PROCESSED LENGTH SHIS TYPE ROUTINE PERMITS VARYING SHE LEN lli OF FBIS FIELD LENGMS FROM ONE RECORD (LINE I8 IS CQMP~~ED TO ME NEXT BY COMPUTING TdE WNAMIWY BY ME LENGTdS AT RU4-TIME DL ROUTINES FBISLENI CRITERIA TriIS TYPE ROUTINE ALLDWS A INFORMATION (LINE 3) GROUP OR F IEU) TO HAVE A IS DECLARED 0 VARIAI3LE NWER OF MEFBERS APPEAR 3 TO 1TIMES BY WECKING T-IE EXISTENCE OF IN TI-IE SOURCE RECORD EACH SUCCEED1 NG MEMBER, DEPENDING ON CERTAIN CRITERIA CONSIDERED IN THE USER PROVIDED WL ROUTINE INTROs THE TAKE GROW OUT-INFO 1LINE 23) APPEARS IF AND ONLY IF INFORFNTION D3ES 4 - SPECIAL ROUTINES \#-IICH WILL PROC 4 (LINE 28) SCANS MODIFY RECONTENTS OF A FIELD FOR AND ELIMINATES SPECIAL BREAK CHARACTERS IN IN-TEXT- BEFORE 7HE SOURCE FIELD IS STORED IN OtTT,TEXTI

(4) Ihe exanple shews the specification of a tape to tape qing

and canverc3ion of a file (=-TAPE (line 18) MAGAZINE (line 29 ) ) ;

oxversion &tween files on other storage media can be handled as well. Sane interestirg statistics regarding the lines of ade, are

-ts, and the requLra~~ntsduring the various Mases of processing for this saqle run are given in Figwe 7. The statistics regarding the nmber of reaords processed and the time it took to transfer and manipulate the data reveal that the efficiency of the generated program is amparable

.to one written by the anventiondl mual manner. At tbe samt the, hcwever, it took a person a lot less tine and lines of -DDa statemnts than required in order to write the program by hand. STORAGE AND TIME RlQUI-:

? NUMBER OF' 03m mu SEm I/O SElXNDS S~~ a? WCBE

~m CIIQIKATICkQ 190K 2.82 14 30 DDL 125 Dl% . 1- 1- sINm I PL/I OOMPILA?rl:ON PL/1 03FPILER SES 2.33 4 FS MLrII rnRE AS 272 AVAILhBLE FOR I 3222 RYTES ExEcWION 104K 33.9 27 OF' rm3ENE LANGUAGE INS-CN a i

NUMBER OF NUMBEROF BLDCK BLOQ(S -= mGrH IN BYTES TRANSFERRED PER rn

INPUT FIU 14 3 1 4096

I,

OUrPm 42 7 100 7500 FILE I MISmmFIGURES: CPU seconds to produce each logical output record - .0011 Channel secands to produce ea& logical output record - .0006 Minutes for trained human to rite DMJDML statements - 40 NWrof Rurns for trained hmms to get a bug-£- program ------3 NOTE: All the above figures are based on a run of the exarrrple made on an IB.Wl68 Ccnputing Facility

Figure 7 QUANTITA!l'IVE STATISTIS -41-

11. CURRENT RESEARCH

Current research is concentrated on developing a Processor whose principle is similar to DDL's, but mi& will be able to produce programs of a m& wider class. 'Ihe current processor is limited to generating programs which accept a single sequential file and produce a single target sequential file, The processor is currently being extended to enable it to accept descriptions of multiple files whose structure is not necessarily sequential. Such a processor would then generate programs which would accept and process any number of files and produce as output any number of desired files. The processor would involve new techniques and procedures not present in the current processor. These techniques would have to be capable of producing programs which would input the files and sequence their reading in the most efficient manner and transform them into a set of desired output files, all this from non- procedural user specifications describing his source and target files. This would involve construction of networks of all involved data elements interacting with routines that process them, followed by designing and structuring the object pro- gram that will process the data most efficiently. The generated program would consist bf all the 11O'related instructions, the logical sequencing and control, and invocations of DML routines. Thus, generated llDdules would again me m~>- level of the desired program with the low level data manipulation to be provided by the user's DML routines. Such a processor would be another step towards the automatic generation of data processing programs and would obviously cover a much wider class of applications.

IV. OTHER POSSIBLE FUTURE WORK Other possible future extensions to the system might include the following areas in order to make the processor of wider use: (a) If automatic generation of COBOL rather than PL/1 program is desired, this could be effected by rewriting the output modules of our processor. (b) As we have mentioned above, we could accept another specification language other than our DDL with the aid of our SAPG. (c) Research could be carried out to develop modules to generate reports logically. That is, a processor which accepts non-procedural and logical description of desired reports could be developed to design and produce programs for report writing much in the same way that the DDL Processor generates files. Complete automation of generating programs is, of course, a long way off, but the above-described system is a small step in that direction. For a more complete analysis of the role of automatic program generation in software development, see 121.

2. N.S. Prywes, "The Role of Automatic Program Generation in Software Development," Moore School of Electrical Engineering, University of Pennsylvania. The author wuld like to thank Dr. N.S. Prywes, the project supervisor, for his direction and supxision of the project.' l!cknmle&~ermmtshould be made to Dr. J. A. Pmwho, as a graduate student, was system designer and original project leader of tk team that implonented the first version of the DlL ?messor. AUIOMATIC GbEBATION OF SOF'IwAE SYSTEMS - A SURIEX N. PRYWES

Department of muter and Infomation Sciences, University of Pennsylvania

iaesearch and devel-t on autmatic prograrrcning has been underway for nearly twenty-five years, and will continue for many years. An ultimate djective is the developnent of methods and facilities to producJe software automatically, on demnd, for the businessman, industrialist or scientist.

I'his paper considers this proposition and examines a nwber of related questions: what is a plausible sequence of developrents?, what is the social- eoxdc need for such automatic pmgramning advances?, what is the extent of the potential inpact of such advances?, what are the envisaged metb&logies? how will they be employed? and what are th? opresearch questions? The

paper is intended to provide rrotivatian for, and critique of, resear& Ward

the above ultimate goal of autanatic programing. Dmtof muter and Informtion Sciences, University of Pennsylvania Philadelphia, Pa. , 19174

1. mWCT1aq:

Resear& and developrent on automatic programing 'has been underway since early applications of digital cosnputers, for nearly bventy-five years, and will wntinue for myyears. It has started with the use of the Ormputer 1 to relieve the programwr of miscellaneous detail . Its ultimate cbjective is envisaged as a situation where software mufd be auton-atically generated for the businessman, industrialist or scientist, on danand. The uxputer would have to access the mined knawledge of the respective field of the application and of

amputer system design and programing in order to generate au-tically the

needed software, ready for use. !ELLS ultimate dsjective of automatic programing is the mah stbject of this paper.

The paper is organized in ism parts. The first part discusses the wide

spread 0311- that wst and effectiveness of software developnent threaten tk mntinued growth of use of amputers. This is offered as a mtivation for

acceleration of the research on automatic programTling to achieve the above cited

ultimate objective. The secnnd part of the paper atteqks an assesmt of the methods of a&ieving the ultimate objective of all autonutic software generation.

The first part of W paper is divided into .two sections. Historic and

eammic antexts of advances in automatic pragramning are discussed briefly

in the next section, as a basis for evaluation and projection of progress.

1. For instance, early developnent of mthematical routines at Hanmrd University, University of Pennsylvania and Canbridge University.

Work supported by OrJR Infomation System Program, Contract #N00014-67-A-0216-0014 -1- FrPm midway vintage point betwen the beginning and ulthte goal, it is possible to see that progress on autcmtic progreg has follwed a natural sequence where earlier work establis'1ed foundations for later advances. -Also, that rate of progress has been a function of the ecoromic pressures of dmd and costs for pmgramnhg in erqloyment of amputers in society. 'Jhen, in the section that follaws, the so£- developnent cycle is analyzed ,to identify the coqonents that need to be automted and to assess the benefits fran their autaMtion.

Subseq~lenttwo secticm constitute the semnd pax-t of the paper, whiol discusses future advances in autogMtic generation of sofdare. The advances described in the first of the two sections are currently underway, and are believed to be capable of replacing the human programers who are engaged in translating mn-procedural specifications into conrputer pmgrm for processing data. This is referred to in the following as aukmatic design and implmmtation

of program rrpdules. It is required that a caputer engaged in performing this functim, have access to lawwledge on ccanputer system design and proqrdng, but that it my be independent of hflwledge in the field of a specific application.

The sand part, autaMtic generation of overall problem requhmmts, is based

on computer access also to knawledge in respective specific application fields.

PARr I CuRREm' Pm- I;g SOFTWARE lmlEmPM

2, OVERVIEW OF HISTOIUC AND EO%JOMIC 03NSU;IERATICNS

The total process of developrat and use of data prucessing systems has been pictured as consisting of many layers. Figure 1 illustrates such a multi-layer structure by showing thirteen such layers. me exmination of

this structure is interesting in that it provides informtion on future areas

of progress of autmatic pmgramning. The layers in Figure 1 are nmrred to

indicate their general function. A reader desirous of mre specific definitions -2- AUTOM4TION DWD OVERALL PRCBLEM EVALUATION OF ALTERNATIVE AUTOMAT I ON PLANS REQUI REMENTS FWCTIONAL SPECIFICATIONS OF COMPUTER SYSTEM

EVALUATION OF FILE STRUCTURE ALTERNATIVES 7 PROGRAM PROGRAM MDW IDENTIFICATION DESIGN AND IMPLEMENTATION PRDGRAM MODULE I NPUT/OL~-PUT LDGICAL SPECIF I CATIONS PROGRAM DESIGN HIGH LEVEL (~WILER,JCW IANGWGE PROGMING

HIGH LEVEL TO ASSWLY LANGU4GE PROGRAM TRANSLATI ON ASSUvBLY LANGUAGE TO MACHINE CODE AND OPT1 MI ZATI ON

PROBLEM AND SUPERVISOR WROS PROBLEM INSTRUCTION SEQUENCES MICRO I NSTRUCTION PROCESS I NG OF WTA

FIG, I TMJSLATIO:VMP!M LAYERS IN MA PWCES5IiJG SYST55 AID IN MEIR WLICATIONS for the layers may have to add additimal layers. The top three layers in Figure 1 are associated with the process of determining au-tion rquiremnts, mi& sm&in~~requires definition of the problem. Note also that typically, a prcblem envimnnmt includes several other uxp0nent.s beside the computer. The next five layers mncern the design and inplesentation of sofbrare, in a language mnvenient for bepmblan. The two layers below, are ccmcerned wit;n ti^ translation and optimization of the program. Finally, the three lowest levels are concerned with the execution of the programs to perbrm the desired automation functions.

One way of regarding these layers is as a hot-up sequence, in the sense that the aubrmtion of a bottom layer is utilized in building the layer above it. Historically, a bottom-up approa& has been taken in autaMting these layers. The first layers to be automated were those associated wi~program execution. Tkis was followed by the layers associateii with language translation and program optimization. To date, a great wasis has also been placed on the 2 efficiency and utility of programing laquges . Improved facilities were quickly put to a test in a variety of applications. Relatively, little auknation has been applied to the tnp seven layers in Figure 1 and the translations £ran one layer to the one below it have been done manually by appropriate sofware specialists.

hmther, topdbwn view of Figure 1, pictures the layers as a series of transducers - transla*=, &ere the flow is &mward so that output of a top layer is used as an input to the layer belaw it. (A feeiback flaw is used for oorrections and mdificatians)

While impmmms~tsin hardware, system software and programing languages

2 Jean E. mt,"Progranming Languages: History and Future, " Coamr. of the ACM, July 1972, Vol. 15, Nuher 7, pp. 607-610. -4- continue to make prograrmcing mre effective, they are not sufficient to wnpensate for the dramtic projected increases in ddfor sofhare. One approad projection of ddof software is as follcrws: 'Ihe ratio of cost of sofbrare to hadware, wfiid-i in 1970 was 2:1, is projected to increase by 1985 to 10: 13. The U. S . Bureau of Labor Statistics 1970 es-tes show a work force of 3G0,OOCI engaged in software developmt in the United States. Of these 137,000 were classified as business progrm, 97,000 as business systms analysts and the remainder were arployed in 4 system and scientific software . These estimates are on the low side as they exclude some s-ts of the U.S. ec0nca-y and were registered at a

low emmmic point of 1970. In spite of the decreasing costs of computer

equiprent, total U. S. revenues from cmnputing hardware have been increasing

since 1970 at a real rate that my be averaged at 10% annually. 'Ihough costs

of muters have been decreasing, mnsidering tie large nmers of

potential users and new areas of industrial applications, this rate of

increase is projected to antine for the period of I270 to 1985. It will amunt to quadrupling the real annual cost of new computer equi-t by 1985. When this is coupled with the 1985 projection of 10: 1 ratio of cost of programing to the cost of hardware, this would munt to 20 fold increase

in programning IM~~EXJW@~by 19 85 (a 22% annual grawth rate) . Obviously such a m-t would constitute not only a financrial dstacle to

advances in use of anputers, but also su& a labor force canmt be recruited, trained, or wntrolled effectively. In order to keep software manpower

3 i3arry W. M, "Software and Its Impact: A ~uantitativeAssessm~nt,'~ Datamation, May 1373, pp. 48-59.

4 B Gildxist and R.E. Weber., "Rnployment of Trained Cbmputer Personnel- A Quantitative Survey, " AE'IPS Canference Proceedings, Vol. 46, .- 19 72, pp. 641-648. -5- inawes at a pace with increases of total hardware costs (10%annual increase) , the mqmer requiremats will have to be reduced by 80%by 1985, as oampared with present (mstly manual) mtlmds. Cbntinuing the bottom-up sequmce of dwelopmt, there are considerable efforts underway on the mmplete autanation of the five layers in Figure 1 that constitute program design and implamtation. Tne bottoan two of the five layers, will provide automatic generation of program, based on program nodule logical specifications; ndy, the autcanatic production of Ad Iioc prografis in aqiler languqes su=h as 03BOL or PL/1. This will reriuce, particularly, the requirements for business programers. As indicated, these programers represent 60% of mse employed in business programning. Subsequently, work of business systan analysts, who are engaged in the top three of the five

layers mentioned, will be reduced as well.

The manpower associated with the top four layers in Figure 1, of determination of overall problem rqubsmmts, represents currently a relatively dlmunt - of -err whim is primarily trained in the respective applicatims rather

than in 03mpute.r systems. Most prabably &e bottomup sequence of developrents will continue and will gradually effect the tap layers in Figure 1. EIwever, tne automtion of determining overall problem requirems~tsmy be delayed

until aubmatic program design and generation methodology (in lower layers)

has been well established. The mthods under developreat are described in Part I1

below. Advances in automation of programning are needed in large scale software

developrwt projects, particularily in the business data processing area wnich qloys the majority of pmgramnexs and where there is likely to be

the mst gMin demand for such services. Exmnples of sucfi system are a

new financial systan rmedby top managenrent to provide new reporting for

improved financial omtrol and planning, or system to support new products

su& as reservations services, medical services or a new insurance plan. Large scale projects are not the creation of a single or a dlgroup of managers.

Such systerrs have an impact on top managmt, business specialists in areas

such as acoounting or finance, operational staff of the organization, and

finally the p&lic that interact with the organization such as wtwoers,

vendors, etc. This is one of the reasons thy large scale sofWare develogmnt projects span several years of develop-rent time and involve activities of

various group within an organizatian. The objective below is t;o put programing

autanration in the context of such projects, .to determine the requiremznts of

research in greater detail. Figure 2 gives an overview of the software developent process, indicating the respective phases, by *can thqr are perforrred, the end pmdwts and the languages lsed in the docunmtation.

Data on distributian of labor and costs in software developrrent Wes

is difficult to obtain for two reasons. First, Mase classification in 5 accounting of developn=nt costs is rarely adhered to systemtically . Semnd,

costs of software developrent projects vary greatly, depending on the quality

of planning and execution. Costs f-ly vary in the ratio of 2:l for similar project and in som instances ti= ratio is much higher (20:l). Therefore, the

estimates that are mde below indicate widely accepted typical values.

5 Nelson, E.A., "Nmagemnt Hanm Fbr me Estirration of Cmputer Programing Qsts," SDCIM 3224, 1966.

-7- SOFTWARE SYSTEM PERFORMED END PRODUCTS LANGUAGES DEVELOPMENT PHASES BY

OVERhLL PROBLEM TOP MANA(;EMENT REQUIREMENTS OVERALL rxsmON OF SYSTEM. AD HE mT/BENEFIT ANALYSIS

SYSTEM BUSINESS (ACUIWI'ING, FUNCTIONAL Fm=, ETC.) 1 SPECIFICATIONS [I SPE(XALISTS 1. mRM?srIaY m, FORMAL FOvlmG AND SEQUENCING SYSTEM SPECZXISTS: IxEamTION OF 03MPVIlER FUNaIONAL IMPLEMENTATION I CDIYPUTER INPUTS AND OUI'PUrS SPECIE'ImCN IDENTIFICATION OF CKIEF PmaAmEB CIEScluPnON OF DATA QUI RED PROGRAM MIWLPULAT1:aJ

STRUCTURE

IEsQIIPTI:ON OF L?JPUT-OmUT mRMAI; Pm- AND DATA ~IE'UWITICBJ OF Em3 GRAM DESIGN, CODE, MDm mm1m DEBUG AND p-/ SPEcIF'ICATIy DOCUMENT II A~YS?S LPROGIWI MODULE I - a)MPmPRIGRAW PKGIWMING 1 & I2lcmwrATION L SYSTEM INTEGRATIO~' & INSTALLATION 03MPUIER/BENESS 'IEAM

J I 1- O~IONALSOFTmFE AD HOC 2. BRD3CUMEPJTIYPICN I MAINTENANCE I MODIFICATIONS AND Y ADDITIONS

FIG. 2 OVERVIEW OF SOFTWARE SYSTEm DEVELOPMENT PROJECTS 3,6,7,18 These estimates that are based on published reprts , and discussims with cnlleages. The estimtes are made to illustrate an approach to the projection of the possible impacts of autrmating software develo-t. A reader whose experierce indicates different estimates can stbstitute his own estimates and verify the validity of the cnnclusions. The estimtes belaw are to be considered as averages for all business data processing projects. Similar analysis can be performed for other areas of pmgramning applications.

In the discussion belaw, reference is made to the plases in Figure 2. Overall Prblem Rqwhmnts - This is a project kick-off +ase concerned primarily with determining what information management needs and indicaticols of the resources needed for the developnent. The initiation of larye scale

sofaare developnent projects is usually pqted by important needs

detemnhed by top managerent. !lk phase includes preparing preliminary es-tes supported by costbenefits analysis. ?his activity requires expertise

in the application area, as well as sizing mnputer requiremnts. The written

description of su& activity together with the indication of required resources and the decision to proceed are then axtymmicated to individuals

charged with carrying out the decision. Tb give a relative weight, this phase

is estimated at 8% of total project mst. System Functional Specifications - These specificatiahls describe the infoxnation flow involving h-, aodcations and cxnputers. They define

the transactions that would be involved as well as managmt reports necessary

for control of the activities in the system.

6 F. T. Baker, "Chief Progrm Team Management of Production Progrmg,I1 IBM Sy~tarrsJourrral, V6l. 11, I, 1972, p~.57-73.

7 J. D. Aron, "Estimating Rsources For Large Programning Systarrs ," 2nd NA!Kl Conference, SofWare Engineering Report, 1969, pp. 68-79 , NATO, Brussels. ale cmputer is envisaged as a black box where the functional specifications describe all the transactions that are entered into the mnputer system, and tile mnagem=nt reports and user infomtion produced by the system. The group tiut prepares the specifications need not include ccarqxter specialists.

However, as will be related further in Part 11, it has been found useful to goploy a formal functional specification language in docmmting the system, which can be processed autoaMtically to indicate inqleteness or inconsistenqy.

Ineffectiveness and waste result mere the functional specifications are

inmmplete or anbigmus thus causing redesign and reprograming. The discipline

hpsed by the use of su5-1 specification languages has been considered as

ueneficial to reducing total developrrent costs, especially in controlling the

progress and flow of work during a developnent project. 22% of the total costs of software developnmt projects is estimated for this *e.

The renrainbg 78% of the cost of a sof- developmt project is

estirmted to be for developt of program n-odules that perform in acmrdance

with the functional specification. If the functional specifications are

03np?le-, the work in this phase requires only quter oriented skills.

Once the total ~vironmntand hardware requiremnts -have been preliminarily

determined the softwa.re demdopmt in this phase may be sbdivided into three

steps* File Structure and Mule Desiqn - The first step in this phase is the specification of file structures and program mxlules . me functional specificatians written by the business spcialists in the previous step are rn

broken durn into distinct logical specifications for each program dule.

Fwthermore, the data structures on which the modules act can rmbe specified. A program IlPdule is typically associated with a transaction, an updating or a reporting function. In a typical $1,000,000 project there would be 50 to

100 program mdules each consisting of 1000 to 2000 lines of high level

language code. The abjective of this step is to cbtain a sequence of input- output operations and data organizatbn that minimize the aost of data processing.

The pmdu=tof the design activity is the generation of file structure

specifications and program dule logical specifications which inmrporate the

system functiaal specification on a per-mdule basis. 15%of project cost

is estimated to go into creating this specification. (In many projects this

step is integrated with ?rogram design, described below, and it is not possible

then to estimte msts separately). Program Design, We and Debug - Ihe next step is the design of each program dule, its coding, debugging and doamentation. The &iff iculties enmuntered currently in this step are due to having to supervise large nmbers of progrmrs, and the lw managemmt visibility of progress or lack thereof. Therefore, prablenrj are discovered late during ~e debugging of

individual program mdules, even later or during installation, resulting in

delays and msts beyond original estimates. This step is estimted to require currently 25% of the total project cost. System Integration and Installation - The last step in the programing gbse mists of integration of individual programmodules into the total system,

testing and ~~ parallel operation of the system. It is during this we atpdlems that have not been previously visible to mnagemnt ane to light.

lhey my appear as malfunctions -t must be wrrected. If difficulties are discovered.in user operation and control of the system, t?eindicated dxmges

must be commmicated to modify the functional specification of either the

entire system or specific program xrodules and only then can mdifications be -11- TMLE I SM13F ESTIiWTES OF FfREJTAGES aF SOFI',fARE EVELOPFCJT DSTS ATTRIi3UTBL.E TO ?HIKES, AID ENVISAGED FEDUCTIOIYS DLE TO AUT3WTION

PHASE DES CR IPT ION ESTIMATED z ESTIWTE OF PO NTI AL OF TOTAL COST REMJCTION~ (IN 3OF COST) WITH DIE TO: TRADITIONAL PROGMING APPROACH

DETERMI NATION OF PROBBLEM REQUIREMENTS GENERATION OF SYSTEM FWCT IONAL SPECS PROGRAMvlI NG: 7D FILE AND E.13DULE DESIGN CODE* TEST* DEBUG AND IX)CWNT

TOTAL Ia -32 -15 -22 -11 20 made. Dependitq on the quality of test.hq prior to installation this last s&-@mse my acaunt for 30% of the btal costs of the project.

~vlaintenance- After t2e system has been in operation, it will require maintenance to correct errors mt determined during the installation process.

But emmre so it will require maintenance to rrpdify and add facilities. This is a post-sofbmre-developnent *ase which must be facilitated during the dewlo-t itself. The software develogmnt should provide a mthod by which

t. mdificatims can be orderly entered in the specifications, the program nodules, tne doamentations and tiw operational system itself.

The autanation of any one phase imposes a disciplim on the entire process

whi& brings savjngs in the adjacent phases of the ?mess as well. For

instance, the discipline provided by a requirerent to specify program rrpdules

in a forrral functional specification language and an automtic generation of

programs would assure that relatively bug free program be provided tie

system integration @-we.

Table 1 smmrizes the estimtes of distribution of costs over the pk.1ases

of the sofbmre developnent process as indicated previously. These estimates

are necessarily subjective as indicated previously. A bottom up sequence of develo-t is ass- in Table 1, with autonatic program design and

generation amnplished first followed by autcmatic file and mdule design,

aukmatic functional specification and finally autaMtion of the determination

* The estimates of savings due to'aukmation of program generatim are inclusive of savings due to improved operating systems and language facilities shown in the five bottom layers of Figure 1. problem requiments. The bjective of such a swcession of develo~ts is to red- the mst of software development by 80% over a period lasting to

1985, as illustrated in Fig. 3. 'Ihe estimtes of savings of cast due to the four envisaged incr-ts in automation of programning, represent a msof the autimr, after extensive discussions with coworkers in this fisld. The esthtes of potential mntributions of autamtion of software developrent

Vesare also based on considering the potential methocaOlogies as described below. Therefore, mre will be said on these estirrates, at the end of Part 11. .. - - -- -

PAKI' I1 FVCUR3 ADVXJCES IN AUrOMATION OF SOlXWAlE LEVDBPMENT

4 AUK,WIC ESIQl AND -ON OF P-

This section examines the automation of the five layers in Figure 1

sham as constituting program design and implementatim. This activity requires only cmputer related -ledge. The autaroation activities of the higher

layers in Figure 1 that require lrnawledge of specific applications are discussed in a subsequent section. The "pure" muter art dependent structures are on a higher abstraction level than the business functions of a specific type

of industry. The automting of the generation of these structures can serve

as a foundation, and can be used in a variety of businesses and industry applications.

The discussions in this section involve only logical-abstract descriptions

of the autanation. The translations fran the logical-abstract mdels b physical devices are perfor& in the an-1 program in lower five layers

of Figure 1, such as Data and Teleprocessing Access Nethods , etc. xwwer, it's important to mte at this point that approaches to autQMtiq sofware development, where application and ccmputer related Wledge ESTLMalE OF POTENTIAL CONTRIBUION M COST REWCTtUi

AUTOIWTIC F'HOGRAM GENERATION

AUTWTIC FILE 8 MWE DESIGN

AUTOMATIC FUIJCTION SPECIFICATION

AUTOMATI C PKBLEM REQUI REMENTS

TOTAL

1373 SOFWARE BUSI NESS PROGRAF~FP~ERS BUS INESS ANALYSTS SYSTEM 2 SCIENTIFIC TOTAL 3f33.93 *AFIPS, 'THESTATE OF ME CDFPUTER INDUSTRY IN THE UISlt ~NNALE, 8.J. I973 FIG. 3. SUMRY i)F SORdAWHARlklAE QSTS ~~ POE4TIR a3URIBLJTIWS TO mT FIDUCT1O:lS -15- were integrated, are being pwcsued as well. One sudn approach mnsists of using prefabricated program aqments oriented to a specific type of business or industry. The mnpnents are appropriately parmetrized so that they can be adapted to use by myoqmizatims. Typically a potential user selects functional amponents tiat are required in his operation. Questicnnaires and cneck-lists are provided to facilitate gather- the user requimnmts.

Also an Editor and a Pert Generator are provided to enter user parameters and report formats. Sudn systems are used by service organizations and

tmnputer manufacturers to install dlbusiness system for wholesale and 8 distribution industries . There are shortmmhgs with this approach on two levels. First tnere is a continuing requirmt for programner skills for

selecting mrqmnents and detemjning the values of the parameters. Also

frquently, necessary functiolls cann;>t be perfow by previously prefabricated

03npnents and additional special purpose program are required. On amther

level, use of such packages requires mlding the needs for automation of a

business into the structure of the prefabricated sofware packages. No

provisions are mde to determine managarujnt's critical decisions regarding

efficient operation and whetkr data for decision making is indeed made

available to managemmt. %is appro ad^ can be based on a mre general and

perful program generation method described below instead on prefabricated 9 -ents and will be discussed further in the next sectim.

Follawing the bottom-up s-ce (Figure 1), au-tic program me generatian is discussed belaw first, and is follmed by the automatic file

8 Examples are IEM Customizing Service for users of IBM System 3 and the proprietary services of Keydata and others for the distribution industry.

9 A.C. Hax and W.A. Martin, "AutOBMtic Generation of Custanized, We1 Based Infonration Systens For Operations Managanent," Pmc. of the -ton mnference on Research on wuters in Organizations, Philadelwid, Pennsylvania, Octcioer 1975, H.L. mrgan, Editor, pp. ll.7-121. s&we and mdule selection mthotblogy. Automatic program nodule generation: This mth&logy is based on the use of processors -le of generating broad classes of programs.

Figure 4 illustrates this methodology. Box (1) at the bottom of Figure 4 illustrates a broad class of programs, dnaracterized as intended for business applications where they have to process a number of input data [or message] files and to produce a nunber of output files [or reports]. Box (2) illustrates a processor which can generate the program rtpdule for (1). The Program Mule Generator (2) consists of tsa parts, for processing the input formal non-procedural functional specification of the desired program nodule, and for p&fonnhg design and code generation.

The design and megeneration progranr; in box (2) , enbody a mathemtical mdel of a program design process. They check the consistency and the

canpleteness of input specifications by tracing each value in the output

data to its sourrpc. From these traces as well as from mquimmnts imposed

by file structures of the respective files [e.g. sequential or indexed] they

determine the sequencing of the input -ds, mrrputation and output ammnds to attain program nodule efficiency.

The program Rodule spxifications used as input in this process are a saset of the overall prablan non-procedural functional specificatims.

Several £orrial languages for stating non-prccedural functional specifications have been developed and some have been in uselo (see also ref. 2, 18 and 19).

10 D. Teichrm, "Survey of Languages For Stating -TEequimts for muter Based Information System, " AJ?IPS Cbnfermce Proc. , Vol. 42, Fall 1372, pp. 1203-1244, r m LANGUAGE DESIGN DESIGN AND C . METHOD SYNTAX - GENERATION 0 ANALYSIS CODE PROGRAM PROGIp GENERATI ON GENERATOR b SEMANTICS + ' GENERATOR SPEC - -

BUSINESS PROGRAM

MODULE DESIGN AND NON-PROCEDURAL CODE FUNCTIONAL MANIPUTLATION GENERATION SPECIFICATION PROGRAM

:PROGRAM LISTING - AND DOCUMENTATION

m OUTPUT FILES

FIG. 3 INTERACTIONS IN AUTOMATIC GENERATION OF A PROGRAM MODULE Because of the eiqimsis in these languages on facilities b describe data, tiley are very similar to languages used to describe data bases11'12. 1t is important to be able to process program module specifications that are given in any carbination of several forms, such as in a formdl language, table fomt or in a question-answer fomt. Also, these languages are still in an experimental pase and little usage wience is available for their evaluation. In order to have a capability to accept several selected languages or fornts, and to nndify them, it is desixeable to generate autcmtically

the language analysis program. %is capability is indicated in Figure 4 by a higher level language analysis program generator processor box (3) which

autoPMtically generates the mdule specification analysis program based on

specif icaticns of language syntax and semantics.

Tne specification of a desired program mdule that is input to the program mdule generator omes in -two parts whi& can be related to top and mttom level parts of program code, in a top.- program structure.

11 CX)DSYL Data Base Tksk Group Weport, Report to the (X>lXSYL Prograrmring Languages Coarmittee, ACM, New York, 1971.

12 N.S. Prywes and D. Pirog Smith, "Organization of Infomtion," in ANlUdl REtViw of Infomation Science and Technology, Vol. 7, C.A. Cuadra, Ed. , ASIS, Washington, D.C. , 1972, pp. 103-158. 13 The qwtation mlw from II. .Nills explains the tnpdown progrw structure:

"We can begin a process which we can repeat over and over until we get the wfiole program defined. This process is to formulate a one page skeleton program which represents that hundred page program. We do this by selecting same of the mst iq~rtantlines of code in the original program and then filling in what lies bemeen those lines by names. Each m name will refer to a new s-t to be stored in a library and called by a macro facility. In this way, we produce a program segnwt with sorrething under 50 lines, so that it will fit on one page. %is program segmmt will be a mixture of aontrol statments and macro calls with possibly a few initializing, file, or assigrrment statemsnts as well. "

In a similar approach, .two levels are defined 5elm. The top level of tirs program is defined to consist of all the data definitions, input/output cxmnands and control logic statements. This part constitues also macro level dccmmtatim, dispensing with the need for flow-&art do-tation. In &e bottan-level would be mutines that provide the mre detailed doamentation of

data manipulatim. These bm levels have been identified because they can be

related to two parts of the rtodule specification. %e top level mcro design

activity is largely based on ~e mdule input-output data specification. The

bottcxn level of tne program is based entirely on the data manipulation

specification (except where input and output data itenr;, records or files are

associated by ormron nan~~and the direct relationship of input to output is -licit) . This relationship is sum~lrizedin Table 2. A system of the type described in Figure 4, with a restriction of only

one input and one output file for a program mdule (nwl), has been developed at the University of Pmnsylvania by Rarnilez14. Expansion of the

13 Harlen Mills, "Top r3mm Prugramnincj In Larye System, " Courant muter Science Symposium I, July 1970. Debugging Techniques In Large Systems, Randall Rustin Ed. , Prentice Hall, 1971, pp. 41-55.

14 J. Raonimz, "Autop~ticGeneration of Data Conversion Program Using A Data Description Language," Ph.D. Dissertation, Univ. of Pennsylvania, 1973. -23- NON PROCEDURAL PROCEDURAL -- -1 ' INPUT LANGUAGE WUt LtVtL GENERATED AUTOMATICALLY -- DDL TOP DEFINITIONS CONTROL mGIC I/O

DM, BOTTOM MAN1 PUATION-ODMPUTATI ON CONVERS ION

--- system for handling multiple input and output files is currently underway. Tne Ramirez systen includes autolmatic capability for generat- language analysis program based on an extended BNF syntax specification and sb- routine cdls timt express saw of the semantics (other sanantics are in hand aS=d oode generation programs) . A non-procedural specification language is used for input to t5e program generatmr. It is similar in 12 structure to titat developed by 03DASYL . It is also a dfied subset of 15 a language developed by Smith . The data mnipulation language [IMLI used is a smset of PL/1. The generated program mdule code is in PL/l, requiring a sdxsequent ampilation to prodwe a load n-odule. The Ramirez system produces also the necessary JCL staterents and a variety of doammtation, in addition to-61e PL/1 program mdule listing.

Tne design process in the Program Mule Generator [box 2 in Figure 41 mquired a painstaking analysis to specify an acceptable hutan program design - process and to state it in term of a mathemtical mdel, which has been programed to constitute a part of t!e Mule Generator. r~lethere exist extensive work on automtically generating language analysis proqr~16there nas been only very limited research on automatic production of code generation which is one of tile m>st labomus tasks in oonstructing srogram generators.

Artificial intelligence researdl in the area of automatic pmblern solvinSl7

appears applicable to the automatic generatian of program to perform design

in awrdance with specified mthods.

15 D. Pirog Smith, "An Approach to Data Description and Conversion, " Ph. D. Dissertation, University of Pennsylvania, 1971.

16 W.N. McKeemn, et.al. , "A wiler Generator, " Prmtioe Hall, 1970.

17 For instance, G.S. Sussnran and D. mtt,Why Conniving is Better Than Planning, " AFIPS Conference Proceeding, Fall 1972. The methdlogy to generate automatically design and code generation programs is the least developed part of the techmlgy that is necessary to produce program dule generators efficiently. Until such tedmokqy is developed and applied it is possible only to proceed slwly and laborously by manually producing design and code generation programs. As will be further discussed below, this inability to easily "tea&" a cmputer how to anplay a method, that a hmcan easily learn is an extremly difficult abstacle to sclrrrpunt on the way tcward all-automatic prograrrtning.

File Structue and Program lade Definitions: This activity is bed on functional specification of the total amputer system, mnsisting of a mn-procedural functional specification of the totdl input and output data and a preliminary determination of the system Mareand sofmare that is required. The outame of this process are the mn-procedural functional specifications of the respective dules. T5is is a mre glWsof-are design activity then the mdule design. Refin-ts are presently carried out iteratively, where a human designer relies on autmatic simulation for

waluatim. Recent dwelo-ts of automation of this are reviwed bed8.

The first step of the process is to analyze the overall systan non-

~mceduralfunctional qecifications to determine campleteness and consistency.

An example of this capability is an analyzer developed for functional

specificatims expressed in the ADS language19. Analysis reprts include indices

18 J. Daniel Oouger, "Evolution of ausiness Systgn Analysis lkdmiques, " Cbnquting Surveys, Vol. 5, No. 3, Septenber 1973, pp. 167-198.

19 J. F. Numaker, et. a1 ., "A Non Procedural High Level Language For AutcaMted Design of rnlication Systars ,I' muter Science Dept. , Purdue University, W. Lafayette, Indiana 47906.

See also, J.F. Nmmker, Jr., "A Methodology for the Design and CQtimizatim of Information Processing System, " AFIPS Proc. , 1971, SJCC, pp. 283-294. of data elements, and mss referencing of data nmipulation routines and the respective source (input) and target (output) data elements. Groups of data elm- tfiat are co~mectedmqh hierarchial relationship are identified. Next these groups are also cross referenced with the routines that process the data elanents in respective groups. A nebmrk can be gmerated here groups of data elements that interact in amputations muld be mected. Closely connected groups of data element, constitute candidate files. Tine related processing functions represent candidate program mdules.

Attapts are then to consolidate or partition mdules and files to increase efficiency. For instance, if tw processing functions occur in the smprocessing cycle and if t~epreliminarily selected data files overlap greatly in having ammn data elewats, the res,pective processing functions and files may be clonsolidated. To desuch decisions it is necessary .to refer mt only to the logical structure of the data and the data manipulatim rules but also to the fr~ciesand cycles of the processing functims.

Partitiow of the processing files, as well as use of intermdiate files scmtirms hpmve efficiency. For instance, effect of pre or post sorting

to order the data may be an important consideration for efficiency. A third

type of ansideration is to evaluate inpact of alternative file organizations.

For emnple, whether the data is accessible seqmtially or on a randm access

basis has impact on efficiency of processing. Such alternatives may be evaluated tkroqh

20 A. F. Cardenas, "Evaluation and Selection of File Organizaticm-A P4xbl and System, " Comn. ACX 16,9, Sept. , 1973, pp. 540-548.

-24- 'lhe analysis, synthesis and evaluations of alternatives can be perfonred piecewise with the aid of automatic simulation and evaluatim.*l Zhe

integration of these functions requires human guidance. .An all-autamtic process will requFre a data base of global ccnrputer design kmwl-e

accessible to a muter. It will be necessary to research first how to fodize su31 knwledge or hw to input it to a mmputer in a natural

language ad-hoc manner. Until such camility is developed, it will be very

costly to enter such information through manual mdelling and pmgramning. !lherefore, the achietmmt of an all autamatic process with no human

participation will be necessarily delayed for some tire.

5 AWMATIC GENERATICN OF LaN-PFXEDUIW SPECIF'ICA!TIQVS

The bp-level systan design activity discussed in this section corresponds

to the top three. layers in Figure 1. !the top layer, named in Figure 1 "automation denand", is mncerned with determining what information would

management need to evaluate ecr,mmic and business alternatives and to make decisiw for their overall oqdzatioral progress and effectiveness. T%e second and third layers are oncemed with developing an autaMtic system that

would clollect and mke the indicated infoxmatian available to mnagemnt. ?he second layer mnsists of generating candidate operatianal concepts and muter

am£iguratians and the evaluation of these aomputer mnfigurations establish mst/benefits of alternative proposed infomatian systems. The third layer onsists of specifying the selected system in a foxmal manner to

be directly applicable in lmer layers. Simulation technoloqy for performing 18,21 saevaluations is highly developed

21 J. Yeh and J. Minker, "Key Word In Oontext Index and Sibliography on muter Systems Evaluation Techniqcuas , University of &Ezyland,Omputer Science Center, Qllege Park, Maryland, TR-246, June 1973. Performing tle top layer activity in an automatic fashion presents the greatest difficuliy. It is the mst complex and imaginative part of the total process. It nas little to do, if any, with ccarrputer mthodology, mlicn oecmes important only in lower layers. Traditionally this process involves interacting with many participants, with expertise in different disciplines : with top managmt, staff specialists , oprational staff and s~~ with outside the organization such as cus-, ven&rs financial

and go-t organizations. Presmably, a future cmrputer system that could this activity autZgMtically would need access to the eined knwledqe

of the present participarts in this process. Current techniques for ~tering

into a quter knwledge on LKXJ to evaluate qlexeconcanic or business

situations consists of aoding the knwledge in program form, hi&reqlires an

enorrrous munt of manual analysis and structuring. Tnis is t'ne mjor problem

in autormting tixis activity. Wo reported approaches to this pdlan, by 9 llax and 1- and by 6alzd2 are summized and reviewed belaw.

Trle dax and Martin approach has already been briefly described previously,

in 031111ectian witn use of prefabricated program omponents for the operational

side of a business. Oticer features of their approad-1 are: 1) specialize in a relatively narrow application field, rqmrtedly in Inventory Control.

2) Inmrporate simulation nodels for evaluating economics and business questions

or operational rethods. 3) use artificial intelligence t&ques for

cdcatingwith the wmputer interactively in English language for the entry

of additionally needed information into the quter.

Two areas of concern in this approad are discussed beluv. First, whether

due to tne prefabricated pmgranrj feature, the structure my be too confininq \

22 R.M. dalzer, "A Glcbal View of AutmMtic Programning," Also -randm on 'Autormtic Programning,' Septenbsr 1972, USC Infol.11~tionSciences Institute 4676 Admiralty Way, Marina Del Ray, California, 90291. -2 6- and restrictive to be used in situations where .technology, or business and ec0mmi.c conditions &age rapidly. Second, since the area of application is highly specialized and relatively narm, the axt of the sofaare generation system develo-t may rot be justified by potential utilization opportunities. Both the usefulness and end value of scr=h a generalized

Inventory Qntrol systern could !lave been tested, for instants, during the situation of major snortages in essential materials that arose at the end of

1973. Could the systen for instance, have qenerated an inventory control system for oil products that would be effective for conserving oil and for planning utilization of oil products to minimize impact of shortages on the eoonmy? Tne aLrrPst instantaneous availability of su& a systm would have dmnstrated its value as surely being sufficiently great to justify the costs of developrent.

As indicated previously, existing systas of prefabricated program ampnents have editors and question-answer facilities to collect and enter

user requiranents. It is not clear hw the use of cited artificial intelligence

tedmigues17r23'24 would mterially enhance s& facilities.

&dzd2 proposes Me construction of a amputer system which will have

a generalized learning capability that could be utilized to enter applications related knuwledge into the computer. The qmtaticn below smtarizes the

functions of the mmputer systan in his proposed ooncept of its operation:

23 T . Wbpgrad, "Understanding Naturdl Languages, " Academic Press, 1972.

24 C. Hewitt, "PLI1NNER: A Language ?l?brProving Theorems In mts, " Proc. of Intl. Joint Cbnference on Artificial Intelligence, Mitre Corp. , 1969, pp. 245-301. "1. Praulem statement in natural laquage in terns of the problern dcPMin. 2. Kraawledge about the domain acquired interactively in natural language in terms of the cmplete rrodel of the prablan &main. 3. Resulting pmgrams which are optimized with respect b data representations, control structure, and code.

This approach requires significant advances in Artificial Intelligence techniques, in such ar5as as -ledge representation, inference systems, learning, and problem solving, and in the dfication of programning knmledge in the areas of data representations, algorithm selection, and optimization techniques."

Item 1 and 2 in the above qmtation refer to the top level design activities addressed in this section. Item 3 refers to program generation and optimization activities similar to those discussed in the previous section. me reference to "domain" is similar to the use of the word "application" aoove. Tne starting kmwledge in the oomputer is assurned to be mnfined to timt of ccmputer system analysis and design. As stated, in item 1 and 2, the description of the problem that needs to be solved, &gether with the > knawledge at is needed to solve the problem would be hprted to the quter system thmugh inte~activeuser-computer question-answer sessions oond~ted in natural English language. The mquter would then learn £ran the user about his business to be able to determine the infomation needed for business

decisions and system r~~ts.The dependence of this type of activity on artificial intelligence metimdology is stated in the second paragra* in

tile above qmtation.

Balzer ahits that his proposed system concept is conjectural. There are questions in regard to kt? effectiveness of the process and feasibility. In

regard to eff&veness, the approach implies, for instance, that a president \ of a capany would find it beneficial to teach his prcb1e11-1and his business

to a ccarcputer that is equipped with only amputer oriented knawlwe, so that the muter auld integrate the tw types of knowledge to provide an effective solution to the president's prablerrs. Additionally, som

- of the informtion would have to be abtained fmthe vice-presidents for operations, marketing and finance. Oonsider the prcblem of all these

participants enter* infomation in a consistent mer so that it all can

be integrated. If the artificial intelligence techniques, cited by Balzer,

are to be used, the hmms interactizg with qutermuld be required

to have -ledge about hm the ocmputer aapins kmledge.

A basic assuption of this approach is that interactive ammmication

in English is an effective way to teach -ledge to a mmputer, although this

is a relatively slow prr>cess in teaching h-. Note also, that when hms are taqht by interactive ammmication, they alxeady have a basic bledge

of word meanings and relatiomhips, whi& would not be true for the computer

system. This prdblem is discussed further belav. It sears that it would have

been less conjectural if it was proposed that the cmputer could accept text- books as input materials and incorporate the respective kmwlec3ge into the

system. The text naterial would than also constitute a base line of the

bowledge in the computer on whid.1 further krwledge incarporation my be based.

Also, s~ha systan could be antinmusly tested as the information was entered.

For instance, at the end of entry of a Chapter fman Introd~ryEmncmics

texl-book, ~e problems at the end of the Chapter would be sdmitted as well,

and the umputer would be required to use the knowledge in the Chapter to

produe answers for tne problerrs.

Another prcblem area is the need to enter into the oxpute.rs large

vocabularies and the inadequacy of present artificial intelligence techniques cited by Balzer for handling volunmus English language cammications with the 17,23,24 muter, The systems cited by Balzer to daronstrate that tne tecimlogy is available, have mczhularies of few hmdred words. To amnunicate app1i~a~d~n.s-1- would require vocabularies of tens of thousands of words. The problem is not simply in the larger nuber of words needed for English language aomrmnication of application knowledge, but in the munt of work that it takes to enter multiple word meanings and relationships. Developrent of ~llethodologyto 2 5 tabulate multiple marings and relationships of mrds has been reported . It estimates that there are 8000 high usage words which have acquired marry manhgs and usages. Tnese mrds , as well as many other wrds , of lesser usage, will have to be integrated within detailed mdels of particular applications. To enter all this informtion, mrd by word, in an interactive process would require a long time. Other techniques, by which a camputer my amre howledge of words purely from ~e usage in text, must be developed to enable rapid entry of an applicatian oriented knowledge base into a

mmputer systan. Ztis would eliminate the need to tabulate maning and

relatim~ipsin vocabularies. Processes of tbis type have been ansidered

and developed by workers in the areas of infomiation storage and retrieval, 2 6 cnntent analysis and text processing .

All the questions that have been raised above seem to be open research

questions that snould be the subject of future research. It appears, therefore,

that tile adequacy of artificial intelligence teddques for implementing the

25 Louis L. Earl, "Use of Word Gmemmnt in Resolving Syntactic and Semantics Arrbiguities," Conference Proc. Computer 2bct Processing and Scientific Researcn, Off ice of Naval %ear&, Pasadena, California, 15 Mar& 1973, pp. 55-96.

26 N. Prywes, A. Lang and S. Zagorsky, "A Posteriori Indexing Classif iaation and Retrieval of Wxtual Mta," to be p&lished in Information Storage and Retrieval. type of system envisaged- by Balzer is far frm proven and feasibility of such a sysbmwill still need to be demnstrated. Therefore, also an effective autcaMtion of this generalized high level analysis and design process canmt be forseen with confidence.

6. cDNCLEICNS

Predictions or projectiom of tedmological develo~tsare always hazardous, especiallywi~enmde for a prolonged period such as the period

lasting to the year 1985. Therefore, it is in order to cement on reasons for confidence, or lack of, in the projections. ale projdnsof grckzth of software manper requirerents are not

reliable. Tky are based on a study of future U.S. Airforce software

xqubxmmts whid have been applied to the total U.S . econcmy. NEW industrial uses of amp- through 1985, that should figure pruminently in such

projections , imve not been considered. The ab jective in making the growth projection was for estimating a target for manpower savings from adwinces in

autaMtic programning. Even if the grawth prpjectims are 50% too high, there

would still be need for the advances described in the paper.

One assuption made in the paper was that software developent will

cantinue in a bottan-up fashion indicated by tl'le layers in Figure 1. The alternative would be sanre major breakthroughs wfiich would upset the past order of progress. For instance, breaktilltoughs in the f iela of artificial intelligence, by which coarp?uters muld quickly "learn" mthods auld have such an impact. dut as indicated in Section 5, them are important research questions that

need to be answered before such breakthroughs can be predicted. Large and extensive research and deveI.0-t activities in the areas of

P aukmatic program generation and systems and files design and evaluation are underway. These efforts are indicated in the references in this paper, and 18 21 especially in the survey paper and bibliography that nave been cited.

This, as well as examhatian of prolpsed m*ods, form the min basis for confidence that tl.le autcanation of program design and irrplerentation would be successfully developti and receive wide industrial and business use by 1985.

This will take place in a nuher of incr~~~tsas discussed in Sectim 4.

Finally, the present prospect is that detemhation of system requiremnts, leading to a system functional specification would be perfomd semi-au-tical$y, with business specialists serving as system innomtors and integra~rs,and that t~leywill be aided by various evaluation and language processing system.

The autaatic integration of these system would have to await admnces in lower layers of Figure 1 and probably also great advances in artificial