User-interface architecture for manipulating business models

The present invention extends to methods, systems, and computer program products of user-interface architecture for manipulating business models. Embodiments of the invention facilitate efficient generation and extension of business related software applications, including commingled data-centric applications that represent both data elements and business logic in metadata. Modules of the user-interface architecture permit users to enter commands through common metaphors and wizards that abstract underlying (and more complex) modeling commands and data formats from users. The user-interface architecture can automatically search for existing models to provide and extend business related functionality.

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.

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.

Generally, user-interface module121can provide a (e.g., graphical) user-interface to a user for manipulating models stored in model store126. User-interface module121is configured to receive input data from input devices (e.g., key board, mouse, touch surface, etc.) connect to user-interface architecture100. 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 store126. For example user-interface module121can receive user input for creating, manipulating, etc, any of the models101A,101B,101C, etc.

User-interface module121is also configured to provide output data to output devices (e.g., a video display device, speakers, printers, etc.) connected to user-interface architecture100. 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 module121can 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 module122. User-interface module121can transfer various search criteria to search module125. User-interface module121can also filer portions of received input data directed to one module for transfer to another module. For example, user-interface module121can identify properties (e.g., field names) included in data schema creation input and transfer those identified properties to search module125.

User-interface121can 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-interface121can 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-interface121can also be configured to receive output data and present it using the common metaphors.

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

Search model125is 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 module125can receive search criteria from user-interface module121. Search module125can search model store126for 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 store126can store a plurality of models including models101A,101B, and101C. A series of two vertical periods (a vertical ellipsis) represents that other models can be stored in model store106before, between, and after models101A,101B, and101C.

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 architecture100, 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

FIG. 1Billustrates an example data format business model101A. Model101A includes data model103, business logic model105, and data views113. Data model103can include a schema representing the data formats for tables, fields and properties of data store117, including data element104. Data element104can represent, for example, the data format of data entity117A (e.g., a value of a data base field).

Business logic model105can include one or more rules including rule106. Rules106includes a reference to event107(e.g., an input event), a condition108that is to be evaluated when event107occurs, and an action109that is to be implemented when condition108is satisfied. Condition108further includes binding113to data element104and expression116.

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: <bindingid, friendly name, URI, [objected], filedref|elementref|recordref>. 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:

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 index111includes one or more entries that map events to corresponding rules. For example, entry112maps event107to rule106.

Data views113includes one or more views to subsets of data from data store117.

Each of data model103, business logic model105, and data views can be represented in metadata102such that no code is required to execute model101A.

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 toFIG. 1A, data modeler123can be configured to manipulate data models, including data models similar to data model103. Rule modeler124can be configured to manipulate rules, similar to those included in business logic model105. Accordingly, the modules of user-interface architecture100(including user-interface module121, model manipulation module122, data modeler123and rule modeler124) 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.

FIG. 2illustrates a flowchart of a method200for processing a data-centric business model. Method200will be described with respect to the components and data depicted in user-interface architecture100.

Method200includes 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 (act201). For example, user-interface module121can receive model creation commands131. Method200includes 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 (act202). For example, user-interface module121can receive rule commands132. Appropriate relationships between the one or more fields can include relationships between individual fields as well as between groups of fields.

FIGS. 5A through 5Cillustrate an example portion of a presented user-interface500that can receive input for creating a commingled data-centric software application. As depicted inFIG. 5A, a user can open up a blank solution. The user can then drag one or more fields from field templates502to crate a customer Order list. One of the fields is a text type field named ‘Customer’ and, as depicted in existing fields503, includes customer name, phone, and email. Another field is of type <“nested list”> 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 reports501are created for the user, based on the data types and the relationship implied by the nested line items.

As depicted inFIG. 5B, the user can select external data504to link available data507from a shipping management system to the custom order list. The user can enter rules at rule entry field506. For example, referring now toFIG. 5C, the user can select promise date field508and then enter ‘=(Order Date+5)’ into rule entry field506to 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 field508and validation at rule type509. The use can then enter ‘=(If(Promise Date>=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 control510to 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 field506can 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 field506. Rule entry field506can 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 bar511can bring up a list of common formulas that can be auto-entered into rule entry field506. 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.

Method200includes 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 (act203). For example, model manipulation model122can interoperate with rule modeler124to convert rule commands132into declarative macros that can be associated with fields identified in model creation commands131. Thus, the interoperation of model manipulation model122with and rule modeler124abstracts 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.

Method200includes 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 (act204). For example, manipulation model122can interoperate with data modeler123and rule modeler124to associate the converted declarative macros with one or more selected fields identified in model creation input commands131(within model101A). Model101A can then be stored in model store126and/or presented to a user.

FIG. 3illustrates a flowchart of a method300for using a user-interface architecture to create a business related software application. Method300will be described with respect to the components and data depicted in user-interface architecture100.

Method300includes 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 (act301). For example, user-interface module121can receive schema creation commands141including commands for creating one or more data fields. Alternately, user-interface module121can receive rule creation commands including commands for creating one or more business logic rules.

Method300includes 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 (act302). In some embodiments, a user-interface architecture automatically searches existing models for relevant models. For example, search module125can search model store126for any existing models having at least the specified level of commonality with the one or more created data fields indicated in schema creation commands141. Alternately, search module125can search model store126for 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 module121).

Method300includes 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 (act303). For example, search module125can identify one or more models from model store126having at least the specified level of commonality with the one or more data fields indicated in schema creation commands141. Alternately, search module125can identify one or more models from model store126having at least the specified level of commonality with rule properties included in received rule creation commands.

Method300includes an act of the user-interface architecture presenting a list of the identified one or more relevant models at the display device (act304). For example, user-interface module121can present list142back to a user.

FIGS. 6A through 6Cillustrate an example portion of a presented user-interface600that assists a user in locating a model that corresponds to an entered model. For example, inFIG. 6A, in response to creating fields for First Name and Last Name, search model125can 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 list601. Returned models can include different column sets for different business purposes.

Method300includes an act of the user-interface architecture receiving a user-entered selection selecting one of the relevant models (act305). For example, user-interface module121can receive selection143from a user. Referring again toFIG. 6A, the user may select column set601A.

Method300includes 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 (act306). For example, model manipulation model122can interoperate with data modeler123to add one or more additional fields to from the selected model to the model indicated in schema creation commands141. Alternately, manipulation model122can interoperate with rule modeler124to add rules from a selected model to received rule creation commands. Referring toFIG. 6B, additional columns E-mail, Phone, and Picture are added to the user-entered columns of First Name and Last Name.

Model manipulation model122can also interoperate with data modeler123to 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.FIG. 6Cdepicts tabs602representing the different views for column set601A.

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.

FIG. 4illustrates a flowchart of a method400for using a user-interface architecture to extend a business related software application. Method400will be described with respect to the components and data depicted in user-interface architecture100.

Method400includes 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 (act401). For example, model manipulation model can access model101A (including data fields and rules) configured to provide a first business related function. Method400includes 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 (act402). For example, user-interface module121can receive extension criteria151indicative of a desire to extend the functionality (e.g., data fields and/or rules) of model101A.

FIGS. 7A and 7Billustrate an example portion of a presented user-interface700that assists a user in extending application functionality. It may be that the user that selected column set602A 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.FIG. 7Adepicts 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 field701.

Method400includes an act of searching existing models for any relevant models having at least a specified level of commonality with the received criteria (act403). In some embodiments, a user-interface architecture automatically searches existing models for relevant models. For example, search module125can search model store106for any relevant models having at least a specified level of commonality with extension criteria151. In other embodiments, a user manually searches existing models for relevant models (e.g., through interfacing with user-interface module121).

Method400includes 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 (act404). For example, search interface module125can identify models101B and101C as having a specified level of commonality with (e.g., indicated data fields and/or rules included in) extension criteria151.

Method400includes an act of the user-interface architecture presenting a list of the identified one or more relevant models at the display device (act405). For example, use-interface module121can present list152(including models101B and101C) to a user. Referring toFIG. 7B, match list702provides a list solutions related to “Issues”, “Issue Management”, “Customer Issues”, and “Invoice Issues”, in response to entry of “Issue” at search entry field701.

As depicted inFIG. 7B, there are several ways in which functionality can be extended. The user selects “Issues” from match list702and is presented with question703prompting the user for more precise instructions on how existing functionality is to be extended. List704lists one or more possible ways to extend existing functionality. Method400includes an act of the user-interface architecture receiving a user-entered selection selecting one of the relevant models (act406). For example, user-interface module121can receive selection153, selecting models101B. As depicted inFIG. 7B, Option704A is selected from list704.

Method400includes 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 (act407). For example, user-interface121can receive connection command154indicating how model101B is to be connected to model101A to add the second business function. Command154can indicate how data fields and/or rules from model101B are to be integrated into the data fields and/or rules of model101A. Referring toFIG. 7B, the user can select add control706to indicate that issue tracking about contacts is to be added to the functionality of the existing application for column set601A.

Method400includes 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 (act408). For example, model manipulation module122can interoperate with data modeler123and rule modeler124to connect (e.g., data fields and/of rules of) model101B to (e.g., data fields and/or rules of) model101A in accordance with connection command154. With reference to column set601A, model manipulation module122can interoperate with data modeler123and rule modeler124to add issue tracking about contacts to the application for column set601A.