CA2236229C - Application program and documentation generator system and method - Google Patents

Abstract

Automatic generation of an application program is performed by a programmed system (30) including a guided editor (32) for establishing program (76), da ta (74), and field definitions (78) into a plurality of functionally descriptiv e atomic sequences (38), each describing a unique characteristic such that a plurality of frames, each comprising zero or more functionally descriptive atomic sequences from each of the functionally descriptive sequences, respectfully describes the plurality of input event elements (14). A rule processor (66), including a program rule base (62) conditionally describing the structure and operation of a predetermined application program, autonomously processes the program rule base (62) in concert with the plurality of functionally descriptive atomic sequences (38) proceeding generally sequentially over the plurality of frames conditionally unifying t he plurality of functionally descriptive atomic sequences (38) with the structu re and operation of the predetermined application program. A syntax processor (22), including a syntax rule base (128) defining the syntax of a predetermined programming language, then autonomously unifies the plurality of functionally descriptive atomic sequences with the syntax of the predetermin ed programming language, then autonomously unifies the plurality of functionall y descriptive atomic sequences (38) with the syntax of the predetermined programming language to provide a coded representation (24) of the structure and operation of the predetermined application program.

Description

W O 97tl5882 PCT~US96/16267 Application Program and Documentation Generator System and Method Inventors:
Brian T. Stack _ 5 Background of the Invention 1. Field of the Invention:
The present invention is generally related to an automated program and docllm~nt~tion generating system and, in particular, to a multi-stage, rule based system ~or managing the concurrent development of a program and documentation specifications that are then processed into program code and directly corresponding user documentation.

2. Descri~tion of the Related Art:
Automatic program generation, referred to variously as the product of program synthesizers, application generators and self generating systems, are particularly desirable as the complexity of application programs increase concurrent with an ever growing desire for different and distinct ~unctionality at all levels of an application's operation. The ability to design, W O 97/lS882 PCTnJS96/16267 implement, maintain and document an application with broad and highly con~igurable ~unctionality ~;m;n;~h~
as the comprehensiveness of the application increases.
Furthermore, training and documentation must deal with the mani~old options that such applications include.
In order to alleviate the presence o~ unnecessary complexities and con~iguration options, yet avoiding the necessity o~ completely redesigning, implementing, maint~;n;ng and documenting dedicated application programs, a variety o~ program generators have been proposed. Perhaps the most cnmmn~ ~orm o~ program generators are the ~orm and report generator shells commonly used with or provided as part o~ database management systems. These systems permit reasonably complete screen and report layout de~inition through the identi~ication of ~ield locations, data types and ~ormatting, and relations to data stored in an underlying, prede~ined database management system. An operative program is generated that allows user data exch~nge through ~orms and data output through reports based on a de~ined correspondence between ~orm, report and database fields. The concept o~ a data dictionary has been introduced to, in part, support internal documentation o~ the relational correspondence between the de~ined database ~ields and the ~orm and report ~ields. Such systems typically provide little additional support o~ application design, little i~ any support o~ ~unctional logic to process data transported to or ~rom the database, and essentially no automatic documentation o~ the programs generated.
In order to support a greater degree o~ internal ~unctional capabilities, program synthesizers based on libraries o~ pre-established program parts have been W O 97/15882 PCT~USg6/16267 proposed. A library based program synthesizer is described in U.S. Patent Number 4,949,253. The described program generator operates from de~ined data to select a best match o~ a program part prototype from a part prototype library. Each program part prototype stored by the library is prede~ined and statically maint~;n~ as part o~ the library until selection during program generation. Upon selection, the program part prototype is processed through macro substitution to merge the inter~ace to the part prototype with, presumably, a previously processed part prototype and, ~urther, to uni~y the variable names utilized by the part prototype with those o~ the previously processed part prototype.
In ~unctional terms, however, the capabilities o~
each part prototype is essentially ~ixed upon initial establ;~hm~nt within the part prototype library. The patent does not describe how part prototypes are selected based on ~unction as opposed to available inter~ace de~initions. In the absence of such selectability, the ~unctionality o~ the various part prototypes must be narrowly de~ined as against the particular ~unction o~ the overall program to be generated to insure that the inherently realized logic o~ the program ~ollows ~rom the de~inition o~ the part prototype inter~aces.
Another program synthesizing system is described in U.S. Patent Number 5,315,710. This system again operates ~rom a library termed by the patent as a program components data base. The system provides ~or an increased degree o~ ~reedom in inter~acing program ~ components ~or the automatic generation o~ mediating program parts that are tailored to speci~ically couple WO 97/lS882 PCT~US96/16267 otherwise disparately defined program components. Thus, where two seemingly incompatible interfaces of program components must be joined, a yloy~.. transformation rule base is consulted for a computative rule that can be utilized to convert the unit, base or type of data to another such representation. A data type transformation rule may be utilized to convert the data type of data from one type to another. By combination of these transformations for each o~ the variables through which data is passed between program components, a m~ ting program is assembled. The two interfaces of such a mediating program are inherently defined by the interfaces of the program components to be joined.
Thus, the program components and mediating program can be assembled into a larger ~unctional unit as part of or to complete a larger application program. However, the generated mediating program is inherently limited in its ability to alter the operational function of the program components. Consequently, the available selection of program components must be well predefined and highly consistent with the ultimately intended functionality of the application program generated.
An automatic program synthesizer system of greater functionality is described in U.S. Patent Number 5,038,296. In this system, a system specification and set of program synthesis rules functionally define a target program through the description of operations to be per~ormed on data represented by variables. The system specification and program synthesis rules i~ nt;fy these variables through functional definitions.
The program synthesizer processes these definitions to resolve functionally described variables to specific variable names. Existing variables are identified by W O 97/15882 PCT~US96/16267 - their assigned ~unctional attributes. Where a variable has yet to have been de~ined ~or a speci~ic set of attributes, an interpolation program is generated to de~ine the necessary variable with the required attributes. Since the interpolation program is apparently generated by the same program generating means utilized to created the target program, the interpolation program apparently operates to combine, as necessary and appropriate, other pre-existing variables to obtain the variable value that is to be ~unctionally stored by the newly created variable. That is, the ~unction o~ the program generating means is to couple speci~ic operations to essentially singular variables.
Consequently, the ~unctional outline o~ the target program provided by the system speci~ication with ~unctional sub-steps being de~ined by program synthesis rules can reasonably de~ine a complete target program.
The program synthesizer described in U.S. Patent Number 5,038,296, however, appears to inherently require a very close concordance between the system speci~ication and the pre-existing program synthesis rules in order to generate a target program. The disclosed system provides no identi~iable method or merh~n;~m ~or creating or m~;nt~;n;ng such a concordance or insuring valid use during the operation o~ the program synthesizer. Furth~rmnJre, the disclosed system ~ails to identi~y any merh~n;~m ~or supporting the development o~ the system speci~ication and certainly ~ails to disclose any mechanism ~or generating documentation appropriate ~or the target program speci~ically produced.
In order to increase the available per~ormance o~
program generators, various ~orms o~ expert systems have WO 97/lS882 PCT~US96/16267 been incorporated. Such expert systems include ~inite state automata, ~orward and backward ~h~;n;ng rule based in~erence engines, ~uzzy logic in~erence systems and context sensitive or guided editor systems. Although the use o~ such expert systems can greatly increase the apparent ~unctionality o~ a program generator system, such expert systems have typically been applied in an application processing environment that, based on prede~ined rules, limits the perceived complexity o~ the operative system to the particular data input and requests made o~ the expert system. As such, the~e expert systems present an environment within which an application appears to have been constructed.
Compilable or interpretable application plOyl~L. code is not generated. Consequently, such environments are di~icult to design and maintain and make little provision ~or the production of documentation that is speci~ic to a particular working application program.
Expert systems have also been utilized as components in more conventional program generators.
However, in most instances, the expert systems are ~unctionally limited to more completely or expansively enabling the selection o~ program part prototypes ~or use in the construction o~ the application program or inferring suitable mediation trans~ormations necessary to inter~ace program compnn~nt~. As a result, the prior art utilization o~ expert systems in program generator systems has not previously enabled the development o~ a comprehensive application program generator.

W O 97/15882 PCT~US96/16267 Summary of the Invention Thus, a general purpose of the present invention is to provide for the comprehensive design, generation maintenance and documentation of indep~n~nt, functionally targeted application programs.
This is achieved in the present invention by a programmed system that provides for the automatic generation of an application program. The programmed system includes a guided, image editor for establishing 0 pLO~ l, data and field definitions from a plurality of input event elements. A sequence generator, coupled to the guided editor, autonomously processes the program, data and field definitions into a plurality of functionally descriptive atomic sequences, each describing a unique characteristic such that a plurality of frames, each including zero or more ~unctionally descriptive atomic sequence from each of the ~unctionally descriptive sequences, respectfully describes the plurality o~ input event elements. A rule processor, including a program rule base conditionally describing the structure and operation of a predeterm;ned application program, autonomously processes the program rule base in concert with the plurality of functionally descriptive atomic sequences proceeding generally sequentially over the plurality of frames conditionally unifying the plurality of functionally descriptive atomic sequences with the structure and operation of the predet~rm;n~d application program. A syntax processor, including a syntax rule base defining the syntax of a predetermined programming language, then autonomously unifies the plurality of - ~unctionally descriptive atomic sequences with the syntax of said predetermined progrAmm;ng language to provide a coded representation o~ the structure and operation o~ the predeterm;ne~ application program consistent with the syntax o~ the predet~rm;ned programming language.
An advantage o~ the present invention is that a set o~ sequences describing input event elements is gathered by the guided image editor. Provided that the input event elements reasonably correspond to the anticipated function o~ the predete~m~n~ application program, the rule generator provides ~or autonomously uni~ying the sequences wlth the program rules by conditionally utilizing the contents o~ the se~nc~s to automatically generate an application ~O~1~LI substantially de~ined by the input event elements and consistent with the program rules.
Another advantage o~ the present invention is that the syntax generator provides ~or the autonomous generation o~ compilable or interpretable code ~ully consistent with the de~inition o~ a predetermined programming language.
A ~urther advantage o~ the present invention is that the guided image editor provides ~or objecti~ying a series or grouping o~ one or more input event el~m~nt~. The resulting objects can be cut, copied and stored away ~or ~uture use. Since an image, rather than a mere re~erence is captured by the object, complete inheritance characteristics are not provided. Rather, internal re~erences are maint~;ne~ within the image and used subject to consistency rules upon pasting o~ the object into another object or larger image. Thus, reuse coupled with the capability for independent modi~ication is provided.

_ W O 97/15882 PCT~US96/16267 - Yet another advantage of the present invention is that the guided image editor provides ~or the docllmPnt~tion of the existence, purpose and operation o~
the input event elements substantially coincident with their input. Documentation is received generally on a per event basis as text input in response to guiding questions or prompts. Subse~uently, all aspects o~ the event desired se~uences can be accessed by the rule generator in concert with the help text to provide highly characterizing docllmPnt~tion that closely ~ollows the structure and appearance o~ the generated application program. The generated documentation can include textural descriptions generated in correspondence with the processing and limiting logic de~ined ~unctionally in connection with the input events. The generated documentation i9 Eurther processed to include library text and constructed tables, including tables o~ contents and ~igures.

Brie~ Description o~ the Drawings These and other advantages and ~eatures o~ the present invention will become better understood upon consideration o~ the ~ollowing detailed description o~
the invention when considered in connection o~ the acc~mp~nying drawings, in which like re~erence numerals designate like parts throughout the ~igures thereo~, and wherein:
Figure 1 provides a general organization o~ the knowledge structure o~ the present invention;
Figure 2 provides a diagram of the preferred relational architecture o~ the various components o~ the present invention;

Figure 3 provides a simpli~ied diagram of the application structure maintained by the present invention;
Figure 4 provides a diagram. o~ the image editor and related sub-~ystems utilized to generate application sequences in accordance with the present invention;
Figure 5 provides a diagram detailing the operation o~ the imaging editor sub-system;
Figure 6 provides a diagram detailing the operation o~ the sequence generator in establishing the parallel application sequences;
Figure 7 provides a diagram detailing the application author expert sub-system constructed in accordance with the present invention; and Figure 8 provides a diagram detailing the pre~erred construction o~ the documentation publisher expert system constructed in accordance with the present invention.

Petailed Description of the Invention A system that provides ~or the substantially comprehensive and automatic generation o~ any number o~
application programs is generally shown in Figure 1.
The application generator system 10 is pre~erably executed within a conventional general purpose computer system (not shown) and within a conventional operating system environment such as provided by Microso~t Windows 3.1 and supporting a conventional progr~mm;ng language, such as BBX Business Basic available ~rom Basis International, Microso~t C available ~rom Microso~t, Inc. and C++ available ~rom International Business Marh;n~, Corp. Within this environment, the system 10 operates to acquire and construct the application W O 97/15882 PCT~US96/16267 structure and sequences 12 that correspond to a particular application program through the application o~ user input 14 optionally in combination with the utilization o~ sequence speci~ying objects 16. The user input 14 may be direct programmer data entry, system speci~ications authored by a skilled end user, or the product o~ computer aided analysis o~ other programs and speci~ications that, in combination with a user's quali~ying direction, produce the equivalent of direct user input.
The objects 16 are, in accordance with the pre~erred embodiment o~ the present invention, high level arbitrarily formed components of the user input 14. As such, the objects 16 are not directly pr~
parts but, rather, are partial detailed speci~ications encapsulated into objects that may be cut, clipped, stored, replicated and moved within the process o~
providing user input 14 during the creation o~ the application structures and sequences 12.
As the application structures and sequences are created or subsequently modi~ied, the resulting structures and sequences are parsed through a substantially hierarchial expert system that successively applies program rules 18, skill rules 20 and syntax rules 22 that clll m; n~te in the generation o~
a discrete module or set o~ modules o~ compilable or interpretable code 24, independent documentation, or both code 24 and corresponding documentation 26. The program rules 18 are provided in a rule base organized to provide a set of common rules and discrete sets o~
rules speci~ic to particular program types. Although - program types may be arbitrarily de~ined consistent with the present invention, the presently pre~erred set o~

program types include data collection, data processing, and data output program types. Additional program types, such as one providing for the definition of an expert system that can be used separately or in support o~ the other program types can also be defined.
Further, program sub-types may be associated as detailed categorizations of the program rules 18. Consistent with a pre~erred embo~;m~nt of the present invention that is oriented toward accounting or accounting type application generation, the p r 0~ r ~11 sub-types pre~erably include maintenance, transactional, and detailed analysis screens subordinate to the data collection program. type, a posting process subordinate to the processing program type and columnar report, inquiry report, and ~orm reports subordinate to the output program type. Thus, as the plO~ r ~1l rules 18 are applied to the application structure and sequences 12, appropriate sets and sub-sets of the program rules are data dependently identi~ied and executed toward the realization o~ the application program speci~ically corresponding to the particular application structure and sequences 12 to which the program rules 18 are applied. Consequently, the present invention provides most directly for the presence and utilization of potentially conflicting program rules that may appropriately exist in support of different types and sub-types o~ application p r oyl~l~. Since some rules are not associated with any particular program type or sub-type, some o~ the program rules 18 are generically and there~ore e~iciently defined ~or use in generation o~
all types o~ application programs.
The skill rules 20 represent the low-level functional operations that are utilized to effectively W O 97/15882 PCTrUS96/16267 implement the application of the program rules. That is, the skill rules provide basic functional operations that are widely used in the generation of an intermediate representation of a generated program.
Although any number of skill rules 20 may be de~ined for use within the system 10, the present implementation provides ~or eight basic skills including:
1) Single Line: directs the processing of a rule through substitution or interpretation to establish an int~rm~;~te or final code representation o~ a constant or variable element in a one-to-one relationship of rule to output line (Bxample: a rule uses this skill to instantiate the rule as a line of code;
2) Recurring Line: directs the processing o~ a rule through substitution or interpretation to generate a series o~ nearly identical int~rm~ te or final code representations o~
a constant, or more typically, a variable element (Example: a rule uses this skill to generate code providing for an array of detail lines in a header detail relationship);
3) Variable List: directs the processing of one or more rules referencing variable elements that may be used in dif~erent contexts (such as numeric verses string) and generates a corresponding single int~rm~ te or final code representation of the rules (Bxample:
rules establish multiple variables that are initialized to either numeric or string - defaults based on the type of a switch variable and organized into a final code W O 97/15882 PCT~US96/16267 representation o~ a "case" programming statement);

4) Recurring hist: directs the processing o~ one or more rules consistent with the application o~ a Recurring hine skill to a Variable LiRt skill (Example: provides ~or generation o~
separate case statements ~or each row of a detail array, thereby providing ~or independent processing o~ the detail rows);

5) Implied List: directs the generation o~ a list of constant values to be used in a variable element (Example: generation o~
program subroutine name re~erences in the construction of a jump table);

6) Translate: directs a sequence search to select one or more sequences related based on a de~ined constant or variable (Example: search sequences to ~ind the sequence speci~ying a screen ~ield location o~ a ~ield re~erenced by the ~unctional logic o~ a ~eature packet re~erenced by a current sequence);

7) Combined hist: directs the evaluation o~ one or more rules to select and process each o~
one or more related sequences based on sequence type, such as alpha verses numeric, based on an ~m; n~tion o~ a set o~ sequences ~or given relationships (Example: ~irs~
declaring and then establishing the value of a system variable based on the content o~
other system variables ~urther constrained by whether such other variables are in use in a relevant context); and W O 97/15882 PCT~US96/16267 8) Mixed List: directs the selection o~ one or more sequences to be used in establishing a variable element based on any coincidental relationships that can be identi~ied through ~m;n~tion of a quali~ied set o~ sequences (Example: det~rm;n~ a best match join o~
~ields declared as part o~ two or more ~ile records to develop a key ~or ordering the return o~ data ~rom a ~ile).

The program rules 18 may exist in the program rule base in a seemingly arbitrary order. However, the program rules 18 may be considered to be ordered when viewed as applicable to a particular program type and sub-type. Thus, ~or a particular program sub-type, program rules will appear to be ordered in an evaluation sequence that, upon application to the application structure and sequences 12, will provide ~or the realization o~ a corresponding application program sub-type. The processing o~ program rules 18 begins at a logical root rule and proceeds through the ordered set o~ rules that are either generic to all program types or speci~ic to the sub-program type presently being evaluated. As the program rules 18 are being evaluated against the application structure and sequences 12, the skill rules 20 are executed to develop a logically complete representation o~ the application program to be realized through the generation o~ the code 24. That is, the skill rules provide for the instantiation o~ the logical statements that, when ~urther evaluated against the syntax rules 22, provide for the generation o~ the - code 24. Since each logical statement o~ an application program can be ~ully represented as a constant or CA 02236229 l99X-04-27 variable element, represented either in numerical or ASCII ~orm, or list structures o~ such elements, even the limited set o~ eight basic skills is su~icient to support a ~ull and ~unctionally complete set o~ program rules 18 neces~ary to generate most, i~ not all, accounting or accounting related applications The eight basic skill rules are also quite su~icient to generically support generation o~ many other types o~
applications as well. Should either di~ferent ~unctionality be desired or required ~or a particular application or a higher level pr Oyl~LI rule be desired to be supported through the construction o~ a complex skill, such skills may be readily added to the skill rule base 20.
In the pre~erred embodiment o~ the present invention, the interme~;ate representation o~ the application program is only transiently developed. As each statement representation is generated, syntax rules ~rom the syntax rule base 22 are applied to realize and output the code 24 to a persistent ~ile stored pre~erable on a non-volatile storage medium.
The syntax rules 22 are maintained in the syntax rule base as largely an ordered series o~ rule statements. Division among the syntax rules within the syntax rule base may be de~ined by a language type code attached to each rule. Di~erent language codes may be de~ined ~or variants o~ the same general type of language such as Business Basic and Visual Basic or ~or signi~icantly di~erent languages, such as C. Where the languages are substantially similar, a common int~rm~ te representation o~ the application program is ade~uate ~or generating the code 24 speci~ic to either particular language. Where the language o~ the W O 97/15882 PCTrUS96/16267 ~ code 24 is significantly different, slight changes in the paradigm implemented by the int~rm~;Ate representation of the code 24 may be necessary. If this is the case, the program rules and skill rules 18, 20 may be made appropriately sensitive to the particular language chosen for the code 24 so as to suitable alter the intermediate representation of the application program as needed for closure in applying the syntax rules 22 for that language to realize the code 24 in its entirety.
Subject to the selection of the appropriate programming language, the application of the syntax rules to the interm~;~te representation of the application program proceeds on a logically statement by statement correlated basis. Each logically complete statement of the int~rme~;~te representation of the application program is utilized to select one or more corresponding syntax rules 22. The syntax rules 22, like the program rules 18, utilize the skill rules 20 to actually per~orm the operations necessary to realize the output of potentially one or more language specific statements to the code file 24 for each logical statement of the interm~ te representation of the application program. Thus, the syntax rules 22, like the program rules 18, are well supported by even a small set of skill rules. Syntax rules 22 that specify higher level ~unctions or require dif~erent operations in the generation of the code 24 may be readily supported by augmenting the skill rules 20 with different or more complex skill rules.
Although the foregoing description of the system 10 - has largely been in relationship to the generation o~
code 24, the system 10 equally produces documentation 26 W O 97/15882 PCT~US96/16267 that is highly correlated to the speci~ics o~ the code 24 as generated by the system 10. The user input 14 and objects 16 both may contain and represent descriptive comments that are ultimately embodied in the code 24 and descriptive text that describes entire programs, sub-programs, individual screens and report, and particular ~ields that are a part thereo~ as the documentation 26.
Thus, these code comments and descriptive text are embodied as or correlated to sequences within the application structure and sequences layer 12 and sub~ected to evaluation by program, skill and syntax rules 18, 20, 22 generally as the sequences are evaluated. The code comments are thus e~~ectively compiled into the code 24. The descriptive text is s;m;l~ly compiled into the documentation :Eile 26 that is persistently stored pre~erably on a non-volatile storage medium.
Since the application structure and sequences 12 are also stored in a persistent ~ile, preferably on a non-volatile storage medium, the system 10 permits ongoing maintenance, modi~ication and derivation o~ the stored application structure and sequences 12.
Consequently, the application generation system 10 provides for the comprehensive design, implementation, maintenance and documentation of a substantially automatically generated application program.
The pre~erred architecture 30 o~ an application generator constructed in accordance with the pre~erred embodiment o~ the present invention is shown in Figure 2. An image editor 32 that combines ~eatures o~ a prompting guided editor facility as well as a context sensitive editor in combination with a ~ull screen imaging editor, provides the primary environment ~or a W O 97/15882 PCTrUS96/16267 acquiring user input. The pre~erred image editor 32 presents as a 80x25 cell viewport on a 999x999 cell image page. The display image presented to a user ~or use in input can be a combination of viewport sections ~rom di~erent parts o~ the image page. In addition, e~ectively o~f screen portions o~ the image page can be utilized as scratch areas utilized in support o~
processes that realize on screen viewable in~ormation.
The image editor 32 is utilized to design and de~ine an application structure 36 constructed as a hierarchal relationship between a topic, identi~ying a particular application program, corresponding programs that together implement the application program, and sequences that, together, define speci~ic programs. The hierarchical relationship serves to establish the application structure 36 in a de~inite and easily re~er~nc~hle ~orm. Furth~rm~e, each topic, program and segment is uniquely identi~ied by a re~erence name stored as part o~ application structure 36.
The application structure 36 also maintains a hierarchical relationship o~ ~iles and ~ile records utilized in connection with a particular topic. Each of the ~iles and ~ile records in the application structure 36 store re~erence names that are hierarchically unique ~or each ~ile and record.
The re~erence names stored within the application structure 36 provide not only a convenient way o~
designing and de~ining the application structure 36, but also uniquely de~ined re~erence handles ~or utilization by the image editor in establishing relationships that will serve as the basis for the generation o~
application sequences 38.

CA 02236229 l99X-04-27 W O 97/15882 PCT~US96/16267 The guided editor and context sensitive editor features of the image editor 32 are preferably driven by an expert system operating from a knowledge base 34.
The expert system supporting the image editor 32 integrates a documentation function with the functions of designing and defining the application structure 36 and the generation of application sequences 38. This expert system draws, from a static file associated with and ef~ectively part of the help file 40, prompting questions and starting text. The prompting questions are context specific to the user input and the starting text is context specific to the prompting questions.
Different prompting questions are retrieved from the help file 40 by the image editor 32 as topics, programs, sequences, files and records are defined. Additionally, prompting questions are selected by the image editor correlated to each field or display data defined for individual segments of programs based on program types and sub-types. In each instance, corresponding starting text that anticipates and suggests the ~orm and nature of the user input answer is provided.
In general, the prompting questions take two basic forms. The first form is a request for introductory information that might be utilized to explain the functional relationship of a segment to a program or a program to a topic or o~ a process to be carried out by a segment or program. The second form is utilized to elicit information describing a specific field or display area or processing choice presented to an end user. These prompting questions are selected from the help file 40 based on the current context of the user operation of the image editor 32 and thus serve to guide the further use of the image editor 32 including W O 97/15882 PCT~US96/16267 speci~ically the acquisition of documentation in~ormation. The user input responses to the prompting questions are stored back into the help ~ile 40 in a m~nner keyed to the original prompting questions and the speci~ic portion o~ the application structure 36 ~or which the prompting questions were generated.
The image editor 32 also provides ~or image manipulation functions, including clipping, cutting, pasting and selecting sections o~ the image page. These manipulation operations permit image portions to be moved, replicated, and deleted. Based on user input, these operations are implemented with the appearance o~
a conventional block operation. However, the image editor 32 provides, as part o~ block operation, ~or the hidden selection o~ the attributes associated with each o~ the display items and ~ields within the blocked portion o~ the image. The various block object operations are pre~erably implemented subject to the evaluation o~ block operation rules retrieved ~rom the knowledge base 34. These rules aid in the reasonable selection o~ the attributes associated with a blocked object and their merger with existing attributes when an object is copied back into an image. As such, the block operation also provide ~or consistency check and merge validation in the execution o~ the image editor 32.
Block portions o~ the image may also be copied to an object store database 42 and stored subject to retrieval upon re~erence to a uniquely assigned object identi~ier. Since the image editor 32 preferably -30 associates attribute identi~iers with each display item or ~ield rather than just re~erences to an attribute, -objects stored to the object store database 42 are logically sel~-contained and do not inherit subsequent W O 97/15882 PCT~US96/16267 changes made through the image editor 32 to any original or other copy of the object. Consequently, the objects stored by the object store database 42 are essentially static, though the objects may be dynamically selected with arbitrary size and complexity.
As display items and field data are input into the image editor 32 and attributes are assigned, the image editor 32 derives and provides definitional information to an application sequence generator that produces a set of application sequences that comprehensively describe a program segment as well as identify the database program and the display item or field, the location of the item or field within the space of the image page, and each of the functional attributes associated with the item or field. These application sequence~ are then provided to the application sequences stacks 38.
Once the application structure 36 and application sequences 38 ~or a ~loyl~llhave been constructed through the operation of the image editor 32, an application author 44 is invoked to generate a corresponding set of compilable or interpretable code. The application author operates from the application structure 36, application sequences 38, the contents of the help file 40 and a corresponding set of programs, skill and syntax rules as stored by the knowledge base 34. The application author 44, operating generally as an expert system, applies program, skill and syntax rules to the available definition of the application structure 36 in concert with the specific application sequences 38 to produce the code for a program of the particular type and sub-type being generated. That is, a program of the selected program type and sub-type is constructed by the operation of the expert system of the author 44 based on -W O 97/15882 PCT~US96/16267 the defined application structure 36 and available applications sequences 38. In accordance with the present invention, the code produced by the author 44 iS
the product o~ the program rules that de~ine a particular program type and sub-type to the extent that such rules are consistent with the provided application structure 36 and application sequences 38. Since the code statements are e~ectively independently generated by the operation o~ the author 44 based on the application structure and sequences 36, 38 the individual code statements are inherently uni~ied with respect to the number, naming and typing of all variables instantiated by the author 44. No ~urther uni~ication of~ variables or m~A; ~tion oi~ the inter:Eaces between segments o~ a single program is required.
Inter~aces between se~m~nt~, to the extent that they are required, are automatically matched by the operation o~
the expert system of the author 44 based on the de:Einition o:E the application structure 3 6 and the application sequences that de~ine data items and ~ields that are shared by di~erent segments o~ a common program.
Finally, a documentation publisher 46 e~ectively operates in parallel with the application author 44.
25 The expert system implementing the document publisher 46 operates based on the application structure and sequences 36, 38 and rules and inf~ormation provided ~rom the knowledge base 34 and help i~ile 40. In the pre~erred embodiment o~ the present invention, the - 30 publisher expert system 46 is simpli~ied by relying upon the application author 44 to ~irst e~i~ectively process - the application sequences 38 to particularly provide detailed help text describing process elements W O 97/lS882 PCT~US96/16267 implemented by the ~unctional logic de~ined by the sequences. For example, the help text for a ~ield de~ined as a three digit positive number might be: "The value o~ the Accounting Period ~ield cannot exceed 999, but may be as small as 0." Consequently, the detailed help f~ile text is generated by the application author 44 on behal:E o:E the documentation publisher 46. This in~ormation thus closely represents the particular code generated by the application author and alleviates the requirement o:E the documentation publisher 46 might otherwise have to completely reconstruct the code through reparsing the application structure and sequences 36, 3 8. Alternately, the expert system underlying the documentation publisher 46 could be merged with the application author 44 so that i~ully ~ormed documentation is directly generated by the author 44. Equivalently, the documentation publisher 46 may duplicate the expert system o:E the author 44 and operate directly ~rom the in~ormation sources utilized by the author 44. In any event, the docl~mPnt;~tion publisher 46 operates on the in~ormation provided to the publisher 46 to generate text documents that correspond closely to the code produced by the application author 44. In particular, this includes a merge of the explanatory text entered into the help :Eile 40, the screens, processes, and report ~ormats designated by the operation o:E the publisher 46 itseli~, the structure and menu organization o~ the documented program as determined from the application structure 36 including any de~initions and explanations processed by the publisher 46 based on documentation structure dei~inition rules obtained i~rom the knowledge base 34.

W O 97/15882 PCT~US96/16267 The application structure 36 maintained by the application generator 30 i8 illustrated in Figure 3.
The application structure 36 is organized as a hierarchy depending Erom a logical root node. The instantiated structure 36 consists o~ any nu~nber oE topic records 50 representing speci~ic application programs, such as an accounts payable application, a charitable gi~t donor tracking application, or a critical path construction management application. Each topic record 50 includes a topic identiEier, typically a descriptive name o~ the application program, a menu structure used to organize application program menu entries in a hierarchy o~ one or more screen oriented menu Eorms, and a program list that is used to identiEy each component program provided to realize as a cumulative whole the particular application program identif~ied by the topic. Another list structure associated with each topic collects i~ile identi~iers as re~erences to each i~ile operated on or ~rom by a particular topic 50.
Thus, a particular topic 501 associates a topic identii~ier, Topicl, a menu list structure (not shown) and program and Eile lists dia~LdLIuLLdtically shown as logical connections to one or more programs 52 and f~iles 56.
Each o~ the program records 52, ~or example speci~ically program 520, includes a program identi~ier, ProgramO, a program type and, as a program level sequence, a sub-type identi~ier and a list structure that identifies the set oi~ program segments that in turn, together, de~ine the ~unction o~ the program 520.
- 30 In the preferred embodiment oE the present invention, the programs 50 are partitioned into relatively discrete Eunctional operations. For example, within an accounts payable topic, a particular program 52 may isolate and perEorm the function of receiving and storing input de~ining an invoice. Another program 52 may be de~ined as responsible for posting invoice records to general ledger accounts. Another program may be speci~ied to select and print a reconciliation report. Thus, the logical partitioning o~ the programs 50 can be discretely identified by program type and sub-type thereby supporting the operation o~ the expert system underlying the author 44 in generating the corresponding pr Oy r ~11 code. Further, additional program types and sub-types may be readily added or de~ined and the set of program rules modified or extended to appropriately support new program types and sub-types.
Each program, such as ProgramO 520 iS effectively 15 implemented as a set oi~ one or more segments 54. A
segment record, such as segment record 541 logically identi~ies a set o~ application sequences that functionally define a sub-program ~unction of the program 520. In the pre~erred embodiment of the present invention, up to 99 segments can be associated with a particular program 520. The arbitrary limit of~ 99 segments is believed more than adequate to permit definition of suf~icient segments, each practically preferred to be of limited complexity, to implement the 25 function of any particular program 52. Thus, a segment 54 may represent an isolated data entry screen and associated input field data validation logic. A subset o~ segments 54 may be utilized to implement a more involved process where separate segments are utilized to implement, for example. a report selection screen, a report data qualification input screen and report generation.

W O 97/15882 PCT~US96/16267 Each o~ the segment records 54 store a segment identi~ier that is logically repeated, either explicitly or implicitly in each o~ the application sequences associate with a particular segment 54. These application sequences 38, in turn, provide the detailed logic utilized by the application generator 30 in the process of generating code and documentation.
The ~ile records 56 each include a ~ile ID that can be re~erenced in an application sequence to speci~y an access o~ the ~ile corresponding to the ~ile record.
The type o~ a ~ile, ~ile name and location are also stored as part o~ the ~ile records 56. The ~ile type in~ormation speci~ies, in e~ect, the access methods ~or a speci~ic ~ile. File types may include relational database ~ile, ~lat ~ile, temporary data ~ile, or in-memory data structure. The ~ile name may be either a relative or absolute path name to a ~ilesystem ~ile or, in the case o~ relational database, the name o~ the database and table that is to be re~erenced by this file record 56. The ~ile location in~ormation may be provided to support distributed ~ile re~erences or structured indirections in the location o~ ~iles within a speci~ic ~ilesystem. In addition, the pre~erred embodiment includes a data dictionary that stores in~ormation that describes the file and data structures, including field size and types, and contains maintA;nAhle location in~ormation.
Each ~ile record 56, such as FileO 560 includes a list logically identi~ying a set of one or more ~ield -30 (or record) records 58. These records 58 each store a record identi~ier that can be re~erenced by an -application sequence as a unique name within a name space comprehensive to the ~ile data space utilized by W O 97/15882 PCT~US96/16267 a particular topic. Each of the records 58 may be hierarchically referenced by a root record sequence that stores field record size and type information for each field represented by the particular record. The field size information typically represents the m~;mllm storage space available or referenceable by a particular field. The field type information specifies a data type 'chat i5 dependant on the record type. Thus, for example in the case of the flat file, the record type may be ASCII, integer or binary. In the case of a database table field, the field type may specify any of the predefined database types, including date, money, text, integer and float.
Figure 4 provides a more detailed diagram of the architecture 60 closely associated with the image editor 32 of the application generator 30. The im ge editor architecture 60 operates to merge user input 14 with objects stored in the object store 42 and feature packets stored as part of the knowledge base 34. The image editor 32 performs this function based in part upon application structure information and validation information obtained from a rule table 62. Based on these inputs, the image editor produces a sequence of image definitions that are provided to a se~uence generator 66.
The user input 14 to the image editor 32 permits a user to directly input image information that, in the case of a screen oriented form for example, specifies background data identifying the location and intended content of screen fields. The user input 14 is also utilized for performing conventional editor functions that, in particular, include the storage and retrieval of image sections as objects to the object storage base W O 97/lS882 PCTrUS96/16267 42. Retrieved objects can be pasted onto the image page maintained by the image editor.
In addition, user input 14 may speci~y attributes to be applied to data fields identi~ied on the image page. These attributes may be directed to the operative process to be implemented by a program 52 currently being edited within the image editor 32 or regarding one or more speci~ic fields of a particular segment 54.
Thus, as a program 520 is being de~ined through the operation o~ the image editor 32, any o~ a prede~ined set o~ program attributes may be selected by the incorporation o~ program based ~eature packets. These program based ~eature packets each provide a speci~ic high level speci~ication ~or a particular procedure or quali~ication that will be applied by the author 44 in generating the code for the program 520. Program based ~eature packets generally are not addressed to any speci~ic ~ield and are generally assigned one per p,~yl~.. segment. Table I provides an exemplary list o~
program based ~eature packets employed in a preferred embodiment o~ the present invention and a description o~
the ~unctional speci~ication generated by each.

Table I
F~o~, dl 11 Feature Packets Basic Pro~ram Specificdlion Allows chan~e to Type, Subtype, Read and Write PlU~Jldlll options selected - when the proS~ram was created.
Suppress Delete Key Disables the F5 DELETE function key from the user access. Used to prevent - deletion of records from master ~iles.

W O 97/1588Z PCTrUS96/16267 Suppress Print Blank Lines -' " ldL~a printinS~ a blank line when all data fields on the report are blank, optionally any back~round text on the line may be su,c,p~essed.
Output Options Defines special p. u~, al,, prucessi"~ for 1 ) Screen Inquiry, 2) Screen Sele~,Lur or 3) ASCII file - if chosen, option to receive output file name from user must be spe,;iried.
Override Pa~e Headin~ Provides for suS~ ession of standard paS;le headinS~, -"DW;..9 the format of a custom headin~. Generally used for forms ,ulucesai"E~. Almost always used when ~ene.dLi"~ an ASCII file for export.
Define Next SeS~ment Used to chan~e natural order of se,J",ehL execution from the lowest number to the hi~hest number. Can provide bldl Gh ,~ to a ptU~Jldlll not ~enerated by the system (non-native) as well as native pru~ldlll p,ucessi,~
Ask User for Main File Name P~ulllpLa the user to assi~n the main pro~ram file to a dirrt~"L file on the disk. Generally used with archive/de-archive pro~ram s to allow control over file place"-enL.
Add Process Halt Support Provides for user initialed ~IU~11dlll halt on demand.
Destroy File on Pur~e Pro~ram will delete the file speciried in Se~ment records as the PurS~e output type with this option activated. Used for Lellluo,d~ work files which are used durin~ a session and then deleted in entirety upon p, u~,~, dl 11 COl I ~F 'e tion .
Side by Side Records Defines number of columns of records to print on report before be~;.",~ a new row. Used to create double-up or four-up labels, for t~kd" . Ie.
Reset Autonumber on Pur~e All continuous autonumbers will be reset to O when records are cleared from the file durin~ purS1es.
Suppress Postin~ Screen Specifies that a postin~ process will be silent and not announce that it has started.
Don't Protect Field Math D ~ w:. divide by zero pruLe~.Lion for a field; also disables field i,,iLiali~c,Lion as a product of a calculation.
Pro~rams Pop-Up Call Ide"Liries Selector Pop-Up pro~J,d", to be called from this field, enter name or W O 97/15882 PCT~US96/16267 use F2 Call preceded by Topic to view list of available pru~ldl,ls~ The Pop-Up is referred to as a Selector.

5In editing a segment 541~ 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 ~ualifications that are to be performed generally on a field specific basis. Each field based feature packet can reference and thereby use or effect 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 - 15 embodiment o~ the present invention are identified in Table II.

Field Based Feature Packets Feature Packet Name Basis Pesc,iulion Screen Data Element defines the local i~,dLion of the data name.
Location This is the "00" packet or root packet that decld~es that there is a data name and that it may have packets. The ima~in~ editor aulu,,,d~;--'ly ~u~ L:~ for the root packet as part and parcel of i.., !e ~-enLi.-~ the data name in the current se~ment. The packet can override data di_Liona~ deriniLions of the data name. For e~-d--,~!e; increase the minimum allowed colle~,Lion len~th or reduce the display len~th. The packet can also make the data name "not a field", but part of the back~round screen mask, causin~ it to be re-displayed on a later screen with any prucessi.-~ to support it.

W O 97/15882 PCT~US96/16267 Element Edits EDITS Limits the ranqe of entered values, sets repeat or recurrin~ entry speciri-,dLions, sets calculation relationship and es ' ':~hes display ~ . ,ashi. ~~s.
Element Display Lo~ic DISPLAY Provides field chald~ li;,Lics for displayed data in the r~O~,v;.~ methods - 1) Display Only, 2) Forced, 3) Default, 4) Tally Tarqet and 5) Invisible. LoS~ic is necessa~y for all options other than (4) Tally Target. Help text F7 is available to explain each of the five options.
Element Verify Lo~ic VERIFY Ide.. liries R~re.t:nce File and Record to verify field value for data entry accuracy.
Specify e--ro-.ie--.el-l option and use ~IA--for alpha or--1#--for numeric field (equivalent to "value of current field") to build the key value for ~ driL-dLion of current field. Any other elo.--t:--Ls of the key should use existin~ data elements by their name.
-Element Skip Loçlic SKIP Allows a field to be by-passed for data entry if the conditions speciried in the Los;lic section are met. If checkin~ a padded field for skip, such as the skip lo~ic 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 con-liLion.
Element Display to LoS~ic DISP2 Displays a value created by the specified lo~ic at a selecLdblE location at the bottom of the screen. The packet causes a value to be placed elsewhere without havin~ the benefit of any known tar~et field.
Field Validation Lo~ic VALID Defines a"cv: ' le values for field data entry.
In Lo~ic section you must include field name if a cor-pd.dLi~le is used as it is not assumed that the field name involved belon~s to the ri~ht or left of the inequality.
Element Calculate to Lo~ic CALC2 Causes another field's value to chançle based on the value captured or received into the current field. The chan~e may be any math operd~or and may be displayed as it is happenin~ or wait until the other field ,~1 u~e5ses.

_ W O 97/15882 PCT~US96/16267 Ele",e"L Input Options Specifies optional data entry pro~ram for input. The current options are Sin~le Chd~d~,Ler 1/0 to allow in-field editin~ and - Multi 1/0 to allow for lon~ text fields of multiple recurrin~ lines.
Case CASE Causes the value lin any type of strin~ field) to have its case forced. The options are chan~e to all UPPERCASE, chan~e to Capitalized first word, ChanS~e to CapiLdli~ed First Letter or chan~e to all lower case. The packet can act on any data name anywhere in the prc,~,d", se~J",e"L. (many packets can cause chan~es in fields which are not displayed in the ima~e, not on the screen or report).
Element Skip Field if SKIPEM Allows a field to be by-passed for data entryEmpty if another field conLc.;ns a null value Iblanks) for strinD Vdli ' !es or zero for numerics -- 5 Input Edit Options INPUT Allows for the entry of a user s,~eciried ran~e of valid cha,d.;Lars for an alpha field.
Options are to limit to numbers, numbers and alpha, alpha only, Y or N or a specific list of chd, d~
Copy Value to Field COPY2 Tar~et field is identified to receive conlt:nL:, of the source field. This is equivalent to a Move in prl~JI dl l ll l ' IS~ -Translate to a Field TRANS Specifies conversion required for 1 ) Encryption, 2) Decryption, 3) Soundex-used in phoneLic searcl,i.,~7 for names, includin~ DescdpLion and Pro~ram Tarçlet.
Element Tally (Runnin~ TALLY Provides totalin~ options (=-~/) for a Total) Display Only Field idenLiried to receive results from this source field.
Don't Exit on LoS~ic NO EXIT Tests for a specific value in field which a!!ows pro~ r: ;i:i Lion on!y whe,. the lo~ic is satisfied. Forces the user to colllp~La reql ~IIlt:lIL:, such as an in-balance condition before exitin~
Post to Another Field POST TO Causes a value created by the defined lo~ic to be place in a Ldr~eLt:d field.

W O 97/lS882 PCT~US96/16267 Post From Another Field PSTREL Causes the value created by logic to be placed in the current field to which the packet is a,...hG,~d.
Field Default NEWVAL Specifies a default field value to be placed in the field either when empty or used to replace the current field coriL~:IlLa. This Feature Packet iâ always used in conjunction with the One-to-Many postin~l rele.Lionsl,i~. discussed as a full function later in this guide.
Convert Date Into Strin~ CONVDT Tlc,nsldL~s a date field, which stores the Name date as a Julian number, into a strin~ field which can be the day of the week or the month of the year. This feature is used e,~L,ansi.~ely in schedulin~.
Convert Numeric Amount CONV2A Used to make a worded dollar amount for to Alpha printing on checks.
-- Report Default Totallin~ RTOTAL Requires numeric field ~ J Lion prior to usinS~ field in a report subtotal or grand total. For numerics, operc.L.r (+~
Calculate to Subtotal Requires numeric field v " '~ Lion prior to usin~ field in a report subtotal. Same scheme as Report Default Totalinq. The subtotal re~ion must exist and contain the tarS~et variable.
Calculate to Grand Total Specifies numeric file v ' ': .n prior to using field in a report ~randtotal re~ion must exist and contain the tarS7et variable.
Specified Ranç~e Inclusive START Specifies Data name from Start-Up screen Start used to verify be~D ,nioS~ rans~e of field value for inclusion in report.
Specified Ran~e Inclusive END Specifies Data name from Start-Up screen End used to verify endin~ ran~e of field value for inclusion in report.
Specified Exclude on Exact MATCH Co",pa,~:s field value with value entered Match here to exclude a record from the report.
Yes or No Lo~ic YES/NO Compares field value to lo~ic to d~Lt:-lt ~e if field should be included. Only works when cG"~ ,ed with Exclude on Yes or No Option.
-W O 97/1~882 PCT~US96/16267 ~ Normal Exclude Record NORMAL Defines con-;Jilions to be met to exclude a Lo~ic record from report. Field does not have to be present on report, and packet may be ~ used to anchor eYclusion 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 Inc,t:.. el.Lur MEMINC Causes the value in the anchor field to be chan~ed by a fixed amount each time (usually each record processed) the countinS~ is self-contained, it starts at the same value, counts in memory and then clears.
Normal Include Record NORMIN Causes records bein~ processed to be Lo~ic included or i~anored based values at the -- time. The packet is cor .. only used in p~ucesses and output.
Skip Pro~ram Se~ment on SKPPRG Co-. I~Lely 8'--indLI:s execution of this Lo~ic se~."e.. L based upon lo~ic condition passin~. The lo~ic must be loaded into a non-stored data name in an earlier se~...e..L.
No records will be read.
Hide Output Detail HIDE Provides print suppression for record based upon lo~ic successfully co--- let-3d.
I~runlldlion from the record can be used in the pru~,.d... to accumulate totals without printinS~ the detail records.
Chan~e Siçln on LoS~ic SIGN Chan~es the si~n of a numeric variable based upon passin~ the lo~1ic s~eciried.
Grand Total Specifies that the field to which the packet is anchored should have ~rand total, subtotal or both created for it. even thou~h there is no specifications on how to create subtotals or ~rand totals defined for the report/,ulucess. The packet supports the - definition of sums, ne~ative sums, p. u~,,- t:ssions and ne~ative uru~l ~ssions.
Debit Lo~ic W O 97/15882 PCT~US96/16267 Grand Total to Credit The same ope-aLion as Tally To Credit Lo~ic Lo~7ic except it is intended to be used to update s,oeciri~ ally defined ~rand total reS~ion's fields.
Tally to Debit Lo~ic TALLY The same operdLion as Effect Other Field but only subtracts field cor~enL~ from variable speciried under passin~ conJilions of lo~ic entered.
Tally to Credit Lo~ic TALLY The same ope.dLion as Effect Other Field but only adds field conLe.~L~ to variable specified under passin~ condiLion of lo~ic entered.
AuLul.. dLic Inc,t:."enLor AUTOIN (also known as autonumber) Specifies one of two types of auLu,--di ~~'ly i-.u.e---e..L-3d fields. The first type continuously numbers the file within the speciried ranS~e, one ---e--L each iltsldliOn. The last llenLed value is stored on disk and the i-.cre-,-t:,.Li-.~ continues next time. The second type counts lines based on a ~ert:.enced header record. Each header ~ets its own i..c-i-..inalor and the values can continue from session to session.
Fields Pop-up Call POPUP Ide,-Liries Selector Pop-Up p-u~ --, to be called from this filed, enter name or use F2 Call preceded by Topic to view list of available prc,~,a---s. The Pop-Up is referred to as a Selector.
Verify By-pass Lo~ic Makes all of the various verify features conditional based on the defined lo~ic.
Element Verify Denial DENIAL Is a ne~ative verify. Specifies that a LoSIic rt:terenced record should NOT be there to pass. Both the feature and the basis are spelled ri~ht in the system.
Verify Only VONLY Same as Cler.. enL Verify Lo~ic but the read to the rt7r~rt:nced file/record is only for the purpose of ve.iri~dLion, no data should be chan~ed or loaded.
Write Record WRITE Is an inverted verify. Instead of readin~ the referenced record, write the It5rl:.~nced record.

CA 02236229 l998-04-27 W O 97/lS882 PCT~US96/16267 Verify Approximately APXVER Is a full verify to (another) r~rt:tt:nced file/record that will load data (the full rere,~ ced record), but the key value to the (other) ,~rt:,enced file/record is not cor". '~tely known. This packet will cause the authored proU,dr" to be able to do table scans as part or a simple reference read, e"~r,/;"~ inexact related data to be matched up durin~ ~,uces~
Verify Load Table LOAD Is a co",. '~Le verify includin~ readin~ the entire (other) ,t:rert:llced record, but the record will be treated as nonvolatile data durin~ the proaram's run.
Update From Specifies the field or colle Lion of fields that will contain the value to place in the current field.
Post Pro~ram Co" pletion Override the Author's default le""t ,d~ion Action scheme for postin~ plUuldlllS, options for dlLt:~llaLe Ler" ,dLion lo~ic provided.

The image editor 32 pre~erably provides a picklist ~or the selection o~ both pLO~ r ~LL and ~ield based ~teature packets. As a ~eature is selected based on user input 14, additional inEormation is presented Eor user input completion. This additional in~ormation is presented typically in the ~orm o~ a pop-up display record that prompts ~or user input to su~iciently quali~y the desired ~tunction o~ the selected ~eature packet.
The ~eature packet identi~ication and supporting in~ormation are collected by the image editor as ~nnm~ated attributes o~ a particular program 520 or segment 54~. Pre~erably the image editor 32 ~urther operates to reasonably validate these attributes against the existing application structure including W O 97tlS882 PCT~US96/16267 speci~ically ~ile and record 56, 58 ref~erences. Feature packets that ~urther de~ine basis attributes are also validated against a rule table 62 that includes a record for each basis. Each basis record de~ines the abstract behavioral characteristics that de~ine a particular basis. The behavioral characteristics, when combined with the quali~ying in~ormation entered by the user with respect to a speci~ic instance o~ a ~eature packet permit the de~inition o~ a set o~ application sequences that can be utilized to implement the ~unctionality o~
the ~eature packet.
The ~eature packets may and generally do provide ~or the user input entry o~ ~unctional logic to complete the definition o~ a particular feature packet. For example, the Tally To ~eature packet supports the specification o~ another ~ield name and the speci~ication o~ an arithmetic operator. For example, the realized ~eature packet can be represented as:

16AP20010OTotal Cost Value Tally o where:
16 ID o~ rule corresponding to this packet AP Topic identifier 2001 Program identi~ier 00 Program Segment identi~ier Total Cost Field identiEier where ~eature packet is anchored O Reserved ~or ~uture use + First ~eature value Value Tally Second ~eature value destination ~ields.
O Third ~eature value Thus, the functional logic of such ~eature packets is largely implicit, with the user providing and being exposed to m; n; m~l 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 obt~;n;ng 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 o~ the application structure 36. Exemplary system variables are detailed in Table III.

Table lll Svstem Variables l# Current Numeric Field Variable la Current Strin~ Field Variable ICurr Basis Key Current Pointer Into Sequence ICurr Error Current Error Number ICurr Field In Process Field Name ICurr Field Max Number of Fields in Se~-"e"L
ICurr Field Rec Current Fields Record ICurr New Line Fully Substituted Text Line ICurr Next Se~ F~u~,d",s Next Sesament Number ICurr Pa~e No. Current Audit Pa~e Number ICurr F~u~ m Current P~ ,dr" ID
ICurr SeS,""ent Current SeDment ID
ICurr Topic Current Topic ID
- - ICurr Variable Current Variable In T~"slalion IData Bell Sound Sound Bell with MEssa5~e !Data Date Run Time System Date IData DSZ Re-- . .~ Data Size Variable IData End Check End of Data Variable IData Input Run Time Input Variable IData Main Read Main File Read Succeeded IData Menu SW1-14 Menu Pa.e~r.. el~r Switches 1-14 IData Next Pro~ Run Time Set Next ProSaram IData Paçle Count Report PaS~e Counter IData Read Write Buffer Read/Write Fla~
IData Required Required Record Yes/No Fla~s IData Row Temporary Variable for Row Number IData Search Search Key IData Temp Num 0-7 Run Time Te.. po.d.~r Numeric Stora~e IData Temp Str 0-7 Run Time Temp Strin~ Variable IData Total Base Numeric Total Array !Data VDP User Run Time WorkStation and User IDDICT Case CVT Case Conversion Option IDDICT Data Type Data Type IDDICT Desc Desc.i~,lion of Entry !DDICT Justify Field Jusliricdlion IDDICT Max Len Maximum Len~th IDDICT Min Len Minimum Len~th IEle Calc Dest Calculated from Screen Math IEle Calc Source Source for Screen Math IEle Calc2 Field TarS~et Field of C-'cu~ation IEle Calc2 Op Calculate to Math O~-e-dlion IEle Calc2 Show Display Calculated Field IEle Col Ele.,.enL Column IEle Conv From Source Field for Conversion IEle Conv2 Alpha Tar~et Field for Numeric to Alpha Conversion IEle Convl Field Tar5~et Field After Conversion IEle Convto Mask Use Mask Number to Strin~ Convert IEle Copyto Field Field Name to be Copied To IEle Copyto Type Record Type of Copy To IEle Disp Lo~ic Ele."t:l-L Display Lo~ic IEle Disp Option Ele.--er,L Display Option IEle Dispto Pos Eler.. e"L Display to Position IEle Dispto Type Record Type of Display to IEle Dispto Lo~ic Eler"e"L Display to Lo~ic IEle Exitlo~ic Don t Exit LoS~ic IEle Exit Option Don t Exit Option IEle Grand Field Grand Total Calculate to Field IEle Grand Si~n MaLl,e",aLical Operator IEle Grand Plus Field Grand Total Add to Field IEle Grand Plus Lo~ic Grand Total Add to Louic IEle Grand Minus Field Grand Total Subtract to Field IEle Grand Minus Louic Grand Total Subtract to Lolaic IEle Imm Field l""... e Jidle Update Tar~et Field IEle Imm File Immediate Update File IEle Imm Op Immediate Update Operation IEle Increment Numeric Display Inc.ts.. t:"L
IEle Input From1 From Value Ran~e one IEle Input From2 From Value Ran~e 2 !Ele Input From3 From Value RanS~e 3 IEle Input Thru1 Throu~h Value-Ran~e 1 IEle Input Thru2 Throu~h Value-Ran~e 2 IEle Input Thru3 Throu~h Value-Ran~e 3 IEle Loop Use Loop Start or End Fla~
IEle Lp Counter Loop Counter Variable IEle Lp Exac tEn Exact Endin~ Loop Number IEle Lp Exact St Exact StartinS7 Loop Number IEle Lp Var En Variable EndinS~ Loop Number IEle Lp Var St Variable Startin~ Loop Number IEle Tally Clear Runnin~ Total Clear Option IEle Tally Field Tar~et Field for Runnin~
IEle Tally Op Runnin~ Total Math Operation IEle Tally Plus Field Tally to Add to Field IEle Tally Plus Lo~ic Tally to Add to Lo~ic IEle Tally Minus Field Tally to Subtract from Field IEle Tally Minus Lo~ic Tally to Subtract from Lo~ic IEle Type Field Type IEle Up To Lo~ic Post to Update LoS~ic IEle Up To Option Post to Option IEle Up To TarSIet Post to Tar~et Variable IEle Up Xl8 Func Update with T.dns6Lion Function Name W O 97/15882 PCTnUS96/16267 lEle Up X18 Lo~ic Source Field to Translate From IEle Up X18 Pro~ T~ s6Lion F~u5~1dlll Name I P~m Subtype ~- u~, al 1 l subtype IPspec Ask Ask for Main Data File Name?
IPspec Ask Prompt Prompt T~xt to ~et Main File IPspec Alt File Reports Output Data File Name IPspec Alt Text Reports Output File Prompt IPspec Output Report Output Option The system variables thus provide an easy me~h~n;~m allowing for the testing o~ 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 c~mmonly 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 ~unctions 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 determ; n~ if an initial default value is to be displayed in the field. The test rules that will determine i~ a default value is to be displayed and the program rules that will det~rm; n~ or fetch the default value can reference the system variables extensively in implementing the necessary ~unctional logic. I~ a field is to be defaulted to the current date, but permitted to be user modi~iable, then the rules may retrieve the current date (!Data Date) and place the date in the field (IDisplay To) if the current ~ield (!a) is empty. Consequently, a direct and highly non-procedural capability is provided by the use o~ 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 pre~erably as each definition is completed to the sequence generator 66. The definitions are evaluated by the sequence generator 66 to generate sets o~ application sequences. The definition evaluation is preferably performed by an expert system underlying the sequence generator 66. As ~eature packets and ~unctional logic are evaluated by this expert system, re~erence 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 o~ generating de~inite application sequences.
The control table identifies sets of rule table entries while the rule table provides the abstracted behavioral characteristics ~or each basis re~erenced in the ~eature 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 ~unction, defined as a basis that may be subject to some ambiguity in its intended u~e, may be first evaluated against the control table to det~rm; n~ a particular set of basis rules to consider in ~urther evaluating the complex basis or ~unction. Thus, for example, a function re~erence to a field name in the context of a data input process may imply the need for establishing the input ~ocus transversal o~ the field relative to others.
However, the same function in the context o~ a report process would imply a signi~icantly di~erent W O 97/15882 PCT~US96/16267 ~unctionality, particularly one related to the optimum retrieval order o~ data for this and related ~ields.
Functions, representing complex basis, are referenced through the control table 64. These :Eunctions are summarized in Table IV.

Table IV
Control Table Functions ALT KEY Defines how prù~ldlll el~,.--e--ls are to be ss~e~ d by an alLt:~-dL~ index key rt:rc~ nce in dirrt:~nL
GOI I L~AL:~ .
AUTONUMBER Defines how ordered prc.5~,a.. ele.llellLa are to be sequenced in dirre-e--L COIIL~AL:~.
ELEMENT Defines the process for cr6dLi~ a p-o~-~---- el~ e~L in ~irr~ .t.-~ GOIILeAL:~.
ENTRY Defines traversal order for fields in dirr-3~enL corL~,.L:
LOCATION DeLe.. ;.. es how the location of a field or pro~ram element is to be determined in dirtt ~e- lL
CGI~ L~A~
MAIN KEY Defines how pru~ldlll elGr.. e.. L:. are to be selected by the main index key .t:rt:rence in dirrt,re..l GOnLt:~L ~.
ORDER DeLelll ~ .es the method of definin~ the order of pru~Jldlll records or el~.--e--L:~ in dirrt ~t ..L
co.- L~La .
RECORD TYPE DeLe~ es the type of a pro~d~- record in dirre-~ ~-L
GOI I L~AL~ .
UIP FIELDS Determines the set of addiLional fields or plO~ldlll el~"t:~L~ that must be defined in support of the further rule p~u~essi--~ of a pl~Jldlll se~ -.l in dirrt.. r.~ GOIlLt:AL:~.

For example, the ELEMENT ~unction, in the context o~ a data capture program, will, in turn, re~erence the ~ollowing ~unctions or simple basis:
E~ELOC Element location on the image page;
ENTRY The order in which data ~ields collect data;
NAME Element o~ field name;
PTRANS Translation sequence ~or the ~ield 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.
Figure 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 ~urther 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 ~ile 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 W O 97/15882 PCT~US96/16267 structure 36 is available to the sequence generator 66 ~or re~erence.
me create ~ield de~inition step 78 and succeeding steps 80, 82, 84, 86 together detail the ~low o~
creating ~ield de~initions and text. This process i5 generally exemplary o~ the de~ine ~ile structure 74 and de~ine program structure 76 steps described above. The process o~ de~ining a ~ield begins with the choice o~
the create ~ield de~inition 78 by user choice 72. A
prede~ined prompting question and any applicable starting text is obt~;ne~ ~rom the question ~ile associated with the help ~ile 40 and presented to the user ~or response. mis introductory question step 80 is utilized to obtain an introductory statement as to the purpose and ~unction o~ the ~ield being de~ined.
mis ~ield introductory text is stored back to the help ~ile 40. A de~ine ~ield step 82 permits the user by input to select the appearance o~ the ~ield being de~ined. This may include the selection o~ an object ~rom the object store 42. The attributes o~ any ~ields within an object retrieved during the de~ine ~ield step 82 are maintained initially, subject to further modi~ication by user input. Speci~ically, ~eature packets associated with a ~ield with in an object may be opened and edited during the de~ine ~ield step 82.
Feature packets associated with an object can also be added or r elLL~ved~ Thus, an object, once retrieved in a de~ine ~ield step 82, pre~erably ceases ~rom being disting~ h~l as an encapsulated object. Each Eield and attribute de~ined through the retrieval o~ an object is ~unctionally no di~erent ~rom a ~ield or attribute newly de~ined through user input.

When the user input indicates that the definition of a particular field i5 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 ;mm~ tely provided to the sequence generator 66 for processing, an image is maint~;n~ by the image editor 32 in support of ~urther 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 -30 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 CA 02236229 l99X-04-27 WO 97/lS882 PCTrUS96/16267 are fully defined, the image editor returns to the user choice step 72.
Referring now to Figure 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 pLoy~cun 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 erabodiment 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 9 8 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, 5 8 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 re~erences between program and data sequences WO 97/15882 PCTrUS96/16267 98, 100. For example, a ~ile sequence may provide a logical connection between a ~ield identi~ied as part of a logical ~unctional statement of a ~eature packet that is realized as an ordered set o~ program sequences and a data sequence 100 that re~erences a particular record 58. A ~ile sequences 102 is utilized to speci~y the trans~er o~ data re~erenced by the data sequence 100 to a ~ield re~erenced by a program sequence 98.
Translation sequences 104 are generated to support the ultimate association o~ 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 identi~ied by a data sequence 100 and retrieved as speci~ied by a ~ile 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 quali~ications that may be applied in re~erence to other sequences. In particular, validation sequences are utilized to embed ~unctional logic conditions applicable to particular data ~ields or groups o~ data ~ields.
Segment record sequences 108 provide a list o~ the record identi~iers o~ the records 58 that may be involved in a data read or write, test ~or existence o~
a speci~ic record, a purge or clear o~ a particular record, and any records that are to be used as a source - 30 or target or involved in a h~ r/detail relationship with a record that is to be read or written during a current segment 54.

W O 97/lS882 PCTAUS96/16267 Feature sequences 110 provide for sequences that describe ~unctional logic that is to be applied to a field or group o~ ~ields and may involve references to system variables o~ all types. Although each ~eature sequence is now pre~erably complete in speci~ying a particular functional logic ~unction, such as tallying a particular ~ield 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 ~eature packet.
The application sequence structures 98, 100, 102, 104, 106, 108, 110 are not ordered strictly as ~irst-in ~irst-out sequence bu~ers. Although sequences may be added to the structures in a generally parallel FIFO
order, each of the application sequences are added in a ~rame by ~rame relationship that relates zero or more sequences in the sequence structures 98, 100, 102, 104, 106, 108, 110 in a virtual ~rame such as the ~rame 112.
Thus, i~ a program sequence within the ~rame 112 does nothing more than assign a value to a ~ield, a translation sequence may be the only other sequence in the ~rame 112. Conversely, any number o~ sequences in one or more of the sequence structures 98, 100, 102, 104, 106, 108, 110 may be related by a particular ~rame 112. Consequently, each ~rame 112 of the application sequences ~ully de~ines 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 ~rames 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 in to 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 ~ields. 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 seq~l~n~s 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 o$ sequences related to a particular ~rame or sequence.
Frames 112 of the application sequences are generally sequentially evaluated by the expert system underlying the application author 44. As indicated in Figure 7, programmer speci~ications, representing the collected application seql~nc~s are received as an input to the application author in combination with the application structure 36 as repre~ented 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 ~Loy~ uller specifications.
These selected program rules anticipate and impose a general ~ramework to the functions and relationships presented by the programmer specifications. As a consequences, 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 det~rm; n~ 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 specii~ications.
The skill rules 126 are applied by the application author 44 to develop the int~n~-i;;3te representation oi~
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.
-CA 02236229 l998-04-27 Finally, the application author 44 also produces t~t~ information relating to the fields, programs and menus that will be realized through the execution of the code. This additional in~ormation typically includes field sizes and types, included programs, and menu organizations, as well as context specific directions on the m~nner of operating at a screen prompt, the available program options at different points o~
execution, actions that are specifically disallowed at a point of execution, for exam~ple. This in~ormation is stored in the help file 40 by the author 44 to augment the in~ormation previously stored there.
Re~erring now to Figure 8, the documentation publisher 46 operates generally in parallel with the application author 44, though with the notable distinction o~ the dependency upon the help $ile 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. Specii~ically, the document publisher 46 implements a relatively simple expert system that evaluates document rules 130, obtained from the knowledge base 34, primarily against the in:Eor-m~ation provided by the help :Eile 40. The document rules 130 serve to guide the construction o~ the documentation ~rom the help file information based generally on the application structure 36. In particular, the menu lists associated with the current topic o:E the program definitions 94 is utilized to organize the body of the - documentation. The program.mer specifications are evaluated, again generally on a frame by ~rame basis, to CA 02236229 l998-04-27 W O 97/15882 PCT~US96/16267 construct screen and report ~ormat representations suitable as illustrations within the documentation. Key words, such as ~unction key names and basis types that occur in the help ~ile 40 are used to trigger the evaluation o~ reserved word rules 132. These reserved word rules 132 are provided preferably to support expanded explanations o~ key concepts, operational ~eatures, or methods o~ use in a non-repetitive m~nn~
Reserved word rules 132 may also support key word indexing and creation of glossary entries ~or key words.
The text library 134 iS provided to support the publisher 46 in evaluation o~ the documentation and reserved word rules 130, 132. The text library provides prede~ined 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 o~ the syntax rules 136. In particular, the help ~ile 40 and programmer speci~ications will provide ~or the identi~ication o~ various ~ields and user visible attributes, such as display only, numeric or text only entry or the source o~ a de~ault ~ield value. The syntax rules 13 6 are evaluated to manipulate this in~ormation into a stA~ rd Eorm o~ presentation appropriate ~or inclusion in the documentation in re~erence to the corresponding image. Consequently, a highly detailed set o~ documentation is produced by the publisher 46 in direct correspon~ence to the exact screen displays processes and reports that are implemented by the speci~ic code generated by the application author 44.

WO 97/15882 PCT~US96/16267 Thus, a complete application generator system and method, providing direct support ~or the design, implementation, maintenance and documentation o~
essentially custom application programs has been described. The system requires a m;n;mnm amount of information to be input by a user in order to speci~y the ~unctionality o~ the resulting application program the in~ormation input is largely constrA; n~ to the de~inition o~ the application structure and logical attributes o~ ~ields that specify the characteristics o~
field and the relationships between ~ields that in~erentially de~ine the functions necessary to carry out the realization o~ the attribute de~ined ~unctions and relationships. From these attributes and the application structure, an over-speci~ication of application sequences is created that ~ully describe the in~erred detailed relationships and quali~ications o~
the attributes de~ined by user input. This over-speci~ication is then reduced by an expert system that selects and utilizes needed and applicable portions o~ the application sequences to realize the control logic necessary to construct an application program consistent with the program types speci~ied as part o~
the application structure. A complete application program is thereby constructed through reduction by syntax rules to a specific programming language. A
parallel reduction o~ the prompted and automatically collected textual in~ormation also provides ~or the generation o~ application program documentation highly - 30 correlated to the speci~ic application produced.
Various modi~ications and alternate implementations o~ the present invention are contemplated and may be readily resorted to by those o~ skill in the art without W O 97/15882 PCT~US96/16267 departing ~rom the nature and scope o~ the present invention. In particular, many dif~erent implementations of the expert systems described above may be utilized in any particular embodiment. Direct rule parsing engines as well as backward ch~3;n;nt7 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 rh~; ne~
sequentially to provide ~or the production o~ 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.

Claims (4)

Claims

1. A programmed system executed on a computer providing for the automatic generation of an application program, said programmed system comprising:
a) a guided editor for establishing program, data and field definitions from a plurality of input event elements;
b) a sequence generator, coupled to said guided editor for autonomously processing said program, data and field definitions into a plurality of functionally descriptive atomic sequences, each of said functionally descriptive atomic sequences describing a unique characteristic such that a plurality of frames, each comprising zero or one functionally descriptive atomic sequence from each of said functionally descriptive sequences, respectfully describes said plurality of input event elements; and c) a rule processor including a program rule base conditionally describing the structure and operation of a predetermined application program, said rule processor autonomously processing said program rule base in concert with said plurality of functionally descriptive atomic sequences proceeding generally sequentially over said plurality of frames conditionally unifying said plurality of functionally descriptive atomic sequences with the structure and operation of said predetermined application program.

2. The programmed system of Claim 1 further comprising a syntax processor including a syntax rule base defining the syntax of a predetermined programming language, said syntax processor autonomously unifying said plurality of functionally descriptive atomic sequences, as unified with the structure and operation of said predetermined application program as received from said rule processor, with the syntax of said predetermined programming language to provide a coded representation of the structure and operation of said predetermined application program consistent with the syntax of said predetermined programming language.

3. The programmed system of Claim 2 wherein said guided editor comprises a first module, responsive to said input event elements, for maintaining a program hierarchical data structure defining ordered tiers of named program nodes and named segment nodes, a second module, responsive to said input event elements, for maintaining a data hierarchical data structure defining ordered tiers of named file nodes and named record nodes, and a third module, responsive to said input event elements, for maintaining a field data structure defining ordered screen data, including named fields, and operational attributes.

4. The programmed system of Claim 3 wherein:
a) said third module of said guided editor further comprises a text submodule for providing to a screen context sensitive prompting text in anticipation of predetermined input event elements and for receiving descriptive text describing said predetermined input event elements, said text submodule providing for the ordered storage of said descriptive text in a help file;
and b) said rule processor includes a documentation rule base conditionally describing the structure and organization of a document describing said predetermined application program, said rule processor autonomously processing said documentation rule base in concert with said plurality of functionally descriptive atomic sequences conditionally unifying said descriptive text with the structure and organization of said document.