Enterprise process models and enterprise application for information technologies

[0002] This application claims priority to U.S. Provisional Application No. 60/158,552 filed Oct. 8, 1999, and is related to filed concurrently herewith, herein incorporated by reference in its entirety.

[0003] The present invention relates generally to tools that aid in the development of software applications and, more specifically, to tools that aid in the development of large scale enterprise applications.

[0004] Enterprise applications perform useful functions (such an expense reimbursement, or order fulfillment) in an enterprise. Software technologies (such as workflow programs, messaging systems, database programs, and Graphical User Interface (GUI) builders) have been developed that aid in the development of large-scale, enterprise-wide applications. These systems are helpful because they provide useful infrastructure and a rapid build time.

[0005] However, because such systems use diverse underlying software technologies, it is often very difficult for the system designer to visualize the enterprise process while at the same time visualize the user interface and the information accessible at each stage of the enterprise process.

[0006] Thus, there remains a need in the art to provide an efficient mechanism to visualize an enterprise process and also visualize the user interface and information accessible at each stage of the enterprise applications that rely on a set of diverse underlying software technologies.

[0007] In addition, in the event that a change is required in the enterprise application, the system designers must make the appropriate changes to each of the underlying software technologies to update the enterprise application. This may be a difficult, error-prone, time-consuming and expensive task if the change effects much of the underlying software technology that makes up the enterprise application.

[0008] Therefore, there is a need in the art to provide a system that provides for rapid integration of software technologies into an enterprise application, yet also provides for flexible and efficient updates to such enterprise applications.

[0009] The problems stated above and the related problems of the prior art are solved with the principles of the present invention, method and system for generating enterprise applications of a diversity of information technologies. An enterprise process model is generated that comprises a plurality of actors, actions performed by said actors, objects acted upon by said actions, and roles. Data characterizing the view of the attributes of at least one of the objects of the model is generated by associating a plurality of situation/role pairs with the at least one object; and then, for each particular situation/role pair, defining a view definition for the attributes of the at least one object based upon user input, and storing the view definition for subsequent use. Preferably, the view definition is stored as part of a model, and used by a code generation process to build program fragments that execute the enterprise application represented by the model.

[0010] Preferably, the view definition provides one or more of the following: i) an indication whether the attributes of the at least one object are to be displayed; ii) information that dictates how to render the attributes of the at least one object; iii) an indication whether the attributes of the at least one object are to be editable; and iv) information that dictates how to edit the attributes of the at least one object.

[0011] In another aspect of the present invention, an enterprise application for use in an information system that comprises diverse software services and hardware platforms is generated by generating a model of the enterprise process, wherein the model comprises a plurality of actors, actions performed by said actors, objects acted upon by said actions, and roles. A configuration defining software services and hardware platforms that support the model is generated. Finally, program fragments that support the model are generated. The program fragments are suitable for execution on hardware platforms defined by the configuration and use the software services defined by the configuration. Preferably, a set of templates that support these hardware platforms and software services are used to generate the program fragments. In addition, the model preferably includes a view definition for the attributes of at least one object of the enterprise process, wherein the view definition is generated via user input as described above.

[0012] FIG. 1 is a block diagram of a computer processing system wherein the method of the present invention may be embodied.

[0013] FIG. 2 illustrates the user interface for a Procedure Editor, which allows the user to enter a procedure diagram for a highly procedural enterprise process.

[0014] FIG. 3 illustrates the user interface for an Object Attribute Definition Editor of the present invention, which allows the user to define classes of object and the attributes for each class of object.

[0015] FIG. 4 illustrates a task window for a particular role performing a particular stage of the enterprise process of FIG. 2.

[0016] FIG. 5 illustrates the user interface for an Object View Definition Editor of the present invention, which provides the user with the ability to selectively define the display parameters and edit parameters of the attributes (which are preferably defined by the Object Attribute Definition editor of FIG. 3) of the domain object for a given view definition.

[0017] FIG. 6 illustrates a user interface for a View Assignment Editor of the present invention, which allows the user to select an object view (which is preferably defined by the object view definition editor of FIG. 5) for a given combination of domain object, role and task.

[0018] FIG. 7 is a pictorial illustration of an exemplary set of templates and an exemplary architecture underlying an enterprise application generated by the methodology of the present invention.

[0019] FIG. 8 is a pictorial illustration of an exemplary set of templates, an exemplary architecture, and an meta-model used in generating an enterprise application according to the methodology of the present invention.

[0020] FIG. 9 is a flow chart illustrating an exemplary code generation process for generating program fragments that embody a given enterprise application.

[0021] The present invention may be implemented on any computer processing system including, for example, a personal computer or a workstation. As shown in FIG. 1, a computer processing system 900 as may be utilized by the present invention generally comprises one or more computers or processors. An examplary system includes at least one central processing unit (CPU) 903 connected to a bus 910 that is further connected to memory 120, a graphical user interface 907 (such as a display), and optionally a network input/output (I/O) device 930. Memory 120 typically includes persistent storage (such as ROM, a hard disk drive, a CD-ROM drive, an optical drive, ROM or other suitable storage device) and non-persistent storage (such as RAM). The operating system and application programs that execute on the CPU 903 are typically stored in persistent storage and loaded into non-persistent storage for execution by the CPU 903. Portions of the operating system and application programs that execute on the CPU may be loaded from network resources into memory 120 via the network I/O device 930. An example of a such a system 900 is the IBM RS/6000 workstation.

[0022] It should be noted that the application program(s) executed by the CPU 903 may perform the methods of the present invention described below. Alternatively, portions or all of the methods described below may be embodied in hardware that works in conjunction with the application program executed by the CPU 903.

[0023] The present invention provides a technology for describing business processes at a very high level, and to automatically generate the software to support that business process. By combining enough information about the business process to generate it and by defining that information in business rather than software terms, generated software can be more easily modified when the business process changes. In order to do this the relevant aspects of business processes need to be modeled. Most business processes involve the coordination of many people, modifying data and physical objects. For the purposes of generating software, the principal concern is with data objects rather than physical objects. The business process specifies who is allowed and asked to modify various data objects at different times. Thus the model is focused on actors (people and program agents), actions (what those actors do) and things that are acted upon (data).

[0024] This patent application is organized as follows: Section 1 describes some of the social aspects of enterprises is described, along with the business processes needed to sustain them and the common elements in those. Section 2 describes how to concretely describe those common elements in a software tool. Finally, section 3 describes how to generate software from that description.

[0025] 1.1. An Enterprise Consists of Many People Working Together Towards a Shared Goal

[0026] People work together via conversations that guide their collective actions. Conversations lead to the formation of social systems called organizations or enterprises.

[0027] An enterprise is a human social system that produces a variety of outcomes that are valuable to a variety of constituencies. Enterprises include:

[0028] business enterprises, which generate capital through the exchange of goods and services for something that is of value to them—typically money, but increasingly other services, information or knowledge

[0029] government enterprises which, amongst other things: establish and enforce regulations governing social conduct; issues licenses and property rights such as a license to drive automobiles or a patent to intellectual property; raise taxes; and dispense largesse in the form of social services

[0030] third sector enterprises (non-governmental organizations) which pursue causes on a not-for-profit basis while remaining independent from government.

[0031] The accomplishment of a particular outcome by an enterprise typically requires a chain or web of conversations amongst a possibly large number of people. The person requiring the outcome need not know about all these conversations, nor what people and knowledge will be required to produce the outcome. All that they rely upon is trust—that the person who commits to deliver an outcome to them speaks faithfully on behalf of the larger group (e.g., the enterprise as a whole, or a team) that as a whole will deliver the outcome.

[0032] 1.2. Many Conversations of an Enterprise Process are Highly Structured and Frequently Repeated

[0033] An enterprise process is the subset of the conversations of an enterprise that contributes to the achievement of a particular class of outcome. Some enterprise processes provide outcomes to people and enterprises beyond the enterprises—for example, a sales process (leads to purchase outcomes), a recruiting process, an order fulfillment process or an auditing process. Other enterprise processes accomplish outcomes of internal interest to the enterprise and its employees—for example, an expense reimbursement process, a strategy formation process, and a facilities management process. Within a business enterprise, some enterprise processes are called “business processes.”

[0034] Frequently the conversations of an enterprise process become stylized, in form, content and job roles. This repeated structure and procedure is often reinforced through artifacts such as paper forms, organizational structures, job definitions, measurement and reward systems, and even scripts to be spoken aloud by employees in particular situations. The typical situations of the enterprise process are enumerated, together with the possible courses of action (procedures) to be followed by participants within those situations. This additional structure corresponds to practices that emerged or were the result of explicit agreements by the members of the enterprise. Some of this structure is deliberately introduced so that automation can be developed and exploited.

[0035] 1.3. Enterprise Applications Support the Agreed Structures and Conventions of Enterprise Processes

[0036] When the conversations of an enterprise process are stylized, repeated structures can be introduced into and thus be supported or even enforced by information technologies. A computer program that imposes upon generic information technologies the additional structure necessary to support the repeated, structured conversations of an enterprise process is referred to as an enterprise application of those information technologies. Here we use the shorter term enterprise application.

[0037] This invention is of methods and technologies for the development of enterprise applications. The engineering task of developing enterprise applications deals with both hardware devices and software technologies. Enterprise applications are hosted by physical, “hardware” devices that interface to people via input and output devices, and to other devices to form networks. Software technologies are programs that are executed by computer hardware devices and communications equipment. Generic software technologies provide a diverse range of enabling services including those that can be used directly “out of the box” (such as word processors and e-mail) and those that require application (such as transaction processing monitors, relational databases, and object request brokers). Supporting the structures of an enterprise process involves the development of computer programs that coordinate these diverse hardware and software technologies to form an enterprise application of the technologies.

[0038] The first aspect of the invention comprises a software tool in which a model of the structures of an enterprise process can be captured. Such a model comprises:

[0039] a description of the common situations of the enterprise process, defined in terms of actors, actions, and acted upon objects, and the relationships between them that characterize each situation

[0040] a description of each conversations contents and a description of the allowed actions and the sequencing of those actions by which people add to the conversation and orchestrate others adding to the conversation

[0041] a description of information visualization and edit actions, defined for an actor playing a certain role in a certain situation of a process.

[0042] The second aspect of the invention is the capability to generate an enterprise application of a diversity of technologies, based upon said enterprise process model. This second aspect is described in Section 3.

[0043] 2.1. Characterizing Common Situations in Terms of Actors, Actions and Acted Upons

[0044] The common, recurring situations of an enterprise process can be characterized in terms of actions, roles and acted upons:

[0045] an “actor” is a human or software agent who may participate (perform actions) within the conversations of an enterprise and its processes

[0046] an “acted upon” is one or more pieces of data and information recorded within conversations. It is an artifact of the conversation that can be observed by other actors later in the process. This data or information may refer to anything of interest to the enterprise (including the actors, actions, and conversations of enterprise processes themselves)

[0047] an “action” is an operation that results in changes to the data and information recorded within conversations. An “action” is performed by an actor, and results in changes to “acted upons”

[0048] a “role” is a label associated with a set of actors and information that characterizes i) when the set of actors associated with the label may perform certain actions, and ii) what such actors can see when they view objects of the model.

[0049] A situation may therefore be defined in terms of:

[0050] under what conditions the situation occurs. These conditions are typically expressed in terms of the state of the acted upon data and information

[0051] which actors may play which roles within given situations

[0052] what actions role players may be permitted or obliged to perform within the situation, and with what urgency.

[0053] The preferred embodiment of the present invention focuses on highly procedural enterprise processes. Thus, its Procedure Editor captures and displays to the user Procedure Diagrams that outline the specific set of a relationships of procedural workflows.

[0054] A “procedure” is a carefully designed and stage-managed sequence of situations, each of which is tied to clearly defined roles, actions and acted upons. This logical sequence of workflow “stages” is designed to ensure efficient achievement of a predictable set of outcomes.

[0055] FIG. 2 illustrates an exemplary Procedure Diagram for a highly procedural enterprise process which is roughly modeled on part of the way help requests are handled when they come in on the telephone. We call this process—CallCenter—and it consists of:

[0056] stages (201)—the procedure's situations—are shown as rectangles (for example, identify customer)

[0057] object variables (203)—placeholders for the procedure's acted upons—are shown as octagons along the bottom of the diagram (for example, problemRecord is a variable that will contain a ProblemRecord object)

[0058] roles (205) are shown as masks to be ‘worn’ by actors (for example, customer).

[0059] The example in FIG. 2 shows the processing of a customer problem within the customer support organization of a software company. The procedure is initiated by a customer who has a problem. The customer contacts a so-called CMC representative who identifies the customer and verifies that they are entitled to support, at which point the customer's problem is passed to one or more levels of support personnel (level1, level2 and level3), based upon the nature of the problem. If a problem has not been previously encountered, there may be a need to correct the software, as specified in an APAR—an “Authorized Program Analysis Report.”

[0060] Along the left hand side of the diagram are masks for the various roles (205) of actor—customer, CMC representative, and level1, level2 and level3 support personnel. Each task is placed in a “swim lane” (207), which is a horizontal strip between two horizontal lines to the right of a role, to indicate which role of actor will perform the stage; for example, the CMC representative will perform tasks called identify customer, identify request type and verify entitlement.

[0061] The conditions in which each situation [stage (201)] of a procedure may occur are straightforward. An order in which stages can occur is indicated by transitions (209), which are shown as named arrows. For example, the process starts with the customer's have problem stage, before proceeding via the call transition to the CMC representative's identify customer stage. For several stages in this procedure, the actor playing a role is faced with a choice between several outcomes, each of which leads to a different transition being followed and subsequently a different continuation of the procedure. For example, when the CMC representative ends the verify entitlement stage they decide whether the customer is not entitled or entitled to support, leading either to the customer receiving an immediate rejection (following the not entitled outcome and transition), or to the rest of the problem determination and resolution procedure being followed. The selection of an outcome is a “transition action” performed by the actor performing the stage.

[0062] Lines connecting object variables (203) [octagons] to stages (201) [rectangles] indicate which object variables (203) are acted upon in each stage of the procedure. For example, the try to deal with the problem stage performed by level2 support acts upon the process's problemRecord and customerRecord object variables. Similarly, the APAR object variable is involved in each of the stages attach to APAR, make new APAR and fix the product.

[0063] Precisely which actor plays which role for which stage, and which domain object instance is associated with which object variable, and when these selections are made, is determined by additional information inputted into the system, but that is not shown in the diagram. In the example: the actor playing the role of customer should be the same for all three stages; and an actor is determined to play the level3 role depending upon their familiarity with the product component that is believed to be faulty. Similarly, the APAR object variable will either be filled by an existing APAR during the attach to APAR stage, or attached to a newly created APAR object during the make new APAR stage.

[0064] The highly procedural enterprise processes captured and displayed by the Procedure Editor has the following limitations:

[0065] the situations of the process are stages in a procedure; the invention supports all levels of structure in the spectrum from ad hoc to highly procedural processes

[0066] each situation involves a single actor, being the actor playing the role associated with a stage; the invention supports both single actor and multi-actor situations

[0067] in each stage there are a limited number of actions available to the actor, including the ability to see and modify objects acted upon by the stage, and the selection of a transition as the outcome for the stage; the invention applies to all situations that can occur within the conversations within an enterprise or between enterprises, and all actions that can occur within those situations.

[0068] 2.2. Characterizing Things Acted Upon

[0069] The informational things recorded, viewed and acted upon within the situations of an enterprise process can be characterized using any of the large variety of means that computer science has developed for characterizing data and information. Commonly used approaches include:

[0070] entity-relationship attribute modeling

[0071] object-oriented modeling

[0072] information modeling and many others. The invention requires at least one means for defining acted upons.

[0073] In the preferred embodiment of the present invention, there is one kind of acted upon—“domain objects”, or “objects” for short. Objects are defined in terms of their attributes and methods. An attribute is a named field that can contain a value of a specified type—for example, a text string, an integer, or another type of object. A method is an operation associated with an object that may update the object's data, invoke methods of other objects and/or return a value. For each of its attributes an object has associated methods for “getting” and “setting” the attribute's value.

[0074] Objects and their attributes are defined in an Object Attribute Definition editor. The user interface to the Object Attribute Definition editor is illustrated in FIG. 3. In the example of FIG. 3, the domain objects of class ProblemRecord (shown top left, 301) have attributes named descriptionofProblem, customerRecord, contractName and requestType. Each attribute is characterized in a number of ways, one of which is its class; here the attribute contractName is of class Object. The Object Attribute Definition editor allows the user to define classes of object (301) and define the attributes (303) for each class of object. Preferably, the Object Attribute Definition editor allows the user to define the name (305) of a given attribute (303) for each class of object, and class (307) for a given attribute (303) for each class of object. The running application may deal with many instances of each class—for example, the many ProblemRecord objects created in the Call Center process. Each instance of the Call Center process, responding to a specific customer call, will act upon a single problem record.

[0075] There are a large number of ways to define acted upons and actions, most of which are suitable for use in this invention.

[0076] 2.3. Characterizing Actions, Including those for Visualizing and Editing Acted Upons

[0077] An action is performed within a situation as an actor acts upon data or information. Actions may, amongst other things, result in: changes to data or information; the display of data or information; or the assignment of work to actors. As a consequence of an action taking place one or more new situations may arise, leading to further actors performing further actions.

[0078] Actions that display and edit information may be defined in terms of “view definitions”. A view definition is information associated with an acted upon that characterizes the display and manipulation of the acted upon when rendered for display.

[0079] Each action should be available only to certain actors and in certain situations. The invention includes a means for defining what each actor may see or may modify within actions that visualize or change acted upons, and in what situations the actors are able to perform those actions. The invention requires at least one means for defining actions.

[0080] Three kinds of actions take place within the “stages” (situations) of a procedure:

[0081] “information visualization actions” result in the display of the attributes (data and information) of objects (acted upons)

[0082] “edit actions” result in changes to objects and their attributes

[0083] “transition actions” determine the subsequent course of action.

[0084] Transition actions are defined using the Procedure Editor, as described above in Section 2.1. Information Visualization and Edit Actions are Defined in the Object View Definition Editor, and are Introduced here.

[0085] In the applications generated from the preferred embodiment, all three kinds of actions are made available in the form of a “task window”, the details of which are shown in FIG. 4. A task window supports an actor in her work in a particular situation (“stage”) in a business procedure. For example, the task window of FIG. 4 supports the CMC role in the identify request type stage of FIG. 2. The task window enables the actor playing the role for a given stage to see and possibly edit the attributes of each of the objects acted upon in the situation by the actor, and enables such actor to select a transition action that indicates the outcome of the stage. Note that the actor may make changes to the attribute values contained in read-write fields, but cannot change read-only fields. A read-write field—in this case, the value “SW-basic” of the problem record's requestType field—is shown with a white background, while a read-only attribute—such as the value “Bob Smith” of the customer record's customerName field—has a gray background.

[0086] The action of opening a task window for a stage is the visualization action of the stage. The action of editing the read-write fields of the form is the edit action of the stage. The actor indicates that the stage is completed by performing a transition action from the “Actions” menu (shown at the top left of the window). This menu is generated to include an entry corresponding to each transition leaving the current stage in the enterprise process diagram—that is, for each transition action of the stage. For the task window of the identify request type stage there is just one such transition—identified—so the menu (not shown) contains just this one transition action. As the user selects a transition action from the action list, the stage is completed and the application transitions to the next stage, for example by routing a work item to the actor that will perform the next stage.

[0087] The details of the task window for a particular role performing a particular stage—in the example of FIG. 4, for the CMC representative performing the IdentifyRequestType stage—are defined as follows:

[0088] the task's “Actions” menu is determined wholly in terms of the transitions leaving the task in its enterprise process diagram

[0089] the set of domain objects displayed in a task window is determined by “acted upon” relationships shown in an enterprise procedure diagram. Thus, the task window for identify request type shown in FIG. 4 contains views of two domain objects: a problem record and a customer record.

[0090] task windows and the object views that they contain require further specification—in terms of task and object view definitions.

[0091] An object view definition is information associated with an object that characterizes the display and manipulation of the attributes of the object when rendered for display, for example, in a task window. It categorizes each of the domain object's attributes as either displayed or not displayed. Each displayed attribute is further categorized as editable or read-only, and has additional formatting information.

[0092] According to the present invention, an object view definition for a given domain object is specified using the Object View Definition Editor. The user interface of the Object View Definition Editor is illustrated in FIG. 5. In this example, an object view definition called SetRequestType is being defined for the domain object ProblemRecord to the CMC role in the IdentifyRequestType task of FIG. 2. The attributes of the domain object for a given view definition may be selectively defined as “Displayed” or “Not Displayed”. In addition, the object view definition editor may provide the user to selectively define the “edit” parameters for a given attribute (which define whether the attribute is editable when displayed and other parameters used to edit the given attribute) and “display” parameters (which define parameters used to render a display of the attribute). In the example shown in FIG. 5, each of the four attributes of the object ProblemRecord (which was defined in the Object Attribute Definition Editor) for the SetRequestType view is to be displayed, so they are all categorized as “Displayed.” Since the goal of the task is to identify the type of request being made by the customer, the requestType attribute is declared to be “editable.”

[0093] Since a stage may act upon several objects, a task view consists of one object view definition for each domain object acted upon by the task performed in the stage. A task view definition is assembled for a given task using the View Assignment Editor. The user interface of the View Assignment Editor is shown in FIG. 6. More specifically, the View Assignment Editor allows the user to select an object view definition (in this example, selected from the table of available views on the right) for a given combination of domain object, role and task (in this example, selected from entries in each of the first three columns, respectively). In FIG. 6 as shown, the object view SetRequestType of domain object ProblemRecord is selected as part of the task view definition for role CMC as they perform stage identify request type.

[0094] Preferably, a task view definition is complete when one object view has been selected for each domain object acted upon by each actor for the given task in the stage.

[0095] Section 3.1 presents the notion of a program generator, which uses enterprise process models and program templates to generate computer programs. Section 3.2 describes how to create program templates. Section 3.3 describes how a tool can support alternative template sets and thus generate programs for a variety of enabling software and hardware technologies.

[0096] 3.1. A Program Generator Uses Program Templates and Models to Generate Programs

[0097] A program generator is a computer program that generates a set of computer program fragments (“modules”) based upon a set of program templates and an input model that represents a description of the actors, actions, acted upons and situations of the business process as described in Section 2.

[0098] FIG. 7 illustrates an exemplary set of templates and an exemplary architecture. The templates are designed to produce applications of a particular hardware and software architecture. In this case, the architecture of the generated application consists of:

[0099] a Client Graphical User Interface (GUI) that runs on each user's desktop (or other) computer. The Client GUI consists of the “Desktop” window from which a user selects new work items (task), and one or more Task Windows appropriate for the various kinds of stage and other situation that the user may have to deal with

[0100] a Workflow Server that runs on one or more server machines. The Workflow Server is responsible for routing work items (tasks) to users. In order to correctly route work, it must also follow stage and procedure definitions and know about roles and organizations.

[0101] an Application Server that runs on one or more server machines. The Application Server is responsible for the acted upons (“data” and “data objects”) of the application, plus any additional business logic (here shown as “find and user-supplied code”) supplied by the supplier of the model. In the preferred embodiment, the Application Server was also responsible for overcoming some of the limitations of the commercial Workflow Server that formed part of the selected architecture—hence the need for people, stage and organization objects.

[0102] The architecture for a particular business procedure consists of a number of program fragments that apply the various technologies of the architecture. As shown in FIG. 7, for each kind of program fragment to be created, there may be one or more a corresponding templates.

[0103] FIG. 7, which is illustrative, shows that a task window—which is an application of generic graphical user interface technologies—is made up of three kinds of program fragment, each of which has a corresponding template. One of these templates—creating an “interface” used by other program fragments of the task window to interact with a data object in the Application Server, and parameterized by the <ClassName> of the data object's class, and an <AttributeName>, <AttributeClass> pair for each of <ClassName>'s attributes—looks like this:

[0104] In the case of the class ProblemRecord from the example shown in Section 2, with its four attributes descriptionofProblem, customerRecord, contractName and requestType, the following code is generated from this template:

[0105] A complete template set contains sufficient templates for generating all aspects of an enterprise application. Each template in the set is similar in nature to the above example, although different program templates may generate program fragments in different programming or specification languages. It is not uncommon for a single application to have modules written in 4 or more different programming or specification languages.

[0106] As illustrated in FIG. 8, templates can also be thought of from the point of view of the meta-model that governs the models that can be recorded within the invention's software tool. The same set of templates can be sorted or grouped not only according to what part of the architecture they will apply (the right-hand template sorting), but also by what meta-model element they are primarily associated with.

[0107] A meta-model is a model of the typical kinds of element of a model. The meta-model of the present invention necessarily includes actors, actions and acted upons, or elements that correspond to these three things. As shown in FIG. 8, the meta-model of the preferred embodiment represents procedures (and their transitions, roles, stages, object variables, and so on), data objects (and their attributes, object view definitions, methods, and so on), and other kinds of elements of a model.

[0108] From the meta-model perspective (the left half of the diagram), the template presented above (and highlighted in the diagram) can be seen as a template associated with data objects. The generated application must contain one program fragment generated from this template for each data object of the model (in the example of Section 2, the data objects include APAR objects, problemrecords and customerRecords). From this perspective, the code generation process can be seen as examining a model, and for each element (for example, a given data object) generating a program fragment using each program template associated with that kind of model element.

[0109] FIG. 9 is a flow chart illustrating an exemplary code generation process according to the present invention. In steps 901-907, a loop is performed over the data objects of the model. For a given data object, steps 903-905 are performed. In step 903, a loop is performed over the attributes of the given data object, wherein for each attribute, appropriate templates are used to generate one or more program fragments that i) define a local variable representing the attribute, and ii) provide access (read method/write method) to the local variable; and the resultant program fragments are stored for subsequent use. In step 905, a loop is performed over the object view definitions of the given data object, wherein for each object view definition, appropriate templates are used to generate a program fragment that provides a user interface element capable of accessing the data objects of the object view definition; and the resultant program fragments are stored for subsequent use. In step 909, a loop is performed over the stages of the model, wherein for a given stage, appropriate templates are used to generate one or more program fragments that implement the functions of the stage (that are independent of role) taking into account information (such as conditions, names, events, etc.) from the transitions into and out of the given stage; and the resultant program fragments are stored for subsequent use. In step 911, a loop is performed over the transitions of the model, wherein for a given transition, appropriate templates are used to generate one or more program fragments that define the data and events communicated between the stages of the process; and the resultant program fragments are stored for subsequent use. In step 913, a loop is performed over the roles of the model, wherein for a given role, appropriate templates are used to generate one or more program fragments to identify an individual (or class of individuals) that can play the given role; and the resultant program fragments are stored for subsequent use. In step 915, a loop is performed over the domain object variables of the model, wherein for a given domain object variable, appropriate templates are used to generate one or more program fragments that define a class providing access to the given domain object variable; and the resultant program fragments are stored for subsequent use. Finally, in step 917, the resultant program fragments are linked together to make a program that invokes the application's stages, roles, transitions and data to thereby execute the enterprise process represented by the model, and the code generation process ends.

[0110] 3.2. How a Template Set for a Wide Variety of Applications is Produced from a Single Software System

[0111] In principle, a template set is produced by abstraction from a carefully designed example system. Thus, a template set may be constructed as follows:

[0112] a set of enabling software and hardware technologies is selected

[0113] a sample program applying these technologies and containing all desired kinds of feature is carefully built and tested by an expert programmer

[0114] each kind of program fragment in the sample application is generalized to produce a corresponding template

[0115] a corresponding generation coordinator program is written, which ensures that all necessary program fragments are generated for each element of the model.

[0116] In practice, a template set is grown, over time, from a small working nucleus, as it is enriched to support further kinds of feature. Each new feature (for example, an ability to “drag” a value from a field in one form and “drop” it into a field in another form) is first programmed as an extension to a previously generated program so that its correctness can be tested in situ. The new feature is then incorporated into the template set, as some combination of extensions to some existing templates, and entirely new templates. The Generation Coordination Program is then updated to apply the new templates.

[0117] Thus incrementally, over time, a rich template set and corresponding Generation Coordination Program are built, sufficient to generate a wide variety of applications.

[0118] 3.3. The Effect of Including Alternative Template S`ets is to Allow the User to Select a set of Software and Hardware Components for which a Software Application will be Generated

[0119] The specific set of technologies that are applied to produce an enterprise application varies depending upon which organization that will use the application, and when it is developed.

[0120] Since the model (presented in section 2) of an enterprise process described to the tool is technology independent, it is possible to produce a program template set for each of a variety of such technology configurations.

[0121] Typically the program required to exercise one technology configuration will not work for a different technology configuration. This may be true not only for technology products from different suppliers, but also for different versions of a single product from a single supplier.

[0122] Each configuration of technology versions requires a dedicated architecture and thus a dedicated set of program generation templates. The tool may support one or more such template sets and thereby more than one application architecture and technology configuration. An application developer may be given a means for choosing one of the supported templates sets. Depending upon the number and nature of supported template sets, the application developer choosing a template set may be presented with a more or less sophisticated template selection mechanism. Examples include:

[0123] when there are a small number of supported template sets, the alternative sets may be presented as a simple list of monolithic wholes

[0124] when there are a large number of supported template sets, or when those templates are parameterized, the template sets may themselves be somewhat modular, allowing a template set to be assembled based on a set of selection criteria (for example, what database technology should be used).

[0125] It is customary to characterize a template set in terms of the technologies that it is able to exercise.

[0126] The preferred embodiment supports a small number of alternative template sets, each of which corresponds to a different choice of enabling technologies:

[0127] “traditional workflow”—an architecture dominated by a commercially available workflow engine

[0128] “non-traditional workflow”—an architecture dominated by a research prototype that offers an alternative to traditional workflow engines

[0129] “simulation engine”—an architecture intended to run on a single, portable computer, and to be used for demonstration purposes only. Given the small number of alternative configurations supported by the preferred embodiment, the choice between them is made available as separate buttons in a code generation window.

[0130] Sample generated program fragments resulting from the application of the methodology of the present invention for the Call Center process as described in Section 2 is set forth in Appendix A.

[0131] While preferred embodiments of the invention have been shown and described herein, it will be understood that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will be apparent to those skilled in the art without departing from the spirit of the invention. Accordingly, it is intended that the appended claims cover all such variations as fall within the spirit and scope of the invention.