EP0180636A4 - Methode et systeme de developpement d'un programme d'application automatise. - Google Patents

Methode et systeme de developpement d'un programme d'application automatise.

Info

Publication number
EP0180636A4
EP0180636A4 EP19850902751 EP85902751A EP0180636A4 EP 0180636 A4 EP0180636 A4 EP 0180636A4 EP 19850902751 EP19850902751 EP 19850902751 EP 85902751 A EP85902751 A EP 85902751A EP 0180636 A4 EP0180636 A4 EP 0180636A4
Authority
EP
European Patent Office
Prior art keywords
file
symbol
user
layout
application program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP19850902751
Other languages
German (de)
English (en)
Other versions
EP0180636A1 (fr
Inventor
Patrick J Messerich
Ian H Abel
Victor C Benda
Charles E Clark
Richard A Ferrera
Joe Olsen Ross
Peter C Patton
George E Sundem
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Analysts International Corp
Original Assignee
Analysts International Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Analysts International Corp filed Critical Analysts International Corp
Publication of EP0180636A1 publication Critical patent/EP0180636A1/fr
Publication of EP0180636A4 publication Critical patent/EP0180636A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design

Definitions

  • 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.
  • 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.
  • the present invention solves many of the problems of conventional programmer productivity tools.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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; .
  • 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.
  • FIGURE 35 is a block diagram of an embodiment of the clean-up subsystem.
  • 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.
  • 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.
  • 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.
  • 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
  • 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).
  • each symbol will become the building blocks of the resulting COBOL program.
  • 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.
  • the user defi- nes the data files involved with the application, the
  • 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.
  • 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.
  • 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.
  • 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.
  • the line type 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a report definition worksheet and corresponding element definition worksheet would be developed.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system will enter the layout phase wherein the application's general logic flow will be defined.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system 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.
  • 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.
  • 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.
  • the user will be asked to identify the arguments and their data flow, input, output, or input/output both.
  • 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.
  • the system 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. ⁇
  • the system of the present invention provides the opportunity to modify the layout.
  • the following modification options are pro ⁇ vided in the maintenance menu:
  • the user can ⁇ review the overall layout structure.
  • 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:
  • 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.
  • the user can delete any symbol or any group of symbols from the overall layout flow.
  • the user can change any symbol; for example, a process symbol to a data
  • 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.
  • 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.
  • 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:
  • 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
  • the file definition phase is the next phase of the preferred embodiment of the present invention.
  • 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.
  • 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.
  • 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:
  • 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:
  • the user is returned either to location 150 or a review menu 164.
  • 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.
  • the review options 166 the user can elect to:
  • the program application development system will also ask the user to define other user names who have permission to modify the file format.
  • 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-
  • 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:
  • 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.
  • the system will ask as to whether the screen is to be a new one, a template, or a changed/corrected name.
  • the system lists screens for the application and gives the chooser the opportunity to modify the screens or go to 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.
  • FIGURE 18A As illustrated in FIGURE 18A at 190, " the user is offered the options of:
  • 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.
  • 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.
  • 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.
  • the user must define each line by type, that is whether it is reoccurring or nonreoccurririg, and the specific line where it will appear.
  • 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.
  • the system will request a control sequence number. .
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • the user preferably will select a path indicated by the less complicated conditions. These conditions might be defined as one of the following options:
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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:
  • 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.
  • 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.
  • 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:
  • the system asks the user to choose one of several options which might be:
  • the system offers the user one of the following derivations:
  • 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:
  • the system also provides for reversing the value of an element using the unitary sign.
  • the system 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:
  • 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.
  • the system 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.
  • 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.
  • the system lists the process symbols for the layout and offers the following menu:
  • the documentation might include:
  • FIGURE 25 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a Spool file includes the Source file infor ⁇ mation in a format that can be handled by a system reader.
  • 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.
  • FIGURE 26 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.
  • the symbol's name and type are saved.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the screen sub ⁇ system function 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • Layout file 290 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.
  • 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.
  • 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,
  • 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.
  • 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
  • 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:
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Méthode et système de développement automatisé d'un programme d'application permettant le développement automatisé de programmes COBOL opérationnels pour des applications autonomes ou des sous-programmes. La méthode et le système de développement d'un programme d'application utilisent un terminal d'utilisateur (52) avec un affichage graphique (54) qui est interconnecté à un ordinateur central programmé universel (50). L'ordinateur central (50) est à son tour interconnecté à des supports de stockage d'informations (56) pour le stockage des programmes COBOL développés. Une imprimante (58) est interconnectée à l'ordinateur central (50) pour obtenir des sorties imprimées sur papier. La méthode de développement d'un programme d'application automatisé fait appel à la création d'un plan d'application (60) qui est utilisé pour développer les programmes COBOL au niveau du terminal (52) de l'utilisateur. Le système de développement d'un programme d'application de la présente invention permet à un utilisateur de développer au niveau du terminal d'utilisateur (52) une source COBOL (64), un langage de contrôle des travaux (66) et une documentation de programmes (68).
EP19850902751 1984-05-04 1985-05-03 Methode et systeme de developpement d'un programme d'application automatise. Withdrawn EP0180636A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US60723884A 1984-05-04 1984-05-04
US607238 1984-05-04

Publications (2)

Publication Number Publication Date
EP0180636A1 EP0180636A1 (fr) 1986-05-14
EP0180636A4 true EP0180636A4 (fr) 1986-09-22

Family

ID=24431409

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19850902751 Withdrawn EP0180636A4 (fr) 1984-05-04 1985-05-03 Methode et systeme de developpement d'un programme d'application automatise.

Country Status (3)

Country Link
EP (1) EP0180636A4 (fr)
AU (1) AU4351185A (fr)
WO (1) WO1985005204A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988007719A2 (fr) * 1987-03-31 1988-10-06 Aimtech Corporation Appareil et representation et d'execution iconographiques de programmes
US5301270A (en) * 1989-12-18 1994-04-05 Anderson Consulting Computer-assisted software engineering system for cooperative processing environments
JPH08221264A (ja) * 1995-02-10 1996-08-30 Sunrise Syst:Kk プログラム作成支援システム
EP2290532A3 (fr) 2001-07-26 2013-04-24 IRiSE Système et procédé de recueil, d'enregistrement et de validation des exigences pour applications informatiques
WO2012048162A2 (fr) 2010-10-08 2012-04-12 Irise Système et procédé d'extension d'une plate-forme de visualisation
CN115373791B (zh) * 2022-10-25 2022-12-30 北京航天驭星科技有限公司 一种航天器自动化遥控作业的编制方法及装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4315315A (en) * 1971-03-09 1982-02-09 The Johns Hopkins University Graphical automatic programming
US4227245A (en) * 1972-06-01 1980-10-07 Westinghouse Electric Corp. Digital computer monitored system or process which is configured with the aid of an improved automatic programming system
US3969723A (en) * 1974-07-03 1976-07-13 General Electric Company On-line modification of computer programs
NL7703078A (nl) * 1977-03-22 1978-09-26 Philips Nv Inrichting voor het genereren en corrigeren van een gebruikersprogramma.
US4232370A (en) * 1978-12-07 1980-11-04 Clark Equipment Company Control system for a storage/retrieval machine in an automated material handling system
US4244034A (en) * 1979-01-09 1981-01-06 Westinghouse Electric Corp. Programmable dual stack relay ladder line solver and programming panel therefor
JPS56168263A (en) * 1980-05-30 1981-12-24 Hitachi Ltd Program making device
US4445169A (en) * 1980-06-13 1984-04-24 The Tokyo Electric Co., Inc. Sequence display apparatus and method

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
IBM TECHNICAL DISCLOSURE BULLETIN, vol. 14, no. 1, June 1971, pages 306-311, New York, US; P. BUSNELLO et al.: "Structure of a source program generator" *
PROCEEDINGS OF THE SID, vol. 11, no. 3, third quarter 1970, pages 121-129, Los Angeles, US; T.O. ELLIS et al.: "The grail project: an experiment in man-machine communications" *
See also references of WO8505204A1 *

Also Published As

Publication number Publication date
EP0180636A1 (fr) 1986-05-14
AU4351185A (en) 1985-11-28
WO1985005204A1 (fr) 1985-11-21

Similar Documents

Publication Publication Date Title
US4742467A (en) Automated programming system for machine creation of applications program source code from non-procedural terminal input
US5233513A (en) Business modeling, software engineering and prototyping method and apparatus
US6239800B1 (en) Method and apparatus for leading a user through a software installation procedure via interaction with displayed graphs
US5634121A (en) System for identifying and linking domain information using a parsing process to identify keywords and phrases
US6901407B2 (en) System and method for updating project management scheduling charts
US5590325A (en) System for forming queries to a commodities trading database using analog indicators
JP2509309B2 (ja) 概念設計ツ―ルとプロジェクト管理ツ―ルを自動的にインタフエイスする方法
US6678716B1 (en) System and method for managing processes
US5778387A (en) Database automated recovery system
Horowitz et al. A survey of application generators
US20030204429A1 (en) Processing life and work events
US20100017698A1 (en) Flexible Multiple Spreadsheet Data Consolidation System
US5544298A (en) Code generation and data access system
US6915487B2 (en) Method, system, computer program product, and article of manufacture for construction of a computer application interface for consumption by a connector builder
CA2253345C (fr) Base de donnees relationnelles compilee / stockee sur une structure de memorisation
US5781905A (en) Program generating method combining data item part with database manipulation part
WO1985005204A1 (fr) Methode et systeme de developpement d'un programme d'application automatise
US7664780B1 (en) Process data development and analysis system and method
Dunford ENDF Utility Codes Release 6.12
Botterill The design rationale of the System/38 user interface
JPH0588863A (ja) プログラム開発支援システム
US20030220856A1 (en) System and method for specifying a financial transaction
Shoval et al. Software engineering tools supporting ADISSA methodology for systems analysis and design
WO1990004828A1 (fr) Contexte d'exploitation d'un logiciel
JPH01147621A (ja) プログラム自動生成方法

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19860221

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE FR GB IT LI LU NL SE

A4 Supplementary search report drawn up and despatched

Effective date: 19860922

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 19881201

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CLARK, CHARLES, E.

Inventor name: ROSS, JOE, OLSEN

Inventor name: SUNDEM, GEORGE, E.

Inventor name: MESSERICH,PATRICK, J.

Inventor name: PATTON, PETER, C.

Inventor name: ABEL, IAN, H.

Inventor name: BENDA, VICTOR, C.

Inventor name: FERRERA, RICHARD, A.