AU2005201715A1 - Automated code generation - Google Patents

Description

AUSTRALIA

PATENTS ACT 1990 COMPLETE

SPECIFICATION

NAME OF APPLICANT(S):: Phase N Australia Pty Ltd ADDRESS FOR SERVICE: DAVIES COLLISON

CAVE

Patent Attorneys Level 10, 10 Barrack Street,Sydney, New South Wales, Australia, 2000 INVENTION

TITLE:

Automated code generation The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5102 -1- SAUTOMATED CODE GENERATION

C.I

S Background of the Invention The present invention relates to a method and apparatus for generating computer executable code, and in particular, to generating computer executable code in an automated fashion.

C 5 Description of the Prior Art The reference to any prior art in this specification is not, and should not be taken as, an C.I acknowledgment or any form of suggestion that the prior art forms part of the common general knowledge.

Currently, when an organisation requires software for implementing desired functionality this can be achieved in a number of ways.

The most common way of getting software for most organisations is to purchase or download an off-the-shelf product and to configure it for their needs. Thus, for example, companies would not generally have a suite of software such as Microsoft OfficeT M produced internally, as this would cost several billion dollars. Thus, in many circumstances, companies simply purchase commercially available packages, and then simply adapt their internal procedures to ensure the packages can be successfully used. However, this is not the only cost effective method of procuring software, and does not address custom needs the organisation may have.

Accordingly, if custom functionality is required, it is typical to use alternative development techniques.

For example, bespoke development operates by writing software applications by hand from scratch. All design, coding, documentation, installation and maintenance is done manually, or assisted by simple tools written during the development. Bespoke development is infinitely flexible, making it the most common form of software development. Most small or highly specialised applications are produced this way, as well as some commercial packages.

However, such techniques tend to be expensive, and beyond the reach of small businesses.

Furthermore, even in small and medium sized companies, resource pressures mean systems are often poorly documented, and difficult to install and maintain. As the original developer(s) -2may be the only entity who understands the operation of the software, maintaining or improving these systems can be expensive and troublesome.

Software Project Line Engineering was pioneered by the defence industry and telecommunication equipment manufacturers, and has become popular with manufacturers of major commercial software packages. In its most common form, it allows a company to automatically produce several "versions" of a software package. This is done at a lower cost per version than maintaining all of them by hand. In this regard, a master version of the software is produced, along with a pattern that describes the allowed "variations". For each version, a specific result is derived from the master version, creating a "product line" of similar applications built for different platforms, or with differing features.

While the master version is still written by hand, and costs are still high, many versions can be produced at the same time for only a limited amount more than the cost of one version. When new products are released, the software for them can be created as needed for little cost. Whilst this technique is therefore useful for large applications, for smaller projects the benefits are outweighed by the development costs.

In the last few years, assisted by the rise of the Java programming language, Code Generation has become an increasingly popular method to create the large amounts of simple required for the core of many types of programs. Passive Code Generation involves entering information on the structure of a program, and having a tool create the code required to implement this structure. Many tools of this type are designed to create general code for the internals of large systems, and significant work still has to be done to complete the application. Others assist in compiling documentation or with testing procedures. The generated code does not represent the primary or complete code, but only a portion of the entire code, with these parts being integrated by an operator into an entire solution. Passive Code Generation is thus a method primarily suitable for assisting with large applications, or to provide a starting point for smaller ones. Most importantly, these techniques do not create comprehensive applications.

As an alternative to passive code generation, Active Code Generation is a method which embodies functionality only within respective tools. The information contained in the tools is the application, and the code generated from it merely the form made available to be installed -3and executed. The tools therefore retain the authoritative form of the application, and those working on the application generally work only with the code generation tools.

Custom changes must be made within the context of the tools and their capabilities. While this lightens the load of creating an application, it has some disadvantages. In particular, when structural or other changes are made, software must be "regenerated" from the tools, which is typically an expensive task. It can be difficult or even impossible to "detach" an application from the tools, which results in a risk of vendor lock-in in these cases.

Furthermore, as tools often become superseded and replaced, or updated, the tools used to develop the software are no longer accessible, and maintenance becomes difficult and/or expensive.

Thus, whilst both active and passive code generation work well for enterprise applications, both have difficulties scaling down to smaller applications.

As a result, there is no suitable solution for constructing relatively simple applications, such as database interfaces, or the like, which is not overly complex, and more significantly, highly expensive.

Summary of the Present Invention In a first broad form the present invention providers a method of creating an application, the method including, in a processing system: determining a specification representing requirements for the application; selecting at least one of a number of predetermined files using the specification, the predetermined files including at least one of: a template; (ii) an executable file; (iii) an object file; and, determining a manifest representing the files to be implemented; and, implementing the selected files using the manifest, to thereby generate preliminary executable code, the selected files being implemented by performing at least one of: compiling a template; (ii) executing an executable file; and, -4- (iii) generating an object file.

The method of selecting the files typically includes, in the processing system: selecting at least one of a number of predetermined features using the specification; and, selecting the files using at least one of: the selected features; and, (ii) the specification.

The method typically includes, in the processing system determining a feature tree, the feature tree being indicative of: each of the number predetermined features; and, if each predetermined feature is selected.

The method typically includes, in the processing system, and for each predetermined feature: comparing feature data to the specification, the feature data being indicative of when the respective predetermined feature is required; and, selecting the predetermined feature in response to a successful comparison.

The feature data usually includes at least one of: an LUT; and, executable code.

The method generally includes: determining requirements for the executable code to be generated; and, determining the specification by selecting at least one of a number of predetermined elements using the determined requirements.

The feature data is generally indicative of the predetermined features required to implement each element.

The elements can include at least one of: entities representing portions of the requirements; properties associated with the entities; relationships between the entities; and, interfaces representing interactions with the entities.

The method typically includes, in the processing system, determining the manifest using at least one of: the feature tree; the specification; and, build configuration information.

The method generally includes, in the processing system: comparing manifest data to the feature tree, the manifest data being indicative of at least one file, or part thereof, required to implement each predetermined feature; selecting the files in accordance with the results of the comparison; and, determining the manifest using the selected files.

The manifest can include an entry for each selected file, each entry being indicative of: the location of the final file; parameters defining a context for the file; and, the method used to create the file, wherein the method includes at least one of: copying the file to the location; (ii) compiling the file from a template; and, (iii) generating the file using code.

The method usually includes, determining the entry from the manifest data.

The method typically includes, in the processing system, implementing the selected files by: determining the next file the manifest; executing a predetermined implementation function associated in accordance with the method used to create the file, and using any parameters; and, providing the resulting code at the location.

The method typically includes applying predetermined agents to the implemented files to thereby generate the preliminary code.

The method may further include: determining modifications required to the preliminary code using at least one of the specification and the requirements; and, -6in the processing system, modifying the preliminary code using the determined modifications to thereby generate final code, the final code representing the application.

The method of modifying the code can include at least one of: adding at least one function; adding at least one interface; modifying at least one function; modifying at least one interface; modifying the appearance of a GUI; and, otherwise modifying the look and feel of the resulting application.

The method typically further includes modifying the application by: determining revised preliminary code; comparing the revised preliminary code, to determine code changes; and, applying the code changes to the final code, to thereby generate a modified application.

The method generally includes determining the revised preliminary code using a revised specification.

In a second broad form the present invention provides apparatus for creating an application, the apparatus including, in a processing system for: determining a specification representing requirements for the application; selecting at least one of a number of predetermined files using the specification, the predetermined files including at least one of: a template; (ii) an executable file; (iii) an object file; and, determining a manifest representing the files to be implemented; and, implementing the selected files using the manifest, to thereby generate preliminary executable code, the selected files being implemented by performing at least one of: compiling a template; (ii) executing an executable file; and, (iii) generating an object file.

The processing system generally includes: -7an input for receiving input commands from an operator; a data store; and, a processor, the processor being adapted to: determine the specification in accordance with input commands; (ii) select the at least one predetermined file using feature data stored in the data store and being indicative of when the respective predetermined feature is required; (iii) determine the manifest using manifest data stored in the data store and being indicative of at least one file, or part thereof, required to implement each predetermined feature; and, (iv) implement the selected files.

The processing system is typically adapted to perform the method of the first broad form of the invention.

In a third broad form the present invention provides a method of determining a framework for generating applications, the method including: selecting a family of applications; determining a number of features required by at least one of the family of applications; determining a manner of implementing each feature; defining at least one predetermined file for implementing at least one feature, or a part thereof, the predetermined files including at least one of: a template; (ii) an executable file; and, (iii) an object file; and, defining requirements for allowing each feature to be selected in accordance with a specification of the application.

The method typically includes: defining a number of predetermined elements, selected ones of the predetermined elements being used to define a specification indicative of the requirements for the application; and, defining feature data representing the features required by each of the elements.

1 -8- The elements generally include at least one of: entities representing portions of the requirements; properties associated with the entities; relationships between the entities; and, interfaces representing interactions with the entities.

The method typically includes, defining a feature tree, the feature tree being indicative of: each of the number predetermined features; and, if the respective predetermined feature is selected.

The method generally includes defining manifest data, the manifest data being indicative of at least one file required to implement each predetermined feature, the manifest data being used to generate a manifest.

The manifest data typically includes a manifest entry for each predetermined file, the manifest entry being indicative of: the location of the final file; parameters defining a context for the file; and, the method used to create the file, wherein the method includes at least one of: copying the file to the location; (ii) compiling the file from a template; and, (iii) generating the file using code.

The method generally includes defining a predetermined implementation function in accordance with the method used to create the file.

The method generally includes defining predetermined agents for applying to the implemented files to thereby generate the preliminary code.

The method typically includes storing, in a database, at least one of: the files; the specification; manifest data; and, feature data.

In a fourth broad form the present invention provides apparatus for determining a framework for generating applications, the apparatus including, a processing system including: a processor for: receiving feature data representing a number of features required by at least one of a family of applications, and requirements for allowing each feature to be selected in accordance with a specification of the application; and, (ii) determining at least one predetermined file for implementing at least one feature, or a part thereof, the predetermined files including at least one of: a template; an executable file; and, an object file; and, (iii) a data store for storing the feature data and the at least one predetermined file.

The apparatus is typically adapted to perform the method of the third broad form of the invention.

Brief Description of the Drawings An example of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a flow diagram outlining an example of the production of software in accordance with the present invention; Figure 2 is a schematic diagram of an example of a processing system for generating computer executable code; Figures 3A and 3B are a flow diagram of an example of the method of creating computer executable code using the processing system of Figure 2; Figure 4 is a flow chart of an example of the initialisation process for the system of Figure 2; Figure 5 is a schematic diagram of an example of a web based system for generating computer executable code; and, Figure 6 is a schematic diagram of an example of an end station of Figure Detailed Description of the Preferred Embodiments An overview of a method of generating software will now be described with reference to Figure 1.

In outline, the method includes up to four phases, including an analysis phase, an automated phase, a customisation phase, and a maintenance phase.

During the analysis phase, requirements for the code to be generated are determined at step 100, these are then used to define a specification at step 110. This may be achieved in a number of manners but typically will be achieved in accordance with standard industry protocols in order to aid the implementation of the procedure in existing environments.

During the automated phase, one or more files are selected using the determined specification at step 120. The one or more files can be selected based on the information in the specification, with this process being aided if the specification is in a standardised form, for example by allowing predetermined specification requirements to be mapped directly to respective elements.

At step 130 the files are used to generate preliminary code. It will therefore be appreciated that in this instance, a file is any object, element, module or the like, which can be implemented to allow preliminary code to be generated. The preliminary code is executable code which can therefore be implemented on a suitable processing system. However, the preliminary code is generally standardised and does not typically address issues which may be custom to the specific requirements. Thus for example it is not typical for the look and feel of any user interfaces implemented by the preliminary code to meet the determined requirements.

The customisation phase is therefore provided to allow modifications to the preliminary code to be determined at step 140, and then subsequently applied to the preliminary code at step 150, to thereby generate final code. Thus, this may include for example coding the look and feel of an interface and merging this with the preliminary code, as will be appreciated by a person skilled in the art.

During an optional maintenance phase, the software can be updated to take into account either changing requirements for the software, or alternatively improvements to the elements which are used in generating the code.

In the former case, at step 160, it is necessary to determine changes to the requirements or the specification. After this it is necessary to rebuild 'the preliminary code by repeating steps 120 and 130 outlined above, to generate revised preliminary code.

-11- At step 170 the preliminary code originally generated during steps 120 and 130 is then compared to the revised preliminary code determined above, allowing changes that have been made to the preliminary code to be determined.

These changes are then applied to the final code generated at step 150 above. By applying the changes to the final code this ensures that the look and feel of the final code is retained, whilst allowing the code to be automatically updated in accordance with changing user requirements.

In the event that elements are modified, it will be appreciated that it is merely necessary to generate the revised preliminary code in accordance with the original specification. This is then compared to the original preliminary code as described above.

As will be appreciated by persons skilled in the art, this process is typically achieved utilising a processing system an example of which will now be described with reference to Figure 2.

In particular, in this example the processing system 10 includes a processor 10, a memory 21, an I/O (input/output) device 23, such as a display and keyboard, and an external interface 24, coupled together via a bus 25. The processing system is typically coupled to the database 11 via the external interface, as shown. This may be achieved via a direct connection, or via a wired or wireless network, or the like.

In any event, the processing system 10 operates to receive details of requirements via the I/O device and convert these into a specification. The specification is then used to access one or more objects, which are typically in the form of files stored in the database 11, or the memory 21. The files are combined in accordance with instructions defined by the files themselves to form the preliminary code which can then be customised by an operator via the 1/0 device 22.

Accordingly, it will be appreciated by a person skilled in the art that the processing system may be any form of processing system which is capable of interacting external inputs and files.

Accordingly, the processing system 10 may be a lap-top, personal computer, palm-top, PDA, specialised hardware, or the like.

An example of the interaction with the processing system will now be described in more detail with respect to Figures 3A to 3C.

-12- At step 200, it is necessary to determine requirements for the project, which as described above, may be achieved in accordance with standard practices for determining software requirements. This may include for example interviewing potential end users of the software, interviewing a customer purchasing the software, performing an analysis of a business, or the like.

Typically this is used to determine a number of entities and relationships therebetween at step 210. The entities represent self contained portions of the defined requirements which are capable of interacting with other entities. Thus for example, if the software is for a database interface, the entities and relationships will typically represent the database schema, with the entities representing respective groups of data within the database.

At step 220 it is necessary to determine interfaces for allowing interaction with the entities.

The interfaces represent points of interaction by one or more categories of users, and may therefore correspond for example to a collection of logical tasks to be performed on more or more entities, such as "Create", "Edit", "Delete", "Search for" or the like." At step 230, required build configuration information is determined. This may include information such as the operating system which will be used when executing the applications software, the circumstances in which the software is to be used, the nature of the database with which the software is to interact, or the like.

At step 240, some or all of the details determined in steps 210 to 230 are provided to the processing system 10 via a GUI. The GUI will therefore allow a user to enter details of entities, the relationships between the entities, and the interfaces (hereinafter referred to generally as "elements"). In order to achieve this in a standardised manner the GUI will typically include fields for each respective element, which allows details of the element including any associated properties to be input.

It will be appreciated by persons skilled in the art that specific elements, which embody specific functionality may have previously been determined, either during previous projects, or during an initialisation phase, as will be described in more detail below. Accordingly, the GUI will typically provide lists of predetermined elements, as well as associated properties.

-13- However, if no pre-existing elements are suitable new elements may be defined, typically by selecting the closest pre-defined element, and then modifying its properties as required, although completely new elements may also be defined if necessary.

At step 250 a builder application implemented by the processing system 10 accesses a number of LUTs (look-up tables) to determine required features, which represent the common and application-wide functionality required to implement the selected elements.

In one example, the features are therefore determined based on a mapping between the elements, or properties thereof, and predefined features. Alternatively, or additionally, this can be achieved by executing code which causes one or more of the defined elements, their properties, the build configuration information, and other features which have already been selected, to be reviewed to determine which features are required, as will be described in more detail below in Appendix A.

If custom entities or the like are defined in the details, this may require that new features are also defined, although this is not essential.

At step 260, the builder application uses the determined features to form a feature tree, representing the features required. This will typically be in the form of a list of the required features, and is typically generated in accordance with information in the LUTs, or by the implementation of the code described above.

It will therefore be appreciated by a person skilled in the art that the LUTs, or code, effectively define a mapping from the elements and associated properties, to respective features and the manner in which they are provided. This will be defined during the initialisation phase, as will be described in more detail below.

At step 270 the builder application determines files required to construct the code using the feature tree and/or the specification.

In particular, features in the feature tree will typically in turn map to respective files. The files will include executable files, which generate a required file, objects which are used by the final code, such as graphics, images, predetermined interface portions or the like, and templates, corresponding to source code which is compiled.

-14- The templates typically include instructions needed for using other files, as well as combining the resultant code generated when the templates are complied or the executable files are executed, as will be described in more detail below.

The builder application also determines any further files required by the selected files at step 280. Thus, this will typically involve scanning each template as it is up-loaded from the database 11, or as the templates are implemented by the processing system At step 290 the builder application generates a manifest, representing a list of the files in the sequence in which they are to be used. The manifest includes an entry corresponding to each file to be implemented, with each entry in the manifest typically describing not just the location of the final file, but also the method used to create it simple copy, compiled from a template, 100% generated by code) and any parameters to the build method needed to describe a particular context for that file. For example, any file added for a specific element would be passed that particular specification element as a parameter.

The manifest is typically determined by accessing an LUT which stores an entry corresponding to defined features in the feature tree, or by code which operates to generate the entry.

At step 300 the builder application determines the next file in the manifest before determining if the file needs to be generated at step 310. If the file needs to be generated at step 320, the will require performing some process on the file, such as downloading the file from a remote location, creating the file through a manual process, or executing code defined by the file. The builder application saves the results of the generated file to a build, which is generally achieved by storing code in a suitable memory location.

In the event that the file does not need to be generated, the method moves on to step 330 with the processing determining if the file is a template. If the file is a template, the processing system will operate to compile the template at step 340, and save the results to the build. Thus, this will typically include copying code portions into the build and ensuring that this correctly interacts with existing code portions provided therein, based on instructions within the template itself.

In the event that the file is not a template, the process moves on to step 350 to copy the file to the build. The file will be provided in a predetermined memory location either during the remainder of the build process or, to allow the file to be provided together with the finalised code such that it may be referenced by the code in use.

At step 360 the processing system 10 determines if all the files in the manifest have been processed and if not returns to step 300. Otherwise the builder application determines one or more agents to apply to the build at step 370. Agents are entirely optional but are typically used to ensure the resulting code is in the correct format or use.

Thus, for example, the created code may represent source code which is subsequently compiled. The agents can therefore operate to perform find and replace operations for example to alter syntax within the source code, thereby allowing it to be compiled using a specific compiler. In addition to this, agents may perform other functionality which typically is required to be applied to each substantial portion of the code provided in the build.

In addition to this, agents may perform a large range of different types of functionality to a subset of the files, this subset being determined by the agents themselves, and which may include non-code files. Thus, for example, an agent may contain code to implement the defined rule 'Any HTML should have excess whitespace removed to reduce download size' by making modifications to a subset of files consisting of plain HTML files, HTML template files, and only those code files containing large HTML portions." The agents are applied at step 380, with the builder application outputting the resulting code as skeleton code at step 390. In this sense, the term "skeleton" means code which can be executed, either directly or after suitable compiling, or the like. Thus, the skeleton code represents complete and working applications software that can be used, but which has not undergone customisation, to ensure the look and feel of the resulting application is as desired, or the like.

At step 400 the builder creates a saved copy of the skeleton code. An operator then reviews the skeleton code and compares it to the requirements at step 410 to determine if any further features and/or interfaces are required at step 420, which will typically occur if the required features or elements in the specification had not previously been defined.

If so, the operator implements the further features and/or interfaces and adds them to the application at step 430.

-16- When this occurs, if the added feature or interface is likely to be used in future projects, the feature/interface can be embodied as respective file(s) and added to the system, so that it can be automatically implemented in future, as will be described in more detail below.

If no further features or interfaces are required, at step 440, it is determined by the operator if any changes to the code are required to match requirements. Thus, this may occur if a required feature could only be implemented by using a feature which is similar, but does not provide all the required functionality. Thus, when a specification is defined, it may only be possible to select a pre-defined element which is similar to the element required. In this case, the features or interfaces associated with the pre-defined element may therefore require modification in order to allow the element to be implemented as required.

Accordingly, the operator then modifies the code as required at step 450.

At step 460 the process involves determining if any changes are required to the appearance and then modifying the code as required at step 470. Thus, this will include modifying basic interfaces, for example to provide GUIs with a particular appearance, or the like. This ensures that the look and feel or the final software matches the requirements determined above.

At step 480 the final code undergoes optional testing to ensure it satisfies the requirements.

This will typically depend on a number of factors such as the number of changes made during steps 410 to 470, as well as the stability of the files and templates used in the manifest.

This testing may optionally include the use of automated testing scripts, with these scripts consisting of code and data files generated and included in the build manifest by the builder.

The test scripts typically consist of a set tests to validate the correct function of the code generated by the builder.

Thus, for example, where a feature is selected by the builder and built into the generated application in steps 250 to 390 above, the builder will also add one or more tests to the tests scripts to ensure that that feature is working as it is intended to.

When a failure occurs in one of these automatically generated tests, the operator will typically need to make modifications to either the code or template used to generate the code being tested, or to repair the customised code directly.

-17- Thus, the final code generated after step 480 can be supplied to the customer and used.

At step 490 the optional maintenance phase can be implemented, with the user of the application software, the customer, or the operator of the processing system 10 determining any changes to the requirements or the specification. It will be appreciated that in the event that the requirements have not been altered, the same specification may be used as before, with the maintenance phase being performed to allow modifications or improvements to the features or the files to be incorporated into the software.

At step 500 the process from steps 250 to 390 is repeated to generate revised skeleton code.

The revised skeleton code is then compared to the copy of the original skeleton code saved at step 400 above. This is used to determine changes between the original skeleton code and the revised skeleton code.

At step 510 the changes are applied to the final code to generate revised final code. The reason for this is that the changes determined at step 500 do not typically effect the customised portions of the code which typically relate to the look and feel, non-standard features, or the like. Instead, the maintenance phase is usually to provide enhanced functionality, correct bugs, errors or the like. As a result, applying the changes to the previously determined final code this will tend to modify the code portions that were originally part of the skeleton code, thereby allowing the changes to integrate automatically into the final code.

In any cases where these updates do change the lines of code which were modified during the customisation process, and the differences between them cannot be automatically resolved, a "collision" will be indicated to the operator. The operator will then update the code in question to resolve the differences.

Optionally, the operator may instruct the system to respond to collisions in a variety of different ways. Thus, for example, if the operator knows the update to be particularly sensitive and does not expect any collisions, the operator may instruct the system to respond to collisions by canceling all changes to all files, allowing the operator to review the collision in advance to ensure there will be no secondary problems resulting from the collision. The operator could then choose to make all changes to all code manually, or instruct the system to run again with the normal behavior, so the collision can be resolved with the standard method, as described above.

18- The process then returns to step 480 to allow the revised final code to be tested, with the maintenance phase being repeated as often as required.

A specific example of the process is set out in Appendix

A.

Initialisation In order for the system to function correctly, it is necessary to perform a stage of initialisation in which a framework, including the features, files, LUTs, and the like, are defined. This is achieved by manually defining files, such as templates, and may be performed solely during an initialisation phase, but is also typically performed each time a new feature is required.

Whilst it will be appreciated that efficiency is improved by maximising re-use of files and features, there is a significant range of functionality between applications, and it is difficult to create files which are capable of being used in any application without the files and features becoming overly complex and time consuming to develop.

Accordingly, it is usual to construct a respective repository associated with a respective "family" of applications, which includes applications of a similar type, but which are unique in their implementation. In this regard, the similarities provide a general structure, and allow additional efficiencies in the production process, while assuming that within the general framework, each project will be substantially different.

The framework, including the files and other associated knowledge required to generate a respective "family" of applications is generally referred to as an environment.

For example, an environment can be provided to generate text-to-speech telephone applications that take requests and report information from various sources. Common code would include the text-to-speech and event handling infrastructure, while the internal code and feature set would be generated to implement the unique requirements of the individual applications.

An environment can be provided for generating software which interacts with databases. In this case, the defined entities represent entities in the database schema, with the interactions representing interactions between the respective entities in the schema. Thus, as will be appreciated by a person skilled in the art, the entities will typically correspond to respective -19groups of data within the database, which may be contained within respective tables, or the like. The relationships then represent links between these groups of tables.

In this circumstance the interfaces represent structured queries which users may wish to provide to the database. These queries can include means for writing to or reading from the database as well as performing complex database analysis procedures.

An example of this process will now be described with respect to Figure 4.

In particular, a family of related applications are selected at step 600.

At step 610, the operator will determine features required by the applications, before determining a manner of implementing these at step 620. This is a manual process and typically requires consideration of the functionality the applications are ultimately to perform, and the circumstances in which this is to occur, and may also require the consideration of respective entities, relationships and interfaces.

The operator then generates one or more files for implementing each feature at step 630, and then stores these in the database 11, at step 640.

It will be appreciated by persons skilled in the art, that in the event that the file is a template, or an executable file which generates code, it is necessary to ensure that the resulting code will integrate successfully with code generated by other files. Furthermore, as the files are typically used in a wide range of combinations, depending on the overall functionality to be provided, the generated files preferably embody a degree of generality, so that the resulting code can be integrated with code provided by any one of a number of other files.

At step 650, the operator defines and stores a manifest entry for each file. The manner in which this achieved will depend on factors such as the respective implementation, and the nature of the file. Thus, for example, the manifest entry can be stored as part of an LUT, or may alternatively be embodied as executable code which needs to be executed to propagate the manifest with appropriate data.

At step 660, the operator will define the elements that can be used in defining the specification.

This is achieved by analysing the functionality required by the family of applications and using this to assess the entities, relationships and interfaces that are required. It will be appreciated 20 that as the elements make use of the defined features, this may have already completed above, when the functionality is used to determine the features.

At step 670, the operator defines and stores relationships between the elements and the features. This may again be achieved in a number of manners. Thus, for example, LUTs can be updated to reflect mappings between the elements and the features. Additionally, or alternatively, code can be generated which is used to review the specifications and determine if respective features are required.

At step 680 the operator determines any agents that are required in order to modify the resulting code, before defining and storing these at step 690.

It will therefore be appreciated by persons skilled in the art, that the process uses an initialisation phase to develop a knowledge rich repository of elements, features, files and agents. These represent the framework for a respective environment that allows a range of applications to be produced automatically within the confines of the environment.

It will be appreciated however that it is not always possible to determine every feature or element that will be required by all the applications in a respective family. Accordingly, it is typical to define custom features and elements on a case-by-case basis as they are required.

In general the custom features and elements will be determined so as to be specific to the respective application, as this requires less effort on behalf of the operator. Thus, for example, the operator may implement a feature by inserting code manually into the build, without constructing an associated file. Alternatively, a file can be written which is specific to the circumstances and which therefore only provides code which can be used in the respective build.

However, if the feature or element proves to be useful in this or other applications, it will be generalised for use in a number of applications and added to the environment. Thus, the operator will define a file which generates code that can be integrated with a number of other files, as described above. This will typically require consideration of the manner in which the other files are implemented, and the resulting code, as well as the applications in which the file may be used.

-21- Once the file is generated, this can be integrated into the environment by defining when it is used, and the manifest entry, as described above. It will therefore be appreciated that as the system is used more frequently, more entities will be defined such that the database represents a knowledge rich repository embodying the functionality required to provide the overall functionality of the executable code.

Variations A number of variations or additions that may be implemented in the above system will now be described.

Modifications Any special features requested by a client typically require the development of new files and features. These modifications may be compatible with the common structure of the environment can be rolled back into the files, allowing this feature to be provided as an option for subsequently developed applications as described above.

In addition to this however, improvements to existing features can also be implemented by updating files. This may occur for example to provide enhanced functionality, as well as to correct errors, and the like. Once the improvements have been made to the files, this results in the improvement being automatically applied to all subsequently developed applications. As a result, the environments become self-improving.

After sufficient improvements have accrued over several months or years, updates could be provided to clients by simply regenerating their application and merging the customisations from the previous version. The extensive use of source code management tools is suggested to assist with this process. These updates might also be provided for free any time the client requests other improvements to their application, providing additional incentives for continued development.

Emergence When generating a new environment it is typical to leverage existing knowledge from other environments may basing the new environment on features contained in other environments.

22 This allows new environments to "emerge" from an existing environment relating to other applications.

Thus an operator will perform the initialisation process for a new environment by examining existing environments, and where possible, re-using elements, files, features, or the like where possible.

Tool Dependency To avoid issues of tool dependency experienced by active code generation systems described above, the environments are built on the assumption that applications will need to be modified and maintained at a later date without access to the original tools. This helps to greatly increase the lifespan of the application, reducing risk and improving the return on investment.

To enable this, it is desirable that the generated code is "clean" and of a high standard, as well as being well commented and documented. The resulting code may also need to include additional code to allow the program to adapt to changing circumstances, rather than relying on being regenerated when changes are made to the application.

For example, many code generation systems generate and store SQL statements for later use.

When changes are made to the database, these SQL statements have to be either regenerated or changed by hand, a high risk and time consuming approach.

In contrast to this, in one example, the systems described above use additional code to create SQL statements at runtime based on knowledge of its own internal structure. This requires more code, but allows the database interface to automatically adapt to a changing internal structure.

Support Tools To allow developed applications to be used independently without preventing further development, it is typical to generate customised support tools in addition to the application itself. These could include tools for debugging, testing, packaging, installation, or database management, and preferably any features added to the application should be matched by the tools.

23 The tools can be generated automatically by the provision of appropriate tools, with the nature of the tools depending on their intended purpose, which can be specified in the specification, as will be appreciated by persons skilled in the art.

This allows follow-up tasks to the generation of the code, such as day-to-day maintenance to be performed by less skilled personnel, reducing costs and potential delays. It also increases the level of control for the client, allowing them to get better use out of the original investment in the application.

For example, in web related environments, any HTML templates should be editable in their stored form in a way that is most convenient for web designers, with documentation on how to work with them included. Likewise, an easy to use automated installer tool could be built, allowing installation by the client or their system administrator, rather than the developers.

Design Tools To assist the design process, the system is preferably accessible and intuitive, allowing it to be used with relatively little experience. To achieve this the system implements a GUI as described above, to allow any reasonably skilled developer to define a specification representing the requirements for the software.

Distributed Architecture It will be appreciated that the above system may be implemented using a number of different architectures. Thus in the example described above, this is achieved by providing a stand alone processing system 10, which is used by an operator to thereby define the specification and hence determine the code.

However, alternative architectures, such as distributed architectures, or the like, may also be implemented. This allows access to the services of the processing system 10 by third parties, thereby allowing third parties to define specifications, an even interact with the processing system 10 during the automated, customisation or maintenance phases.

An example of this is shown in Figure 5 in which the processing system 10 is coupled to a database 11, provided at a base station 1. The base station 1 is coupled to a number of end stations 3 via a communications network 2, such as the Internet, and/or via communications 24 networks 4, such as local area networks (LANs) 4. Thus it will be appreciated that the LANs 4 may form an internal network at an organisation, or the like. This allows third parties at locations remote to the central base station 1 to access the services provided by the processing system Accordingly, in use the end stations 3 must be adapted to communicate with the processing system 10 positioned at the base station 1. It will be appreciated that this allows a number of different forms of end station 3 may be used.

An example of a suitable end station is shown in Figure 6. As shown the end station 3 includes a processor 30, a memory 31 and an input device 32 such as a keyboard, an output device 33 such as a display coupled together via a bus 34, as shown. An internal interface 35 is typically provided to allow the end station to be coupled to one of the communications networks 2, 4.

In use, the processor 30 is adapted to communicate with the processing system 10 provided in the base station 1 via the communications networks 2, 4 to allow the above described process to be implemented. Accordingly, it will be appreciated that if the communications network 2 is the Internet, this will typically be achieved by having the base station 1 present web pages to the third party via the end station 3.

Accordingly, it will be appreciated that the end stations 3 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, hand-held PC, or the like, which is typically operating applications software to enable data transfer and in some cases web-browsing.

In this case, the user of the end station 3 will be presented with the GUI for defining the specification as an appropriate web-page. The user can then select and/or define entities, relationships, interactions and the like as described above, to thereby provide a specification to the processing system The processing system 10 will then perform the automated phase as described above, before providing the skeleton code for customisation, which may be performed either by an operation of the base station 1, or the user of the end station 3, depending on the circumstances in which the system is used.

In this case, it will be appreciated that access to the process may be controlled using a subscription system or the like, which requires the payment of a fee to access a web site hosting the process. This may be achieved using a password system or the like, as will be appreciated by persons skilled in the art.

In this case, by providing an automated billing system, this allows organisations or other third parties to use the system to generate their own applications software. In the case of specialised application types, deployment into an hosting environment could also be provided.

In this configuration, the tools and documentation provided by the system supports the client, limiting the need for additional technical support.

Prototyping System When a distributed architecture is used, or otherwise, by ensuring that the design tools are sufficiently basic and straightforward to use, this allows the system to be utilised by nondevelopers, who are only able to define basic requirements relating to desired functionality.

This allows a fuilly working prototype to be developed on-site in 10 or 20 minutes, allowing organisations to rapidly assess whether the system will be suitable for use in developing software applications to satisfy the organisations requirements. This provides an extremely powerful sales tool, and helps to reduce the gap in understanding between sales and technical staff when building the final version.

Code Bloat The term "bloat" in software describes the situation in which increasing amounts of features are added to an application that are only used by a small percentage of users, but that consume the resources of all users.

Applications created by the systems above already have more code than is required to accomplish the immediate task, to add flexibility post-detachment, and to allow re-use of templates and other files in a wide variety of applications. This coupled with the ease of adding features by simply adding them to the master version, encourages a tendency towards bloat.

26 To avoid these problems, new features are only built into the generated code when needed.

Aggressive "culling" of unused features reduces the size, complexity and resource overhead of the resulting applications, simplifies documentation and support tools, and increases the speed of the applications.

Thus, by constantly reviewing and optimising the feature set, and the associated implementation files, this ensures that the generated application can provide a wide range of functionality without generating bloated code.

This also reduces the cost of computing resources needed for the application, resulting in significant client savings for heavily used applications.

Software on Demand The system allows applications software to be generated extremely rapidly. This is important when many situations require a basic first version of an application to be deployed as quickly as possible, to meet an immediate need. This can then be followed by one or more slower upgrade cycles. It will be appreciated that in simple cases, the systems described above can be used to allow software to deployed in a few hours or days.

One result of this ability to create software very quickly is the provision of "Emergency" or "Just-In-Time" Software, where an application is required at extremely short notice.

For example, in a disaster, war, refugee situation or some other emergency, there may be a previously unforeseen need for a software application. In particular, in emergency situations it is often required to collect information relating to victims in a quick manner so this can be subsequently accessed via third parties. Often a wide variety of information must therefore be processed rapidly depending on the circumstances.

Accordingly, in this case, an operator of the system can assess the sort of information which will need to be stored in the database and then use this to define a database schema. The details of the database schema are then entered into the builder application via a GUI presented to the user on the processing system 10. The process described above is then used to construct required applications software, allowing it to be created and deployed to a pre designated hosting environment, or to the field. In this case, the tools and documentation created with the 27 application would simplify its installation and use, allowing this to be achieved by untrained users.

A business orientated example could involve customer information capture applications for marketing departments who deal with bookings for advertising that cannot be changed, and need an application for this absolute deadline, reliably and at short notice.

In order to achieve software on demand, a permanent agreement may be used between a developer and an organisation such as a government, large charity, or the military which would manage development capacity, keeping it available at short notice.

Disposable Software By being substantially automated, and by re-use of developed knowledge, this allows software to be developed extremely cheaply. Development of an application to a fixed price becomes less risky, allowing a safety margin for unexpected events, and the ability to regularly come in on or below budget.

The ability to provide cheap software leads to the ability to generate "Disposable Software", which is custom software written to be used for a limited period of time, either for a temporary event, or to serve as a short term measure until a larger solution is created.

The high cost of the bespoke development creates an unwillingness to write off these costs too early even for short term applications, or to be seen as "wasting" money. Companies often end up spending additional money on substandard first versions of software because of this unwillingness to throw a program away and start again.

The ability to create applications for what is fairly insignificant amounts of money for a large company allows them to "try out" concepts, set up software for short term events, or avoid significant expenditure on the premature creation of larger more advanced systems. This software will still be of a good quality, meaning more frequent requests for the same types of applications.

Quality To ensure correct operation of the system, the feature set and associated files can be periodically reviewed to ensure they are optimised and stable. This in turn ensures a high -28quality end product. Furthermore, the techniques provide mechanisms which allow software to be generated rapidly, and at low cost.

This has the potential to offer huge benefits in software quality, delivery speed and development costs. The cost and time savings can open new markets to the developer, as well as allowing prototyping of techniques at low cost.

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

-29- Appendix A First Specific Example An example of the implementation of the above described techniques to generate applications software will now be described.

In particular, this example is provided in the environment of the time-sheet applications.

Analysis Business Requirements Initially it is determined that the creation of a simple but custom time-sheeting system to record general consulting work done for clients, and generate Statements of Work and Tax Invoices is required.

In this example, the goal is to construct a basic functioning package as quickly and cheaply as possible, to allow a more comprehensive customer management system to be completed in due course. In view of this, it is intended that the system store only a minimal amount of information regarding clients.

Analysis Entities and Relationships The system tracks three primary Entities, "Client", "Activity Type" and "Work Period". The general structure and relationship of these Entities is outlined in the tables below: Client WorkPeriod WorkPeriods: Relation +Client: Relation +Name: String +Day: Date +EntityType: String +Start: TimeOfDay +ABN: Integer +End: TimeOfDay +ABN: Integer (Der.ve d ActlvnyType +Contact: string Length: Integer (Derived) ActivityType +Active: Boolean +Activity: Relation Created: DateTime (Auto) +Comments: Text +Name: String Modified: DateTime (Auto) Created: DateTime (Auto) +Description: Text +Rate: Float Analysis System Interfaces On the above data, the following Interfaces, and associated actions are required.

Client Manager Interface Available to Administrator Add a new Client Edit existing Client details List Clients View a Client's details Activity Type Manager Interface Available to Administrator Add a new Activity Type Edit existing Activity Types List Activity Types Show Activity Type details io Time Sheet Program Interface Available to all Staff Add a new Work Period Edit a Work Period List Work Periods Search for a Work Period Show Work Period details Invoice and Statement Tool Interface Search for Work Periods Calculate Invoice Line Items to be entered into QuickBooks Generate Statements of Work to be printed and attached to Invoices System Capture of Analysis Results In this example, the environment includes existing features for implementing all the functionality outlined above, except for the "Calculate Invoice Line Items" and "Generate Statements of Work" functionality.

The Entity Relation Diagram can therefore be entered into the GUI provided by the processing system 10, with a 100% fit. Thus, the schema required to implement the above system can be input using predefined options selected using the GUI, such that the tools provided by the environment can generate functionality to implement 100% of the structure and functionality for the Schema of the system.

The four Interfaces outlines are then defined using an Interface Designer, with a "List Work Periods" item added as a close match to the functionality required for the "Generate Statement of Work" item. Nothing was added for the "Calculate Invoice Line Items" entry, as the environment does not currently contain auto-generated functionality which is suitably similar to it's requirements.

-31- Creation of Skeleton Application Details of the deployment environment and some documentation and code style options are entered into the Builder, which then proceeds to build the application as described above.

1) Feature Analysis The builder application examines the build options and application specification to determine a "feature tree" of the features to build, or to not build, into the main core of the generated system.

These features will later become available across the entire application. A sample of these feature tree entries follows: bundle.all: yes build.tools.basic: yes build.tools.cgi: yes build.test.basic: yes build.test.pod: no build.modperl.only: no build.modperl.support: no build.image.library: no build.html.cycle: no build.html.libs: yes build.html.shortcuts: yes build.html.template: yes build.html.widgetall: no build.html.widgets: yes build.feature.asml: no build.feature.created: yes build.feature.edit: yes code.removefeatures: yes code.shorthand: yes code.technical: no code.unduplicate: smart code.strip.comments: no 2) Assemble the Build Manifest A combination of the feature tree, the specification and the build configuration information is then used by the builder to create a build manifest for the application. This manifest includes a number of categories of files, as follows: a) Files common to every generated application cgi-bin/lib/TimeKeeper/Util.pm 32 cgi-bin/lib/TimeKeeper/Obiect .pm cgi-bin/lib/TimeKeeper/Iflterface .pm cgi-bin/lib/TimeKeePer/Infoa.pm cgi-bin/lib/TimfeKeeper/Coflfig .pm b) Files to support a particular feature cgi -bin/i ib/TimeKeeper/DB/Schema .pm# build.db.schema: 1 cgi-bin/lib/TimeKeeper/DB/Transaction.pm 4 build.db.tralsactiOfl 1 cgi-bin/lib/TimeKeeper/Cofldition.pm# build. feature. search: 1 cgi-bin/lib/TimeKeeper/Web/Search.pm# build. feature. search: 1 c) Files dedicated to a particular specification element cgi-bin/InvoiceTool .pl cgi-bin/html/InvoiceTool/Login .html cgi-bin/lib/TimeKeePer/Web/Application/InvoiceTool .pm cgi -bin/lilb/TimeKeeper! Info/WorkPeriod .pm cgi-bin/lib/TimeKeeper/Entity/WorkPeriod .pm d) Files implementing a widget or resource shared by one or more specification elements cgi-bin/lib/TimeKeeper/Data/LongString .pm cgi-bin/lib/TimeKeeper/Data/Date .pm cgi-bin/lib/TimeKeeper/Interface/AU/A3N .pm cgi-bin/lib/TimeKeeper/Interface/Checkbox/LabelledYesNo .pm cgi-bin/lib/TimeKeeper/Interf ace/Email .pm Each entry in the manifest describes not just the location of the final file, but also the method used to create it simple copy, compiled from a template, 100% generated by code) and any parameters to the build method needed to describe a particular context for that file. For example, any file added for a specific element would be passed that particular specification element as a parameter.

3) Generate Application Files For each file listed in the manifest, the builder will call the appropriate generation function for the file, which will copy the file from a source location, compile the file from a template, or generate the file completely from code.

-33- 4) Apply Agents to Generated Files Once the files have been generated, a number of Independent Agents will be assigned to work C on the files. An Independent Agent is a logically standalone piece of code which can examine the generated application and then add, remove or modify the files in it as needed to perform a 5 particular higher level task. In our example, the following agents were applied.

l^- Build::Agent: :HTML::StripBlanks O Remove whitespace from HTML to reduce download size (i SBuild::Agent: :Perl: :UnduplicateSubs Find cases where the builder accidentally put more than one method of the same name in a code module, and keep only the last one.

Build::Agent::Newline Ensure that all newlines in all files match the platform Unix/Win32 that the program will be deployed to.

Build::Agent::Image::Shrink Find all images in the application and optomise them to reduce size Build: :Agent::Autodoc::HTML Find and remove all embedded API documentation, convert it to a cohesive set of HTML documentation files, and add it to the documentation section of the build manifest.

Dispatch the completed Application This may involve simply saving the project to disk, uploading it to a FTP site, or converting it into a compressed archive file .zip, .tar.gz, etc and emailing it to a remote operator. The builder will also save a copy of the application as a 'checkpoint' version, so that changes made in future builds can be analysed to automatically move any improvements into a version modified by the operator.

In the example, the files were simply saved to disk for the operator to later work with, and as this was the first build, there was no previous checkpoint, and no version modified by the operator, so a change merging process was not required.

Customisation With the basic application completed, a copy of the application can be installed to a development/test server.

-34- Working with the development installation, a programmer altered the generated "List Work Periods" section of the Invoice and Statement Tool to meet the requirements for the "Generate Statements of Work" entry. The developer also created and added the custom "Calculate Invoice Line Items" entry by copying the "Search for Work Periods" entry and using it as a starting point.

Also working with the development installation, a HTML developer modified the HTML templates for the application to apply a common company-branded header to all the applications, and to alter the layout of various pages and forms to a more desirable format.

Once customisation is completed, the changes to the application can be committed to the source code repository to allow future changes to be more easily made to the system.

Deployment The completed application can be deployed to a production server. A database tool that had been generated and bundled with the system was used to set up and initially populate the production database. User training and general use of the system followed as per normal.

Second Specific Example A second specific example focussing on the manner in which a feature is implemented causing the build manifest to be generated will now be described.

In this regard, the feature relates to the ability of a database to store and retrieve large arbitrary chunks of binary data, commonly referred to by the term BLOB Binary Large Object or often just LOB. Implementing a "database LOB support" feature therefore allows use of the "Binary" application data type, which is further used for the "image support" feature or the "file storage" feature, which is further used to provide a variety of image and file related Interface widgets as options for Properties and Outputs.

Because it is quite a significant feature, and is implemented differently in different databases, the implementation of the "database LOB support" feature highlights many of the factors in adding a feature.

1. Identification of Requirements The "database LOB support" feature exists in the feature tree as "build.db.lob", and is assigned a true or false value depending on whether it is required.

A dedicated method, "AppCore::Entity::Project::_need_lob_support", is used to implement the rules that determine whether this feature tree element is set to true of false. This method is only called if a database is needed for the application.

The rule assesses whether "any Property elements or any Output elements anywhere in the application structure for a Project use the 'Binary' data type". Because the only thing that uses the "database LOB support" code directly is the 'Binary' data type, searching for any use of this data type determines whether this feature is required.

This is achieved by executing code which causes the properties defined as part of the specification to be examined.

The code to implement this rule follows.

Do we need LOB support in the database.

Look for any use of the Binary data type.

sub _need_lob_support my $self shift; Get the Binary datatype my $Binary AppCore::Entity::DataType->findByName( "Binary" or return undef; Get the identities of all the Entities in the Project my $EntityIds $self->getEntities or return undef; return if $EntityIds->null; Are there any Properties that use the data type my $rv AppCore::Entity::Property->count( ['Property.Parent', $EntityIds->list 'Property.DataType', $Binary->getId return undef unless defined $rv; return 1 if $rv; Are there any Outputs that use the data type $rv AppCore::Entity::Output->count( 'Output.Parent', $EntityIds->list 'Output.DataType', $Binary->getId return undef unless defined $rv; $rv; -36- Thus, as will be appreciated by persons skilled in the art, the code does not attempt to determine which Properties use the data type, but merely counts the number. If the Binary data type is found in any Properties, the method immediately returns true, as there is no need to additionally check for the use of the Binary data type in any Outputs.

Typically, if it is decided that the "database LOB support" feature is needed, the operator cannot disable the feature. If it is decided that the "database LOB support" feature is not needed, the operator can manually force the feature to be built into the application.

2. Adding Files to the Build Manifest When the builder is creating the build manifest, a section of code relating to the addition of database-related files stores a set of logical module names that are needed to implement the respective feature.

Thus, when the builder generates the build manifest, it will implement the code associated with the "database LOB support" feature, which will in turn populate the manifest with any required files.

In this example, one module is specified as follows: my @LOB qw{ DB: :LOB Add the LOB modules if needed if $features->get('build.db.lob') $self-> add core modules( @LOB or return $self->_error( "Error adding database LOB modules" This utilises a common builder method "_add_codemodules" which takes the module name and adds the specific file "lib/MyProject/DB/LOB.pm" to the build manifest, identifying the template that is to be used to create it.

It also uses a LUT detailing which modules have external dependencies, and what those external dependencies are. In the case of the above module, the external and relatively standard CPAN modules "IO::Scalar" and "IO::File". A further LUT identifies required minimum versions for the external modules. This information is stored and used later to assist in the generation of several files relating to test scripts and documentation.

-37- Thus, this allows the build manifest to be populated with the required modules.

At a later point, the builder compiles the code template for the file, which is listed below.

package base use strict; use UNIVERSAL 'isa'; use base base use IO::Scalar This standard chunk size, although used for all database backends, is designed specifically to be the most efficient for Oracle, which is the most likely database for handling any really heavy duty binary work.

our $BUFFERSIZE 32767; Get's and return a LOB from a database Return a reference to a scalar containing the LOB data sub getLob my $class shift; Create a new anonymous IO::Scalar my $handle IO::Scalar->new; my $rv $class->streamTo( $handle, $rv $handle->sref $rv; Pull stuff in from the interface specific external file interface db.interface db.interface 'adaptive' PROCESS "modules/DB/LOB.${interface}.pm" As can be seen, the base placeholder is used to insert the root namespace of the module. Because of the huge difference between the different database LOB implementations, the main template pulls in another template (based on the database interface that will be used) to provide the specific code for the particular back-end database.

While the contents of these files are relatively simple, a more complex set of templated code may look like the following in this case, for a custom "delete" method for entities which need to delete "child" entities first).

IF Children We need to cascade delete our children first.

As usual, be VERY VERY careful when deleting.

sub delete my $self shift; return 1 if $self->(_DELETED} or $self->{_NEW}; IF build.db.transaction error trans.db '->_error' This needs to happen inside a transaction my $db base %>::DB::Transaction->ensure( shift or return undef; I -38- ELSE error '$self->_error' END C. FOREACH Child IN Children Other Child.OtherClass Find our child Other.LabelPlural and delete them I my Other.Name %>List $self->find<% Child.Name unless defined Other.Name %>List return error "Error finding Other.LabelPlural to delete" p if Other.Name %>List 02 foreach my Other.Name Other.Name %>List Other.Name %>->delete<% IF build.db.transaction $db END or return error END Finally, delete ourself as normal $self->SUPER::delete<% IF build.db.transaction $db END or return error Commit the transaction and dispose of it trans.db %>->commit or return error IF build.db.transaction $db->done; Always return true END END As can be seen, this fragment of code contains quite a number of different variations, based on whether "database transaction support" is needed, how many and what "child" relationships the Entity is involved with. Indeed, if the Entity has no "child" Entities, the method is not needed at all.

Third Specific Example A third specific example focussing on the operation of the builder to implement the manifest will now be described in more detail.

As mentioned in the "database LOB support" example above, the builder accumulates references to external modules that are needed to be installed. One of the test scripts typically built with an application has the task of determining if these external modules are available on the computer on which a generated application is deployed, that these external modules are of a new enough version, and that the application "compiles" or loads successfully into memory, -39- S passing internal startup checks. The list of modules determined during the manifest creation stage is stored in the builder.

One file in particular in the manifest "test/data/MODULES.txt" is added to be completely generated, with the builder providing as argument the complete list of these external dependencies accumulated through the rest of the build manifest creation process.

sub create modules list my $self shift; Smy $Builder shift; c 10 Get the full list of modules needed, and attach the required minimum version if it has one.

my $modules join map $CPAN_VERSION{$ $CPAN_VERSION{$_}" sort keys %{$Builder->{externalmodule_dependencies}); Return the merged list to be the content of the file return join map @modules; The content returned from this method is saved by the builder to be the content of the file "test/data/MODULES.txt" when dispatching the project, after any agents have modified the file, which in this case would likely only be the correcting of carriage returns for an alternate platform other than the one on which it was created.

Dated this of TWENTY-SECOND Day of April, 2005 PHASE N AUSTRALIA PTY LTD By their Patent Attorneys DAVIES COLLISON CAVE