Application program and documentation generator system and method5815717Abstract Automatic generation of an application program is performed by a programmed system including a guided editor for establishing program, data and field definitions from input event elements. A sequence generator, coupled to the guided editor, autonomously processes the program, data and field definitions into descriptive atomic sequences, each describing a unique characteristic such that a plurality of frames describes the input event elements. A rule processor, including a program rule base describing the structure and operation of an application program, autonomously processes the program rule base with the descriptive atomic sequences unifying the descriptive atomic sequences with the structure and operation of the application program. A syntax processor, including a language syntax rule base, autonomously unifies the descriptive atomic sequences with the language syntax to provide a coded representation of the application program. Claims I claim: Description BACKGROUND OF THE INVENTION
TABLE I
______________________________________
Program Feature Packets
______________________________________
Basic Program Specification
Allows change to Type, Subtype, Read
and Write Program options selected
when the program was created.
Suppress Delete Key
Disables the F5 DELETE function key
from the user access. Used to prevent
deletion of records from master files.
Suppress Print Blank Lines
Eliminates printing a blank line when all
data fields on the report are blank,
optionally any background text on the
line may be suppressed.
Output Options Defines special program processing for
1 Screen Inquiry, 2) Screen Selector or
3) ASCII file - if chosen, option to
receive output file name from user
must be specified.
Override Page Heading
Provides for suppression of standard
page heading, allowing the format of a
custom heading. Generally used for
forms processing. Almost always used
when generating an ASCII file for
export.
Define Next Segment
Used to change natural order of
segment execution from the lowest
number to the highest number. Can
provide branching to a program not
generated by the system (non-native)
as well as native program processing.
Ask User for Main File Name
Prompts the user to assign the main
program file to a different file on the
disk. Generally used with archive/de-
archive programs to allow control over
file placement.
Add Process Halt Support
Provides for user initialed program halt
on demand.
Destroy File on Purge
Program will delete the file specified in
Segment records as the Purge output
type with this option activated. Used
for temporary work files which are used
during a session and then deleted in
entirety upon program completion.
Side by Side Records
Defines number of columns of records
to print on report before beginning a
new row. Used to create double-up or
four-up labels, for example.
Reset Autonumber on Purge
All continuous autonumbers will be
reset to 0 when records are cleared
from the file during purges.
Suppress Posting Screen
Specifies that a posting process will be
silent and not announce that it has
started.
Don't Protect Field Math
Disallows divide by zero protection for
a field; also disables field initialization
as a product of a calculation.
Programs Pop-Up Call
Identifies Selector Pop-Up program to
be called from this field, enter name or
use F2 Call preceded by Topic to view
list of available programs. The Pop-Up
is referred to as a Selector.
______________________________________
In editing a segment 54.sub.1, designated fields on the image page can be assigned attributes also based on feature packets. These field based feature packets are utilized to define operative logic inclusions and qualifications that are to be performed generally on a field specific basis. Each field based feature packet can reference and thereby use or affect the contents of other fields. They can also control program flow by starting or skipping other program segments. Exemplary field based feature packets as used in a preferred embodiment of the present invention are identified in Table II.
TABLE II
__________________________________________________________________________
Field Based Feature Packets
Feature Packet Name
Basis
Description
__________________________________________________________________________
Screen Data Element
Defines the local iteration of the data name.
Location This is the "00" packet or root packet that
declares that there is a data name and that
it may have packets. The imaging editor
automatically prompts for the root packet as
part and parcel of implementing the data
name in the current segment. The packet
can override data dictionary definitions of
the data name. For example, increase the
minimum allowed collection length or reduce
the display length. The packet can also
make the data name "not a field" part
of the background screen mask, causing it
to be re-displayed on a later screen with any
processing to support it.
Element Edits
EDITS
Limits the range of entered values, sets
repeat or recurring entry specifications, sets
calculation relationship and establishes
display maskings.
Element Display Logic
DISPLAY
Provides field characteristics for displayed
data in the following methods - 1) Display
Only, 2) Forced, 3) Default, 4) Tally Target
and 5) Invisible. Logic is necessary for all
options other than (4) Tally Target. Help
text F7 is available to explain each of the
five options.
Element Verify Logic
VERIFY
Identifies Reference File and Record to
verify field value for data entry accuracy.
Specify enforcement option and use .about.|A.about.
for alpha or .about.|#.about. for numeric field
(equivalent to "value of current field") to
build the key value for verification of current
field. Any other elements of the key should
use existing data elements by their name.
Element Skip Logic
SKIP Allows a field to be bypassed for data entry
if the conditions specified in the Logic
section are met. If checking a padded field
for skip, such as the skip logic on a Display
Only variable used to show the name of a
field read with verify, you should use SKIP
IF FIELD IS EMPTY, otherwise you must
check for blanks, as well as a null condition.
Element Display to Logic
DISP2
Displays a value created by the specified
logic at a selectable location at the bottom
of the screen. The packet causes a value to
be placed elsewhere without having the
benefit of any known target field.
Field Validation Logic
VALID
Defines allowable values for field data entry.
In Logic section you must include field name
if a comparative is used as it is not assumed
that the field name involved belongs to the
right or left of the inequality.
Element Calculate to Logic
CALC2
Causes another field's value to change
based on the value captured or received into
the current field. The change may be any
math operator and may be displayed as it is
happening or wait until the other field
processes.
Element Input Options
Specifies optional data entry program for
input. The current options are Single
Character I/O to allow in-field editing and
Multi I/O to allow for long text fields of
multiple recurring lines.
Case CASE Causes the value (in any type of string field)
to have its case forced. The options are
change to all UPPERCASE, change to
Capitalized first word, Change to Capitalized
First Letter or change to all lower case. The
packet can act on any data name anywhere
in the program segment (many packets can
cause changes in fields which are not
displayed in the image, not on the screen or
report).
Element Skip Field if
SKIPEM
Allows a field to be bypassed for data entry
Empty if another field contains a null value (blanks)
for string variables or zero for numerics.
Input Edit Options
INPUT
Allows for the entry of a user-specified
range of valid characters for an alpha field.
Options are limited numbers, numbers
and alpha, alpha only, Y or N or a specific
list of characters.
Copy Value to Field
COPY2
Target field is identified to receive contents
of the source field. This is equivalent to a
Move in programming.
Translate to a Field
TRANS
Specifies conversion required for 1)
Encryption, 2) Decryption, 3) Soundex -
used in phonetic searching for names,
including Description and Program Target.
Element Tally (Running
TALLY
Provides totaling options (=-*/) for a
Total) Display Only Field identified to receive
results from this source field.
Don't Exit on Logic
NO EXIT
Tests for a specific value in field which
allows program termination only when the
logic is satisfied. Forces the user to
complete requirements such as an in-balance
condition before exiting.
Post to Another Field
POST TO
Causes a value created by the defined logic
to be placed in a targeted field.
Post From Another Field
PSTREL
Causes the value created by logic to be
placed in the current field to which the
packet is anchored.
Field Default
NEWVAL
Specifies a default field value to be placed
in the field either when empty or used to
replace the current field contents. This
Feature Packet is always used in
conjunction with the One-to-Many posting
relationship discussed as a full function later
in this guide.
Convert Date Into String
CONVDT
Translates a date field, which stores the
Name date as a Julian number, into a string field
which can be the day of the week or the
month of the year. This feature is used
extensively in scheduling.
Convert Numeric Amount
CONV2A
Used to make a worded dollar amount for
to Alpha printing on checks.
Report Default Totalling
RTOTAL
Requires numeric field validation prior to
using field in a report subtotal or grand
total. For numerics, operator (+-/*).
Calculate to Subtotal
Requires numeric field validation prior to
using field in a report subtotal. Same
scheme as Report Default Totaling. The
subtotal region must exist and contain the
target variable.
Calculate to Grand Total
Specifies numeric file validation prior to
using field in a report region must
exist and contain the target variable.
Specified Range Inclusive
START
Specifies Data name from Start-Up screen
Start used to verify beginning range of field value
for inclusion in report.
Specified Range Inclusive
END Specifies Data name from Start-Up screen
End used to verify ending range of field value for
inclusion in report.
Specified Exclude on Exact
MATCH
Compares field value with value entered
Match here to exclude a record from the report.
Yes or No Logic
YES/NO
Compares field value to logic to determine if
field should be included. Only works when
combined with Exclude on Yes or No
Option.
Normal Exclude Record
NORMAL
Defines conditions to be met to exclude a
Logic record from report. Field does not have to
be present on report, and packet may be
used to anchor exclusion to another field
which does appear on report.
Define Sort Key
SORT All sort options created in the Start-Up
screen must be defined and anchored to
fields used on the report. The sort option
should be located on the lowest field order
of the sort.
Data Name Incrementor
MEMINC
Causes the value in the anchor field to be
changed by a fixed amount each time
(usually each record processed) the
counting is self-contained, it starts at the
same value, counts in memory and then
clears.
Normal Include Record
NORMIN
Causes records being processed to be
Logic included or ignored based on values at the
time. The packet is commonly used in
processes and output.
Skip Program Segment on
SKPPRG
Completely eliminates execution of this
Logic segment based upon logic condition
passing. The logic must be loaded into a
non-stored data name in an earlier segment.
No records will be read.
Hide Output Detail
HIDE Provides print suppression for record based
upon logic successfully completed.
The image editor 32 preferably provides a picklist for the selection of both program and field based feature packets. As a feature is selected based on user input 14, additional information is presented for user input completion. This additional information is presented typically in the form of a pop-up display record that prompts for user input to sufficiently qualify the desired function of the selected feature packet. The feature packet identification and supporting information are collected by the image editor as enumerated attributes of a particular program 52, or segment 54.sub.1. Preferably the image editor 32 further operates to reasonably validate these attributes against the existing application structure including specifically file and record 56, 58 references. Feature packets that further define basis attributes are also validated against a rule table 62 that includes a record for each basis. Each basis record defines the abstract behavioral characteristics that define a particular basis. The behavioral characteristics, when combined with the qualifying information entered by the user with respect to a specific instance of a feature packet, permit the definition of a set of application sequences that can be utilized to implement the functionality of the feature packet. The feature packets may and generally do provide for the user input entry of functional logic to complete the definition of a particular feature packet. For example, the Tally To feature packet supports the specification of another field name and the specification of an arithmetic operator. For example, the realized feature packet can be represented as:
______________________________________
16AP200100Total Cost
+
Value Tally
where:
16 ID of rule corresponding to
this packet
AP Topic identifier
2001 Program identifier
00 Program Segment identifier
Total Cost Field identifier where feature
packet is anchored
0 Reserved for future use
+ First feature value
Value Tally Second feature value -
destination fields.
0 Third feature value
______________________________________
Thus, the functional logic of such feature packets is largely implicit, with the user providing and being exposed to minimal requirement specifications. In support of this functional logic, a number of system variables are provided for reference. These system variables are not conventional variables, but rather abstract elements to the system functions, calls, and literals, as well as reserved or predefined variables and user defined variables. System functions include obtaining the system date (|Data Date), while calls may call for system operations such as generating an audible tone (|Data Ring Bell), literals include fixed data strings (|Lit Asterisk) and data constants. Reserved variables include functional programming constraints (|Ele LP Counter), arithmetic functions (|Ele Calc 2 Field), pre-allocated variables (|Data Temp Num 1), and functional system status (|Curr Topic; |Data Main Read). Finally, user defined system variables include all of the field names defined by the user through the image editor, thereby allowing direct consistent reference to custom as well as predefined aspects of an application program and its dynamic execution environment. The functional logic may include conventional, numeric and logical operators that serve as relational connectors between combinations of system variables, field names, file names, and record names, as well as information in the application structure, provided by the sequences, and dynamic execution memory variables and literals. The field names are the names associated with fields as part of the definition process implemented by the imaging editor 32. The file and record names correspond to the file and record ID's specified in the definition of the files and records 56, 58 of the application structure 36. Exemplary system variables are detailed in Table III.
TABLE III
______________________________________
System Variables
______________________________________
|# Current Numeric Field Variable
|a Current String Field Variable
|Curr Basis Key
Current Pointer Into Sequence
|Curr Error Current Error Number
|Curr Field In Process Field Name
|Curr Field Max
Number of Fields in Segment
|Curr Field Rec
Current Fields Record
|Curr New Line
Fully Substituted Text Line
|Curr Next Seg
Programs Next Segment Number
|Curr Page No.
Current Audit Page Number
|Curr Program
Current Program ID
|Curr Segment
Current Segment ID
|Curr Topic Current Topic ID
|Curr Variable
Current Variable In Translation
|Data Bell Sound
Sound Bell with Message
|Data Date Run Time System Date
|Data DSZ Remaining Data Size Variable
|Data End Check
End of Data Variable
|Data Input Run Time Input Variable
|Data Main Read
Main File Read Succeeded
|Data Menu SW1-14
Menu Parameter Switches 1-14
|Data Next Prog
Run Time Set Next Program
|Data Page Count
Report Page Counter
|Data Read Write
Buffer Read/Write Flag
|Data Required
Required Record Yes/No Flags
|Data Row Temporary Variable for Row Number
|Data Search Search Key
|Data Temp Num 0-7
Run Time Temporary Numeric Storage
|Data Temp Str 0-7
Run Time Temp String Variable
|Data Total Base
Numeric Total Array
|Data VDP User
Run Time WorkStation and User
|DDICT Case CVT
Case Conversion Option
|DDICT Data Type
Data Type
|DDICT Desc Description of Entry
|DDICT Justify
Field Justification
|DDICT Max Len
Maximum Length
|DDICT Min Len
Minimum Length
|Ele Calc Dest
Calculated from Screen Math
|Ele Calc Source
Source for Screen Math
|Ele Calc2 Field
Target Field of Calculation
|Ele Calc2 Op
Calculate to Math Operation
|Ele Calc2 Show
Display Calculated Field
|Ele Col Element Column
|Ele Conv From
Source Field for Conversion
|Ele Conv2 Alpha
Target Field for Numeric to Alpha Conversion
|Ele Conv1 Field
Target Field After Conversion
|Ele Convto Mask
Use Mask Number to String Convert
|Ele Copyto Field
Field Name to be Copied To
|Ele Copyto Type
Record Type of Copy To
|Ele Disp Logic
Element Display Logic
|Ele Disp Option
Element Display Option
|Ele Dispto Pos
Element Display to Position
|Ele Dispto Type
Record Type of Display to
|Ele Dispto Logic
Element Display to Logic
|Ele Exitlogic
Don't Exit Logic
|Ele Exit Option
Don't Exit Option
|Ele Grand Field
Grand Total Calculate to Field
|Ele Grand Sign
Mathematical Operator
|Ele Grand Plus Field
Grand Total Add to Field
|Ele Grand Plus Logic
Grand Total Add to Logic
|Ele Grand Minus Field
Grand Total Subtract to Field
|Ele Grand Minus Logic
Grand Total Subtract to Logic
|Ele Imm Field
Immediate Update Target Field
|Ele Imm File
Immediate Update File
|Ele Imm Op Immediate Update Operation
|Ele Increment
Numeric Display Increment
|Ele Input From1
From Value Range one
|Ele Input From2
From Value Range 2
|Ele Input From3
From Value Range 3
|Ele Input Thru1
Through Value-Range 1
|Ele Input Thru2
Through Value-Range 2
|Ele Input Thru3
Through Value-Range 3
|Ele Loop Use
Loop Start or End Flag
|Ele Lp Counter
Loop Counter Variable
|Ele Lp Exac tEn
Exact Ending Loop Number
|Ele Lp Exact St
Exact Starting Loop Number
|Ele Lp Var En
Variable Ending Loop Number
|Ele Lp Var St
Variable Starting Loop Number
|Ele Tally Clear
Running Total Clear Option
|Ele Tally Field
Target Field for Running
|Ele Tally Op
Running Total Math Operation
|Ele Tally Plus Field
Tally to Add to Field
|Ele Tally Plus Logic
Tally to Add to Logic
|Ele Tally Minus Field
Tally to Subtract from Field
|Ele Tally Minus Logic
Tally to Subtract from Logic
|Ele Type Field Type
|Ele Up To Logic
Post to Update Logic
|Ele Up To Option
Post to Option
|Ele Up To Target
Post to Target Variable
|Ele Up X18 Func
Update with Translation Function Name
|Ele Up X18 Logic
Source Field to Translate From
|Ele Up X18 Prog
Translation Program Name
|Pgm Subtype Program subtype
|Pspec Ask Ask for Main Data File Name?
|Pspec Ask Prompt
Prompt Text to get Main File
|Pspec Alt File
Reports Output Data File Name
|Pspec Alt Text
Reports Output File Prompt
|Pspec Output
Report Output Option
______________________________________
The system variables thus provide an easy mechanism allowing for the testing of current state, the manipulation and conversion or translation of data between records and fields and between sets of fields, for the establishment of option sets, and in specifying logic function operations for particular fields or actions to be taken entering or exiting fields. While the system variables are available for reference in feature packets, they are more commonly used in or referenced by the program and test rules implemented in the knowledge base 34. Most of the system variables affect or detail lower level functions relative to the functional specifications established in relation to feature packets. For example, a mere field name reference in a feature packet that supports editing of the displayed value will be implicitly evaluated subject to the program and test rules to determine if an initial default value is to be displayed in the field. The test rules that will determine if a default value is to be displayed and the program rules that will determine or fetch the default value can reference the system variables extensively in implementing the necessary functional logic. If a field is to be defaulted to the current date, but permitted to be user modifiable, then the rules may retrieve the current date (|Data Date) and place the date in the field (|Display To) if the current field (|a) is empty. Consequently, a direct and highly non-procedural capability is provided by the use of the system variables within function packets, while providing a detailed yet highly abstracted capability in support of the formation of program and test rules. Finally, the various definitions generated by the image editor are provided preferably as each definition is completed to the sequence generator 66. The definitions are evaluated by the sequence generator 66 to generate sets of application sequences. The definition evaluation is preferably performed by an expert system underlying the sequence generator 66. As feature packets and functional logic are evaluated by this expert system, reference is made to a control table 64 that, in combination with rule table 62, operates as an abstract, multi-level data look-up facility utilized in support of generating definite application sequences. The control table identifies sets of rule table entries while the rule table provides the abstracted behavioral characteristics for each basis referenced in the feature packets. A simple basis may have a single rule table entry that is properly used in all instances where the basis may appear. A more complex basis, or function, defined as a basis that may be subject to some ambiguity in its intended use, may be first evaluated against the control table to determine a particular set of basis rules to consider in further evaluating the complex basis or function. Thus, for example, a function reference to a field name in the context of a data input process may imply the need for establishing the input focus transversal of the field relative to others. However, the same function in the context of a report process would imply a significantly different functionality, particularly one related to the optimum retrieval order of data for this and related fields. Functions, representing complex basis, are referenced through the control table 64. These functions are summarized in Table IV.
TABLE IV
______________________________________
Control Table Functions
______________________________________
ALT KEY Defines how program elements are to be selected by
an alternate index key reference in different
contexts.
AUTONUMBER
Defines how ordered program elements are to be
sequenced in different contexts.
ELEMENT Defines the process for creating a program element in
different contexts.
ENTRY Defines traversal order for fields in different contexts.
LOCATION Determines how the location of a field or program
element is to be determined in different
contexts.
MAIN KEY Defines how program elements are to be selected by
the main index key reference in different
contexts.
ORDER Determines the method of defining the order of
program records or elements in different
contexts.
RECORD TYPE
Determines the type of a program record in different
contexts.
UIP FIELDS
Determines the set of additional fields or program
elements that must be defined in support of the
further rule processing of a program segment in
different contexts.
______________________________________
For example, the ELEMENT function, in the context of a data capture program, will, in turn, reference the following functions or simple basis: ELELOC Element location on the image page; ENTRY The order in which data fields collect data; NAME Element of field name; PTRANS Translation sequence for the field name; and RECORD Add to the database. However, in the context of a posting process, the ELEMENT function will reference only ELELOC, NAME, PTRANS, and RECORD. FIG. 5 illustrates the process implemented by the image editor 32 in creating the various definitions and text that are provided to the sequence generator 66. The process 70 begins with the election of a user choice 72 to define the file structure 74, define a program structure 76, or create a field definition 78. With each of these choices, the user is prompted, and provided with starting text as appropriate, through a process that results in the production of definitions and text representing the user's further inputs. In the case of defining a file structure 74, file definitions and text are produced. The file definitions are utilized to logically establish the file and record 56, 58 entries in the application structure 36. Prompt responsive text entered with respect to each of file and record 56, 58 is also captured by the define file structure step 74. This text is stored to the help file 40. The process 70 then resumes with another user choice 72. The define program structure step 76 similarly results in the creation of program definitions and text. The program definitions are utilized to logically define the program and segment records 52, 54 of the application structure 36. The prompt responsive text is stored in the help file 40. The file and program definitions created by the steps 74, 76, including the applicable record and are effectively made immediately available to the sequence generator 66. That is, with each iteration of the operation of sequence generator 66, the application structure 36 is available to the sequence generator 66 for reference. The create field definition step 78 and succeeding steps 80, 82, 84, 86 together detail the flow of creating field definitions and text. This process is generally exemplary of the define file structure 74 and define program structure 76 steps described above. The process of defining a field begins with the choice of the create field definition 78 by user choice 72. A predefined prompting question and any applicable starting text is obtained from the question file associated with the help file 40 and presented to the user for response. This introductory question step 80 is utilized to obtain an introductory statement as to the purpose and function of the field being defined. This field introductory text is stored back to the help file 40. A define field step 82 permits the user by input to select the appearance of the field being defined. This may include the selection of an object from the object store 42. The attributes of any fields within an object retrieved during the define field step 82 are maintained initially, subject to further modification by user input. Specifically, feature packets associated with a field within an object may be opened and edited during the define field step 82. Feature packets associated with an object can also be added or removed. Thus, an object, once retrieved in a define field step 82, preferably ceases from being distinguished as an encapsulated object. Each field and attribute defined through the retrieval of an object is functionally no different from a field or attribute newly defined through user input. When the user input indicates that the definition of a particular field is complete, at least temporarily, the imaging editor 34 transitions to the validate field step 84. The rule table is consulted in real time in combination with the application structure 36 to ensure that proper feature packet basis and functional logic have been defined for each attribute associated with the defined field. If the validation of the field fails, the imaging editor 32 returns to a define field step 82 to permit user directed correction. Failures that are subject to unambiguous correction may be automatically corrected by the imaging editor 32. When a field is finally validated, corresponding field definitions are produced by the imaging editor 32. These field definitions serve to identify all aspects of the field and assigned attributes. Although these field definitions are preferably immediately provided to the sequence generator 66 for processing, an image is maintained by the image editor 32 in support of further editing of the defined fields. Once a field has been validated, an explain question step 86 is performed to obtain detailed explanatory text regarding the purpose and function of the defined field. A prompting question and, again, any applicable starting text selected based on the currently chosen attributes of the defined field is presented to the user. Prompt responsive text provided by user input is stored in the help file 40 as field explanatory text. Where multiple fields are to be defined relating to a specific function, such as category and sub-category fields used to identify an inventory item, the image editor 32 returns to the define field process step 82 to define a next field. Once the set of one or more fields are fully defined, the image editor returns to the user choice step 72. Referring now to FIG. 6, a detail 90 of the sequence generator 66 and application sequences produced by the sequence generator 66 are show. As previously established, the sequence generator 66 operates from the application structure 36, presented as file definitions 92 and program definitions 94, and the field definitions 96 produced by the image editor 32. These definitional inputs are processed by the expert system of the sequence generator 66 directly or indirectly through reliance on the control table 64 to identify and select behavioral characteristics of a specific basis from the rule table 62 as identified by attributes of the field definitions 96. In the preferred embodiment of the present invention, the sequence generator 66 operates to generate discrete sequences that are functionally descriptive of particular aspects of the input definitions. Specifically, program sequences 98 are generated to define the apparent ordered execution of the process represented by a particular segment 54. For example, program sequences will define the order that screen display fields are visited. Program sequences will also implicitly define the order of retrieving, editing, and saving record data. Data sequences 100 are discretely generated to describe ordered data relationships between various records 58. For example, data sequences will define the files and records 56, 58 and the key fields that are to be used to retrieve or store data to those or other files and records 56, 58. File sequences 102 are generated to provide relation references between program and data sequences 98, 100. For example, a file sequence may provide a logical connection between a field identified as part of a logical functional statement of a feature packet that is realized as an ordered set of program sequences and a data sequence 100 that references a particular record 58. A file sequence 102 is utilized to specify the transfer of data referenced by the data sequence 100 to a field referenced by a program sequence 98. Translation sequences 104 are generated to support the ultimate association of particular data names with abstracted variable names that are either implicitly allocated on a dynamic basis through the operation of the sequence generator 66 or represent system variables. Thus, data identified by a data sequence 100 and retrieved as specified by a file sequence 102 will be instantiated ultimately in a program variable established by the author 44 based on a translation sequence 104. Validation sequences 106 provides discrete sequences that represent conditional qualifications that may be applied in reference to other sequences. In particular, validation sequences are utilized to embed functional logic conditions applicable to particular data fields or groups of data fields. Segment record sequences 108 provide a list of the record identifiers of the records 58 that may be involved in a data read or write, test for existence of a specific record, a purge or clear of a particular record, and any records that are to be used as a source or target or involved in a header/detail relationship with a record that is to be read or written during a current segment 54. Feature sequences 110 provide for sequences that describe functional logic that is to be applied to a field or group of fields and may involve references to system variables of all types. Although each feature sequence is now preferably complete in specifying a particular functional logic function, such as tallying a particular field to another with a specific arithmetic or boolean operator, more generalized functions can be implemented through the use of multiple sequences to represent a single feature packet. The application sequence structures 98, 100, 102, 104, 106, 108, 110 are not ordered strictly as first-in first-out ("FIFO") sequence buffers. Although sequences may be added to the structures in a generally parallel FIFO order, each of the application sequences are added in a frame by frame relationship that relates zero or more sequences in the sequence structures 98, 100, 102, 104, 106, 108, 110 in a virtual frame such as the frame 112. Thus, if a program sequence within the frame 112 does nothing more than assign a value to a field, a translation sequence may be the only other sequence in the frame 112. Conversely, any number of sequences in one or more of the sequence structures 98, 100, 102, 104, 106, 108, 110 may be related by a particular frame 112. Consequently, each frame 112 of the application sequences fully defines a very narrow logical relationship that may be ultimately realized in the execution of the code generated by the application generator 30. Although the application sequences are related to one another as frames 112, the individual sequences may be added to the application sequence structures 98, 100, 102, 104, 106, 108, 110 on an as generated basis. The functional partition of the sequences into discrete sequence types results in sequence relationships being implicitly defined by frame reference. In a preferred embodiment of the present invention, the application sequences are simple data records each with a small number of sequence fields. Each of the different types of sequences 98, 100, 102, 104, 106, 108, 110 have a unique, predefined set of sequence fields. In general, all of the sequences include a sequence field identifying a corresponding segment 54 and directly or indirectly a frame identification field. However, some sequences 98, 100, 102, 104, 106, 108, 110 may be generic to a file 56, program 52 or even a topic 50. These generic sequences are considered part of the sequence sets of art all hierarchically depending segments 54 and records 58. Sequence type specific fields include function fields for specifying a program sequence function, such as verify vendor, and more generalized sequence fields, such as counters, for specifying the order of sequences related to a particular frame or sequence. Frames 112 of the application sequences are generally sequentially evaluated by the expert system underlying the application author 44. As indicated in FIG. 7, programmer specifications, representing the collected application sequences are received as an input to the application author in combination with the application structure 36 as represented by the file definitions 92 and program definitions 94. In addition, the application author 44 has access to the knowledge base 34 for retrieval of program rules 120, test rules 122, basis rules 124, skill rules 126, and syntax rules 128. Based on the program type and sub-type obtained effectively from the program definition 94, the applicable set of program rules 120 and corresponding test rules 122 are selected for evaluation by the author 44 against the programmer specifications. These selected program rules anticipate and impose a general framework to the functions and relationships presented by the programmer specifications. As a consequence, the program rules 120 serve to select out of the programmer specifications the information from the available application sequences needed to satisfy the program rules 120. The test rules 122 serve as high level qualifications tests to determine whether different subsets of the program rules 120 are to be utilized in view of the particular programmer specifications being supplied to the application author 44. Consequently, the comprehensive structure and flow of a particular code module generated by the application author 44 is inferentially dependant on the fields and field relationships initially established based on user input. The basis rules 124 are evaluated in concert with individual program rules and specific frames of application sequences to instantiate the previously abstracted behavioral characteristics of feature packets as represented by the programmer specifications. The skill rules 126 are applied by the application author 44 to develop the intermediate representation of the code being produced by the application author as a consequence of the evaluation of the program and basis rules 120, 124. The skill rules 126 also participate in the evaluation of the syntax rules 128 against the intermediate representation of the code to ultimately realize the instantiation of individual code statements. Finally, the application author 44 also produces textual information relating to the fields, programs and menus that will be realized through the execution of the code. This additional information typically includes field sizes and types, included programs, and menu organizations, as well as context specific directions on the manner of operating at a screen prompt, the available program options at different points of execution, actions that are specifically disallowed at a point of execution, for example. This information is stored in the help file 40 by the author 44 to augment the information previously stored there. Referring now to FIG. 8, the documentation publisher 46 operates generally in parallel with the application author 44, though with the notable distinction of the dependency upon the help file 40 as being prior augmented by the author 44. The publisher 46 depends on the application structure 36 as provided by the file definitions 92 and program definitions 94, which include the segment and record definitions, as well as the programmer specifications provided from the sequence generator 66. Specifically, the document publisher 46 implements a relatively simple expert system that evaluates document rules 130, obtained from the knowledge base 34, primarily against the information provided by the help file 40. The document rules 130 serve to guide the construction of the documentation from the help file information based generally on the application structure 36. In particular, the menu lists associated with the current topic of the program definitions 94 is utilized to organize the body of the documentation. The programmer specifications are evaluated, again generally on a frame by frame basis, to construct screen and report format representations suitable as illustrations within the documentation. Key words, such as function key names and basis types that occur in the help file 40 are used to trigger the evaluation of reserved word rules 132. These reserved word rules 132 are provided preferably to support expanded explanations of key concepts, operational features, or methods of use in a non-repetitive manner. Reserved word rules 132 may also support key word indexing and creation of glossary entries for key words. The text library 134 is provided to support the publisher 46 in evaluation of the documentation and reserved word rules 130, 132. The text library provides predefined text sections, including section titles, screen introductions, appendix titles, legal notices and standard instructions. The text library 134 may also include a variety of small, less specialized text strings that can be manipulated upon evaluation of the syntax rules 136. In particular, the help file 40 and programmer specifications will provide for the identification of various fields and user visible attributes, such as display only, numeric or text only entry or the source of a default field value. The syntax rules 136 are evaluated to manipulate this information into a standard form of presentation appropriate for inclusion in the documentation in reference to the corresponding image. Consequently, a highly detailed set of documentation is produced by the publisher 46 in direct correspondence to the exact screen displays processes and reports that are implemented by the specific code generated by the application author 44. Thus, a complete application generator system and method, providing direct support for the design, implementation, maintenance and documentation of essentially custom application programs has been described. The system requires a minimum amount of information to be input by a user in order to specify the functionality of the resulting application program. The information input is largely constrained to the definition of the application structure and logical attributes of fields that specify the characteristics of field and the relationships between fields that inferentially define the functions necessary to carry out the realization of the attribute defined functions and relationships. From these attributes and the application structure, an over-specification of application sequences is created that fully describe the inferred detailed relationships and qualifications of the attributes defined by user input. This over-specification is then reduced by an expert system that selects and utilizes needed and applicable portions of the application sequences to realize the control logic necessary to construct an application program consistent with the program types specified as part of the application structure. A complete application program is thereby constructed through reduction by syntax rules to a specific programming language. A parallel reduction of the prompted and automatically collected textual information also provides for the generation of application program documentation highly correlated to the specific application produced. Various modifications and alternate implementations of the present invention are contemplated and may be readily resorted to by those of skill in the art without departing from the nature and scope of the present invention. In particular, many different implementations of the expert systems described above may be utilized in any particular embodiment. Direct rule parsing engines as well as backward chaining inference engines may be readily utilized in realizing the expert systems of the present invention. In addition, the expert systems of the author and publisher may be implemented as a single expert system or chained sequentially to provide for the production of code and documentation. Accordingly, the present invention may be practiced otherwise than as described above though within the scope of the present invention particularly as defined by the appended claims.
|
Same subclass Same class Consider this | ||||||||||