WO1985005204A1 - Automated application program development system and method - Google Patents

Abstract

An automated application program development system and method enabling automated development of operational COBAL programs for stand-alone applications or subroutines. The application program development system and method utilizes a user terminal (52) with a graphic display (54) which is interconnected to a programmed general purpose host computer (50). The host computer (50) is in turn interconnected to storage media (56) for storage of the developed COBAL programs. A printer (58) is interconnected to the host computer (50) for hard copy printout. The automated application program development method involves creation of an application plan (60) which is used to develop the COBAL programs at the user terminal (52). The application program development system of the present invention enables COBAL source (64), job control language (66) and program documentation (68) to be developed by a user at the user terminal (52).

Description

AUTOMATED APPLICATION PROGRAM DEVELOPMENT SYSTEM AND METHOD

Background of the Invention

The present invention relates to an automated application program development system and method. More particularly, the present invention relates to an automated application program development system and method which enables automated development of complete operational COBOL programs for stand alone applications or subroutines.

Most application programming is left to mana¬ gement information systems (MIS) personnel. However, typical MIS personnel do not have a good understanding of the application needs of the end user. Some studies have shown that the vast amount of effort spent debugging an application in a typical MIS department is related to errors which were introduced during the requirements specification process. A lesser amount of time is spent on bugs introduced during the detailed design while an even lesser amount is spent on bugs created in the coding phase. Merely increasing the user's up front involvement and spending more time on traditional design will not facilitate application^' program development. Further, programmer productivity can only be increased up to a certain point. Simply helping talented programmers to write code faster does not address the overall application program development problem, but rather only serves as a stop gap measure.

SUBSTITUTE SHEET Many programmer productivity tools have been developed and are currently on the market. The limita¬ tions include the fact that you have to have a person skilled in programming and programming language to uti- lize them. In addition, they are implemented rather late in the application program development cycle and only do a partial job. Many of these programmer pro¬ ductivity tools facilitate programmer design reports and screens, and even produce modules of code, but these various pieces of productivity still have to be knitted together by a programmer to create an opera¬ tional application program. Furthermore, these programmer productivity tools are not very flexible. If the application does not meet the user's require- ments, there is considerable time and expense required to modify and recode it.

At the other end of the spectrum are pure design tools or methodologies. _%They may provide a graphic representation of logic flow, and the rela- tionship of modules within a system design, but they do not produce code and they do not give an end user an operating application program.

The key to improving efficiency in the appli¬ cation program development process and one which current development tools do not provide, is to improve the efficiency of the communication process between the people who are going to use the system and the people who are going to build it. In the application develop¬ ment continuum, the user and analyst have to be able to clearly communicate and understand exactly what the application is supposed to produce and how it will flow logically to produce those results during the func¬ tional specification stage of the development.

During the detailed design and coding and checkout stages which are very technical and overwhelming to the end user, the end user will fre¬ quently lose contact with the overall development pro¬ cess. They then do not become involved again until the testing stage to determine whether the application program performs to their expectations. If it does not, the design must be revised and the code rewritten which is very time consuming and expensive.

The present invention solves many of the problems of conventional programmer productivity tools.

Summary of the Invention

The present invention is particularly advan¬ tageous in that it automates the time consuming and expensive steps of detailed design and coding and allows the analyst and end user to develop operating prototypes, then test and modify those prototypes until they meet the user requirements.

The present invention can be used by MIS per¬ sonnel to develop application programs that precisely meet user requirements in less time than conventional programming methods.

Additionally, the present invention is par¬ ticularly advantageous because the user is not required to learn a special programming language. The present invention prompts the user to provide the information necessary to design a complete application.

The present invention addresses the total application program development process, not just iso¬ lated portions thereof. Communication between MIS per¬ sonnel and the end user is improved as the present invention utilizes a dialogue which the end user understands and is not overly technical. In the pre¬ ferred embodiment, the present invention will have at least a couple of different dialogue levels so as to facilitate use by the analyst and by the end user. Yet another feature of the present invention is that it provides for operational source code deve¬ lopment.

In addition, the present invention provides for automated documentation.

The present invention is particularly helpful in that it checks for errors in user logic and enables modification at any time.

Furthermore, one embodiment of the present invention has several built in default conditions such that in many cases the μser can rapidly step through a sequence of events in the course of program develop¬ ment.

Yet another feature of the present invention is that it enables a user to browse through various aspects of the program development.

The preferred embodiment of the present invention takes the user through five- phases of deve¬ lopment. In the layout phase, the user utilizes graphics to paint a picture of the task/program description or logic flow. This is particularly advan¬ tageous because both the user and the analyst can review and agree on the logic flow of the application task or program. The file, screen and report phases allow the user to create or use existing input and out¬ put structures. Finally, in the process phase, the user answers a series of questions to complete the detailed design. From the information provided in these five phases, the present invention then automati- cally produces the COBOL source code, program documen¬ tation, and much of the job control language.

A particularly advantageous feature of the present invention is that true prototyping is an econo¬ mic reality. The particular application program can be tested with the user's own data. If the prototype does

SUBSTITUTE SHEET not satisfy the user's exact requirements, it can be quickly and readily changed by use of the editor func¬ tions provided by the present invention.

These and various other apparatus and features of novelty which characterize the present invention are pointed out with particularity in the claims annexed hereto and forming a part hereof. However, for a better understanding of the invention, its advantages, and objects obtained by its use, reference should be had to the drawings which form a further part hereof, and to the accompanying descrip¬ tive . matter, in which there is illustrated and described a preferred embodiment of the invention.

Brief Description of the Drawings In the drawings, in which like reference numerals indicate corresponding parts through the several views:

FIGURE 1 is a simplified block diagram illustrating an operational environment of the present invention;

FIGURE 2 is a simplified block diagram of the functions of an embodiment of the present invention;

FIGURES 3A-B illustrate the symbols utilized in one embodiment of the present invention during the layout phase;

FIGURES 4A-B illustrate a sample layout worksheet;

FIGURE 5 illustrates a sample file definition worksheet; FIGURE 6 illustrates a sample screen defini¬ tion worksheet;

FIGURE 7 illustrates a sample definition worksheet of elements appearing on the screen shown in FIGURE 6; .

SUBSTITUTE SHI FIGURES 8A-B illustrate a worksheet of the layout shown in FIGURES 4A-B with comments attached;

FIGURE 9 illustrates a sample general planning worksheet documenting details for a given out¬ put such as the screen definition shown in FIGURE 6;

FIGURE 10 illustrates a sample display pre¬ sentation during the layout phase;

FIGURE 11 illustrates a sample display pre- sentation during the file definition phase;

FIGURE 12 illustrates a sample display pre- sentation during the screen definition phase;

FIGURE 13 illustrates a sample display pre- sentation during the report phase;

FIGURE 14 illustrates a sample display pre- sentation during the process phase;

FIGURES 15A-D are a diagrammatic represen¬ tation of an embodiment of the layout phase;

^•FIGURES 16A-B are a diagrammatic represen¬ tation of an embodiment of. the file definition phase;

FIGURES 17A-B are a diagrammatic represen- tation of an embodiment of the screen definition phase;

FIGURES 18A-D are a diagrammatic represen- tation of an embodiment of the report definition phase;

FIGURE 19 is a diagrammatic representation of an embodiment of the Decision Paths step of the process phase;

FIGURES 20A-C are a diagrammatic represen¬ tation of an embodiment of the Where to Derive step of the process phase;

FIGURES 21A-B are a diagrammatic represen¬ tation of an embodiment of the Data IN/OUT Directives step of the process phase;

SUBSTITUTE SHEET FIGURES 22A-B are a diagrammatic represen¬ tation of the logic flow of the how to derive elements portion of the process phase;

FIGURES 23A-B are a diagrammatic represen- tation of the logic flow of the exception processing portion of the process phase;

FIGURE 24 is a diagrammatic representation of an embodiment of the screen validation during the pro¬ cess phase; FIGURE 25 is a block diagram of the sub¬ systems of a digital program of one embodiment of the present invention;

FIGURE 26 is a block diagram of an embodiment of the layout subsystem; FIGURE 27 is a block diagram of an embodiment of the file subsystem;

FIGURE 28 is a block diagram of an embodiment of the screen subsystem;

FIGURE 29 is a block diagram of an embodiment of the report subsystem;

FIGURE 30 is a block diagram of an embodiment of the logical block subsystem;

FIGURE 31 is a block diagram of an embodiment of the process subsystem; FIGURE 32 is a block diagram of an embodiment of the source subsystem;

FIGURE 33 is a block diagram of an embodiment of the documentation subsystem;

FIGURE 34 is a block diagram of an embodiment of the spooling subsystem; and

FIGURE 35 is a block diagram of an embodiment of the clean-up subsystem.

SUBSTITUTE SHEET Detailed Description of the Preferred Embodiment Referring now to the drawings, there is illustrated a preferred embodiment of the present invention. FIGURE 1 is a block diagram illustrating a typical operational environment of the present inven¬ tion. The present invention includes a digital program which is resident in a host computer 50. The user interacts with the digital program in the host computer 50 by use of a user terminal 52 for input to and output from the host computer 50. In the preferred embodi¬ ment, a graphics display 54 will be utilized to display menues and various graphic symbols or icons. The host computer 50 in turn is suitably connected to various peripherals such as storage media 56 for file access and a printer 58 for report outputs. As illustrated in FIGURE 2, the user will typically develop an overall application plan as generally designated, by the block 60. The user will then take this plan and implement, it at the user terminal 52 as designated* by the block 62 and thereby develop COBOL source 64, job control language 66, and/or program documentation 68 as required.

When developing an application program using the application development system and method of* the present invention, the user will progress through five major steps and substeps as listed below:

1. LAYOUT PHASE

- Symbol Selection - Layout Modification

- Layout Validation

SUBSTITUTE SHEET 2. FILE DEFINITION PHASE

- File Format

- File Reference

- File Modify Permissions 3. SCREEN DEFINITION PHASE

- Screen Format

- Screen Field Definition

4. REPORT DEFINITION PHASE

- Report Form Selection - Body of Report

- Control of Report

5. PROCESS PHASE

- Decision Paths

- WHERE to Derive Elements - Data IN/OUT Directives

- HOW to Derive Elements

- Exception Processing

In the layout phase, the user uses the graphics capability of the graphics display 54 to name and identify the processing functions and decisions associated with the application. The user will further define all input and output associated with the appli¬ cation. The final layout structure will serve as a logic flow road map for the remainder of the applica- tion development. The layout structure is built by selecting and naming one icon or symbol at a time. The automated system will build the path vertically as the user adds symbols, one path at a time, until all paths logically end. After building an initial layout or during the course thereof, the system allows the user to add, change, or delete symbols. Much of the layout phase, as are the remaining phases, is menu driven such that the user is presented with options to select from. The system will automatically review the user's logic

SUBSTITUTE SHEET layout and via error messages and warnings inform the user if there are any errors in the logic flow. The user is then provided an opportunity to correct such errors. The layout phase is a graphic way of outlining in detail the logic flow of the application program as it is defined in the functional specifica¬ tion, each function being associated with a symbol and each symbol being named. Illustrated in FIGURES 3A-B are the symbols associated with various program functions and the input and/or output functions which may be associated with the process symbol. The process symbol 70 represents a position in the application where data can be collected or displayed or any data manipulation can be performed. The decision symbol 72 represents a point at which the application will follow one of two alternative paths. The data processing symbol 74 represents a point at which a coded function that already exists is referenced. It may be external source statements, a subroutine, or an external table that already exists. The connect to symbol 76 represents a connection bet¬ ween two paths of the application or a connection within the same path and is representative of a COBOL GO TO statement. The go to and return symbol 78 is used with a reference point and represents a point in the logic flow at which the user wishes to leave the current path, go to another path, perform specified activities, and return to the next step in the current path. This symbol is representative of a COBOL PERFORM. The reference point symbol 80 is a marker in the logic path used to reference where the go to and return or data processing symbols 78 and 74 are located. The return to symbol 82 designates the completion of the other path when a go to and return path is entered. It returns the logic flow to the next step after the reference point or decision symbol. The stop symbol 84 indicates an exit from the application. Every application must include at least one stop signal. This symbol is representative of a COBOL STOP RUN or PROGRAM EXIT. The file symbol 86 in FIGURE 3b represents the reading and writing of an organized collection of related data stored in index or direct access form. The screen symbol 88 represents a ter- minal display necessary to collect or display data. It requires a human interface via a CRT terminal or the like. The report symbol 90 indicates the point at which reports will be generated within an application. The sequential data symbol 92 represents the reading and writing of information stored in sequential format such as tapes, sequential files, etc. Accordingly, the logic flow is represented by one of the four primary function icon or symbols (70, 72, 74, 78), • three ter¬ mination icons (76, 82, 84), and four I/O icons (86, 88, 90, 9-2).

As a result of the layout phase, each symbol will become the building blocks of the resulting COBOL program. For example, the process symbol names will become the COBOL paragraph names. Names of files, screens and reports become the COBOL file description names. The details are not yet defined, but the basic logic flow is defined. The general layout information is utilized by the system to prompt the user in the remaining phases. The information subsequently gathered in the remaining phases will add the necessary detail to the basic program application structure defined in the layout phase so as to enable an opera¬ tional COBOL program to be developed.

In the file definition phase, the user defi- nes the data files involved with the application, the

SUBSTITUTE SHEET organization of the data within the files, and how this data will be referenced. Each is named and its attri¬ butes (type, length, and decimal positions) identified. The elements which form the primary key or reference are sequenced as well as the elements which form each secondary key or reference. File definitions are shared by all application programs created on the system. However only the files's creator is permitted to modify unless other user names are specified. It is also used to define the data processing symbol 74 argu¬ ments. As a result of the file definition phase, all the detailed information needed to construct the file definition for each file in the application program is provided. The elements in each file become part of the data dictionary for the application program. The file name becomes universally known to all program applica¬ tions developed.

In the screen definition phase, the visual format of each screen or display presentation is planned, plus its input and output characteristics, and the sources of the data to be used. Underscores are entered for each element on the screen that the appli¬ cation will collect or display. The underscored ele¬ ments are named and their attributes (type, length, and decimal positions) identified. Any validation or layout requirements for input elements are specified. The screen definition elements become part of the data dictionary for use by the application program. The elements named on the screen or display presentation are identified as part of the COBOL screen section. The automated system of the present invention will record any relationships for those screen elements which have the same name as other elements in the data dictionary for the particular application being deve- loped. These elements will automatically be valued or derived by the system in the process phase. In the report definition phase, the visual format and the sources of data for the hard copy reports included in the program application will be defined. The user is allowed .to choose the appropriate form from those predefined in the installation file. For each line of the report, the user specifies the line type as reoccurring or nonreoccurring. The ele¬ ments contained on each line are defined by specifying the starting column, element type (variable or literal), and the element's name and attributes. Each control line type is defined as a control header, sub¬ total or grand total, and the control sequence (major to minor) . The elements which are contained on each line are defined by specifying the starting column, element type (variable or literal) and the element's name and attributes. The report elements will become part of the data dictionary for the program applica¬ tion. The elements named in the report will become part of COBOL's working storage section. Any rela- tionships for those report elements that have the same name as other elements in the data dictionary will be recorded and will automatically be valued or derived by the system in the process phase, that is a COBOL move statement will be generated. In the process phase, the detailed infor¬ mation required to build the procedure divisions of the COBOL application program which will accomplish the functions defined in the layout phase will be gathered. The system will ask questions based on the layout and provide options so that the activities which must be performed by the application program can be readily defined. The process phase inverts the overall layout logic and creates logical paths to each output symbol. Accordingly, the process phase defines how each element in the output is valued or derived.

SUBSTITUTE SHEET The preferred embodiment of the process phase will be divided into five major steps:

1. Path Decisions

2. Where to Derive Elements 3. Data In/Out Directives

4. How to Derive Elements

5. Exception Processing

In the Path Decisions step, the system will sequence through the layout to each decision symbol and ask the user to define the criteria for taking either the horizontal or vertical path so that the system is obtaining information to generate a COBOL IF statement.

In the Where to Derive Elements step, the system- will sequence to each process symbol with an attached file symbol and ask which key (primary or secondary) will be used and the method of processing (sequentially or randomly, etc.) so that the system knows that elements of the specified key must be valued and how to open and close files.

Also in the Where To Derive Elements step for each output symbol found in the layout, the system will ask the user to assign each element associated with that output symbol to a process symbol so that the system knows in which process symbol the output ele¬ ments are valued and the sequence of these process sym¬ bols by logical path. In addition, the system enables the user to create elements needed temporarily to value an output element whereby the _ystem will recognize that it must define a working storage element. In the Data In/Out Directives step for each process symbol having multiple inputs, the system will ask the user to sequence the multiple input. Otherwise, for each pro¬ cess symbol, the system assumes a sequence of input

SUBSTITUTE SHEET directives, data manipulation (valuation or derivation), then output directives. In addition, if a process symbol has a screen which is both input and output the system will ask the user to sequence the input and output. If a file is to be output randomly in one process symbol, the system will ask the operator if this is to write, rewrite or delete a record on that file. The results of these questions enables the system to determine the order of the input and output directives for each process symbol. In the How to Derive Elements' step for each element assigned to a process symbol, the system asks a series of questions as to how the element is to be valued which aids the system in determining the type of COBOL statement needed to value the element (e.g., compute, move, etc.) and the specific details needed , for each statement. Importantly, the system is determining the order of the valuing of each element within the process symbol. In the exception processing step, the system allows ^' the operator to skip some or all activities in one process symbol whereby the system generates an IF statement according to the conditions and activities specified. Furthermore, a review of all . the activities (derivations and directives) for each process symbol is provided.

Application Development Process

Described hereafter is an embodiment of an application program development process in accordance with the principles of the present invention. The pre- sent invention is not intended to be limited to the specific features and details of process.

Typically, the user will begin the applica¬ tion development process with a series of planning steps. The overall purpose, objectives, and require- ments and basic functions to be performed by the appli- cation are defined. Once the user has completed the general planning of the application, the layout phase symbols are arranged on a worksheet in their logical sequence for the application program. For example, illustrated in FIGURES 4A-B are sample layout worksheets for a gold exchange application program which calculates the total number of ounces of gold that can be purchased for a specified dollar amount, calculates the total number of dollars involved if a specified number of ounces of gold is sold, and displays the results of the requested calculation. Illustrated in FIGURE 5 is a file definition worksheet for the file commodities of the example shown in FIGURES 4A-B. The - file commodities contains the com- modity exchange information including the commodity code, the exchange rate, the exchange time, and the exchange date. As illustrated in the file definition worksheet, the commodity code is utilized as the pri¬ mary reference to the file. Illustrated in FIGURE 6 is a screen definition worksheet wherein the menu screen or display presentation is documented. The underscores illustrated on the screen definition worksheet repre¬ sent the collection of data (input) or the display of data (output) in the application. As shown in the ele- ment definition worksheet of FIGURE 7, each of these elements or underscored fields are named and defined so that they may be referred to in the process phase of the application program development. The first underscore on the screen definition worksheet refers to the element Action and the second set of underscores refers to the element named Amount. Action relates to the user's selection of option 1, 2, or 3 shown on the screen worksheet and Amount relates to the value entered, either dollars or ounces. It will be appre- ciated that a separate screen definition worksheet should be defined for each display presentation. In the example shown in FIGURES 4A-B, there are three such presentations, two of them representing output and one representing input. Although not shown in the example illustrated, if there were a report generated by the application program, a report definition worksheet and corresponding element definition worksheet would be developed.

Typically, after the user has finished planning the layout, files, screens and reports, com- ments should be added to the layout which will help to define the events occurring in each symbol as is generally illustrated in the sample worksheets of FIGURES 8A-B. In addition, a general planning worksheet as illustrated in FIGURE 9 may be developed to document the other pertinent details for a given output, such as the results . screen or display presen¬ tation of the example.

After planning of the application is complete, the user uses the worksheets as a guide and enters the application layout via use of the terminal 52 and graphics display 54. The system will prompt the operator, provide menus and options, and display errors or warning messages on the display throughout the process. Frequently, as illustrated by the sample display presentations of FIGURES 10 and 14, a split screen display will be provided with the logic layout symbology on the right side of the display and user prompts or options on the left side.

The preferred embodiment of the present invention provides a secured system wherein the user must provide a name and password in order to gain access to the system. Once the user has gained access to the system, the following menu of general functions is provided:

SUBSTITUTE SHEET 1. Work on an application;

2. Define a file;

3. Document a file;

4. Change your user profile; 5. Work on the installation file;

6. Use a utility;

7. Sign off.

Upon designation of one of the above-listed general functions, the user is offered a second menu of options and so forth.

Selecting the work on an application options enables the user to work on a specific application. The user can create a new application or subroutine and define the user names allowed to use the application or subroutine. . The user must name the application or the subroutine being created. If a subroutine is being created, the system will prompt the user to- name the arguments or data elements being transferred to the subroutine and their flow. Each argument is then treated as a file and the system will prompt the user to define each in the file definition phase. Under the work on application option, the user can modify an existing application by starting in any of the system phases. The system will prompt the user for the phase to begin in. Additionally, the user can delete a pre¬ viously entered application. If while working on an application the user had terminated application program development via a time out function provided by the present invention, when the system is restarted it will return to the point at which the time out function was initiated such that the user is able to finish the application without repeating any steps. If the time out was pressed after completing a particular transac¬ tion, the system will go to the next step when it returns to the application program development. If the

^{" "} time out function was initiated during a transaction, after restart, the system will return to the beginning of that transaction. The user also has the option to create any hard copy printouts of all or a part of the documentation provided by the system. Further, the user can permit others to read, change, delete from, or add to the application development. The user is also given the option to list any applications/reports which have been created. Such reports may be listed; for example, by owner and creation date which displays application name, type, access, owner and date created. Or they may be listed by user and last date modified which provides application name, type, access, name who last modified, and last modified date. Also, the system of the present invention enables an entire application to be copied whereby the user can enter the modify mode of the layout phase and modify the copied application.

Under the define a file option, the user will name a file and define whether i.t is sequential or direct access. A direct access file represented by the file symbol 86 is a collection of data which is an index file or data base. A sequential file represented by the symbol sequential data symbol 92 is a sequential collection of data. If a sequential file is iden¬ tified, the^* system will ask the storage medium; tape, cards or disk. The system will then progress to the normal file definition phase.

The document a file option allows the user to print the file documentation without having to find a specific application.

The change user profile enables the user to select either the standard dialog which is intended or for end users, or an abbreviated dialog which is intended for MIS or data processing personnel.

SUBSTITUTE SHEET The work on an installation option is reserved for only specified users so as to enable the installation file to be created or modified.

The use a utility option prompts the operator or user as to whether specific application is to be restored or backed up.

The sign off option disconnects the user name and asks for a new user name and password. The system can then be unloaded by initiating a special function key and following normal log off procedures.

If the user elects to develop a new applica¬ tion or a stand alone routine, the user is given the opportunity to define who will have access to the application or subroutine and is further allowed to define the application for documentation purposes. Once this has been accomplished, the system will enter the layout phase wherein the application's general logic flow will be defined. During the layout phase, the user will enter one ^* graphic symbol at a time. Illustrated in FIGURE 10 is a screen presentation which appears on the graphics display 54 at the beginning of the layout phase. The logic flow of the layout phase is illustrated in FIGURES 15A-D. As illustrated in FIGURE 10, the symbol choices and system prompts or queries appear on the left side of the screen whereas the graphics of the application program appear on the right side of the screen, the start symbol being illustrated at the top on the right side of the screen. Once into the layout phase, the system will prompt the user for a symbol choice as illustrated by the connec¬ tor 100 in FIGURE 15A. Initially, the operator will have the choice of selecting the process symbol 70, the decision symbol 72, the DP symbol 74, or the go to and return symbol 78. Upon selection of an appropriate symbol, the user will be asked to name the process and will be given the option to enter a brief description for documentation purposes. At connector 102 as illustrated in FIGURE 15A, if the process symbol 70 had been selected, the user is given the option to attach any input and/or output symbol to the process. The process symbol 70 is the only one to which input or output may be attached with up to eight input or output symbols being attached to one process symbol. If no input or output is to be performed at the process sym- bol, the user is then given the opportunity to select another symbol as indicated by connector 104 in FIGURE 15B. If input or output is to be performed, at connec¬ tor 106 the user is prompted to identify the input or output type. The user may select either the file sym- bol 86, the screen symbol 88, the report symbol 90, or the sequential data symbol 92 as illustrated in FIGURE 3B. After, selecting an input/output symbol, the system asks the user to name the symbol. If the sequential data symbol 92 is selected, at connector 108 the user is asked the type of media; tape, cards or disk. As illustrated at connector 110, the system queries the operator as to the data flow of the input/output; that is, is it input, output, or both? The system then asks the user at connector 112 if more input/output is desired for the process symbol. If so, then as illustrated the system will query the operator as to the nature of the input/output at connector 106. If there is no more input/output associated with that par¬ ticular process symbol, then as illustrated at connec- tor 104 in FIGURE 15B, the system will provide the operator with a selection of new symbols.

When any of the symbols are selected, the system asks the user to name a symbol and allows a brief description for documentation purposes. If the decision^" symbol 72 is selected, the system asks the operator to attach the connect to sym¬ bol 76, the stop symbol 84, or the go to and return symbol 78 as indicated by the connector 114. If the stop symbol 84 is selected, then at 116 the system will query the user as to whether this is a stop run for an application or a sub-routine. If the DP symbol 74 is selected, the system will prompt the user for the reference point symbol 80 and ask the user to identify the referenced computer program as one of the following: include external source statements, use a subroutine, or use an existing table. The system will then prompt the user to name the other program. If external source statements or an existing table are selected, the name must be defined in the installation file. If subroutine is selected, the system will inquire as to the arguments or data elements trans- ferred and at 118 will ask for their data flow status; input, output or both. Each argument will then be treated as a file and the elements will be defined in the file definition phase.

Once the initial ^x layout symbol has been cho- sen, as indicated at 104 the- user will have a choice of essentially seven different layout symbols. If the process symbol 70 is chosen then once again the system will query the user at 120 as to whether or not there is any I/O associated with the process. At 122, the user will be queried as to the type of I/O, and if the sequential data symbol 92 is chosen, at 124 the user will be queried as to the type of media. At 126, the user will be queried as to the data flow of the input/output, then asked at 128 whether more input/output is needed. If the decision symbol 72 is chosen, at 130 the user will be queried as to the type of symbol for the horizontal path. If the attached symbol is the stop symbol 84, the user will be queried at 132 as to whether this is a stop run for the stand alone application or an exit for a subroutine. The

^■ system will then ask the user whether any more logic symbols are to be included in the vertical path. If the operator selects the go to and return symbol 78, the user will be prompted for the reference point sym- bol 80 and the name of the first symbol and the other path. If the connect to symbol 76, the stop symbol 84 or the return to symbol 82 are selected, at 134, 136 and 138, respectively, the system will determine whether all logical paths have been resolved. If they have not been resolved, then as indicated by the line 140 the user will be given an opportunity to select another symbol at location 104. If all paths have been resolved then the system will provide the user the opportunity to modify the logical layout of the appli- cation program via a . maintenance menu as indicated at location 142. As illustrated at 144 if the DP symbol 74 is selected, the user will be asked to identify the arguments and their data flow, input, output, or input/output both. As illustrated at the connector 130, the return to symbol 82 might be attached to the decision symbol 72 if the decision symbol is in a go to and return branch of the logical flow.

When progressing through layout, the system will complete the main vertical logic flow path first. Once that path is finished, the system will - ask questions and develop the information required to define any additional paths as specified using the con¬ nect to symbol 76 or the go to and return symbol 78. The system will not allow the user to leave the layout phase without at least one of the paths terminated with the stop symbol 84. _β

As illustrated in FIGURE 15D, prior to exiting the layout phase, the system of the present invention provides the opportunity to modify the layout. The following modification options are pro¬ vided in the maintenance menu:

SUBSTITUTE 1. Browse Layout

2. Add Primary

3. Add I/O

4. Delete

5. Change

6. Move

7. Duplicate

8. Rename

9. Review Validation Errors

Under the Browse Layout option, the user can_^ review the overall layout structure.

Under the Add Primary option, the user can add a primary graphics symbol at any point in the layout. The system then offers the following options as to where the user wants to place the symbol:

1. at the beginning of an application;

2. at the end of an application; 3. following another symbol-;

4. use it to start a branch path with a connect to symbol; and

5. use it to start a branch path with a go to and return symbol.

Under the Add^* I/O option, the user can add an additional input or output symbol to one of the process symbols 70 with up to eight input or output symbols being attached to one process symbol.

Under the Delete option, the user can delete any symbol or any group of symbols from the overall layout flow. Under the Change option, the user can change any symbol; for example, a process symbol to a data

- -— * ~^{^}~^ processing symbol. If the option is selected, as shown in FIGURE 15C at 143 the system offers the following options:

1. A symbol from one type to another; 2. The data flow for an I/O symbol;

3. The destination of a connector;

4. A DP symbol or the argument list.

Under the Move option the user can move any named symbol or group of symbols within the layout to another point in the layout. The system prompts the user for the symbol name and the targeted location.

Under the Duplicate option, the user can move a copy of a symbol or a group of symbols to another area of the layout. The system prompts the user for the symbol names from the existing layout and the target location. The duplicated symbols must be renamed.

The Rename option allows the user to rename a symbol. The system prompts the user for the existing and new name of the symbol. The system provides the user with the option to keep all inputs and outputs attached to the renamed process symbol 70. If a symbol is renamed, it must also be redefined. For example, if the screen is renamed in layout, the screen defini- tion phase will ask the user to create a new screen template, or change the name. It will be appreciated, that the maintenance menu might be provided with other options such as the capability to define a branch path before connecting' it to the main path of the applica- tion.

If the Review Validation Errors option is selected, the system will list all errors in the logic layout. Errors detected by the application development

SUBSTITUTE SHEET system will be listed on line 23 of the graphics display while overall system errors will be presented on line 24. Possible errors which might be generated in layout validation include:

1. ERROR - No Output in the Application.

2. ERROR - No Stop Symbol in the Layout.

3. ERROR - Endless Loops starting at:

4. WARNING - No Loop in the Main Logic.

5. WARNING - These are Unreferenced Symbols

Starting at:

6. WARNING - No Input (No Data is

Collected) and Ending at: 7. ERROR - No Exit From Subroutine.

The application program development system of the present invention will check to insure that each path in the layout produces a logical loop or logically ends. In addition it will check to make sure that the application has input and output and contains at least one stop symbol. Any errors detected will be displayed. Indicated at location 144 in FIGURE 15C, if there are- no errors the user will be given the option at 146 to go back to the maintenance menu for further work with the logic layout or progress to the next phase which will be the file definition phase, a sample display presentation for which is illustrated in FIGURE 1 and the logic flow for which is illustrated in FIGURES 16A-B. If only warnings appear on a display presentation then as indicated at 148 the user can elect to proceed to the file definition phase or go back to the maintenance menu for further work on the

E SHEET layout. If in fact some errors do appear, then the user must go back to the maintenance menu for further modification of the layout so as to correct the errors. The file definition phase is the next phase of the preferred embodiment of the present invention. Here, the application program development system con¬ tains information about the data files described in the application layout by asking various questions of the user regarding the file and the elements therein. Preferably, the user will utilize the file definition worksheet shown in FIGURE 5 during this phase of the application program development. The files which are defined might be index files, sequential files, or argument files formed when a subroutine is called. At location 150 the system will prompt the user at the graphics terminal 54 to indicate whether the file is new or already exists. If the -file is new to the system, at 152 the user may simply enter the new file by providing an element definition thereof or choose one of the following options:

1. Use the name as an alias for an existing file such that the system associates the new file name to a file already defined. (This file cannot be modified. ) 2. Use an existing file as a template wherein the file definition of another file confined within the system is copied and then can be modified. 3. Change or correct a file name.

If the user chooses to enter a new file, the user must define for each file:

1. The File Format;

2. The File Referencing Method;

3. The File Modified Permissions. To define the file format, the user enters the element name, type, length, decimal, and usage as specified on the file definition worksheet as shown in the example in FIGURE 5. Information will appear on the display presentation as illustrated in FIGURE 11 as it is entered or modified. As illustrated in the logic flow diagram of FIGURE 16A, at 154 the element type is selected and at 156 compacting of data specified. The element name "filler" may be used to designate charac- ters not referenced on the file.

The operator is prompted as to whether the file is sequential or index as generally indicated by connector 158. If the file is not sequential then at 160 the system asks a series of questions to determine the procedure for referencing each file. Since reference paths are used to gain access to information in the file, the elements are listed and the user is asked to define the^' primary reference. Since the reference^• may include up to ten elements, a column is provided for entering the sequence number. Once the file referencing has been defined, the system^* at 160 then offers the user the following options:

1. Add a New Secondary Reference Path;

2. Modify the Primary Path; 3. Modify the Secondary Path;

4. Delete the Secondary Path;

5. Review All Paths in the File.

At 162 if a new file is to be defined, the user is returned either to location 150 or a review menu 164. At the review menu 164 the user can select to review the file structure or proceed to the screen definition phase as illustrated in FIGURE 17A-B, or go back to the layout. At the review options 166 the user can elect to:

SUBSTITUTE SHEET 1. Accept the File Definition;

2. Review the File Structure;

3. Change or Correct the File Name;

4. Review Available File Names; 5. Redefine the File Element Structure.

The program application development system will also ask the user to define other user names who have permission to modify the file format.

At the end of the file definition phase, the user is given an opportunity to review and modify files. When modifying, a file, the following functions may be used:

1. Deletion of only the first element or the entire file; 2. Go to a particular element named in the file;

3. Browse a multiple page file definition by scrolling the screen or display presentation up and down; 4. Position the cursor at the beginning of the file.

The next phase is the screen definition phase. A sample screen or display presentation ^"of the system is shown in FIGURE 12 while the logical flow is illustrated in FIGURES 17A-B. The screen definition phase is where the screens described in the layout phase are described. The application program develop¬ ment system will ask the user a series of questions about each screen in the layout. The name of the screen will appear in the top of each display presen¬ tation as generally illustrated in FIGURE 12. As indi-

SUBSTSTUTE SHEET cated at 168, the preferred embodiment of the present invention offers the user the following options:

1. Create a new screen this name;

2. Use an existing screen as a pattern; 3. Change or correct^•-a name entered during layout; 4. Review other screen names by pressing the options key.

If the user elects to create a new screen with this name the system will ask the user to paint or define a picture of the screen. The user must key underscores for each element on the screen where the application will collect or display data. The number of underscores must equal the length of the element, including all decimal places in any formating charac¬ ters. The system will designate the row and column of the screen being painted in the lower right hand corner. If the user elects to use an existing screen as a pattern or template the user will be asked to name the screen and as indicated at 170 whether the applica¬ tion from which it should be copied is within the application or within another application and name of the application. The change or correct name option will change all references to the screen in the appli- cation. The system will assume that this is a new screen and so it must be redefined. The fourth option is to review screens in the application.

The system asks the user to name the element that will be associated with each of the underscored elements or fields. If the system does not find the element names in a file or elsewhere in the applica¬ tion, as illustrated at 172 the user is asked to define the element for temporary use and to define the ele¬ ment's characteristics as indicated at 174. If one screen is used for both input and output the system will ask the user to define the data flow for each ele¬ ment on the screen. The system will then ask the user to define a number of characteristics for each element including the name, the type as indicated at 174, and the length. Whether the element was found elsewhere in the application or it was defined for temporary storage, the system allows the user to specify addi¬ tional attributes for these elements. These attributes are defined through responses to dialogue and prompts from the system which as illustrated in FIGURE 5 appear generally at the bottom of the display presentation. At 176 in FIGURE 17B some of these options are shown for the input and output elements. Some of the options for input elements are:

1. whether entry is required;

2. whether each position in the field must be filled;

3. whether automatic tabbing is to be used; 4. whether minus signs may be entered as part of the element;

5. whether a default value is to be used;

6. whether the field is to be invisible on the screen or secured; 7. whether special characters such as hyphens, slashes, periods, etc. are to be used.

For the output elements the user can specify:

1. Dollar sign insertion;

2. Comma insertion;

3. Display of leading zeros;

4. Subminus signs;

5. Special characters.

STITUTE SHEET The system enables the user to assign speci¬ fic criteria to determine valid and invalid responses for each element. For example, the validation can be based on a comparison where the numeric element is of equal value, greater than or equal to, greater than, less than or equal to, less than or not equal to. Similarly alphanumeric elements may be specifically compared to another element. If a screen's elements to be entered or displayed do not comply with the above validation criteria or attributes, the system will display an error message on line 23 when the applica¬ tion is running. Furthermore the system will not reference the next element until a correction is made. If during the screen validation process at 180 it is determined at 182 that another field is needed then the definitions for that field are provided. If at 184 it is determined another screen is necessary then the system will ask as to whether the screen is to be a new one, a template, or a changed/corrected name. At 186, the system lists screens for the application and gives the chooser the opportunity to modify the screens or go to the report definition phase.

In the report definition phase, the user answers questions about the reports named in the layout phase of the application. The sample display presen¬ tation or screen is illustrated in' FIGURE 13. As illustrated in FIGURE 18A at 190, ^" the user is offered the options of:

1. Using an existing report as a pattern; 2. Changing or correcting the name entered during layout; 3. Creating a new report.

SUBSTITUTE SHEET The first option allows a report to be copied or templated from the application. The second option will allow the name entered during the layout for the report to be changed. If the report is renamed to a previously defined report in the application, the ori¬ ginal definition will be used. If the report name was not previously defined in the report definition phase, the system will prompt the user for its definition.

In the report definition phase, the report is created using literal, variable and page number ele¬ ments to define each line. The system allows the body of the report and the control area to be defined separately. Within the body of the report, the user can define column headings, page counters and detail lines. Within the control area the user can define control headers, subtotal and grand total lines.

As illustrated at 194, the user must define each line by type, that is whether it is reoccurring or nonreoccurririg, and the specific line where it will appear. Next the user "defines beginning column number and the element type. If the element is a literal, the system will prompt the user to enter the constant value. If the element is a variable, the system requests the name of the element. If the name element has already been • defined the system will display the defined characteristics. If more than one element has the same name, the system will prompt the user through a list until the correct one is found. If the element is to be defined for temporary use, the system will prompt the user to define the element's characteristic such as type, length, and decimal. Whether the element is found elsewhere in the application or defined for temporary use the system tells the user to specify display attributes defining appearance of the field.

SUBSTITUTE SHEET The user must define each element in every line. Whenever the user begins to define a new ele¬ ment, the system prompts the user to the next available column on that line. Since all the elements in one line have been specified, the user can lead to a new line or proceed to file control area if the body of the report is complete. The user can also specify for the first element on a new line, when the line should be printed. When choosing to define the control area of the report at 196, the system asks the user to specify the line type. For each line, it may be designated as a subtotal line, a control header or a grand total line. Totaling is done on the numeric elements found in the subtotal and grand total lines. For the sub¬ total and control header, the system will request a control sequence number. . In addition, the system will ask the user to define the conditions which will cause the subtotal to be taken, how many lines should be skipped before the next line is printed, and certain other information. For the control header, the system will ask the user to define the conditions which will cause the line to be printed, how many lines should be skipped before printing the next line, whether the next line should appear at the top of the next page or be printed on a next available line on the current page, and what element will cause each break.

Once the user has provided information spe¬ cifying line type and other control factors, the user will be asked to define each element in the line. At 198 the user will then be given the option to define additional elements, lines, or exit to the next report in the application. If this is the last report, the system will list the reports and give the user the opportunity to review or modify them or continue to the next phase. The last phase of the application program development process is the process phase. An example of the screen or display presentation at the graphics terminal 54 during the process phase is illustrated in FIGURE 14. As previously indicated and as illustrated in FIGURES 19-23, the process phase consists primarily of five subphases or steps:

1. Decision Paths

2. Where To Derive Elements 3. Data In/Out Directives

4. How To Derive Elements

5. Exception Processing

In the Decision Paths step, the application program development system of the present invention asks the user to define the criteria required to take the vertical or horizontal path for every decision symbol found in the layout. During this step, the system displays the layout on the right hand of the screen and the decision symbol is flashing for the decision currently being addressed. The system prompts appear on the left side of the screen. As generally illustrated at 210 in the logical flow diagram 19, the user preferably will select a path indicated by the less complicated conditions. These conditions might be defined as one of the following options:

1. Element Comparison

2. Successful File Table Operation

3. Unsuccessful File Table Operation

4. Use of a Function Key 5. Nonuse of a Function Key

6. Duplicating Conditions From a Previous

Condition Based on the options selected the system asks a series of questions to define precisely when the cho¬ sen decision path is taken. The alternate path is taken automatically under all other conditions. Several conditions can be related to one another using boolean logic with and/or conditions. The system will ask a series of questions which will allow the user to connect each condition with an and or an or. If there are no more conditions, the system gives the user the ability to add or change conditions, link conditions, or specify conditions which are independent. Illustrated in FIGURE 9 for the element comparison are some of the follow-up questions asked of the user regarding the element comparison. The next s,tep in the process phase is* where to derive elements, the logic flow for which is illustrated in FIGURES^' 20A-B. In the Where To Derive Elements step, the system asks the user to define for each output symbol in the .^'layout, where each output element will be derived, that is to which process or processes it will be defined. The system first establishes the proper references within each process that has a file attached. The system will ask the operater . which "key path" (primary reference or the user's choice of secondary references) the user will use to read the file in the specific process. The system then asks how to read that file in this process. As generally indicated by 220, the user may specify processing the file sequentially from the beginning to the end, one record at a time, process the file with a key greater than or equal to the key paths specified, or process the file randomly using only one specific record in the file.

When determining how a keyed file is to be processed, the user must recall how the file was defined in layout phase and the key path chosen.

HEET This system then displays a screen or display presentation at the graphics display 54 wherein all output elements or file references appear on the left side of the screen and all the process names on the right side. Each element name or file reference must then be assigned to the process or processes from which it is to be derived. As indicated at 222 the user selects from a list of options such as follows:

1. Assign each element to one or more pro- cess;

2. Assign several elements to a single pro¬ cess;

3. Assign all elements on the screen to a single process; 4. Review derivations already assigned;

5. Create a working storage element.

It should be noted that in the preferred embodiment, a screen or a report element defined to be the same as the element with the same name in another file and/or screen aήd/or report causes automatic valuation. Input to one values the others. Derivation of one derives the others. The system will monitor this assignment process and inform the user if all ele¬ ments have been assigned. While the user is not required to assign all elements and the system will allow the user to return to this step from the How To Derive Elements step, the user cannot delete or modify any derivations once the user leaves this step.

The next step in the process phase is the Data In/Out Directives step the logic for which is diagrammatically illustated in FIGURES 21A-B. In the Data In/Out Directives step the system asks questions regarding the input and output on the left side of the screen. The layout is displayed on the right side of

TUTE SHEET the screen and flashing is the process symbol con¬ taining the input/output symbol being addressed. If more than one input and output symbol for a process symbol is used, the system assumes input first, then data manipulation, then output. If a process symbol has a screen symbol used both for collecting and displaying data, then as generally illustrated at 230 the user is asked to choose one of the following:

1. Collect information, derive elements, display results;

2. Display information, collect changes, derive elements;

3. Derive elements, display results, collect change.

If a process symbol is used with more than one input, the system asks sequence of each. If one of the inputs is an I/O screen, the system will allow the user to sequence the input only if the user chooses option 1. If a file is used for both input and output, the user will be asked if the user wishes to write, rewrite, or delete as generally illustrated at 232 for each process symbol in which the file is output. At the end of this step, the system the gives user the opportunity to review any of the input and/or output symbols which have been defined in this step.

In the preferred embodiment of the present invention, if the user specifies any screen validation in the screen definition phase, the system, will give the user the opportunity to review and/or modify this validation as generally illustrated in FIGURE 24.

The next step in the process phase is How To Derive Elements. For every element assigned to each process in the Where To Derive step, the system asks a series of questions to determine its derivation. This is accomplished by the system displaying the element name of a specific file, screen or report and the pro¬ cess name. The system then prompts the user in defining the derivation. As illustrated in FIGURE 22A at 240 if the element to be defined is an alphanumeric, the system asks the user to choose several options which might be as follows:

1. Equal to another element; 2. Equal to literal or constant;

3. Similar to another element with a deri¬ vation you want to use as a pattern.

If the element is numeric, the system asks the user to choose one of several options which might be:

1. Equal to another element;

2. Equal to a literal or a constant;

3. The result of an arithmetic operation;

4. An average of other elements and/or , constants;

5. A percentage of another element;

6. Similar to an element with a derivation you want to use as a pattern.

If the element is a date or time type of ele- ment, the system offers the user one of the following derivations:

1. Equal to a constant or another element;

2. Results of an arithmetic operation;

3. Similar to any element whose derivation you want to use as a pattern.

SUBSTITUTE SHEET When numeric elements are derived math- matically, the system allows the user to create sophisticated arithmetic operations and the system will generate COBAL compute statements for all arithmetic statements. The system will recognize the following operations:

1. Addition

2. Subtraction

3. Multiplication 4. Division

5. Exponentiation

The system also provides for parenthetical - expressions. Within each arithmetic statement there can be six levels of parentheses. Within the parentheses, the sequence of operations is:

1. Exponentiation

2. Multiplication or Division

3. Plus or Minus

Within an arithmetic operation, the system also provides for reversing the value of an element using the unitary sign.

When an element is assigned to more than one process, the user must provide how to derive infor¬ mation for each use. However, the system assists the user with this activity. Each time the element occurs, at 242. the system will automatically display any pre¬ vious derivations of the element and will provide the user with the following options:

1. Duplicate the above derivation; 2. Modify the above derivation;

SUB_STITUTE SHEET 3. Create a new derivation;

4. Review another derivation of an element with this name;

5. Use the derivation of a different element as a pattern for this one.

If an element that has not been assigned to a process in the Where to Derive step is used, the system will offer the use of the option to return to that step- or use another element. If the user uses an element that is not previously defined in the application, the system will offer the user the option to return to Where to Derive step to define it and assign it to a process for derivation.

Prior to completing this step, the system gives the user the opportunity to review and/or modify any elements.

The next step in the process phase is the exception processing step. With completion of the pre¬ vious four steps, the user has described the activities to be performed within each process symbol. The system allows the user to further define when these activities should not be performed. For example, do not perform an activity if one of the elements is. equal to zero. As indicated at 244 and 246 in FIGURES 23A-B, the system lists the process symbols for the layout and offers the following menu:

1. Review each process symbol with the option of skipping some statements based on a decision; 2. Review selected process symbols;

3. Review a range of process symbols;

4. Proceed to source generation.

SUB_STITUTE SHEET If the user selects options 1, 2, or 3, the system displays each activity or group of activities in the specific process symbol and asks if there is any reason not to perform all or any part of these activi- ties. The user is asked questions to define the con¬ ditions which can cause this group to be performed or not performed. This is similar to the questions asked in the Decision step. This takes place at 252.

After completing these three phases, the system is able to produce COBAL source, program docu¬ mentation, and job control language. The documentation might include:

1. A consecutive listing of symbols used in the layout; 2. Symbol name list;

3. File descriptions; .4. Screen descriptions.

When a new application is being created, all the above documentation might be produced. If an existing application is being worked on, the system will ask the user which of the above documentation the user wants.

Detailed Description of Computer Program A subsystem arrangement of an embodiment of a computer program in accordance with the principles of the present invention is illustrated in FIGURE 25. The embodiment of the digital computer program shown will utilize the following data base files:

Installation File

An Installation file 280 contains information which relates to either global operations throughout the system or installation specific information which is unique to the particular user site. Examples of global information will be tables and subroutines. Examples of installation specific information will be JCL streams, source libraries, and environment descrip¬ tions.

Data Dictionary File

A Data Dictionary file 282 contains all the global file/data base elements that are used or could be used by any user developing an application with the system at a particular site. The Data Dictionary 282 is organized in file and/or record name by element order and is usually accessed by element name. The

Data Dictionary file 282 will include the element name and all of its various attributes.

File Dictionary A File Dictionary 284 contains file specific information for all files and/or records within the Data Dictionary. This information includes access security and applications which use a particular file. Accordingly, the File Dictionary 284 contains a list of the applications using each particular file. The File Dictionary 284 is accessed by field name and/or record.

Internal Element File An Internal Element file has the basic same format as the Data Dictionary file 282 except that it is only for a single application. It also includes the working storage elements for the application. The Internal Element file 286 will include the element names and their attributes. It is accessed by element name.

SUBSTITUTE SHEET Maintenance File A Maintenance file has the same general for¬ mat as the internal . element file except that it can contain only elements which have been changed, added and/or deleted during the course of a particular file maintenance run. The Maintenance file will include the element names and their attributes. It is accessed by the element's name.

Layout File^* A Layout file 290 contains a representation of the logic flow of the application along with the type of I/O that is used in the application and where it occurs in the logic flow. The Layout file serves as the controlling file for the application program deve-- lopment process. For each functional symbol and I/O symbol entered by the operator at the graphics display 54, the Layout file will include a record of its type, name, a unique index pointer or identifier ^* reflecting the order of selection by the operator of the - symbols, pointer to the previously selected symbol, and a pointer to the subsequently selected symbol. In addi¬ tion, for I/O symbols the Layout file 290 will include the flow of the I/O. The Layout file 290 is accessed by the symbol pointer, the symbol type, and the symbol name.

Application File An Application file 292 contains the- name and type of each I/O symbol entered by the user in an app¬ lication and the number of times that particular named I/O symbol occurs. This file is primarily utilized as a quick reference file to indicate whether a particular I/O type has been utilized. It is also used during the maintenance phase. If a particular I/O is deleted, the

SUBSTITUTE SHEET count reflects if any occurrence remains. The Application file 292 also contains the remarks section of the application being created wherein the user's notes or comments regarding each symbol are stored. The Application file 292 is accessed by the symbol type.

Ancestor File An Ancestor file 294 contains the symbol pointer of the symbol in any path that is referenced via a skip or jump in the logic. In addition it con¬ tains the symbol type and pointer of the symbol that caused the logic transfer. The Ancestor file 294 is accessed by the symbol pointer which is the destination or jump.

Screen Dictionary

A Screen Dictionary file 296 contains the row and column of each element and literal associated with a given screen. It also contains all edit criteria that was designated for any particular element. The Screen Dictionary file 296 also contains a pointer to the Result Table file if any validation criteria was built for any screen field. It is accessed by screen name by application. There is a Screen Dictionary file 296 for each application.

Report Dictionary

A Report Dictionary 298 contains the same general information as the Screen Dictionary file 296 for all reports. With the exception that,* the pointer to the Result Table represents the criteria to deter- mine under what conditions a particular print line should be sent to the printer.

SUBSTITUTE SHEET Logical Block File A Logical Block file 300 contains each logi¬ cal block as part of the total logic flow and all paths which relate or input to that path. A Logical Block includes all of the logic flow which might influence a given output. The Logical Block file is accessed by an identifier for each block and an identifier for each path within a given block.

Result Table A Result Table 302 contains multiple record types of all information concerning actions that must occur during execution of the application being created. This includes the decision logic and I/O actions that are to occur; however, its main purpose is to identify where each .element is to be valued and how it should be valued in the various logical blocks and paths it occurs in.

Process Dictionary A^' Process Dictionary 304 contains all execu- tion actions that need to occur and the order they should occur in as represented by the individual sym¬ bols in the logic flow created during the layout phase and represented by the Layout file 290.

Source File A Source file 306 contains the exact source statements for the application that is being created including Data Division, Procedure Division, Comments, and BMS Maps for CICS applications.

Spool File A Spool file includes the Source file infor¬ mation in a format that can be handled by a system reader.

^" STITUTE SHEET JCL File A JCL file contains the job control language to enable source generation by the particular system.

It will be appreciated, that the digital com- puter program will have numerous other data base files and information to accomplish various tasks which are required of a digital computer program of this nature.

Illustrated in FIGURE 26 is a block diagram of the layout subsystem 252 showing its interaction with the data base files. The layout subsystem 252 corresponds to and is the controlling portion of the program for the layout phase of the application deve¬ lopment process. As each of the functional symbols and input/output symbols are entered by the user, they are stored in the Layout file 290. The symbol's name and type are saved. In addition, each symbol stored in the Layout file is assigned a unique pointer value reflecting its order of entry by the user. If the user designates I/O for the process symbol 70, the I/O type, name, and flow are also stored in the Layout file 290 as well as an index pointer. As previously indicated up to eight of the I/O symbols may be attached to one of the process symbols 70. Also saved is the pointer of the symbol previously entered and the pointer of the symbol which^" is subsequently entered. Accordingly, the layout subfunction 252 collects a picture or represen¬ tation of the logic flow of the program that is to be created and stores this information in the Layout file 290. In addition, the layout subsystem 252 includes a graphics function 252a which utilizes the symbol type information in the Layout file 290 to display on a 3 x 7 matrix on the right hand of the graphics display 54a pictorial representation of the logic flow as it is built. The validation subfunction 252a updates the Ancestor file 294 to insert the symbol type and symbol

UTE SHEET pointer of the destination symbol in any logic path which results rom a branch or skip in the logic. In addition the symbol pointer and type of the symbol that caused the logic transfer are also inserted into the Ancestor file 294. Examples of when this might occur, are the use of the connect to symbol 76, the go to and return symbol 78, etc. As previously indicated, the present invention informs the user if any of the logic paths are incomplete or not logically connected to the remainder of the flow. The validation function 252a will search through the Layout file 290 utilizing the forward pointer and backward pointer fields to deter¬ mine whether the logic is complete in the forward direction. For example, have all branch paths returned to the main path or go to a stop symbol. In addition, the validation function 252a will ensure no obvious loops occur in the logic. The validation function 252a will also search the Ancestor file 294 to make sure that all logical flow paths are connected to the overall logic flow of the application. For each of the symbol pointers in the Ancestor file representing the first symbol in a logic path, a check is made of the corresponding symbol pointer of the symbol that caused the logic transfer to make sure that it has not been deleted from the Layout file 290 such that the logic path is isolated from the main logic flow of the program. In addition, the validation function 252a will check the Application file 292 to make sure that an output has been defined. As previously indicated if no output has been defined an error symbol is displayed. The validation function will also check the Application file 292 to see if any . input has been defined. If no input has been defined, a warning indi¬ cation will be displayed at the graphics display 54. Whenever the user requests a modification of the logic flow, the Layout file is accessed by the symbol name so that the Layout file 290 can be appropriately updated. For example, if a series of functional symbols are to be added to the logic flow, the layout file will pro¬ vide the backward pointer for the first symbol in the series as well as the forward pointer for the last sym¬ bol in the series. Once the layout phase has been completed, the layout file 290 becomes the director of all of the other subsystems in the program to dictate the requirements and direct their dialogue or interface with the user at the graphics display 54.

Illustrated in FIGURE 27 is the file sub¬ system 254 of the program. The file subsystem 254 corresponds to and controls the file definition phase of the application program development process. Its major function is to collect the specific record infor¬ mation for the files and/or data base structures that will be used within an application. The file subsystem 254 will make a quick check of the application file 292 to ascertain whether there are any such files. It will then sequence through the file symbol types in the Layout file 290. For each file symbol type located in the Layout file 290, the file subsystem 254 will search the Data Dictionary to ascertain whether this is a glo¬ bally defined file. If the file name is found in the Data Dictionary file 282, the file subsystem 254 will store the information for the file in the Internal Element file 286 which includes all of the files and data base information for the application being worked on. If the file name is not found in the Data Dictionary file 282, then the file subsystem will display the presentation as generally illustrated in FIGURE 11 and collect the information regarding the named file. This information is then stored in both the Data Dictionary file 282 so that it becomes -a glo- bal definition and the Internal Element file 286. The file subsystem 254 includes a function 254a which allows a file name to be changed or corrected if necessary. The name change function 254a will then update the Layout file 290 to reflect the correct name. In addition, the file subsystem 254 performs any modi- fications as indicated by the operator in the file definition stage and will store the old elements in the Maintenance file 288 so that the other subsystems can check this file to determine if any modifications have been made. In addition, the file subsystem 254 provi- des a copybook function 254b which enables existing elements in the Data Dictionary file 282 to be copied and modified or renamed by the user during the file definition phase. The major function of the file sub¬ system 254 is thus to collect specific record infor- mation for the files and/or data base structures to be used within an application. The structures are either included within the application or created for the application based on the Layout file 290. The Main Data file of the file subsystem 254 is the Internal Element file 286.

Illustrated in FIGURE 28 is the screen sub¬ system function 256. The screen subsystem 256 controls and corresponds to the screen definition phase of the application program development process. The screen subsystem 256 will check the. Application file 292 and the Layout file 290 to determine if any screens were included in the logic flow. If no screen types of out¬ put were included in the logic flow, the screen defini¬ tion phase is not performed. The screen subsystem accesses the Internal Element file 286 during the defi¬ nition of the fields that will be created or displayed during the I/O operation. If the field (element) already exists in the Data Dictionary file 282, it is marked. If it has not been previously defined the user is required to define it at this time. During a main¬ tenance run the Maintenance file 288 is checked by the screen subsystem. If it finds any elements that have been modified that are used in any sceens, the user is requested to redo these areas of the screens. In con¬ junction, if the user modifies any fields on any screens, the maintenance file is updated for the remainder of the subsystem to act on. If the user chooses to create a new screen, a screen paint function 256a will monitor the screen painting process so as to record the location of the various elements and their definitions. As previously indicated, during the screen definition phase the user can assign specific criteria to determine valid and invalid responses for each element upon the screen. The user is given the option to attach validation criteria to any of the screen input fields. If this option is chosen, the decisions function 256b is called and creates the field validation criteria. This criteria is stored in the Result Table file 302 and the pointer associated with this criteria is stored in the Screen Dictionary 296. The screen subsystem 256 will as a result of the user inputs, update the Screen Dictionary file 296, the row and column location of each element and numeral asso¬ ciated with a given screen, as well as any edit cri¬ teria that was designated for a particular element. The report subsystem 258 forms a similar function as the screen subsystem 256. Once again, if there are no reports in the application as determined by looking at the Application file 292 and the Layout file 290, the report definition phase is skipped. The report subsystem 258 includes a decisions function 258a similar to that of the screen subsystem 256b for updating the result table 302 as required. The primary output of the report subsystem is the Report Dictionary file 298 which is similar to that of the Screen Dictionary 296.

SUBSTITUTE SHEET The purpose of the logical block subsystem 260 is to break the logic flow into workable pieces for the process subsystem 262. This is done by breaking the flow at each output operation. That is, using the Layout file 290, all the symbols sequentially from the start or the last output to an output operation are grouped together. Then, using the Ancestor file 294, all the symbols in the paths which enter this logical block and therefore can affect the value of the output field are also grouped together. These logical blocks and paths which have identifiers assigned thereto then dictate the organization of the Result Table file 302 through the process subsystem 262.

The purpose of the process subsystem 262 is to identify and define all execution actions which will occur during the course of the logic flow as described during layout. This is done in several steps:

The CPDPDS function 262a collects the deci¬ sions or conditions which will cause either a shift in the logic flow (as represented by an icon in layout), screen validation criteria, report line printing deci¬ sions or the execution of process action steps (I/O or element).

Its main purpose is controlled by the Layout file 290. It searches the Layout file 290 via the sym¬ bol type index. It then allows the user to specify the condition that needs to be met for the continuation of the logic flow or the transfer of the logic flow to another path. A single condition may be all that is necessary or there may be a string or conditions which will be linked together by boolean ands or ors.

These condition(s) are stored in the Result Table file 302. The first condition has the appropriate Layout file 290 pointer for access and has a next Result Table file pointer if there are nested conditions.

The . CPDPRT function 262b serves two major purposes: 1. Allow the user to specify the file access method that should be used for all data base input operations. 2. Identify and record in the Result Table file 302 the location(s) within the logic flow where each output element should be valued.

The file access to be used is stored in the Result Table file 302 by both the Layout file 290 index pointer in which the function should occur as -well as the logical block identifier in which it resides.

The output elements are stored in the Result

Table file 302 by the logical block identifier and path identifier where their valuation will occur. This allows the valuation CPDPIS function *262d to control its process.

The CPDPIO function 262c sets the order of all I/O functions that are to occur within one process based on the formula that all inputs occur before out¬ puts. The functions are then sequenced in the

Result Table file 302 recording the layout file index pointer and the appropriate logical block for collec¬ tion later by the CPDPSO function 262e.

If any process has multiple input functions the user determines the order of these operations.

The CPDPIS function 262d converses with the user to determine the type of operation that needs to be created to satisfy the requirement that each output and intermediate element must be valued in each of the positions dictated by the CPDPRT function 262b. If

UBSTITUTE SHEET intermediate elements are used the valuation of the element is not satisfied until all the elements that make up a valuation have been valued or exist as an input to this application. The CPDPIS function 262d also ensures that the valuation is consistent and logical. For example,

A = X + Y and X = A + B is not logical. In this condition the user is warned and asked to correct. These valuations are stored in the Result

Table file 302 in logical block sequence that was established by the CPDPRT function 262b. This is necessary since a previously defined output result may be a source (input) field to an output that will occur in the later logical block.

The CPDPSO function 262e functions to create the Process Dictionary 304 in order of the Layout file 290. This is done by taking the operations stored in the Result Table file during the preceding process pha- ses and translating them in the correct order for each layout icon in the Process Dictionary 304.

Two separate operations occur during this process:

1. Since CPDPIS works from the final output backwards towards some source element, the operations are backwards in the Result Table file 302. CPDPSO reverses this order while it creates the Process Dictionary file 304.

2. CPDPSO also gives the user the oppor- tunity to embed any decisons within a series of opera¬ tions which shoald be executed conditionally. This is done by calling CPDPDS at the user's request.

The Process Dictionary is created during this phase of process. This is done by walking sequentially

SUB_STITUTE SHEET through the Layout file 290 via the forward pointers. For each symbol, in the Layout file 290 all functions that relate to that symbol are gathered from the various sections of the Result Table file 302 by use of the layout file index pointer associated with the sym¬ bol and written out in the Process Dictionary 304 con¬ taining the information necessary to create the appropriate COBOL statements. The Process Dictionary record types correspond to standard COBOL verbs. The CPDPWS function 262f creates working storage entries on the Internal Element file 286 if at either the CPDPRT function or the CPDPIS function it is necessary to create temporary work fields.

As illustrated in FIGURE 32 the source sub- system 264 utilizes the information contained in the files created by. the six subsystems that preceded it to create COBOL source code. Source code is stored in the Source Dictionary file 306. The source subsystem 264 is the equivalent of a COBOL programmer. In this sub- system, all of the information created by the^* preceding subsystems is translated by the source subsystem 264 to COBOL source statements which taken together form a complete COBOL program which will compile^' error free on the standard system COBOL compiler. The source sub- system 264 uses the following files while it makes up the COBOL statements for the four main COBOL divisions:

Identification Division: (The control portion of the program is accessed for user ID information.)

1) The Application File 292

2) The Installation File 280

Environment Division:

1) Installation File 280

UBSTITUTE SHEET Data Division:

1) The Internal Element File 286

2) The File Dictionary 284

3) The Screen Dictionary 296 4) The Report Dictionary 298

5) The Installation File 280

Procedure Division:

1) The Process Dictionary 304

2) The Screen Dictionary 296 3) The Report Dictionary 298

4) The Layout File 290

5) The Installation File 280

6) The Ancestor File 294

The documentation subsystem 266 uses the same data base files as source, only its output is. documen¬ tation directed to the system's print spool.

The JCL subsystem reduces JCL based on the information gathered during the first six subsystems. It also collects from the data base any installation specific JCL that was stored at installation which is needed and sends all the JCL to the spooler.

The spooling subsystem 270 collects the source and the JCL streams and sends them to the system job queue for execution. The clean-up subsystem cleans-up the overall data base for the application just completed.

Even though numerous characteristics and advantages of the invention have been set forth in the foregoing • description, together with details of the structure and function of the invention, the disclosure is illustrative only, and changes may be made in detail, especially in matters of shape, size and arrangement of parts, within the principles of the

?«S"*f*r.**!^*■■_ I. "5 _-n ?*.Ϊ T** invention, to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.

SUBSTITUTE SHEET

Claims

WHAT IS CLAIMED IS:

1. An automated system for generating applica¬ tion programs in source code for use on a general pur¬ pose computer, comprising: a) terminal means for operator input and control of the automated system; b) display means for display of operator input and output from the automated system; and c) data processing means adapted to receive the operator input and based on the operator input generate the source code of the application program, said data processing means including: i) layout means for identification of processing functions, decision branches, input and OUT - put, and the overall logic flow of the applicat; program; ii) file definition means for defining data files, the organization of data within the data files, and the method of referencing the data files which will be utilized by the application program; iii) screen definition means for defining the format of each display presentation, the input/output characteristics of each display presentation, and the sources of the data to be used for each display presen- tation associated with the application program; iv) report definition means for defining the format for each report and the sources of the data to be used for each report associated with the application program; v) process means for partitioning the logi¬ cal flow of the application program into procedural divisions of the source code, said process means further defining how and where each element output by the application program is derived; and vi) source means utilizing information created by the layout means, file definition means, screen definition means, report definition means, and process means for generating source code.

5 2. An automated system in accordance with claim 1 wherein said process means includes: a) path decision means for defining the criteria for taking -a particular path at each of the decision branches;

10 b) first element derivation means for defining where to derive elements by defining the key access to each of the data files and the method of pro¬ cessing each of the data files associated with a par¬ ticular process function, the process function

15 associated with each element to be output by the appli¬ cation program, and temporary elements needed to value an output element; c) data input/output directive means' for defining the sequence of multiple inputs if occurring

20 for a particular process function, the sequence of input and output in a display presentation for a par¬ ticular process function which has both an input and an output, and whether a data file which is randomly output in a particular, process function is to be writ- ^'25 ten, rewritten, or have a record deleted; and d) second element derivation means for defining how to value each element assigned to a par¬ ticular process function.

3. An automated system in accordance with claim 30 1, wherein said data processing means further includes documentation means for generating documentation of the application program using the information created by the layout means, file definition means, screen defini¬ tion means, report definition means, and process 35 means.

UB_STITUTE SHEET

4. An automated system in accordance with claim 1, wherein said data processing means further includes job control language means for generating job control language of the application program using the infor- mation created by the layout means, file definition means, screen definition means, report definition means, and process means.

5. A process for developing application programs by operator input via a terminal to a programmed general purpose computer, comprising: a) defining processing functions and deci¬ sion branches, input and output, and overall logic flow associated with the application program by use of interconnected graphic symbols input by the operator from the terminal; b) defining data files associated with the application^' program, the organization of the data files, and how the data will be referenced in the data files; - c) defining the format of display presen¬ tations, associated with the application program, the input and output characteristics of the display presen¬ tations, and the source of the data to be used; d) defining the format of reports asso- ciated with the application program and the source of data to be used in the reports; e) defining the detailed logic of the application program including: i) defining the criteria for taking a particular path at each of the decision branches in the application program; ii) defining where to derive the various elements of the application program; iii) defining the order of the input and output directives associated with each of the pro¬ cessing functions of the application program; and iv) defining how each element assigned to the processing functions is to be valued; and f) generating the source code of the appli¬ cation program from the information provided by the preceding steps.

6. An automated system for developing an appli- cation program, comprising: a) a master catalog of symbol types repre¬ sentative of processing functions from which a user may choose to build logic flow paths of an application program, each symbol type having associated therewith a unique identifier; b) terminal means for user entry of the symbol types and display of same; and c) data processing means adapted to receive input signals representative of the symbol type iden- tifier entered by the user at the terminal means inclu¬ ding: i) layout means for storing the symbol type identifier in a Layout Data file means, the layout means associating with each of the symbol types and storing a unique pointer value representative of the order in which the symbol types are entered by the user at the terminal means, the layout means further storing in an Ancestor file means the pointer value of a symbol jumped to in each logic flow path and the pointer value of the symbol causing transfer to that particular flow path, said layout means including means for validating the backward and forward pointers of each symbol type in the Layout file means to verify all the logic flow paths are complete in a forward sense, said layout

^■' C--^{" 1}*-^"" means including means for verifying the pointers of the Ancestor file means to verify there are no isolated logic flow paths; ii) means for gathering information regarding files, screens, and reports of the applica¬ tion program; iii) means for asking of the user addi¬ tional information respecting the logic flow paths and the symbol types therein; and iv) means for constructing source code based on the information so obtained.

7. A process of operating a general purpose data computer of known type to enable the data processer to validate the overall, logic flow of an application program, the overall logic flow possibly including a plurality of interconnected individual logic flow paths each represented by a plurality of interconnected sym¬ bols which 'are selected from a master catalog of symbol types, various ones of the symbol types indicating transfer from one logic flow path to another logic flow path, each symbol being representative of an isolated action within the application program, comprising: a) inputing the symbols from terminal means into a memory location of the general purpose data com- puter; b) associating with each of the symbol types a unique identifier; c) - associating with each of the symbols a unique pointer representative .of the sequence in which the symbols are inputed from the terminal means; d) associating with each of the symbols the pointer of the symbol entered previously and the pointer of the symbol entered subsequently; e) storing in memory the symbol pointer of the first symbol in each of the individual logic flow paths in association with the symbol pointer of the symbol which caused the transfer to the respective individual logic flow path; and f) examining the pointers in memory to verify that all the individual logic paths of • the overall logic flow are interconnected such that the logic flow is not disjointed.