Patent Application
20060253830
The present invention relates to metadata driven application building, and more particularly to a method and system for guiding application building using business constraint metadata that reflect business requirements.
Software application development tools are known that enable a developer to rapidly develop a highly targeted application specific to a customer's needs, or to be able to rapidly customize an existing application. Some application development tools use a framework such as J2EE or .NET, to include component libraries for use in a software development environment, such as JBuilder or VisualC++ to allow a developer to create component-based software applications.
Such software development tools typically maintain a set of component libraries, where each component in the library is represented by its metadata that refers to a pre-compiled procedure that can be reused by different applications. Example types of components include UI components, such as a form, report, or pull-down menu, and business objects. Along with the component libraries, conventional software development tools may also include an application builder engine and a runtime engine. The application builder engine enables a developer to access to the components when building an application and to specify the sequence of how the selected components will be invoked during runtime. Some application builder engines may even guide the user through a component definition process to enable the user to develop a specific instance of a type of component. Once the application definition is complete, the tool stores the application as metadata that refers to the storage locations of the procedures of the corresponding components. At runtime, the application is interpreted by the runtime engine, which invokes the components identified by the metadata in the specified sequence. For example, during execution of the application, one or more components may be invoked that generate a display page requesting the user to enter data into form fields.
Although conventional component-based software development tools may provide advantages over writing actual computer code when developing and implementing the functionality of applications, conventional software development tools do have disadvantages. One disadvantage is that conventional software development tools leave it up to the developer to decide what components are selected for building the application and the sequence that the components are assembled. This means that although some software development tools may allow for integrating and linking to components of the application by checking the language syntax and conformance to the component APIs, conventional tools do not have any knowledge of the business requirements, rules and constraints for which the application is being developed. The result could be an application that has been assembled from selected components, but may not be functionally correct or complete.
Accordingly, what is needed is an improved software development tool for guiding the assembly and creation of new applications using business constraint metadata that incorporates business domain knowledge and application business requirements. The present invention addresses such a need.
The present invention provides a method and system for guiding application building using a registry of components, wherein the components are stored as metadata having a reference to one or more saved software procedures that are used to build custom applications. Aspects of the present invention include allowing a user to define an application definition based on business requirements, wherein the application definition comprises a process flow defining a series of process steps, user actions, and domain objects. Each process step identifies one or more domain objects from the business requirements, and each domain object is represented by one or more components in the component registry. A restricted set of components is then created using the components from the component registry that represent the domain objects specified in the application definition. During application building, only access to the restricted set of components is allowed.
According to the method and system disclosed herein, the present invention provides an application design tool that improves the correctness of the application by imposing constraints on the components available to build the application. This is in contrast to conventional software development tools that make all components available for selection by the user during application design, which may result in a programmatically correct, but functionally error laden application. Because business constraint metadata is used to confine the application building, the number of assembly errors committed by the developer may be reduced, which may result in less runtime errors.
The present invention relates to a method and system for guiding application building using business constraint metadata. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
The present invention provides an application design tool for guiding component-based application building that includes a registry of components represented as metadata that are used to build custom applications. According to the present invention, application design data that includes the registry component metadata is extended to include constraint metadata that includes user-specified information about the business domain, application requirements, and customizable rules representing a business solution for a particular custom application. These constraints are then used to guide the developer through the creation and assembly of the custom application by restricting what components are available to the developer for selection.
According to the preferred embodiment, in addition to including a design module 14 for building applications from stored components 19 and a runtime module 16 for executing the components 19 at runtime, the application design tool 10 further includes the application feature design module 12 that allows the user to define an application definition 29 based on business requirements for a custom application. In a preferred embodiment, the application definition 29 comprises a process flow 30 defining a series of process steps, user actions 32, and domain objects 34. More particularly, from a particular set of business requirements representing some business solution, the user defines the process flow 30 for the solution, the action or actions 32 to be performed in each step in the process and the sequence of those actions, and one or more business objects 34 that will be the recipients of the actions 32.
According to a preferred embodiment, the actions 32 may be defined either as role-based or task-based. Role-based actions are defined by identifying the role that will perform the action, such as a submitter, a reconciler, or an approver, for example. Task-based actions are defined by identifying the task to be performed, such as performing a product search, or submitting changes to an approver, for instance.
Domain objects 34 are preferably represented by one or more components 19 in the component registry 18. For example, in a human resources (HR) application, a business object may be an “employee”, and the HR application should have the ability change an employee's salary or position. In this example, the employee object may map to several components 19, such as a person, a role or position, and the relationship between the person and the role. Besides process flow 30, the user actions 32, and domain objects 34, the application definition 29 may also include other information that may be based on customizable rules, and business domain knowledge, for example.
In a preferred embodiment, the components 19 are implemented as object-oriented class templates that are stored as metadata definitions referencing one or more saved software procedures 21 that are invoked at runtime. The software procedures 21 for the components 19 may be stored in a database 22. The component registry 18 may include various types of components 19. Example types of components 19 include 1) user interface components, 2) user interface controls, 3) process steps, 4) user actions, 5) business objects, 6) validators, and 7) business logic rules. User interface components include items that can be displayed in a user interface such as forms, screens, and pages, etc. User interface controls include items that can be displayed on a user interface component, such as buttons, form fields, pull-down lists, etc. Each control may include default renderers and a control property sheet. Process steps are steps that can be performed in the business. User actions are actions that can be performed in the process steps. Business objects are logical groupings of a set of data attributes of a business. A set of business objects may be used to define the business. The behavior of each business object is defined by set of attributes associated with the business object.
Validators are algorithms that can be attached to other components for automatically validating values entered into a form field when the finished application incorporating the form field is executed. An example of a validator function is checking that a value entered onto a data field is entered in mm-dd-yyyy format, for instance. Thus, the metadata for at least a portion of the components 19 may identify the validator(s) associated with the component 19 and the metadata for the requirements provides further constraint by which a validator, if any, should be attached, such that when the component 19 is placed into an application, the validator associated with the component 19 is also automatically added to the application, thus preventing the developer from missing the step during application building.
After the application definition 29 is completed, the design module 14 creates a set of constraint metadata 28 from the application definition 29. The constraint metadata 28 is then applied to the domain editor 20 during assembly of the application to restrict which components 19 from the component registry 18 the domain editor 20 makes available to the user. That is, the constraint metadata 28 instructs the domain editor 20 to only make available those components in the component registry 18 that represent the domain objects specified in the application definition 29 for the custom application. By creating a restricted set of components 36 and only allowing access to the restricted set of components 36 during application building, the application design tool 10 improves the correctness of the application by imposing constraints on the components available to build the application. This is in contrast to conventional software development tools that make all components available for selection by the user during application design, which may result in a programmatically correct, but functionally error laden application.
After the assembly of the application using the restricted set of components 36 is complete, the application may be stored as runtime metadata 24 that specifies the components 36 selected by the user and the order the components 36 are to be invoked. When a user wishes to run the application, the user invokes the runtime engine 26, and specifies the runtime data 24 for the desired application. The runtime engine 26 reads the metadata in the runtime data 24 and invokes the specified components 36 in the order specified. Because business constraints metadata 28 were used to confine the application building, the number of assembly errors committed by the developer is significantly reduced, thereby resulting in a more robust and error-free custom application.
In a preferred embodiment, a vendor of the application design tool 10 designs and creates the component registry 18 during a component design phase and bundles the component registry 18 with the application design tool 10. In a preferred embodiment, the components 19 are designed to be used in a wide range of businesses applications, and the application design tool 10 is made commercially available to customers for use in designing and building custom applications. Although the application design tool 10 may be installed and executed on any type of computer such as a PC or workstation, in a preferred embodiment, the application design tool 10 is installed on server and made available to users over a network, such as an Intranet or the Internet. Elements of the application design tool 10 may be stored and executed on the same or different computers.
In a preferred embodiment, the application design tool 10 is provided to various customers, such as large and small business enterprises, who then define their own business constraints and use those constraints when creating their own component-based custom applications. Although the tool 10 has been described as being operated by “a user”, in a preferred embodiment, the tool 10 may actually be used by different people, in a customer's organization, as described below.
In step 102 an application loader 38 (
During an application building phase, the domain editor 20 of the application design module 14 is invoked in step 104 by another user, preferably by an application developer of the customer. Steps 102 and 104 are order independent in that the constraint metadata 28 may be generated either at the conclusion of the application feature design phase, or at the beginning of the application building phase. In step 106, the domain editor 20 displays a UI workspace that organizes the customer's applications and guides the application developer in selecting components 36 to build the application per the application definition 29 defined by the application designer.
Referring again to
As an example, assume the application developer is building a form authoring flow. The application developer may begin by instantiating the form by browsing for form-type components displayed in the restricted set of components 36. The application developer may then add field controls by selecting control-type components. The application developer may then select and attach validation-type components for the fields. Finally, the application developer may select and attach an initialization rule to a control to specify a rule for parameter data.
In step 112, the domain editor 20 reads the metadata rules for the selected components 36 and assembles the selected components as specified. In a preferred embodiment, steps 108-112 are repeated for each process step defined in the application definition. In step 114, the domain editor 20 validates the assembly and functionality of the application using the constraint metadata 28 to validate the functionality of the assembled steps. For example, when building a form that has ten fields, the domain editor 20 checks that all ten fields were selected by the application builder. The validation results may be displayed in the diagnostic view 208 (
After the functionality of the custom application is validated, the custom application is deployed by the customer for use by end users in step 116. The end-users then access the application runtime module 16 and invoke the application in step 118, which is then executed by the execution engine 26.
A method and system for guiding application building using business constraint metadata has been disclosed. The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
