User-interface architecture for manipulating business models

CROSS-REFERENCE TO RELATED APPLICATIONS

Not Applicable.

BACKGROUND

Background and Relevant Art

Computer systems and related technology affect many aspects of daily life in society. Computer systems commonly perform a great variety of tasks (e.g., word processing, scheduling, database management, etc.) that aid in work and business productivity. Such tasks are generally accomplished by processing functions within software applications.

Generally, software application developers design software applications to provide a certain type of functionality. For example, some applications are tailored to word processing; other applications are tailored to data management. Often, users of such software applications desire to tailor the functionality of the application to their specific needs. For example, a user of a data management application may desire to add form processing functionality that was not included in the original application. Such a user could, optionally, pay for a systems integrator to come to the user's office and reconfigure or extend the application to include the desired functionality. Alternatively, if the user's company was large enough to have an IT department, the user could ask his or her IT manager to code in the additional functionality. This may, of course, require a great deal of time from an already busy IT manager. As a last option, the user may opt to write the extension themselves, assuming the user has sufficient knowledge and available time to dedicate to such a task.

In addition to the resource requirements, allowing users to create their own application extensions can be problematic. Many users have neither the time nor the savvy to write a fully functionally application extension. Furthermore, once completed, the extension may only be configured to work on that particular user's computer system. This creates portability problems if other users want to use the extension. For these reasons, many software developers have attempted to allow users to modify their applications without having to write code.

To accomplish this, the developer can do at least one of two things: 1) implement a code generator, where a user inputs or selects a set of rules to be followed when certain actions are performed and the code generator generates the corresponding code for the application extension, or 2) implement a model engine approach where a model of the extension is turned into an object tree such that each object corresponds to the model and the model engine is able to execute the object tree.

The first approach (code generation) has several limitations. For example, it may be difficult to determine which portion of generated code relates to which part of the model. Thus, if a user wanted to use only part of the extension's functionality, it may be difficult to determine which portion to use. Furthermore, when changes are made to the model, the code for the entire extension has to be regenerated which may introduce undesirable processing delays. The second approach (model engine), although widely implemented, is still of limited use. Generally, model engines are only used for relatively simple things such as modeling workflows and corporate business policies. Providing users with the ability to extend and modify applications without using code has proved to be a difficult task.

BRIEF SUMMARY

The present invention extends to methods, systems, and computer program products of a user-interface architecture for manipulating business models. In some embodiments, a user-interface architecture is used to create a commingled data-centric application. The user-interface architecture receives user-entered data commands for creating a data model including one or more data fields and any appropriate relationships between fields or groups of fields. The user-interface architecture receives user-entered rule commands indicating a business logic rule is to be associated with one or more selected data fields and/or relationships among the one or more data fields and relationships. The user-interface architecture converts the user-entered rule command into a meta-data format that can be associated with the one or more selected data fields and/or relationships in a commingled data-centric application. Thus, the user-interface architecture abstracts the meta-data format from the user and thereby relieves the user from having to know the meta-data format. The user-interface architecture associates the meta-data format of the business logic rule with the one or more selected data fields and/or relationships to commingle the data model with the business logic rule within a commingled data-centric application.

In other embodiments, a user-interface architecture is used to create a business related software application. The user-interface architecture receives user-entered commands for creating a new model, including user-entered commands for creating one or more data fields and appropriate relationships. Existing data models are searched for any relevant models having at least a specified level of commonality with the one or more data fields and/or relationships. The user-interface architecture identifies one or more relevant models having at least the specified level of commonality with the one or more data fields and/or relationships.

The user-interface architecture presents a list of the identified one or more relevant models at the display device. The user-interface architecture receives a user-entered selection selecting one of the relevant models. The user-interface architecture automatically adds one or more additional fields and/or appropriate relationships from the selected relevant model to the new model to automatically provide the user with the functionality of an existing business related software application. Thus, the user is relieved from having to manually create the functionality.

In additional embodiments, a user-interface architecture is used to extend a business related software application. The user-interface architecture accesses a current model for a business related software application. The model is configured to provide a first business related function.

The user-interface architecture receives user-entered criteria indicative of a desire to extend the functionality of the business related software application by adding a further second business related function to the business related software application. Existing models are searched for any relevant models having at least a specified level of commonality with the received criteria. The user-interface architecture identifies one or more relevant models having at least the specified level of commonality with the received criteria. The identified relevant models have an increased likelihood of being configured to provide the second business related function relative to other unidentified data models accessible to the user-interface architecture.

The user-interface architecture presents a list of the identified one or more relevant models at the display device. The user-interface architecture receives a user-entered selection selecting one of the relevant models. The user-interface architecture receives a user-entered connection command indicating how the selected relevant model is to be connected to the current model to add the second business related function to the business related software application. The user-interface architecture connects the selected relevant model to the current model in accordance with the user-entered connection commands to add the second business related function to the business related software application.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

<figref idref="DRAWINGS">FIG. 1A</figref> illustrates an example computer user-interface architecture that facilitates manipulating business models.

<figref idref="DRAWINGS">FIG. 1B</figref> illustrates an example data format for a business model.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flowchart of a method for using a user-interface architecture to create a commingled data-centric application.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates a flowchart of a method for using a user-interface architecture to create a business related software application.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates a flowchart of a method for using a user-interface architecture to extend a business related software application.

<figref idref="DRAWINGS">FIGS. 5A through 5C</figref> illustrate an example portion of a presented user-interface that can receive input for creating a commingled data-centric software application.

<figref idref="DRAWINGS">FIGS. 6A through 6C</figref> illustrate an example portion of a presented user-interface that assists a user in locating a model that corresponds to an entered model.

<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> illustrate an example portion of a presented user-interface that assists a user in extending application functionality.

DETAILED DESCRIPTION

The present invention extends to methods, systems, and computer program products of a user-interface architecture for manipulating business models. In some embodiments, a user-interface architecture is used to create a commingled data-centric application. The user-interface architecture receives user-entered data commands for creating a data model including one or more data fields and any appropriate relationships between fields or groups of fields. The user-interface architecture receives user-entered rule commands indicating a business logic rule is to be associated with one or more selected data fields and/or relationships among the one or more data fields and relationships. The user-interface architecture converts the user-entered rule command into a meta-data format that can be associated with the one or more selected data fields and/or relationships in a commingled data-centric application. Thus, the user-interface architecture abstracts the meta-data format from the user and thereby relieves the user from having to know the meta-data format. The user-interface architecture associates the meta-data format of the business logic rule with the one or more selected data fields and/or relationships to commingle the data model with the business logic rule within a commingled data-centric application.

In other embodiments, a user-interface architecture is used to create a business related software application. The user-interface architecture receives user-entered commands for creating a new model, including user-entered commands for creating one or more data fields and appropriate relationships. Existing data models are searched for any relevant models having at least a specified level of commonality with the one or more data fields and/or relationships. The user-interface architecture identifies one or more relevant models having at least the specified level of commonality with the one or more data fields and/or relationships.

The user-interface architecture presents a list of the identified one or more relevant models at the display device. The user-interface architecture receives a user-entered selection selecting one of the relevant models. The user-interface architecture automatically adds one or more additional fields and/or appropriate relationships from the selected relevant model to the new model to automatically provide the user with the functionality of an existing business related software application. Thus, the user is relieved from having to manually create the functionality.

In additional embodiments, a user-interface architecture is used to extend a business related software application. The user-interface architecture accesses a current model for a business related software application. The model is configured to provide a first business related function.

The user-interface architecture receives user-entered criteria indicative of a desire to extend the functionality of the business related software application by adding a further second business related function to the business related software application. Existing models are searched for any relevant models having at least a specified level of commonality with the received criteria. The user-interface architecture identifies one or more relevant models having at least the specified level of commonality with the received criteria. The identified relevant models have an increased likelihood of being configured to provide the second business related function relative to other unidentified data models accessible to the user-interface architecture.

The user-interface architecture presents a list of the identified one or more relevant models at the display device. The user-interface architecture receives a user-entered selection selecting one of the relevant models. The user-interface architecture receives a user-entered connection command indicating how the selected relevant model is to be connected to the current model to add the second business related function to the business related software application. The user-interface architecture connects the selected relevant model to the current model in accordance with the user-entered connection commands to add the second business related function to the business related software application.

Embodiments of the present invention may comprise a special purpose or general-purpose computer including computer hardware, as discussed in greater detail below. Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, computer-readable media can comprise physical (or recordable type) computer-readable storage media, such as, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

In this description and in the following claims, a “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, by way of example, and not limitation, computer-readable media can also comprise a network or data links which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example computer user-interface architecture <b>100</b> that facilitates manipulating business models. As depicted, computer user-interface architecture <b>100</b> includes user-interface module <b>121</b>, model manipulation module <b>122</b>, data modeler <b>123</b>, rule modeler <b>124</b>, search module <b>125</b>, and model store <b>126</b>.

Generally, user-interface module <b>121</b> can provide a (e.g., graphical) user-interface to a user for manipulating models stored in model store <b>126</b>. User-interface module <b>121</b> is configured to receive input data from input devices (e.g., key board, mouse, touch surface, etc.) connect to user-interface architecture <b>100</b>. Input can include commands for creating, editing, deleting, modifying, selecting, connecting, extending, and searching for data models, data schemas, and business related software application functionality present in the models stored in model store <b>126</b>. For example user-interface module <b>121</b> can receive user input for creating, manipulating, etc, any of the models <b>101</b>A, <b>101</b>B, <b>101</b>C, etc.

User-interface module <b>121</b> is also configured to provide output data to output devices (e.g., a video display device, speakers, printers, etc.) connected to user-interface architecture <b>100</b>. Output data can include data models, data schemas, lists of models, as well as other results responsive to received input data.

In response to receiving input data, user-interface module <b>121</b> can identify other modules that are to receive and process the input data. For example, creating, editing, deleting, modifying, selecting, connecting, and extending commands for a specified model can be transferred to model manipulation module <b>122</b>. User-interface module <b>121</b> can transfer various search criteria to search module <b>125</b>. User-interface module <b>121</b> can also filer portions of received input data directed to one module for transfer to another module. For example, user-interface module <b>121</b> can identify properties (e.g., field names) included in data schema creation input and transfer those identified properties to search module <b>125</b>.

User-interface <b>121</b> can be further configured to receive input data using common metaphors more likely to be known to a user, such as, for example, commands and syntax of commercially available software applications. User-interface <b>121</b> can transfer received input to other modules that in turn convert, translate, etc., the input data into metadata or other appropriate data formats of models representing business related functionality. User-interface <b>121</b> can also be configured to receive output data and present it using the common metaphors.

Model manipulation module <b>122</b> is configured to implement user-entered commands for creating, editing, deleting, modifying, selecting, connecting, and extending models, schemas, and business related application functionality. User-interface <b>121</b> can present an interface for receiving input data in format that is more familiar to a user. For example, user-interface <b>121</b> can present a user-interface common to known spreadsheet or database application. User-interface <b>121</b> can receive input data in the more familiar format and then transfer the input data to model manipulation module <b>122</b>. Model manipulation model <b>122</b> can translate, modify, convert, etc. the input data into an appropriate format for use with models stored in model store <b>126</b>. Accordingly, user-interface module <b>121</b> abstracts the underlying (and potentially more complex) modeling commands and data formats for manipulating models (e.g., stored in model store <b>126</b>) from the user.

Search model <b>125</b> is configured to receive search criteria and return a list of models that have a specified level of commonality with the search criteria. For example, search module <b>125</b> can receive search criteria from user-interface module <b>121</b>. Search module <b>125</b> can search model store <b>126</b> for any models that have a specified level of commonality with the search criteria. Search criteria can include data schema properties and data schema property values. Search criteria can be from an existing model or for a model being created.

A specified level of commonality is configurable. The specified level of commonality can be selected to balance the number of results that are returned form a search. A level of commonality can specify how close the properties/property values of a model are to search criteria. An increased level of commonality corresponds to a specified level of commonality that is closer to the search criteria. On the other hand, an decreased level of commonality corresponds to specified level of commonality that is further form the search criteria

The amount of commonality can be increased to cause a search to return fewer models, but models that are more likely to be appropriate. The amount of commonality can be decreased to cause a search to return more models, but possibly include models that are less likely to be appropriate. In some embodiments, models have the specified level of commonality with search terms when the properties of the model exactly match the search terms. An exact match may be the highest level of commonality. Other specified levels of commonality that allow some amount of variability in the matching, can be lesser levels of commonality.

Model store <b>126</b> can store a plurality of models including models <b>101</b>A, <b>101</b>B, and <b>101</b>C. A series of two vertical periods (a vertical ellipsis) represents that other models can be stored in model store <b>106</b> before, between, and after models <b>101</b>A, <b>101</b>B, and <b>101</b>C.

In some embodiments, models are commingled data-centric application models that include a data model for a data store and a business logic model for interacting with data entities contained in the data store. Data models can also include relationships between different parts of the data model, such as, for example, tables in an entity and hints about how an entity is to related to other entities. The business logic model is associated with an index tree of one or more business logic rules represented in the business logic model. Each business logic rule in the index tree identifies at least one data entity in the data store that is affected by the business logic rule.

Data-centric applications can be used to incorporate data into a form, display data in a graph or a chart, categorize and/or label different portions of the data, develop workflows based on the data, or any other data-related task. For example, commingled data models can be processed to implement workflow applications related purchasing, inventory management, manufacturing control, etc. Generally, a data store can be any data source accessible user-interface architecture <b>100</b>, such as, for example, a relational database, a Web service, an infofeed, a Windows® SharePoint™ Services site or list, etc. Thus, accessed and processed data entities can vary accordingly to the type of data store. For example, data entities can include relational data (e.g., values of data fields from related data tables), services, business objects, lists, Web parts, etc

<figref idref="DRAWINGS">FIG. 1B</figref> illustrates an example data format business model <b>101</b>A. Model <b>101</b>A includes data model <b>103</b>, business logic model <b>105</b>, and data views <b>113</b>. Data model <b>103</b> can include a schema representing the data formats for tables, fields and properties of data store <b>117</b>, including data element <b>104</b>. Data element <b>104</b> can represent, for example, the data format of data entity <b>117</b>A (e.g., a value of a data base field).

Business logic model <b>105</b> can include one or more rules including rule <b>106</b>. Rules <b>106</b> includes a reference to event <b>107</b> (e.g., an input event), a condition <b>108</b> that is to be evaluated when event <b>107</b> occurs, and an action <b>109</b> that is to be implemented when condition <b>108</b> is satisfied. Condition <b>108</b> further includes binding <b>113</b> to data element <b>104</b> and expression <b>116</b>.

Rules can relate to any number of different things including: data validation (rules that control software application updates), data integrity (rules that control what happens after software updates), synchronized updates, data snapshots, audits and logs, form flow, user authorization (at row, column, and action level), task flow (i.e. flow of a work process), conditional formatting that controls what users see in a form, based on data or workflow state, policies that determine allowable discretionary actions and automatic actions based on data or workflow state or other means of controlling functionality of a data-centric software application.

Rules can be of a variety of different formats. In some embodiments, a rule includes a data binding to a data entity, a constraint (e.g., an expression over the data entity), and an action. A binding might be of the format: &lt;bindingid, friendly name, URI, [objected], filedref|elementref|recordref&gt;. A namespace resolver can resolve references in a binding to permit the execution engine to access data from a specified data store. When an accessed data entity (e.g., a field of a relational database) satisfies the constraint (e.g., is less than or equal to a specified value), the action is performed (e.g., allowing a purchase order to be created).

Rules can be used to implement business logic for various types of data-centric application behavior. Accordingly, a portion of business logic can include rules to guard and/or impose data quality, such as, for example, validation within the scope of a record, a view or a workflow, integrity requiring consequential actions after some data is changed, and/or synchronization updates involving copying of data from one table to another. Business logic can also include rules to conditionally format a form's user interface (UI). For example, depending on the state of the data, add, show, and/or hide elements in the form, format based on validation and/or authorization rules. Business logic can also include rules to enable navigation and filtering in a form, including cascading choices and filtered lookups, and conditionally enabling and/or showing queries and views in a form. Business logic can also include rules on form and task flow (i.e., how forms are used in sequence or in a set, based on state rules).

Furthermore, rules can be used to invoke authorization policies (e.g. row and column level policies based on user and data state), offline policies (e.g. restrictions on what can be done offline), referential integrity (e.g. ensuring there are no orphan processes, related entries are cascade deleted, etc.) and/or any other form of application behavior.

Business logic can include user-created rules. Furthermore, these rules may be propagated throughout a data-centric application. In some embodiments, business logic may be categorized in the form of declarative macros. Declarative macros, as used herein, are portions of business logic. For example, if a user creates a form for a data-centric application, part of the business logic for the form may be to highlight boxes that have not been filled out and validate the data in the boxes that have been filled out. Accordingly, a declarative macro can include instructions (e.g., XML) for the data-centric application to highlight un-filled boxes. Another declarative macro can include instructions (e.g., also XML) for the data-centric application to validate the data in filled boxes.

Declarative macros can be associated with one or more information items via one or more data organization items. Information items, for example, may include data, forms, data plus forms, form region, task, workflow, user or role. Organization items, for example, may include forms, data structures, workflow descriptions or organization structures. Thus, in some embodiments, declarative macros may be associated with data and/or tasks, for example, via data structures and/or workflow descriptions. Accordingly, business logic can be metadata represented in XML instructions.

The following XML example, represents metadata of a declarative macro:

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>&lt;DeclartiveMacro Type = “Validation”&gt;</entry></row><row><entry /><entry> &lt;Source&gt;</entry></row><row><entry /><entry>  &lt;Element&gt;OrderDate&lt;/Element&gt;</entry></row><row><entry /><entry>  &lt;Element&gt;PromiseDate&lt;/Element&gt;</entry></row><row><entry /><entry> &lt;/Source&gt;</entry></row><row><entry /><entry> &lt;Scope&gt;global&lt;/Scope&gt;</entry></row><row><entry /><entry> &lt;Constraint&gt;</entry></row><row><entry /><entry>  &lt;Expression PatternType=“MinimumDifference”&gt;</entry></row><row><entry /><entry>   &lt;Arguments First= “DeliveryDate” Second=“OrderDate”</entry></row><row><entry /><entry>   Difference =“5”/&gt;</entry></row><row><entry /><entry>  &lt;/Expression&gt;</entry></row><row><entry /><entry>  &lt;Environment&gt;MacroEvaluator&lt;/Environemt&gt;</entry></row><row><entry /><entry> &lt;/Constraint&gt;</entry></row><row><entry /><entry> &lt;OnFalse&gt;</entry></row><row><entry /><entry>  &lt;Action PatternType=“MinimumDifferenceDenyChange”/&gt;</entry></row><row><entry /><entry> &lt;/OnFalse&gt;</entry></row><row><entry /><entry>&lt;/DeclartiveMacro&gt;</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Execution of the XML example representing the declarative macro insures that at a Delivery Date is at least 5 days after an Order Date otherwise entry of the a corresponding order is denied. Data within the Source Tag indicates data that is being guarded and implies the data change and forum events are relevant. The scope tag indicates that the declarative macro applies to data irrespective of whether the change happens via a particular form or through direct data update. The environment tag declares whether other modules, besides a macro evaluator, are needed to evaluate the constraint. Actions can include built in or custom actions.

Rule index <b>111</b> includes one or more entries that map events to corresponding rules. For example, entry <b>112</b> maps event <b>107</b> to rule <b>106</b>.

Data views <b>113</b> includes one or more views to subsets of data from data store <b>117</b>.

Each of data model <b>103</b>, business logic model <b>105</b>, and data views can be represented in metadata <b>102</b> such that no code is required to execute model <b>101</b>A.

Accordingly, since data schema and views defining data formats and data access can also be represented in metadata, representing declarative macros in metadata, such as, for example, XML, permits the development of codeless data-centric applications. Data schema can include basic data structures representing formats for lists/tables, fields, properties of files, nested data, relationships keyed on multi-columns, enforced relationships, enforced editing, cascading deletes, etc. Generally, a view indicates a subset of data store sorted and/or displayed in a particular way. Views can include joins, such as, for example, projection of multiple columns from related lists, updates on related records or records sets, such as, for example, concurrency control of update patterns by multiple users (a lightweight check-out mechanism), reference to external data, such as, for example, binding and synching lists to external data sources. For example, binding fields of one database sources in another database. Accordingly, data-centric applications can be constructed essentially entirely in metadata significantly simplifying application design.

Returning to <figref idref="DRAWINGS">FIG. 1A</figref>, data modeler <b>123</b> can be configured to manipulate data models, including data models similar to data model <b>103</b>. Rule modeler <b>124</b> can be configured to manipulate rules, similar to those included in business logic model <b>105</b>. Accordingly, the modules of user-interface architecture <b>100</b> (including user-interface module <b>121</b>, model manipulation module <b>122</b>, data modeler <b>123</b> and rule modeler <b>124</b>) can interoperate to identify, create, delete, modify, connect together, etc. models of business related software applications, including applications represented in commingled data-centric application models.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flowchart of a method <b>200</b> for processing a data-centric business model. Method <b>200</b> will be described with respect to the components and data depicted in user-interface architecture <b>100</b>.

Method <b>200</b> includes an act of a user-interface architecture receiving user-entered data commands for creating a data model including one or more data fields and any appropriate relationships between the one or more fields (act <b>201</b>). For example, user-interface module <b>121</b> can receive model creation commands <b>131</b>. Method <b>200</b> includes an act of the user-interface architecture receiving user-entered rule commands indicating a business logic rule is to be associated with one or more selected data fields and/or relationships among the one or more data fields and any appropriate relationships (act <b>202</b>). For example, user-interface module <b>121</b> can receive rule commands <b>132</b>. Appropriate relationships between the one or more fields can include relationships between individual fields as well as between groups of fields.

<figref idref="DRAWINGS">FIGS. 5A through 5C</figref> illustrate an example portion of a presented user-interface <b>500</b> that can receive input for creating a commingled data-centric software application. As depicted in <figref idref="DRAWINGS">FIG. 5A</figref>, a user can open up a blank solution. The user can then drag one or more fields from field templates <b>502</b> to crate a customer Order list. One of the fields is a text type field named ‘Customer’ and, as depicted in existing fields <b>503</b>, includes customer name, phone, and email. Another field is of type &lt;“nested list”&gt; named ‘line items’ and gets a line item column that expands to show multiple sub-columns. Default views (including a master detail form for Orders and Line Items) and reports <b>501</b> are created for the user, based on the data types and the relationship implied by the nested line items.

As depicted in <figref idref="DRAWINGS">FIG. 5B</figref>, the user can select external data <b>504</b> to link available data <b>507</b> from a shipping management system to the custom order list. The user can enter rules at rule entry field <b>506</b>. For example, referring now to <figref idref="DRAWINGS">FIG. 5C</figref>, the user can select promise date field <b>508</b> and then enter ‘=(Order Date+5)’ into rule entry field <b>506</b> to create a rule that sets the promise date for an item five days later than the order date for the item.

More complex rules can also be entered. For example, the user can select promise data field <b>508</b> and validation at rule type <b>509</b>. The use can then enter ‘=(If(Promise Date&gt;=Order Date+3), true, (msg: “promise date must be at least 3 days after the date the order was placed”))’ to insure that a promise data is at least three days after an order date. The user can select expand/zoom control <b>510</b> to get a set of rows in which smaller formula steps can be defined. Thus, the user can select a small formula and include it as a parameter in a larger formula. Rule entry field <b>506</b> can also include type ahead functionality to make filed name selection more efficient.

Other types of rules for validation, conditional formatting, form navigation, etc. can also be entered at rule entry field <b>506</b>. Rule entry field <b>506</b> can be configured to receive rule input in the form of known mathematical expressions or syntax, such as, for example, that supported by other existing spreadsheet and database applications. Further, selecting formula bar <b>511</b> can bring up a list of common formulas that can be auto-entered into rule entry field <b>506</b>. Accordingly, there is an increased likelihood of a user being able to appropriately enter rule input. In some embodiments, user-interface architecture includes software wizards that assist a user in rule creation and rule entry.

Method <b>200</b> includes an act the user-interface architecture converting the user-entered rule command into a meta-data format that can be associated with the one or more selected data fields and/or relationships in a commingled data-centric application such that user-interface architecture abstracts the meta-data format from the user and thereby relieves the user from having to know the meta-data format (act <b>203</b>). For example, model manipulation model <b>122</b> can interoperate with rule modeler <b>124</b> to convert rule commands <b>132</b> into declarative macros that can be associated with fields identified in model creation commands <b>131</b>. Thus, the interoperation of model manipulation model <b>122</b> with and rule modeler <b>124</b> abstracts the meta-data format of the declarative macros from the user and relieves the user from having to know the meta-data format of declarative macros.

Method <b>200</b> includes an act of the user-interface architecture associating the meta-data format of the business logic rule with the one or more selected data fields and/or relationships to commingle the data model with the business logic rule within a commingled data-centric application (act <b>204</b>). For example, manipulation model <b>122</b> can interoperate with data modeler <b>123</b> and rule modeler <b>124</b> to associate the converted declarative macros with one or more selected fields identified in model creation input commands <b>131</b> (within model <b>101</b>A). Model <b>101</b>A can then be stored in model store <b>126</b> and/or presented to a user.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates a flowchart of a method <b>300</b> for using a user-interface architecture to create a business related software application. Method <b>300</b> will be described with respect to the components and data depicted in user-interface architecture <b>100</b>.

Method <b>300</b> includes an act of a user-interface architecture receiving user-entered commands for creating a new model, including user-entered commands for creating one or more data fields and any appropriate relationships between the one or more fields (act <b>301</b>). For example, user-interface module <b>121</b> can receive schema creation commands <b>141</b> including commands for creating one or more data fields. Alternately, user-interface module <b>121</b> can receive rule creation commands including commands for creating one or more business logic rules.

Method <b>300</b> includes an act of searching existing models for any relevant models having at least a specified level of commonality with the one or more data fields and/or any appropriate relationships (act <b>302</b>). In some embodiments, a user-interface architecture automatically searches existing models for relevant models. For example, search module <b>125</b> can search model store <b>126</b> for any existing models having at least the specified level of commonality with the one or more created data fields indicated in schema creation commands <b>141</b>. Alternately, search module <b>125</b> can search model store <b>126</b> for any existing models having at least the specified level of commonality rule properties included in received rule creation commands. In other embodiments, a user manually searches existing models for relevant models (e.g., through interfacing with user-interface module <b>121</b>).

Method <b>300</b> includes an act of the user-interface architecture identifying one or more relevant models having at least the specified level of commonality with the one or more data fields and any appropriate relationships (act <b>303</b>). For example, search module <b>125</b> can identify one or more models from model store <b>126</b> having at least the specified level of commonality with the one or more data fields indicated in schema creation commands <b>141</b>. Alternately, search module <b>125</b> can identify one or more models from model store <b>126</b> having at least the specified level of commonality with rule properties included in received rule creation commands.

Method <b>300</b> includes an act of the user-interface architecture presenting a list of the identified one or more relevant models at the display device (act <b>304</b>). For example, user-interface module <b>121</b> can present list <b>142</b> back to a user.

<figref idref="DRAWINGS">FIGS. 6A through 6C</figref> illustrate an example portion of a presented user-interface <b>600</b> that assists a user in locating a model that corresponds to an entered model. For example, in <figref idref="DRAWINGS">FIG. 6A</figref>, in response to creating fields for First Name and Last Name, search model <b>125</b> can search for data models that match one or more of the created fields. Models that have the specified level of commonality with First Name and/or Last Name are presented in list <b>601</b>. Returned models can include different column sets for different business purposes.

Method <b>300</b> includes an act of the user-interface architecture receiving a user-entered selection selecting one of the relevant models (act <b>305</b>). For example, user-interface module <b>121</b> can receive selection <b>143</b> from a user. Referring again to <figref idref="DRAWINGS">FIG. 6A</figref>, the user may select column set <b>601</b>A.

Method <b>300</b> includes an act of the user-interface architecture automatically adding one or more additional fields and any appropriate relationships from the selected relevant model to the new model to automatically provide the user with the functionality of an existing business related software application and thus relieve the user from having to manually create the functionality (act <b>306</b>). For example, model manipulation model <b>122</b> can interoperate with data modeler <b>123</b> to add one or more additional fields to from the selected model to the model indicated in schema creation commands <b>141</b>. Alternately, manipulation model <b>122</b> can interoperate with rule modeler <b>124</b> to add rules from a selected model to received rule creation commands. Referring to <figref idref="DRAWINGS">FIG. 6B</figref>, additional columns E-mail, Phone, and Picture are added to the user-entered columns of First Name and Last Name.

Model manipulation model <b>122</b> can also interoperate with data modeler <b>123</b> to automatically generate one or more views for the columns including a single instance form, a multi instance form, reports, photo galleries, contact lists (address book), and maps. <figref idref="DRAWINGS">FIG. 6C</figref> depicts tabs <b>602</b> representing the different views for column set <b>601</b>A.

Accordingly, embodiments of the invention facilitate the automated injection of an existing model (data fields and/or rules) into a new model creation so as to reuse existing models in the creation of new models when appropriate. The automation can permit less skilled users to create models that otherwise may not be possible. Embodiments of the present invention also assist a user in extending application functionality in an automated fashion.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates a flowchart of a method <b>400</b> for using a user-interface architecture to extend a business related software application. Method <b>400</b> will be described with respect to the components and data depicted in user-interface architecture <b>100</b>.

Method <b>400</b> includes an act of a user-interface architecture accessing a current model for a business related software application, the model configured to provide a first business related function (act <b>401</b>). For example, model manipulation model can access model <b>101</b>A (including data fields and rules) configured to provide a first business related function. Method <b>400</b> includes an act of the user-interface architecture receiving user-entered criteria indicative of a desire to extend the functionality of the business related software application by adding a further second business related function to the business related software application (act <b>402</b>). For example, user-interface module <b>121</b> can receive extension criteria <b>151</b> indicative of a desire to extend the functionality (e.g., data fields and/or rules) of model <b>101</b>A.

<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> illustrate an example portion of a presented user-interface <b>700</b> that assists a user in extending application functionality. It may be that the user that selected column set <b>602</b>A to track contacts desires to add issue tracking functionality to the application. However, the user may not know what fields are appropriate for tracking issues or how to add such fields to application. <figref idref="DRAWINGS">FIG. 7A</figref> depicts a solution overview that can assist the use in extending the application. For example, the user can enter the text “Issue” (the extension criteria) into search entry field <b>701</b>.

Method <b>400</b> includes an act of searching existing models for any relevant models having at least a specified level of commonality with the received criteria (act <b>403</b>). In some embodiments, a user-interface architecture automatically searches existing models for relevant models. For example, search module <b>125</b> can search model store <b>106</b> for any relevant models having at least a specified level of commonality with extension criteria <b>151</b>. In other embodiments, a user manually searches existing models for relevant models (e.g., through interfacing with user-interface module <b>121</b>).

Method <b>400</b> includes an act of the user-interface architecture identifying one or more relevant models having at least the specified level of commonality with the received criteria, the identified relevant models having an increased likelihood of being configured to provide the second business related function relative to other unidentified models accessible to the user-interface architecture (act <b>404</b>). For example, search interface module <b>125</b> can identify models <b>101</b>B and <b>101</b>C as having a specified level of commonality with (e.g., indicated data fields and/or rules included in) extension criteria <b>151</b>.

Method <b>400</b> includes an act of the user-interface architecture presenting a list of the identified one or more relevant models at the display device (act <b>405</b>). For example, use-interface module <b>121</b> can present list <b>152</b> (including models <b>101</b>B and <b>101</b>C) to a user. Referring to <figref idref="DRAWINGS">FIG. 7B</figref>, match list <b>702</b> provides a list solutions related to “Issues”, “Issue Management”, “Customer Issues”, and “Invoice Issues”, in response to entry of “Issue” at search entry field <b>701</b>.

As depicted in <figref idref="DRAWINGS">FIG. 7B</figref>, there are several ways in which functionality can be extended. The user selects “Issues” from match list <b>702</b> and is presented with question <b>703</b> prompting the user for more precise instructions on how existing functionality is to be extended. List <b>704</b> lists one or more possible ways to extend existing functionality. Method <b>400</b> includes an act of the user-interface architecture receiving a user-entered selection selecting one of the relevant models (act <b>406</b>). For example, user-interface module <b>121</b> can receive selection <b>153</b>, selecting models <b>101</b>B. As depicted in <figref idref="DRAWINGS">FIG. 7B</figref>, Option <b>704</b>A is selected from list <b>704</b>.

Method <b>400</b> includes an act of the user-interface architecture receiving a user-entered connection command indicating how the selected relevant model is to be connected to the current model to add the second business related function to the business related software application (act <b>407</b>). For example, user-interface <b>121</b> can receive connection command <b>154</b> indicating how model <b>101</b>B is to be connected to model <b>101</b>A to add the second business function. Command <b>154</b> can indicate how data fields and/or rules from model <b>101</b>B are to be integrated into the data fields and/or rules of model <b>101</b>A. Referring to <figref idref="DRAWINGS">FIG. 7B</figref>, the user can select add control <b>706</b> to indicate that issue tracking about contacts is to be added to the functionality of the existing application for column set <b>601</b>A.

Method <b>400</b> includes an act of the user-interface architecture connecting the selected relevant model to the current model in accordance with the user-entered connection commands to add the second business related function to the business related software application (act <b>408</b>). For example, model manipulation module <b>122</b> can interoperate with data modeler <b>123</b> and rule modeler <b>124</b> to connect (e.g., data fields and/of rules of) model <b>101</b>B to (e.g., data fields and/or rules of) model <b>101</b>A in accordance with connection command <b>154</b>. With reference to column set <b>601</b>A, model manipulation module <b>122</b> can interoperate with data modeler <b>123</b> and rule modeler <b>124</b> to add issue tracking about contacts to the application for column set <b>601</b>A.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.