Patent Application
20110023022
This invention relates generally to modification of an application program to produce an upgraded version of the program. More specifically, the invention describes the use of a database to store and manipulate an application template to create an upgraded version of the application defined by the template.
The development of complex software applications has become a team effort. The days of a solo engineer working to craft all of the source code for an application have given way to a highly cooperative environment in which multiple developers contribute to an end product. Nowhere is this collaborate style more evident than in the development of interactive television (iTV) applications, which combine stringent requirements and often arcane engineering expertise with the desire for highly attractive and compelling user interface appearance and behavior.
The development of a user interface application consists of generating or modifying a body of source code that defines the appearance and behavior of the application, and selecting or creating resources such as textual content, images, video sequences, audio sequences, and other auditory or graphical material that are displayed in conjunction with the execution of the application. For collaborative development projects, modern software engineering practice encourages the use of software configuration management (SCM) systems that can be used to store source code files, textual content, binary image content, and other artifacts associated with an application. An SCM system can track modifications to source code to allow multiple versions of a project to exist in parallel, can manage access to the individual artifacts of an application, and can allow collaboration among team members, even when located at multiple worksites. SCM systems are intended for use with human-readable files, affording efficient storage of differences between successive revisions to a file and allowing regeneration of previous versions on demand. Some SCM systems accommodate binary file content, by storing the entirety of each successive version of a binary component of a project. In general, SCM systems treat the artifacts of a project at a coarse-grained level, the level of individual files or resources.
Database (DB) technology provides the capability for managing a body of data at a very fine-grained level. Any specific datum can be modified, and the modification can be managed and tracked, using conventional DB methodology. DB systems allow for control over who can access or perform modifications to data, and manage concurrency among multiple users of the database to avoid data collisions and reconcile access conflicts. Database systems can also provide efficiencies of storage by reducing the need to store duplicate copies of large or complex entities. Moreover, modern object-based databases allow the storage and manipulation of collections of data structures as objects, rather than being limited to simply storing numbers or textual content. Database systems also provide for scalability, allowing for easy expansion to larger projects, larger numbers of projects, and larger numbers of users accessing project data; provide for data security and fault tolerance, to protect data integrity in the face of hardware or software failures; and provide for distributed support of database functionality, allowing simultaneous access to a database from multiple dispersed locations.
What is required is a method and system for application authoring and application versioning that combines the features of a source configuration management system with the features and functionality of modern object-based databases.
The current invention provides a computer system and method for authoring applications based on an application template, characterized by creating an application template, for example by creating an in-memory object representation of an original application, storing the object representation in an object database, and converting the object representation into an application template, for example by selecting at least one attribute of the object representation that is suitable for modification, creating one or more metadata items that specify an attribute suitable for modification and specify at least one requirement for the modification of the attribute, aggregating the metadata items, associating the aggregated metadata with the object representation, and storing the metadata with the object representation in the object database; making a copy of the application template in the database; modifying the copy, for example by selecting at least one metadata item associated with the copy of the object representation and modifying at least one attribute of the object representation specified in the metadata item in accordance with all requirements for the modification of the attribute; and generating an executable application from the modified template, for example by extracting the modified copy of the object representation to create a modified in-memory object representation, and generating an executable version of the modified application from the in-memory modified object representation.
In a further embodiment of the inventive system and method, the generation of an executable version is performed by generating a set of at least one human-readable source code file from the in-memory modified object representation and compiling the source code to produce an executable application.
In a still further embodiment of the inventive system and method, the generation of an executable version is performed directly from the in-memory modified object representation.
In a further embodiment of the inventive system and method, the in-memory object representation is created by parsing the source code for the original application.
In a still further embodiment of the inventive system and method, the in-memory object representation is created by decompiling the executable version of the original application
In a still further embodiment of the inventive system and method, the database operations are performed through a web services interface.
In a still further embodiment of the inventive system and method, the attribute to be modified is one of the position, size, shape, or color of a region of color displayed by the application.
In a still further embodiment of the inventive system and method, the attribute to be modified is one of the position, background color, font face, font size, font weight, text color, alignment, or textual content of an area of text displayed by the application.
In a still further embodiment of the inventive system and method, the attribute to be modified is one of the position, size, or image content of an image displayed by the application.
In a still further embodiment of the inventive system and method, the requirement for a modification is that the modified value is one of a list of valid values.
In a still further embodiment of the inventive system and method, the requirement for a modification is that the modified value falls within a bounded or half-bounded range of values.
In a still further embodiment of the inventive system and method, the requirement for a modification is that the modified value matches a regular expression.
The preferred and alternative embodiments of the present invention are described in detail below with reference to the following drawings.
By way of overview, embodiments of the present invention provide a method for authoring a modified version of an application.
As used herein, the term “application” is intended to refer to a body of digital information comprising code and data that when processed on a suitable computing platform yields appearance and behavior as intended by the creator of the application. An application may be encoded using native CPU instructions, interpreted byte codes, declarative data structures, or any combination of such encodings. An application may respond to external events by appropriate modification of appearance and behavior, as specified by the code and data comprising the application.
As used herein, the term “metadata” is intended to refer to human-readable or binary content which is not part of the source code or executable content of an application, but which refers to attributes of the source code or executable content of the application, or to modifications that may be made to such attributes.
As used herein, the term “object” is intended to refer to a software entity defined by a body of software code that declares the member properties and functions of the entity. Objects form the basis of object-oriented software languages. An object may be considered to be a collection of data upon which operations can be performed, the object encapsulating the details of how the data are stored and manipulated.
As used herein, the term “object instance” is intended to refer to a collection of data in a structured format that describe a single instantiation of a software object class defined by member properties and functions. The data of an object instance correspond to the values of the various member properties of the class. The data of an object instance may include executable code in source or executable format corresponding to a property or properties of the instance. The complete representation of an object instance may also require reference to the values of properties shared by all instances of the software object class. In common with conventional usage, the term “object” may refer herein to a class of entities with a shared specification or to a specific instance of the class, depending on the context of the usage. When necessary to disambiguate the latter meaning, the term “object instance” is used in distinction to the term “object”.
As used herein, the term “object representation” is intended to refer to an object instance or a hierarchy of object instances, the cumulated properties of which and relationships among which form the structure and define the functionality of an application. Each of the object instances in an object representation has associated properties and functions defined by the body of software code that declares the member properties and functions of the corresponding object class.
As used herein, the term “template” is intended to refer to a body of data stored in an object database representing an object-based representation of an application and associated metadata. The associated metadata define allowable modifications to the object-based representation. The object-based representation for a template can be modified in accordance with metadata associated with the object-based representation. The modified object-based representation can be extracted from the database and used to generate an application. The phrase “application template” as used herein is synonymous with the term “template”.
As used herein, the phrase “generate an application” is intended to refer to the process of converting an in-memory object-based representation of an application into a machine-readable format suitable for ingestion and execution by a suitable computing platform.
As used herein, the term “resource” is intended to refer to a body of binary data, exclusive of application source code, that is used during the execution of an application to control the appearance or behavior of an application.
The various aspects of the claimed subject matter are now described with reference to the annexed drawings. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.
Furthermore, the disclosed subject matter may be implemented as a system, method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer or processor based device to implement aspects detailed herein. The term “article of manufacture” (or alternatively, “computer program product”) as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network. Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
The representation of the original application is processed by a template creation component 140. A user of template creation component 140 creates an in-memory object representation of the original application, for example by using component 140 to parse application source code 120 or by analyzing or otherwise reverse-compiling application executable 130. A user of template creation component 140 then stores the in-memory object representation into object database 150 in the form of database structures that reflect the contents of the in-memory object representation of the application. A user of template creation component 140 then examines the various elements of the in-memory representation and selects one or more attributes that are desired to be subject to modification when creating a new version of the original application. A user may also associate one or more restrictions on the choices that may be made when modifying an attribute. All such modifications and restrictions are encoded as metadata to be associated with the application representation to form an application template. Individual modifications might be further labeled as required or optional. When the desired set of modifications and restrictions have been selected and specified, a user of template creation component 140 then stores the associated metadata into object database 150 and associates the metadata with the database representation of the application to create an application template 160. Communication between template creation component 140 and object database 150 may be through any conventional means, such as Software Query Language (SQL) or other suitable database transaction interface protocol.
Once an application template 160 has been created in the object database 150, template editing component 170 provides an interface to allow authoring of a modified application based on the application template. As described above for the template creation component, communication between template editing component 170 and object database 150 may be through any conventional means. A user of template editing component 170 can make a copy of an application template 160, query to determine the modifiable attributes of the template, and assign values to one or more modifiable attributes, storing the new values into the copy of the application template. Following conventional database access and manipulation practice, the right to perform particular operations in the database may be restricted to particular individuals. For example, for a given application template 160, a single person may have the right to make a copy of the template, that right belonging to a ‘role’ designated as the ‘owner’ of the template. The owner of the template may have the right to assign ownership to a second party, and may have the right to associate particular roles with the various possible modifications that can be made to the copy of the template. For example, one role might be granted the right to change the textual content of particular object instances (a ‘text editor’ role), while another role might be granted the right to change the image content of other particular object instances (a ‘graphical editor’) role. Yet another role might be granted the right to review all modifications (a ‘reviewer’ role). The definition of access and manipulation roles to objects in a database, and the assignment of individuals to particular roles, are conventional features of database systems and database manipulation known in the prior art. Inasmuch as multiple individuals might be assigned to multiple roles granting access to a particular application template and its modifications, the task of authoring a modified application might involve multiple users interacting with the object database 150 through template editing component 170. The final step of modifying the copy of application template 160 might require the review of all possible modifications to ensure that all required modifications have been performed and that the supplied values of all modifications meet a set of external criteria not encoded within the template, for example, that stylistic guidelines have been followed when modifying the application and that no spelling or grammatical errors are found in textual content specified during the template editing process.
Once all modifications to the copy of application template 160 have been made and optionally reviewed, application generation component 180 is used to generate the final executable application. A user of application generation component 180 retrieves all the data in the modified copy of application template 160. This retrieval is achieved using a standard database interface protocol. The retrieved data are used to create an in-memory representation of the modified application, similar in structure but different in at least one detail from the in-memory representation originally created for the application in application template creation component 140. The in-memory representation of the modified application is used to generate an executable version 190 of the application. This generation can proceed through the generation of one or more source code files representing the content of the in-memory representation, followed by compilation of the source code files by an external application to generation an executable version of the application. Alternatively, the in-memory form could be used to directly generate the executable module or modules representing the executable version of the application.
The steps involved in creating an application template, copying and modifying the template, and generating an executable version of the modified application are now described in further detail. By way of illustration, the following description describes an exemplary implementation of the inventive method, in which the application source code is written using the TVScript-BIF language as employed in the Create ETV-BIF™ authoring environment marketed by Ensequence, Inc., Portland, Oreg.
Briefly, TVScript-BIF is an object-oriented language for authoring declarative applications that execute on an ETV-BIF user agent. A TVScript-BIF application consists of an object hierarchy constructed from the various native objects defined by the TVScript-BIF language; optional variables that contain static or dynamic values used during the execution of the application to control application appearance or behavior; optional event function code that is executed in response to events; optional data tables used to control application appearance or behavior; optional resources used when executing the application; and optional signal and trigger data that may be sent to the application during execution. TVScript-BIF applications execute on compliant ETV-BIF user agents. The ETV-BIF binary format and the behavioral requirements for a compliant ETV-BIF user agent are defined by OpenCable specification OC-SP-ETV-BIF1.0-I04-070921 “Enhanced TV Binary Interchange Format 1.0” issued by Cable Television Laboratories Inc., Louisville, Colo., incorporated herein by reference.
The source code of a TVScript-BIF application comprises a series of human-readable files that define the hierarchy of object instances that make up the application; declare the associated functions and variables used during the execution of the application; specify the values of data tables incorporated into the application; designate the source files for image and font resources used by the application; specify the timing and content of signals and triggers sent to the user agent during the execution of the application; and define the structure of the ETV-BIF resources to be generated when compiling the application.
An exemplary in-memory representation of a TVScript-BIF application consists of a series of data structures constructed when the source code for the application is parsed. The data structures comprising the in-memory representation correspond to the various elements comprising the application. Every object instance in a TVScript-BIF application has a matching structure; the contents of the structure reflect the object instance property values specified in the source code. For example, the TVScript-BIF Page object is the parent of all visible and functional objects active at any one time in a TVScript-BIF application. An application may have multiple Page objects, which can become active in sequence. Every Page object is contained within a Partition object, which can have one or more Page object children. A Page object has properties that define, for example, the width and height of the page, the style used to display the page background, flags indicating whether the page is visible, enabled, and selected when the page is first displayed, function code executed when particular events occur during execution (event handler code), and so forth. Some properties must be specified in the TVScript-BIF source code, while other properties have default values and need not be specified in the source code. Another of the properties of a Page object is a list of the child objects of the Page object, defined by the object hierarchy specified by the source code. All of these elements of the application are reflected in the in-memory representation of the application.
By convention, the source code for a given Page object is contained in a single TVScript-BIF source file. When an in-memory representation of an application is being created, the source file is parsed and object structures are created in memory to reflect the object structure of the source file. Each object is represented by an object structure that contains pointers to the string containing the name of the object, values or pointers to values for the properties of the object, a pointer to a list of function strings, and a pointer to a list of child object structures. For convenience, each object also has a pointer to its parent object.
An author may wish to modify the appearance of the example application, for example by modifying the position, size, shape, or color of the region of color displayed behind the slogan; the position, background color, font face, font size, font weight, text color, alignment, or textual content of slogan text; or the position, size, or image content of the image icon.
Attention is directed to lines 306 and 315 in
Attention is further directed to line 320 in
Other source code for the application, not shown in
The syntax of TVScript-BIF and the nature of the built-in objects, properties, resources, styles, and so forth lead to natural in-memory object representations of the elements of the application that parallel the syntactic structure of the source code. The inventive method involves conversion between this in-memory representation and an equivalent database representation. Preferentially, the inventive system utilizes a limited set of database structures to represent the application.
Other aspects of an application are represented in the database by ModifiableObject 420 and ModifiableProperty 430 structures. As described above, a TVScript-BIF application comprises a hierarchy of TVScript-BIF objects; each object is represented by a ModifiableObject structure 420. A ModifiableObject structure includes an ID field, and a field that identifies the Template structure to which the ModifiableObject belongs. A ModifiableObject structure has a Name field that gives the name of the corresponding TVScript-BIF object instance, and a Type field that gives the type of the object instance (that is, Page, TextBox, etc.). A ModifiableObject structure has a ParentModifiableObjectID field that names the parent of the object, and an Order field that gives the position of a child object within the list of children of the parent object. By convention, an instance of the top-level Application object has a ParentModifiableObjectID field value of 0, since an Application object is the root of the application representation and has no parent object.
Each object in an application may have a set of associated property values. Each property value is represented by a ModifiableProperty structure 430. A ModifiableProperty structure has an ID field, a TemplateID field that names the template containing the property, and a ModifiableObjectID field that names the object within the template whose property value is defined by the ModifiableProperty structure. A ModifiableProperty structure also contains a Name field that names the property, a Type field that names the type of the property value, and a Value field that contains the value for the property. The Type field value determines the nature of restrictions that can be placed on a replacement value for the Value field. Certain properties, for example the Main property of a Page object, cannot be modified in an application template under any circumstances. A ModifiableProperty structure contains an IsReadOnly field to signal these special cases.
ModifiableObject structure 500 is the structure corresponding to the txbxSlogan object. The structure has an ID of 130. The TemplateID value of 100 matches the TemplateID value of all the structures generated for this application. The structure Name and Type fields signal the name and type of the object, while the ParentModifiableObjectID field value of 120 signals that ModifiableObject structure 510 (which has an ID of 120) is the parent object of this object. ModifiableObject structure 510 in turn corresponds to the Page object, and has a ParentModifiableObjectID field value of 110, signaling that ModifiableObject structure 520 is the parent object of the Page object. ModifiableObject structure 520 corresponds to a Partition object, and has a ParentModifiableObjectID field value of 100, signaling that ModifiableObject structure 530 is the parent object of the Partition object. ModifiableObject structure 530 is of type Application, which is the parent object of the entire application. An Application object has a ParentModifiableObjectID field of 0, signaling that it is the root object of the object tree.
The properties of the txbxSlogan object are represented by ModifiableProperty structures 540, 550, 560, 570, 580. ModifiableProperty structure 540 has an ID of 200 and a ModifiableObjectID field value of 130, which identifies ModifiableProperty structure 500 as the corresponding object to which the property value applies. ModifiableProperty structure 540 has a Name field value of Left, a Type field value of Integer, and a Value field value of 112, corresponding to the contents of source code line 311 from
The TVScript Partition object corresponds to the ETV-BIF page resource and serves as the parent object of all Page objects contained in the Partition object. The TVScript-BIF ResourceArchive object, which corresponds to the ETV-BIF data resource module, can be the parent object of data tables.
Each TVScript-BIF Partition object has an associated StyleSheet object, the representation of which is stored in a stylesheet source code file. A StyleSheet object is the parent of all the Styles defined in the stylesheet file. Styles are represented by ModifiableObject and ModifiableProperty structures. A TVScript-BIF style comprises a Style structure that references a sequence of nested StyleElement structures, reflecting the ETV-BIF style organization model. In source code, a Style structure contains a set of optional attributes, which refer to StyleElements that define the corresponding sub-styles. Similarly, a StyleElement structure contains a set of optional attributes, which may specify values directly or may refer to further StyleElements. In the database representation of a template, a style is represented by a ModifiableObject structure of type “Style”, the properties of which point to sub-style ModifiableObject structures, corresponding to the Alignment, Background, Fill, . . . sub-structures of the ETV-BIF Style structure. Each sub-style ModifiableObject structure has the appropriate type, and associated ModifiableProperty structures representing the values in the sub-style may contain literal values or may point to further ModifiableObject structures. A Style structure may be incomplete in the source code file, that is, some of the optional attributes may be unspecified. This signals that any TVScript-BIF object that references the incomplete Style inherits the unspecified portions of the Style structure from its parent object.
Table resources are represented in the database by ModifiableObject structures. A table resource can be contained within a Partition or a ResourceArchive object. The ModifiableObject structure corresponding to a table resource has a ParentModifiableObject value that identifies the ModifiableObject structure corresponding to the Partition or ResourceArchive object that contains the table resource.
Table resources in a TVScript-BIF application correspond to data tables in the ETV-BIF binary output. A Table resource has a corresponding data table definition in the TVScript-BIF source code for the resource. A data table is represented in the database by a series of structures. A parent ModifiableObject structure represents the table resource, with a Type field value of “Table”. This parent ModifiableObject structure has one or more child ModifiableObject structures representing the columns of the table. The parent structure also has one or more child ModifiableObject structures representing the rows, which in turn have one or more child ModifiableObject structures representing the cells, the values of which are represented by ModifiableProperty structures. The filename of the data file is stored in a ModifiableProperty structure that refers to the ModifiableObject structure for the resource. Palettes are a special case of a data table, in which the Type field of the ModifiableObject structure for the palette has a value of “Palette”.
Other resources defined in the application source code are also represented by ModifiableObject structures. For example, an Image resource is represented by a ModifiableObject structure that has a Name field that contains the logical name of the resource and a Type field value of “Image”. The URI that specifies the source for the resource is represented by a ModifiableProperty structure that references the ModifiableObject structure for the resource, has a Name field value of “Source”, and has a Type field value of “URI”. The Value field value of the ModifiableProperty structure is the URI for the image resource.
In an alternative embodiment of the inventive system, addition information related to the modification may be specified at this step. In an alternative embodiment, a label for the attribute being modified might be specified, with the label being presented when the modification is available for selection. In an alternative embodiment, a rule might be specified as to whether the annotation is required or optional. In an alternative embodiment, a hint might be specified to display to the editor when the modification is being performed.
Once an attribute is selected to modify, at a further step 1050 a constraint is specified on the modification. At least one implicit constraint is specified for each modification, namely that the replacement value be of the same type as the original value in the ModifiableProperty structure. Additional constraints may be applied that depend on the type of the value. For example, if the value of the attribute to be modified is a string, the constraint might be a limit on the number of characters in the replacement string. As further examples, if the attribute to be modified is a string, the constraint might be that the replacement string is one of a list of possible strings, or that the replacement string matches a regular expression. If the value of the attribute to be modified is an integer, the constraint might be that the replacement value fall within a given range. A value range might be bounded (have both lower and upper bounds) or half-bounded (have either a lower or an upper bound but not both). A constraint might be specified as a combination of other constraints; that is, a constraint might be that the replacement value satisfies all of a given set of constraints, or alternatively a constraint might be that the replacement value satisfies any one of a given set of constraints.
After a constraint is specified, at a further step 1060 a decision is made whether there are more constraints for the modification of the selected application attribute. If so, step 1050 is repeated. If not, at a further step 1070 a decision is made whether there are more application attributes to be modified. If so, step 1040 is repeated. If not, at a further step 1080 the modifications and constraints are stored in a database. At a further step 1090, a template structure is created in a database, and the structures representing the application, the modifications, and the constraints are associated with the template structure.
The steps of flow chart 1000 may be performed by a single user or by multiple users working consecutively or concurrently.
In an exemplary implementation of the inventive system, a modification is stored in the database in a ModificationAction structure. A ModificationAction structure contains an ID field that denotes the unique identifier for this ModificationAction structure among all ModificationAction structures. A ModificationAction structure also contains a TemplateID field that denotes the Template to which the modification is associated; a ModifiableObjectID field that denotes the identifier of the ModifiableObject structure associated with the attribute being modified; and a ModifiablePropertyID field that denotes the identifier of the ModifiableProperty structure whose value is to be modified. In an alternative exemplary embodiment, the ModificationAction structure contains a Status field that denotes the status of the modification, the value of which might be one of “pending”, “completed”, or “reviewed”. The interpretation of the Status field value is that “pending” signifies that the modification has not been performed; “completed” signifies that the modification has been performed but not reviewed; and “reviewed” signifies that the modification has been performed and reviewed. In this alternative embodiment, the editing of an application template copy is not completed until all ModificationAction structures have a Status field value of “reviewed”. In a further alternative exemplary embodiment of the inventive system, a ModificationAction structure might have an additional Rule field that denotes a rule for the modification, the value of which will be one of “required”, “optional”, or “forbidden”, where a value of “required” signifies that the modification must be performed when modifying the template to create a new application, “optional” signifies that the modification may be performed when modifying the template, and “forbidden” signifies that in this copy of the template, the modification has been disallowed. In a further alternative exemplary embodiment of the inventive system, a ModificationAction structure might have a Sequence field that denotes the sequential order in which the modifications will be presented during the template editing process.
In an exemplary implementation of the inventive system, a constraint is stored in the database using one or more ModificationConstraint structures. A ModificationConstraint structure contains an ID field that denotes the unique identifier for this ModificationConstraint structure among all ModificationConstraint structures. A ModificationConstraint structure also contains a TemplateID field that denotes the Template to which the modification constraint is associated; a ModificationActionID field that denotes the identifier of the ModificationAction structure associated with the constraint; a ModificationConstraintID field that optionally denotes the identifier of a ModificationConstraint structure associated with the constraint; a Type field that denotes the type of the constraint, and a Value field that denotes the value associated with the constraint type. A simple constraint may apply directly to a modification action. For example, if the maximum number of characters allowed in a string is 6, the constraint is encoded with a Type field value of “maximum length” and a Value field value of “6”. A more complex constraint may involve one or more subordinate ModificationConstraint structures. For example, a constraint that specifies the valid range of an integer modification value would be encoded by a first ModificationConstraint structure with a Type field value of “range” and an empty Value field; a second ModificationConstraint structure with a ModificationConstraintID field value that references the first ModificationConstraint structure, a Type field value of “minimum”, and a Value field value listing the minimum end of the range; and a third ModificationConstraint structure with a ModificationConstraintID field value that references the first ModificationConstraint structure, a Type field value of “maximum”, and a Value field value listing the maximum end of the range. Additional constraint types include for example type “match” which signals that a modification value matching the Value field is acceptable; type “file extension” that signals that any file with the corresponding extension type given by the Value field is acceptable; type “regular expression” that signals that any string matching the regular expression given by the Value is acceptable; logical negation type “not” that signals that for the ModificationConstraint to be met, the ModificationConstraint structure that references the negation ModificationConstraint must not be met; and logical combination types “and” and “or” which signal a conjunction or disjunction, respectively, among the ModificationConstraint structures that reference the logical combination ModificationConstraint. Thus, for example, if a constraint requires that a modification value can be one of a list of three possible values, the constraint could be encoded with a logical combination type “or” ModificationConstraint structure and three type “match” ModificationConstraint structures that reference the logical combination type “or” ModificationConstraint structure.
The steps described above in reference to
Database structure manipulation layer 1130 provides for basic manipulations of the structures stored in the database. For example, this layer provides application programming interface (API) functions to create, modify, copy, and delete database structures and sets of structures. This API is used by functional modules 1140 to perform operations that are specific to the task being performed. For example, a functional module might perform the operation of reading in application source code and creating an in-memory representation, then converting the in-memory representation to an equivalent set of database structures. The activity of functional modules 1140 is controlled through a further API that can be accessed by user interface layer 1150, which also utilizes the API provided by database structure manipulation layer 1130. User interface functionality may be provided by software specifically coded for this purpose, by a web browser interacting with a web services interface, or by other means well known in the art.
The divisions depicted in
Once a template is created, an updated version of the original application can be created.
The steps of flow chart 1200 may be performed by a single user or by multiple users working consecutively or concurrently.
Once all modifications have been performed on a template copy, a review step might be performed to verify that all modifications meet an external set of criteria not embodied within the constraints in the template.
The operations described above in reference to
Once all modifications are made to a copy of an application template, application generation component 180 is used to create an executable version of the modified application. The modified copy of the application template is retrieved from a database and used to create an in-memory representation of the application. The in-memory representation is used to generate the executable version of the application. The generation process may proceed by using the in-memory representation to create one or more source code files that reflect the content of the application template, and then use an external compiler tool to generation an executable version of the application from the source code. Alternatively, the in-memory representation may used to directly generate an executable version of the application.
In an exemplary implementation of the inventive system, the organization of the functionality of application generation component 180 also follows the software layer model 1100 depicted in
The term “computer” is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term “computer” includes PCs, servers, mobile telephone, personal digital assistants and many other devices.
The methods described herein may be performed by software in machine readable form on a storage medium. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
The description acknowledges that software can be a valuable, separately tradable commodity. The description is intended to encompass software, which runs on or controls ‘dumb’ or standard hardware, to carry out the desired functions. It is also intended to encompass software which ‘describes’ or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.
While the preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the scope of the invention is not limited by the disclosure of the preferred embodiment. Instead, the invention should be determined entirely by reference to the claims that follow.
