WO2002069142A1 - Business modeling framework system and methods - Google Patents

Abstract

Aspects of the invention provide rapid development of static and/or dynamically modifiable intra and inter-entity business supply-chain and other systems. In one embodiment, a framework comprises core business-system implementation components (507) ('core components') including resource (504), process (505) and order (503) elements that are intrinsically independent of behaviors and links to other core components. The framework also includes behavior components for associating (506b) one or more behaviors with the core components (509), and linking components (901) for providing associative operational coupling of the business components and behavioral components.

Description

BUSINESS MODELING FRAMEWORK SYSTEM AND METHODS

PRIORITY REFERENCE TO RELATED APPLICATIONS This application claims benefit of and hereby incorporates by reference provisional application serial number 60/270,917, entitled "Business Modeling Framework System and Methods," filed on February 23, 2001 by inventors Anja Behrman, et al. This application further claims benefit of and hereby incorporates by reference provisional application serial number 60/295,462, entitled "Distributed Artificial Intelligent Agent Network", filed on May 31, 2001 , by inventors Claudia Betz-Habould, et al. This application further hereby incorporates by reference application serial number 09/152,494, entitled "Method and Apparatus for Business Modeling", filed on September 13, 1998, by inventors Anja Behrman, et al.

BACKGROUND OF THE INVENTION

Field of the Invention

This invention relates generally to business facilitation and automation systems, and more particularly provides a system and methods for implementing a framework of business modeling components for dynamic intra and inter enterprise business solutions.

Description of the Background Art

Business systems have long promised to streamline business operations. To date, however, efforts have yielded primarily special-purpose business "application programs," such as: supply chain management ("SCM") programs used in planning and scheduling, enterprise resource planning systems ("ERPs") used within manufacturing, and customer resource management systems ("CRMs") used in order and customer management. Unfortunately, using such programs in the contexts of evolving enterprises or enterprise interaction can be problematic.

For example, each existing business application program provides only a point- solution for solving a specific application within a particular business unit of a targeted business sector. They therefore rigidly encapsulate applicable functions according to a specific existing business model, application and utilization constraints. As a result, crucial operational gaps may well arise due to unique considerations or evolution of the business unit, a business unit counterpart, the enterprise business model, or of the industry. Another problem is that existing business application programs process and store information in unique, proprietary and, non-interoperable manners. Thus, not only is a particular system incapable of serving differing needs within even a particular enterprise, but the systems are also incapable of determining or supplying needed information to one another, let alone in a suitable form. Costly attempts to add "bridging software" have also provided only limited success among even targeted custom applications.

Also problematic is that existing application programs are implemented using traditional programming approaches.

Most of the above systems utilize "procedural code" (e.g. Fortran, Pascal, C) in which a highly integrated program is written using main and subroutine procedures having a tight weave of predetermined functional behaviors and data elements. As a result, modification of the procedures is often unworkable and new procedures are appended to existing ones (i.e. "bandaiding") until such modification becomes too unwieldy and the entire program is replaced. While object oriented programming ("OOP") has long provided encapsulation, inheritance and delegation, no particular object utilization is imposed and programmers tend to use familiar procedure-like techniques. As a result, OOP programs similarly tend to provide a fixed system of objects that integrate all aspects of the object function according to a business-&-application based model. A fixed system is created and loaded, an input is received, and each object executes its function and passes the modified data to the next one, until the system outputs the finally-processed input.

As with procedural programming, "reuse" of conventional OOP objects most often requires considerable reprogramming and programming expertise. Adding or modifying functions, for example, typically requires the addition or rewriting of an object for each included data instance, and modifications to data, e.g. a new format, presentation, etc., typically requires a new/re- written object for each operability that is affected by the data modification (i.e. bandaiding, once again).

The above problems are further exacerbated by changing business models, restructuring, advances in connectivity and evolving technologies, since the systems are inherently limited and non-adaptive.

Accordingly, there remains a need for systems and methods that enable more flexible and interoperable intra-entity applications suitable to largely static enterprises. There is further a need for systems and methods that are adaptable to inter-enterprise operation, and to dynamically changing enterprise models. There is also a need for systems and methods that are capable of exploiting emerging/future networking technologies, such as Java™ (Sun Microsystems, Inc.), ActiveX™ (Microsoft Corporation) and Visual Basic (Microsoft Corporation), HTML, XML and various incarnations of Simple Object Access Protocol or "SOAP" (developed by a consortium including DevelopMentor, IBM, Lotus, Microsoft and Userland), among others. There is still further a need for systems and methods that are capable of better exploiting existing and emerging processing system, programming and other technologies.

SUMMARY OF THE INVENTION Business modeling framework systems and methods provide for rapid development of static and/or dynamically modifiable intra and inter-entity business supply-chain and other systems. Embodiments enable ready implementation and adaptation to existing and changing business models and better exploitation of existing and new technologies, as well as the ready integration with existing system elements. In a system embodiment, a framework comprises core business-system implementation components ("core components") including resource, processes and order elements that are intrinsically independent of behaviors and links to other core components. The framework also includes behavior components for associating one or more behaviors with the core components, and linking components for providing operational coupling of the business components and behavioral components, thereby enabling direct reuse of the core components in diverse or modified systems without core component reprogramming.

A further system embodiment includes a framework for maintaining core components, behavior components and linking components, and a framework component loader-saver for providing to a business system portion determined ones of the components, and for persisting component information within or via the framework (e.g. to a further persistent storage medium), thereby enabling static or dynamic configuration re-configuration of business system or portions thereof. The framework can also facilitate both intra and/or inter- enterprise business system portions, among other permutations.

Another system embodiment includes a framework storing core component objects and a framework loader for providing the core component objects to a distributed intra or inter-enterprise runtime system, the objects including one or more each of process objects for determining one or more runtime system process slices to be conducted, resource objects for determining business system resource utilizations (e.g. associations or uses) corresponding to the process slices, and order objects for communicating decisions or conditions according to which the slices can be initiated or conducted. The framework can further include one or more of a saver for persisting object information received from the business system, object state machines for determining behaviors of the objects, framework state machines for determining behaviors of groups of the objects and/or the framework, and linkers for determining object couplings of the provided objects within the runtime system.

A method embodiment according to the invention includes providing one or more of order, resource and process objects to a distributed inter-enterprise business system for enabling the business system to conduct one or more process slices, and providing one or more state machines to the business system, the state machines being associated with ones of the objects for determining a behavior of the objects.

Advantageously, embodiments of the invention are capable of facilitating the rapid development, modification and implementation of distributed inter-enterprise supply-chain systems. Embodiments provide for true no reprogramming core component reuse within diverse systems, for rapid system updating and for dynamic inter-enterprise system reconfiguration. Embodiments further enable variably ordered and propagative implementation of inter-application decisions, variable coupling, and inter-enterprise collaboration and propagation at various determinable points in the execution of business system operations (e.g. rather than mere data passing or static linking). Embodiments still further enable data storage within the framework to be optimized for supplying components to business system elements while also enabling a different execution optimization within the business system, among still further advantages.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram illustrating an example of an underlying interconnected network in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram illustrating an exemplary computer system in accordance with an embodiment of the invention;

FIG. 3 is a flow diagram broadly illustrating an exemplary agent network as an example of a business system operating in conjunction with a framework system implementation according to an embodiment of the invention;

FIG. 4 is a flow diagram illustrating an example of a multi-tiered framework system and facilitated business system architecture, according to an embodiment of the invention;

FIG. 5 is a flow diagram illustrating a framework system according to an embodiment of the invention;

FIG. 6 is a flow diagram illustrating an example of a utilization of framework aspects according to an embodiment of the invention; FIG. 7 is a flow diagram illustrating an example of a utilization of framework grouping aspects according to an embodiment of the invention;

FIG. 8 is a flow diagram illustrating an example of a hierarchical utilization of framework grouping aspects according to an embodiment of the invention;

FIG. 9 illustrates an example of compositing using framework grouping aspects, according to an embodiment of the invention;

FIG. 10 is a flow diagram illustrating an example of utilizing of propagative order elements and framework component justification, according to an embodiment of the invention;

FIG. 11 illustrates an example of using an order element in conjunction with justification, decision and progress aspects, according to an embodiment of the invention; FIG. 12 illustrates an example of coupling an order element to operational requirements and an operational process, according to an embodiment of the invention; FIG. 13 is a flow diagram illustrating an example utilizing groups with a shared element, according to an embodiment of the invention; FIG. 14 is a flow diagram illustrating an example of utilizing of time-based variables in conjunction with a resource element, according to an embodiment of the invention;

FIG. 15 is a flow diagram illustrating an example of utilizing time-based variables in conjunction with a resource element and production of multimedia results therefrom, according to an embodiment of the invention; FIG. 16 is a flow diagram illustrating an example of process element relationships, according to an embodiment of the invention;

FIG. 17 is a flow diagram illustrating the example of the FIG. 16, further in conjunction with utilization of a grouping aspect, according to an embodiment of the invention;

FIG. 18 is a flow diagram illustrating an example of variable changes as they relate to time-based variables, according to an embodiment of the invention;

FIG. 19 is a flow diagram illustrating an example of a descriptive requirement, according to an embodiment of the invention; FIG. 20 is a flow diagram illustrating an example of the descriptive process with requirements and parameters, according to embodiment of the invention;

FIG. 21 is a flow diagram illustrating an example of an operational process with requirements, according to an embodiment of the invention;

FIG. 22 is a flow diagram illustrating an example of the descriptive process, and order and a resultant operational process, according to an embodiment of the invention;

FIG. 23 is a flow diagram illustrating a utilization of Or-elements, according to an embodiment of the invention;

FIG. 24 is a flow diagram illustrating a utilization of And-elements, according to an embodiment of the invention; FIG. 25 illustrates an example of a utilization of framework core components as associated with behavior, according to an embodiment of the invention;

FIG. 26 is a flow diagram illustrating a utilization of the state process element, according to an embodiment of the invention;

FIG. 27 is a flow diagram illustrating an exemplary state model, according to an embodiment of the invention;

FIG. 28 is a flow diagram illustrating an exemplary framework integration, according to an embodiment of the invention;

FIG. 29 is a flow diagram illustrating an example of and executed order net, according to an embodiment of the invention; FIG. 30 is a flow diagram illustrating an example of elemental relationships, according to an embodiment of the invention;

FIG. 31 is a flow diagram illustrating an example of a set of group types, according to an embodiment of the invention; FIG. 32 is a flow diagram illustrating an example of order elements typed using groups, according to embodiment of the invention;

FIG. 33 is a flow diagram illustrating a further example of order elements typed using groups, according to an embodiment of the invention; FIG. 34 is a flow diagram illustrating an example of an order element and its associated aspects, according to an embodiment of the invention;

FIG. 35 is a flow diagram illustrating an example of a decision aspect coupled to an operational process, according to an embodiment of the invention;

FIG. 36 is a flow diagram illustrating an example of a decision aspect coupled to an operational requirement, according to an embodiment of the invention;

FIG. 37 is a flow diagram illustrating an example of a decision aspect coupled to more than 1 operational requirement, according to an embodiment of the invention;

FIG. 38 is a flow diagram illustrating an example of a justified order network ("order net"), according to an embodiment of the invention; FIG. 39 is a flow diagram illustrating an example of and order quantity split scenario, according to an embodiment of the invention;

FIG. 40 is a flow diagram illustrating an example of an order and product/process split scenario, according to an embodiment of the invention;

FIG. 41 is a flow diagram illustrating an example of and order quantity merges scenario, according to an embodiment of the invention;

FIG. 42 is a flow diagram illustrating an example of and order quantities split and merge scenario, according to an embodiment of the invention;

FIG. 43 is a flow diagram illustrating an example of a simple aggregated manufacturing order network, according to embodiment of the invention; FIG. 44 is a flow diagram illustrating an example of and order network in conjunction with AMOs and DMOs, according to an embodiment of the invention;

FIG. 45 is a flow diagram illustrating an example of a grouping of purchase line item orders into a purchase order, according to an embodiment of the invention;

FIG. 46 is a flow diagram illustrating an example of ResourceElements and requirements, according to embodiment of the invention;

FIG. 47 is a flow diagram illustrating an exemplary design of a TimeBasedVariable class implementation, according to an embodiment of the invention;

FIG. 48 is a flow diagram illustrating an exemplary utilization of a time-based variable and time-based profiles, according to an embodiment of the invention; FIG. 49 is a flow diagram illustrating and implementation subset of types of time- based variables, according to an embodiment of the invention;

FIG. 50 illustrates an example of a discrete-valued time-based variable change and a multimedia presentation producible therefrom, according to an embodiment of the invention; FIG. 51 illustrates an example of a continuous-valued time-based variable change and a multimedia presentation producible therefrom, according to an embodiment of the invention;

FIG. 52 is a flow diagram illustrating an exemplary lifecycle state model for a manufacturing order, according to an embodiment of the invention;

FIG. 53 illustrates exemplary timelines for a quantity completed and lifecycle state time-based variables, according to an embodiment of the invention;

FIG. 54 is a flow diagram illustrating an exemplary DescriptiveProcessElement class implementation, according to an embodiment of the invention;

FIG. 55 is a flow diagram illustrating an exemplary Processlnstructions Aspect class implementation, according to an embodiment of the invention; FIG. 56 is a flow diagram illustrating an exemplary DescriptiveRequirement class implementation, according to an embodiment of the invention;

FIG. 57 is a flow diagram illustrating an exemplary ParameterContext and ParameterValueContext class implementation, according to an embodiment of the invention;

FIG. 58 is a flow diagram illustrating an exemplary formula class implementation according to an embodiment of the invention;

FIG. 59 is a flow diagram illustrating an exemplary DescriptiveTimeSpecification class implementation, according to an embodiment of the invention;

FIG. 60 illustrates an exemplary set of formulas used to establish time periods, according to an embodiment of the invention; FIG. 61 illustrates an exemplary set of time relationship examples, according to an embodiment of the invention;

FIG. 62 illustrates an exemplary set of change-types examples, according to an embodiment of the invention;

FIG. 63 is a flow diagram illustrating an exemplary DescriptiveVariableChange class implementation, according to an embodiment of the invention;

FIG. 64 is a flow diagram illustrating an exemplary DescriptiveDecimalChange class implementation, according to an embodiment of the invention;

FIG. 65 is a flow diagram illustrating an exemplary DescriptiveQuantityUnitChange class implementation, according to an embodiment of the invention; FIG. 66 is a flow diagram illustrating an exemplary DescriptiveStringChange class implementation, according to an embodiment of the invention;

FIG. 67 is a flow diagram illustrating an exemplary OperationalProcessElement class implementation, according to an embodiment of the invention; FIG. 68 is a flow diagram illustrating an exemplary OperationalRequirement class implementation, according to an embodiment of the invention;

FIG. 69 is a flow diagram illustrating an exemplary AndElement and OrElement class implementation, according to an embodiment of the invention;

FIG. 70 is a flow diagram illustrating an exemplary ProcessTransition class implementation, according to an embodiment of the invention;

FIG. 71 is a flow diagram illustrating an example utilizing start, and, and unconditional process transitions, according to an embodiment of the invention;

FIG. 72 is a flow diagram illustrating an example of a conditional process transition implementation, according to an embodiment of the invention; FIG. 73 is a flow diagram illustrating an example of eight loop process transition implementation, according to an embodiment of the invention;

FIG. 74 is a flow diagram illustrating an example of a StateProcessElement class implementation, according to an embodiment of the invention;

FIG. 75 is a flow diagram illustrating an example of a StateTransition class implementation, according to an embodiment of the invention;

FIG. 76 is a flow diagram illustrating an example of a state transition operation implementation, according to an embodiment of the invention;

FIG. 77 is a flow diagram illustrating an example of a TriggerRule class implementation, according to an embodiment of the invention; and FIG. 78 is a flow diagram illustrating an example of an Activity class implementation, according to an embodiment of the invention.

DETAILED DESCRIPTION In providing for business modeling framework system and methods, embodiments of the invention enable business operations within or between one or more enterprises to be flexibly conducted in an automatic (e.g. programmatic), user facilitated or combined manner. Embodiments provide for implementing frameworks including framework component information, and elements for statically and/or dynamically transferring the framework component information to/from suitable business systems, persistent stores, other systems and/or portions/combinations thereof.

Embodiments further enable framework implementations in which a framework includes core framework/business system components ("core components") that are configurable and combinable for unitarily, collaboratively or propagatingly conducting business operations within a suitable business system according to varying business models and/or business operations facilitation. Embodiments also enable operations to be conducted in accordance with intra or inter-enterprise process slices, business applications or various combinations of one or more of these or other suitable composite business operations.

Note that the term "or", as used herein, is generally intended to mean "and/or" unless otherwise indicated. The term "portion" will also be used to refer to an entirety or a part thereof. Additionally, the term "enterprise" will be used to refer to an enterprise portion (e.g. one or more of a corporation, its various owned or controlled companies, business units within the corporation or companies, or other discemable subdivisions that might apply); the term "entity" will also be used to refer to a lesser enterprise portion where a discussion of greater and lesser enterprise portions might otherwise be confusing. Particular "Skyva" implementations, agent networks, agents or other implementations may also be referenced, such that various aspects of the invention might be better understood. It should be understood, however, that such implementations are merely exemplary and should not be construed as limiting.

FIGS. 1 through 4 illustrate examples of how one or more frameworks can be implemented to operate in conjunction with business systems. FIGS. 1 through 4 are taken from FIGS. 1, 2, 3a and 7 respectively of the above-referenced agent network provisional patent application. (Note that the agent network application uses the term "entity" as synonymous with "enterprise" as given above; for clarity sake, these terms will instead be used as already discussed herein.)

Framework and Business/Runtime Systems Integration Beginning with FIG. 1, each of frameworks 102d, 103d and 105d serves a dual role. Each framework provides to a business system portion operational building blocks and (any applicable) data or "framework component information" according to which that portion can then operate. The framework components set forth the architecture, controls and operations that can be conducted by the corresponding business system portion. Each framework further provides for receiving from the business system portion framework component information and causing the information to be persisted. While in the typical case one framework might operate in conjunction with a given business system, more than one framework can also be used in conjunction with a system or subsystems of that system. (Note that, while persisting is typically conducted by the framework, persisting can also be conducted outside the framework, e.g. using more localized storage for transient data, real-time data, data that is less critical to the integrity of the business system, and so on.)

In the FIG. 1 example, each of frameworks 102d, 103d and 105d is separately hosted by a respective processing systems (servers 102a, 103a and 105a) of a corresponding enterprise subsystem within a distributed inter-enterprise business system portion (indicated by executors 110). The business system can, for example, include one or more of manufacturing, process, service, engineering, administrative or other sub-system portions for performing various operations within the respective enterprises along a supply chain. Each subsystem can also include further subsystems. The various levels of subsystems might, for example, be configured by the framework components to conduct local operations alone or in conjunction with inter-subsystem interaction via a local area network (e.g. intranets 101b and 101c). The various levels of subsystems within an enterprise might also similarly be configurable for interoperating with other enterprises over a wide area network or "WAN" (e.g. Internet 101a), among other possibilities. Servers of business system 100 can also be coupled to or include storage media onto which framework component (or other) information can be persisted or otherwise stored. It will become apparent that persisting of framework component information (typically including storage and retrieval of such information) can be conducted in a conventional manner, in a manner not inconsistent with the examples provided herein or otherwise by one or more of a framework, server or other suitable system elements.

FIG. 2 illustrates an exemplary processing system 200, that can comprise one or more of the elements of FIG. 1 or the remaining figures. While other alternatives might be utilized, it will be presumed for clarity sake that the elements discussed herein are implemented in hardware, software or some combination by one or more processing systems consistent therewith, unless otherwise indicated.

System 200 comprises elements coupled via communication channels (e.g. bus 201) including one or more general or special purpose processors 202, such as a Pentium® or Power PC®, digital signal processor ("DSP"), etc. System 200 elements also include one or more input devices 203 (such as a mouse, keyboard, microphone, pen, etc.), and one or more output devices 204, such as a suitable display, speakers, actuators, etc., in accordance with a particular application.

System 200 also includes a computer readable storage media reader 205 coupled to a computer readable storage medium 206, such as a storage/memory device or hard or removable storage/memory media; such devices or media are further indicated separately as storage device 207 and memory 208, which can include hard disk variants, floppy/compact disk variants, digital versatile disk ("DVD") variants, smart cards, read only memory, random access memory, cache memory, etc., in accordance with a particular application. One or more suitable communication devices 209 can also be included, such as a modem, DSL, infrared, bluetooth or other suitable transceiver, etc. for providing inter-device communication directly or via one or more suitable private or public networks that can include but are not limited to those already discussed.

Working memory further includes operating system ("OS") elements and other programs, such as application programs, mobile code, data, etc. for implementing framework or other elements that might be stored or loaded therein during use. The particular OS can vary in accordance with a particular device, features or other aspects in accordance with a particular application (e.g. Windows, Mac, Linux, Unix or Palm OS variants, a proprietary OS, etc.). Various programming languages or other tools can also be utilized, such as those compatible with the Java 2 Platform, Enterprise Edition ("J2EE"), C#/.NET or other platforms/languages. Embodiments can also include a network client such as a browser or email client, etc., e.g. as produced by Netscape, Microsoft or others, and a suitable mobile code executor, such as a Java Virtual Machine ("JVM"). (Embodiments might also be implemented in conjunction with a resident application or combination of mobile code and resident application components.)

One or more system 200 elements can also be implemented in hardware, software or a suitable combination. When implemented in software (e.g. as an application program, object, downloadable, servlet, object, procedure, etc. in whole or part), a system 200 element can be communicated transitionally or more persistently from local or remote storage to memory (or cache memory, etc.) for execution, or another suitable mechanism can be utilized, and elements can be implemented in compiled or interpretive form. Input, intermediate or resulting data or functional elements can further reside more transitionally or more persistently in a storage media, cache or more persistent volatile or non-volatile memory, (e.g. storage device 207 or memory 208) in accordance with a particular application.

FIG. 3 illustrates how a business system portion facilitated by a framework embodiment can, but need not, provide functionalities consistent with one or more conventional application programs, or utilize conventional application program elements. As shown, business system 300 includes a virtual agent network of distributable agents 303a-m, 311, 304a-g and 321 that are capable of inter-operating with each other and with conventional business application program elements 312a-c.

The virtual agent network is further overlayed onto a physical network. Agents 303 a- j and 311 correspond to a first enterprise and are hosted by one or more first enterprise processing systems coupled by LAN 305a. Agents 303k-m and 321 correspond to a second enterprise and are hosted by one or more second enterprise processing systems coupled by LAN 305b. Agents 304a-g correspond to a third enterprise and are hosted by one or more third enterprise processing systems coupled by LAN/WAN 305c. The depicted and other enterprises (e.g., given by "links" to agents 303j-k, 304g and 304j) are further coupled via physical network elements for enabling inter-enterprise communication (not shown for clarity sake). It will be appreciated that other wired/wireless couplings, local, remote, handheld or other processing system types, other business system portion or framework portion embodiments, or other elements/permutations can also be utilized in accordance with a particular implementation.

Each of the system 300 agents is populated by framework component information of one or more frameworks (not shown) for performing a respective slice of the business operations or functionalities that are capable of being performed by business system 300 using the agents. That is, the framework components enable each agent to perform one or more operations that, when combined, form operational slices that are in turn combinable to form complete functionalities (e.g. as compared with conventional application functions); a complete functionality, which can include slices of the same or different conventional applications, might thus be performed by in a unitary manner by one agent or in a collaborative or propagating manner with other agents corresponding to the same or another enterprise. (In other words, a slice enabled by framework component information can have a variable operation-combination granularity that is typically smaller than a function, such that functionality flexibility can be maximized or merely extended to the applicable limitations of the implementation; a static implementation might also be used.)

For example, agent 304b, which is configured for conducting higher level planning operations, might conduct a portion of a functionality alone or "unitarily", while agents 304d- f might operate sequentially or concurrently in a collaborative manner to determine optimal scheduling. Agent 304d-f operations might further propagate to/from corporate plan agent 304a or outsourcing agent 304g, or further to/from plan agent 304b and possibly 3^rd party (e.g. different enterprise) agent 304j or exchange agent 303 g in accordance with producing a given composite functionality (e.g. to coordinate enterpriseA-plantl planning with enterpriseA- plantN manufacturing, enterpriseB component supply, some enterpriseC contribution, and so on, which might further occur concurrently with or without human intervention).

It will become apparent as the discussion progresses that framework components can provide varying operability/functionality in accordance with a static or changing business model, application or other considerations merely by varying component combinations and without reprogramming or otherwise modifying framework components. It will further be appreciated that similar variability can also be achieved with respect to the operations/functionalities of agents or other system elements of a suitable system that is operable in conjunction with a framework embodiment according to the invention.

A framework embodiment can further be configurable for dynamically transferring framework component information to/from an agent network element or other suitable business system element. Thus, for example, operations/functionalities of one or more of the system 300 agents (or other business system elements) can be similarly rendered modifiable via transfer of framework component information between a framework and the one or more business system elements while the business system is operable. (Note that, for brevity sake, the term "operation" will hereinafter also include any resulting slice or functionality, unless otherwise indicated.)

System-level operation of system elements might also be rendered similarly modifiable. For example, broker-agent operation (e.g. storing inter-agent communication parameters or initiating such communication) might be enabled or disabled via such transfer. In a framework embodiment in which a framework behavior is provided (see below), the behavior might further be used to coordinate business system modifications, e.g., by disabling one broker-agent and establishing a different broker-agent, enabling/disabling co-supportive operations among two or more agents, and so on, among other mechanisms that might be used alone or in conjunction therewith. FIG. 4 illustrates an example of a framework implementation capable of providing framework components to a business/runtime system element and of persisting framework component information received from a business/runtime system element. For clarity sake, the present example again utilizes an agent network, and more particularly, the combination of a Skyva framework implementation and a Skyva object-based agent network implementation. (It will be appreciated, however, that other suitable framework and framework-facilitated system implementations are also enabled by the teachings herein.)

As shown in FIG. 4, the framework implementation or "framework-system" comprises framework 401 including framework components information (not shown) and a framework-system behavior component implemented as state model 401a. The framework- system also comprises a framework component transfer system including loader 402a and saver 402b, and a persistence system including persistor 403 and persistent store 404. System 400 also includes agent 405, which includes an abstract data model ("ADM") 406, and which agent is coupled via user interface 407 to a user. For present purposes, ADM 406 can be considered a container for containing framework components associated with agent 405.

The depicted framework system example is configured for interoperating with agent 405 (and other facilitated system elements) both during agent initialization, and further, dynamically in concurrence with agent 405 operation. At system 400 startup and prior to agent initialization, the framework-system is initialized by transferring to framework 401 via persistor 403 framework component information stored in persistence store 404 (e.g., at least that portion of component information corresponding to the business or runtime system portion hosted by agent 405 and other facilitated system elements). Persistor 403 operates as a (framework system managed) database manager for querying the database (or other) structure of store 404 and retrieving requested framework component information. During agent initialization and thereafter, loader 408 provides for requesting framework component information from framework 401. Framework 401 provides for identifying a more specific area in which the requested information is stored, gathers the information and provides the information to loader 402b, which transfers the information to agent 405. Unlike conventional application programs, in which the application data model drives the system functions in a direct one-to-one correspondence, embodiments of the present invention enable application driven component storage, communication and delivery optimizations. For example, generally, framework 401 is capable of storing framework component information in a more suitable "supply" form for providing the component information to various business/runtime system elements, while further enabling the each of the elements to store information in a "deployed" form more suitable to the one or more manners in which each element operates within the business/runtime system.

In the more specific current object-oriented example, the framework 401 is based on the framework object model (see below), and it is that model, which schema is mapped by the relevant application server (e.g. IBM San Francisco, BEA WebLogic, Websphere, ADO in .Net, and so on.) into a suitable representation for the persistence database (e.g. where relational, to MS Sequel Server, DB2, Oracle, etc.). The abstract data model or "ADM" of agent 405 is an object data model which, while borrowing elements from framework 401, is only in-memory at runtime and represents a normalized view of the data specifically for that application. (It will be appreciated, however, that the particular forms utilized can also be optimized in accordance with the constraints of a particular application.)

Framework System FIG. 5 illustrates a framework system embodiment in greater detail. In this example, the aforementioned loader and saver are separately implemented and are not part of the framework system. However, an included controller and component locator facilitate saving and loading as discussed below. It will be appreciated that the loader or saver might be implemented as further framework system control elements, or the controller and component locator might be otherwise implemented, and so on.

As shown in FIG. 5, framework system 500 includes framework controller 501, component locator 501a and framework 502. Framework 502 further includes core components 502a, component aspects 506a, characteristics 506b, component state machines 507 and framework state machine 508. In the present example, framework system controller 501 operates in conjunction with component locator 501a to initialize framework system 502 and, further in conjunction with framework state machine 508, to initiate initialization of a business system portion facilitated by the framework system. During framework system 500 initialization, controller 501 receives from a persistent store and stores in component locator 501a a mapping of framework component information and any business system security information corresponding to business system elements. Controller 501 also similarly populates framework 502 with framework component information that has been persisted to an external persistence store (e.g., see above), thereby assuring system integrity in the event of a framework/business system portion anomaly. During business system initialization, controller 501 transfers to a business system element (via a loader) framework component information indicated by the mapping associated with that element. (Framework system 500 might also operate responsively to one or more requests for business system portion initialization, among other alternatives.) Controller 501 also similarly uses the component locator mapping to supply framework component information to business system elements and to persist framework component information received from a business system portion during dynamic business system reconfiguration. (See also the above initialization and dynamic reconfiguration discussions.) The static, object-oriented framework example 502 provides a unique foundation of behavior-independent and link-independent core, coupling, data, justification and behavior components, and other features that enable diverse business system or "supply-chain" problems to be described as substantially a consequence of physical reality. In actuality, however, the components and other features might be more aptly described as providing an abstract superset within which a wide variety of different and even mutually exclusive physical realities can nevertheless be facilitated. In fact, framework 502 may be extended and applied to substantially any business process. Thus, while more common labeling is provided to facilitate a basic understanding, the framework architecture and implementation are unusually capable. (For example, since framework 502 is static and does not include behavior patterns, attributes provided to classes at their most abstract levels do not require alterations to form different relationships with other classes.)

Since the intricacies of framework embodiments according to the invention can become confusing without some basic understanding, we will begin with a broader overview of the framework elements and then separately consider embodiment details.

Returning now to FIG. 5, core components 502a include order elements 503, resource elements 504 and process elements 505. These three elements represent the most abstract class within framework 502: the core component class. It is through extending core component subclasses and expressing their attributes and relationships that business objects are modeled.

Order element 503 describe why a requested activity occurs, and may be more easily viewed as an abstraction of a traditional customer order. Within a business/runtime system, however, order elements are propagative (typically at the slice level), enabling not only sophisticated decision-based operation and communication by some or even all system elements, but also providing a vehicle for collaborative, propagative or combined processing

(e.g., see order justification and order network below). Order elements 503 can express a request and provide the motivation for a subsequent process. They can also be used for hierarchical, top-down communication between, for example, central planning and plants, or for horizontal communication, for example, between a plant and vendor regarding a purchase order. They can further be utilized in various groupings, among other features. Of the remaining core components (and in accordance with the particular framework

502 of components), resource elements 504 are abstractions that, rather than describing merely available input, describe the "means of activities" or processes, or their associateable capacities. They are "capacity-indicating" or "capacitative," being capable of indicating things used, consumed or produced during an activity, as well as their availability and the extent of that availability (over and above their physical reality). Resource elements 404 can, for example, represent such things as the work centers, machinery, personnel, services, time, lots, batches, raw materials, finished products, and so on, as well as the extent to which they are available.

Process elements 405 are further abstractions that can again encompass differing perspectives in order to meet differing application requirements. Process elements 405 are more specifically "constraintive" or "definitive" in that they represent -within the vastness of possible activities- those activities that should or did occur, again typically at the slice level. Process elements 405 can range from "master" process descriptions or "descriptive" processes, to a record of a concrete "operational" activity ("predictive" or "actual" processes), such as a manufacturing process, service or other activity.

Turning also to FIG. 6, core component aspects ("aspects") provide an association mechanism for more specifically representing core components in a readily modifiable and replaceable manner without requiring modification of the core components themselves. In the present example, aspect 506a subclasses hold and provide data attributes of the core components ("header aspect" subclasses) and provide for association between/among the core components 502a, and other classes ("relationship aspect" subclasses). Aspects 506a are also subclasses of the core components and, as such, inherit the attributes and associations available to their superclass (FIG. 6).

It will become apparent that not all of the subclasses of the aspects class available within framework 502 will apply to every situation; instead, aspect classes are optional, configurable classes. Taken together, aspects 506a form a design pattern within framework

502 and provide for defining the following five concepts by way of associative aspects that are shared by all core component classes: descriptions; groupings, relationships, state behaviors; and change tracking. In framework 502, for example, these shared aspects and their associateiveness provide a core of modularity and reusability not only as an associative mechanism, but also as a functional implementation with the aspects forming a fundamental basis of all business systems.

The aspects corresponding to the five concepts can be broadly described as follows. (Further descriptions and examples are also provided following the current summary.) Description aspects enable the assigning of long and short descriptions to the objects, which descriptions can be made in different languages.

Grouping aspects organize the core components/data both structurally and in terms of type. Each instance of a core component element may be a member of one or more groups, but may be a member of only one group type. For example (FIG. 7), a Service Technician 705 might be a member of a Customer Service Employees group 704 as well as a member of a Salaried Staff resource element group (not shown) because that group would be a different type representing different data. However, a Service Technician could not simultaneously be a member of a Customer Service group and a Shipping Employees group. The reason is that, in this particular implementation, the group type is used in the group aspect of a core component and states the name of the group to which the core component belongs. Since groups are implemented as strictly hierarchical and not nets a duplicate record exception can occur (e.g. with a group aspect for a REl with a group type Group_RE) with the group type taking the group name. So, for the same to be in two different groups, they must have different group type. (A different naming or grouping convention or other alternatives can, of course, also be used in other implementations.)

Continuing with FIG. 8, each of the core components can also have a more detailed substructure. There is no limit on the number of levels in this structure, and additional groups or group members can be added, modified or removed at any level, thus enabling an unlimited nesting mechanism for representing and accessing more specific instances of the core elements/data.

The process model example of FIG. 9 further illustrates how grouping can also be used to access/utilize composite characteristics of group members (here, enabling the state of one process to be incoφorated within another process). As shown, a batch process has two sub-processes including Reaction Operation 901 and a Filtration operation 902, and Reaction Operation 901 further includes Loading, Cooking and Discharge sub-processes 911-913. The use of a grouping aspect, for example, enables the state of BP1 to be understood (or measured) by the composite of the state of its sub-elements, such that BP1 can be determined to be not completed until both Reaction and Filtration have been performed (including sub-processes 911-913).

Of the remaining shared attribute components, relationship aspects represents how one or more of core components 502a (FIG. 5) are associated one or more other ones of core components 502a in a network structure. State behavior aspects further link a core component and a core component state model 507. Finally, change tracking attributes provide for recording information corresponding to implement changes. For example, log aspects enable the tracking of the creation or modification of a core component, including the creation change and associated username.

Of the remaining framework 502 elements, characteristics 506b (via a characteristic value assignment class) provide for user and future definition of attributes for which aspects do not (yet) exist. Like aspects 506a, characteristics 506b can be associated with any of the core component classes. Core component state machines 507 provide dynamic state models that are associated to associateable core components 502a and that provide for core component behaviors. Finally, framework state machine 508 provides for framework-level behaviors (e.g. see above). Framework state machine 508 is associated with framework 502, but might further be associated with core components 402a or other framework system or business system elements in accordance with the requirements of a particular application.

The discussion will now consider framework system and method examples in greater detail, first from the point of view of component relationships within a static framework, and then from the point of view of dynamic business system facilitation. For consistency and greater clarity, the following discussion will also build on the examples of FIGS. 5-9 rather than departing in order to particularize the broad range of enabled embodiments.

Returning again to FIG. 5, order elements 503, being an abstraction, can also accommodate a perspective other than communication of decisions. Additionally, order elements 503 can also operate within a business system as requests that provide the motivation and drive for business activities. Order elements 503 can also operate within a business system as communication devices between different sections of a supply chain that can be related horizontally across organizational or physical boundaries or vertically between different aggregation levels or time resolutions.

Such order element capabilities can further be combined, thereby enabling a particularly wide range of physical reality instances to be facilitated by this single core component type. For example, horizontal communications of requests can include a communication between a manufacturing enterprise and a vender or other provider. Vertical communications can include a communication between an enteφrise planning or forecasting system and an order fulfillment scheduling system. Horizontal and vertical communication combinations can also be facilitated, for example, where communication is conducted between an enteφrise planning or forecasting system and an order fulfillment scheduling system of a different outsourcing enteφrise, among still further examples (e.g., see FIG. 3).

Static Core Components: Order Elements

Continuing with reference to FIG. 10, such order element flexibility is also co- supportive with regard to providing for propagative order elements that are capable of operating as a virtual order net within a framework facilitated business system. Broadly stated, an order net provides a flexible mechanism whereby a facilitated business system need not operate in an application sense, but can also operate in accordance with a decision making process (and further, at a finer operational granularity of a business process slice). Such operation can further be conducted propagatively or collaboratively, and such propagation can further be conducted manually or automatically among the same or different enteφrise portions and even enteφrises. At the same time, order element flexibility simplifies integration and facilitates reuse of the abstracted order elements, which elements can further be extremely lightweight, thereby minimizing the bandwidth required to exploit the order net.

Order nets will be considered in greater detail below. For now, the simple order net examples of FIGS. 10 and 11 will be used to better illustrate framework component relationships.

Viewing propagative orders as communications between decision makers and order nets as mapping the decision process in a supply chain, an examination of the order net 1000 of FIG. 10 reveals a (an order) "life cycle" in which each of order elements 1001-1005 is created, accepted or rejected and, if accepted, progresses through its execution as successive order elements propagate through the order net. Facilitating this abstraction are three order element aspect types associated with each of order elements 1001-1005: justification aspects, decision aspects and progress aspects.

Chart 2 below indicates the operation of the three aspects. As shown, a justification aspect (e.g., "J" 1011 of FIG. 10) is associated with an order element when the order element is created and holds justification information indicating the reason for creating the order element, or "why the order element exists". While such information can vary in accordance with a particular application (e.g., an indication that a prior justifying initial order or order set in motion by the initial order, conditions, reasons, etc.), the order elements 503 justification aspects of FIG. 5 store information identifying the prior order element. A decision aspect (e.g., "D" 1012) contains the disposition of an order element which, in the present example indicates whether the order element has been accepted or declined (here, in its entirety and without a reason/condition). Finally, a progress aspect (e.g. "P" 1013) keeps information about the fulfillment or condition of fulfillment of an order element until the order element has completed its lifecycle (is executed). (Note that, in accordance with the framework 502 example, an order element can be associated with one or more justification aspects, but only one decision aspect and only one progress aspect.)

In FIG. 10, for example, the arrows point from a "justified" order to the "justifying" order, such that sales order 1001 justifies purchase order 1002 and manufacturing order to produce the product to fulfill the order. When the manufacturing facility planned the execution of the manufacturing order, two execution orders were generated and justified by the manufacturing order. Even in the simple example of FIG. 11, we can perceive that the justification aspect involves several other potential orders elements (for food, companionship, getting out of the house) and one or all of these justifying order elements may be related through the justification aspect to the justified order element, "the dinner date." In turn, the requirement of a mode of transportation (a resource element) involves a decision as does the timing of the operation. The data used to determine these operational requirements is held in the decision aspect, and a decision aspect might also be used to contain the operational process that proposes the appropriate resources as well as formulating a delivery date (in this example, a time of arrival). Until the process begins, however, all of the data that is available is based upon assumptions and predictions. The progress aspect collects that data that is available once the order element starts. This includes information about the actual state of the order element such as levels of completion or the number of completed pieces (for a detailed order). Note that, because an order element within an order net may have more than one other order element justifying it and an order element may justify more than one other order element, order elements may be split or merged depending upon their relationship with each other in terms of their justification. Thus, for example, a manufacturing order for 100 widgets might justify a split order of 60 widgets from stock (a stock order or stock transfer) and 40 widgets from a vendor (a purchase order). Likewise, a manufacturing order that justifies a 40-widget purchase order might be merged with another purchase order for 500 widgets that is justified by a stock order.

Like the other of core components 503, order elements may also have a group aspect associated with them. Because of this aspect, multiple order elements within a group may be considered as a single logical order. Thus, for example: line items may be grouped into one customer order, purchase line items may be grouped into one purchase order, manufacturing orders may be grouped together, and transfer orders may be grouped into one shipping order, among other examples. Additionally, when used with a header aspect, the group aspect allows multiple items to be treated as one logical order under one header aspect, which, in turn, can be linked directly to other related information (e.g. regarding a customer, in the case of a customer order, or a vendor in the case of a purchase order). Continuing with the FIG. 12 example, order elements (and the order element class) can further be associated with resource elements using an operational requirement. While the more specific details of this association also relate to process elements and are discussed below, it should now be noted for completeness that any of the three primary aspects

(decision, justification, or progress) of an instance of an order element may be associated with one or more operational requirements, each of which can, in turn, be linked to a resource element.

FIG. 12 also shows how a justification aspect ("JA") 1202, a progress aspect ("PA") 1203, and a decision aspect ("DA") 1204 of the same order element 1201 can be linked to operational requirements 1221, 1231, 1241, and a progress aspect 1203 and a decision aspect 1204 can further be linked to operational processes (which mirror descriptive processes). However, while a justification aspect 1202 can be linked to an operational requirement, it cannot be linked to an operational process. This design constraint is imposed because, while a justification aspect links orders and provides the reason behind the justified order, that aspect needs no direct reference to the operational process itself. On the other hand, decision and progress aspects need to be connected to an operational process in order to have access to data regarding the predicted (decision aspect) or actual (progress aspect) process.

Resource Elements We now turn to resource elements 504 (FIG. 5). As with order elements, resource elements 504 are named as such to instill a basic frame of reference for non-technical users. However, resource elements 504 represent an abstraction that instead covers a multiple- perspective superset encompassing all enablers of activities - or essentially everything potentially or actually capable of being utilized or otherwise affecting activities (e.g. see above). Within this superset are more traditional work centers and personnel resources, but also all materials, lots, and batches, as well as such enablers of activities as pollution permits and overtime pools, among other examples.

In addition, no distinction is made in this core element embodiment between the representation of consumable resources and that of non-consumable resources (e.g., where the same resource used as a tool in one manufacturing process has been previously manufactured in another process). This minimizes the number of ways in which a resource must be identified, and instead puts the responsibility of determining such a distinction on the processes that use the resource element as a requirement.

Because framework 502 uses resource elements to represent a wide variety of objects, the aspects that define those resources are numerous, and can include but are not limited to the following (see Chart 3). Description aspects include multi-lingual descriptions.

Integration aspects indicate aspects relating to integrating a resource element with external planning and scheduling systems, process control systems, laboratory information systems and so on. Location aspects indicate location, location specific parameters or location-type specific parameters. Production aspects indicate capacity, capability or operational data which provide production/process parameters. Inventory/stocking aspects indicate parameters relating to stocking a corresponding resource. Acquisition aspects indicate acquisition data of the corresponding resource, e.g., purchase, harvest, beg, or steal, economical order quantity, etc. Variable aspects indicate information about the recorded, the present, and predicted future values of variables of a resource element. (As with other aspects, these can vary considerably in accordance with a particular application.)

Like the other core components, resource elements may have a group aspect. Unlike order and process elements, however, the nature of resource elements makes their grouping appear more clearly hierarchical. It is easy to see, for example, how a resource element with a group aspect called "customer service" could have several sub-elements.

In a production environment, grouping may create several types of hierarchies that combine to form a product hierarchy (and, in turn, there may be several product hierarchies). For example, in a brewery domain, the resource element "beer" may have multiple sub- elements and any or all of those sub-elements may be the super-element to another group of sub-elements. Of course, end-products are not produced in such a simple fashion. (Even if we assume a production line that includes only three types of beer with three possible types of lager, the various types of packages, labels, shipping cartons and other resources required in the production of beer have yet to be considered.) FIG. 13, for example, illustrates a potential resource hierarchy might be used in the representation of a plant that has three production lines with a total of five machines. In this example, resource elements are created for a plant and each line within the plant, as well as for each machine on the various maintenance and production lines. Note that grouping aspects enable framework components to be shared, such as with the sharing of resource element or "RE" 1304 (Machine 2) by the two group types, maintenance 1302 and production 1303.

Time-Based Variables Framework 502 components, and especially resource elements 504 (FIG. 5), often have properties that change as time changes, such as a machine's availability. In order to represent this changing property, resource elements 504 are associated with time-based variables. In FIG. 14, for example, components 1401-1403 are used to represent a holding tank (resource element 1401) containing a quantity of material that changes over time. Such change can be represented by associating with the holding tank time-based variables 1402 and 1403. In this example, Variable 1402 represents the quantity "level" with values between zero and 400 kg, while variable 1403 represents "use" periods of time during which the tank is connected to other apparatus with possible Boolean values of true and false. Each of these variables provides a different attribute for the resource element "Tank." The rates of these different variable changes are also different. Once the tank is put to use the "Use" variable is made true and, at the same time, the level of the tank changes as materials flow into and out of the tank. (FIG. 15 illustrates how various graphic displays are also producible from the system of FIG. 14).

Process Elements

Process elements 505 (FIG. 5) provide a broadly inteφreted abstraction describing how resources such as products, machines, and people are used to carry out activities. Process elements 505 can, for example, describe not only how to make a product starting from parts or ingredients, but can also include activities, such as those needed to maintain a machine, transport materials, or schedule shipping.

As with other of core components 502a, process element aspects include those inherited from a core component class (e.g. see FIG. 6). Additionally, process element aspects also include a header aspect, which holds basic information about the process element, and the integration aspect, which contains data that allows a process element to be integrated with external system elements, e.g., legacy business system elements (see Chart 4).

Also consistently with the other core components, process elements have a class hierarchy, and at the top of a process hierarchy is the process element (a subclass of core component). Beneath this process representation, however, are subclasses including descriptive process elements (DPEs), operational process elements (OPEs), And-elements, and Or-elements. Descriptive process elements form a hierarchy containing data that indicates how the process is to be performed (e.g., a master process description). Contrastingly, operational process elements store information regarding the actual and predicted process that takes place (or will take place) once that process is executed. In other words, the operational process assigned to an order element decision aspect stores the decisions made on a chosen descriptive process, and the operational process assigned to an order element progress aspect stores data indicating the progress of the order element.

The relationship aspect is also associateable to process elements 504 for coupling together process elements to form sequential process models, coupled stages of a multi-stage process models, or combinations thereof (e.g. see FIG. 16). FIG. 17 further illustrates how the use of the relationship aspect in conjunction with the group aspect enables a "Hole

Drilling" process 1601a to be seen as incoφorating two sub-processes, "Drill Hole" and "Tap Hole." Here, the relationship between "Hole Drilling" 1603a and "Drill Hole" 1604a is coupled via a "Start Process Transition" 1621a that marks the drilling of the hole as the beginning of the process. This process, which links "Drill Hole" 1603a with "Tap Hole" 1604a using "Process Transition" 1623a, ends when "End Process Transition" 1623a couples "Hole Drilling" 1601a with "Tap Hole" 1604a.O

Each of process elements 504 can also be associated with requirements. Requirements, which are also core components of framework 502a, model how a resource element (such as a reactor, a truck, or the service of some member of personnel) is involved (i.e. associated) with a process element. Thus, requirements of a process element also provide a mechanism for representing associations formed as a process utilizes resources.

Rather than merely identifying how a resource element is to be allocated by a process element, framework 502a also provides for determining and utilizing changes in the value of a resource element as the value changes concurrently with a process. More specifically, Variable Changes describe in a qualitative and quantitative way the manner in which a requirement influences a resource element that has been associated with it. Variable Changes are associated on a one-to-one basis with Time-Based Variables that define the behavior of Resource Elements over time (The general structure for requirements is illustrated by FIG. 18).

Descriptive and Operational Processes

As noted earlier, framework 502a also provides for distinguishing between descriptive and operational views of a process. The Descriptive Process defines manufacturing, transport, purchase or other activities in a generic, reusable way in which times and values are further expressed as formulas. An Operational Process (whether actual or predicted), on the other hand, defines those same activities in concrete terms.

Turning to FIG. 19, a descriptive process element (a subclass of the process class of a process element) holds reference data that can, for example, include relative timings, intended temporal constraints, resource choices, and other unbound parameters. A hierarchy can further be formed wherein a descriptive process is created as a subclass of a descriptive process element and serves as a group head for a number of further descriptive process elements. This hierarchical structure permits a number of descriptive process elements to be identified with the same descriptive process. Descriptive requirements further couple resource elements with a descriptive process

(e.g. see FIG. 19). This coupling between resource elements and a descriptive process provides a representation mechanism for allocating resources (represented by a resource element) during a process (represented by a process element). Combined with process transitions (of the relationship aspect), descriptive requirements provide a model of how resources should be utilized during the course of the process.

Each descriptive process can declare multiple parameters, which parameters (e.g. duration, quantity, and so on) enable a more expansive application of the process that can further be expressed using formulas derived in relation to these parameters. For example, by defining requirements based upon formulas that use order quantity as a variable, a descriptive process can represent a flexible structure that can be used by an operational process to determine the actual requirements for an unlimited number of order quantities.

A more specific descriptive process example is illustrated in FIG. 20 in which a process for making water 2001 is parameterized as to duration by a formula. The formula, in this example, stipulates a time period of 15 seconds (2001) for each unit specified by an order quantity 2003 a-b. Additional parameters are also included for requirements of oxygen and hydrogen (2004a, 2004b), the respective quantities of which are formulaically established by again using the order quantity 2005 as a variable. An additional example can be found in the duration formula (equation 1) for a first operation of a hypothetical batch process of the FIG. 20 example:

[Equation 1] duration = quantity / resource.rate

In equation 1 , the resource rate is the fixed variable while the quantity is yet to be decided.

That decision, which can later be communicated by via an order, will provide input corresponding to the quantity, and consequently complete the ratio that will formulate the duration of the operation.

If we further suppose that more than one reactor can perform this operation, and the choice of reactor is dependent on time constraints, this formula could determine whether or not a specific reactor is to be used. Parameters (combined with below-discussed Or-Elements) can thus be used as decision points for alternative process paths.

Continuing with FIG. 21 (which depicts an exemplary operational process corresponding to the descriptive process of FIG. 20), operational process elements store decisions made based on a corresponding (associated) descriptive process. As a subclass of an operational process element, an operational process serves as a group head for a number of operational process elements. This structure permits a number of operational process elements to be identified with the same Operational Process. Operational requirements, like descriptive requirements, couple resources with a process. However, while the requirements of the descriptive process maintain the unbound parameterized formulas, an operational process involves the actual or predicted requirements. It is important to note that while an operational process largely mirrors a corresponding descriptive process, the operational process is further associated with a predicted or actual order that has been made (here, regarding quantity) -or in the abstract terms of framework 502a (FIG. 5): the decision aspect or the progress aspect of the order element has had an operational requirement specified.

Thus, as illustrated in FIG. 22, an interaction can exist in operation within a framework facilitated business/runtime system in which (1) a descriptive process 2201 provides a basis for decision-making by formulating necessary resource requirements, (2) a request is made and communicated (an order takes place via order element 2202), and (3) an operational process 2203 is generated, with parameterized formulas of the descriptive process becoming more specific requirements of the operational process after an order element has provided a corresponding decision (here, to manufacture 500 chairs).

Process Path Facilitation

FIGS. 23 and 24 illustrate how And-elements and Or-elements represent alternative and parallel paths of action in process descriptions that couple other process elements via process transitions. As a subclass of a process class of process elements, And-elements and Or-elements are also subclasses of an underlying core component class and their association with other core components (e.g. process elements) takes place using a process transition class.

As illustrated in FIG. 23, Or-elements 2301 and 2308 provide for implementing or framing path choices within a process. In operation, when a choice between process elements occurs, an Or-Branch element 2301 is used to represent this choice. An Or- Join element 2308 can further be used to return to the process (proper) after the results of the choice have taken place. Thus, for example, a gas industry might use different recipes at different times of the year, the representation of which can be represented by two alternative paths. The choice of path, which is made at Or-Branch element 2301, depends on conditions associated with the process transitions (2302, 2305) following the Or-Branch. (In this example, the evaluation strategy of the alternatives is not defined.) Once the process element alternative has taken place, the process continues toward termination along a path shared by both alternatives. An Or- oin element, e.g. 2308, couples (here, two) alternative process paths after the Or-Branch element. A transition to another step in the process can now occur regardless of whether the Summer or Winter recipe was used.

Like Or-elements, And-elements can involve multiple sub-processes; however, And- elements express concurrent independent processes instead of alternative processes. And- Branch and And- Join elements of framework 502a enable the representation of well-defined start and end of sub-processes in which execution control is in essence split at the And- Branch element and re-synchronized at the And- Join element. In the FIG. 24 example, And- Branch element 2401 effectively splits the process (proper) at process transitions 2402 and 2405 such that the process of filling a railroad car with materials from a silo takes place concurrently with the process of the paperwork for that process being printed 2406, and And- Join element 2408 represents the completion of the two processes prior to their probable transition to the next process (e.g. back to the process proper).

Defining Dynamic Behavior ' While framework core components, their attributes and other associations provide structure for business processes, slices, applications, etc. that are modeled on the framework, they are implemented in framework 502a as behavior-independent. An associateable behavior mechanism, i.e. a state model in the framework 502a implementation, is used to describe the behavior of various objects during the dynamic course of their lifecycles. Components of a state model further include state process elements.

Turning to the FIG. 25 example of a rider responding to a request for a dinner date, two states "A" and "B" mark different parts of the bicycle's progress toward its goal. Assuming that "A" is a first state and "B" is a final state in a process that involves a series of additional intervening states and moves the bicycle from one point to another on the road, we can ask what Event places the bicycle in motion (i.e., a downward push on the left pedal), and, after the process begins, we can examine the subsequent changes (of state) that take place as the bicycle moves from its state- A to state-B. That is, while the generic activity could be represented as a descriptive or operational (predicted or actual) process element, such process is behavior-independent and behavior is applied by modeling the consecutive states and what causes them to interact, and associating the resulting behavior mechanism

(here, a state model) with the corresponding process.

In accordance with framework 502a, a state model defines (from a business point of view) the specific fixed or optional states in the lifecycle of an associated core component (to any of which a state model can be associated), and describes the transitions (triggers and actions) that are involved in moving from one state to another. The state process elements that make up a state model are provided as subclasses of core component class of the core components. A mailbox aspect of a state behavior aspect provides all events that can cause a state change, currently though not necessarily using a simple queue. (It will be appreciated that one or more of various other mechanisms can also be used.) FIG. 26 illustrates an example of one ("current") state of a state model.

Transitions, Trigger Rules and Actions

Like a process transition, the transition from one state to the next in the lifecycle of an object or "state transition" of framework 502a is implemented as a subclass of relationship aspect and can therefore be used to represent a relationship between/among state process elements. The state transition further represents a dynamic change in the state of a core component. An external Event that occurs to an object always causes a decision as to whether or not an action should be triggered. The specification of one or more conditions, events or times that govern that trigger (i.e. the transition's "trigger rule") then determines the action that will occur and the subsequent state.

Evaluation according to trigger rules determines if a state transition is valid, and if so, an action corresponding to the trigger rule is executed. When an Event occurs to an object associated with a transition, the associated trigger rule evaluates if the conditions comprising the trigger rule and necessary for its associated action are true or false. If "true," the action is executed; if "false," the action is not executed. Time may also play a part in this determination, and the framework 502a implementation includes conditional trigger rules and timer trigger rules. (In framework 502a, no action is taken on an evaluation as false. However, no action, an exception or some other false condition action or some combination might be taken, and so on, in accordance with a particular implementation.) When a state transition occurs, an action is executed and the state is changed; actions therefore correspond to the "true" evaluation of trigger rules.

In the FIG. 27 example, a state process 2701 associated with and representing the behavior of Machine 1 2701a is shown having an "Idle" state 2703 and an "Active" state 2705. Trigger rule 2706 and its associated Action are coupled to the State Transition 2704 that takes place between the two states. While it is clear in this example that the rule "if the button is pressed, start the machine" 2709 and the "activate machine" action 2707 form the transition that takes Machine 1 from its idle state to its active state, not all rules are so straightforward or actions so simply defined. However, the same principle applies in a framework 502a facilitated system any time an event causes a transition from one state to another.

Integrating the Framework Mechanisms capable of being used for integrating framework embodiments according to the invention with other applications are as various as the number of applications themselves. However, while it is unlikely that a model of one process or a simple set of processes will adequately cover all the alternatives available in any business 's operations, such framework embodiments enable processes to be parameterized and alternatives created that allow for the dynamic configuration of products, the use and selection of materials, the assignment and scheduling of plants, machinery, and personnel, as well as the choice of various routes or (chemical) recipes, and so on. Then, by filling in the functional gaps of an existing system (using a suitable framework embodiment) and integrating that with existing systems, an application can be created by extending the framework so that its components can receive data from and provide data to legacy systems (e.g. see FIG. 28). In this way, the specific circumstances of the business operation are connected to the generic objects of the Framework. Consequently, the static framework serves as the foundation for a dynamic utilization of data and a corresponding ability to produce customized results in a just-in-time environment. Through parameterization of the various processes involved in manufacturing a product, a complex web of potential alternatives can be managed from the point of the initial request (or order) with the relevant planning and scheduling tasks already performed. FIG. 29, for example illustrates how, as the order network or "order net" is executed and the multiple functions related to the order are carried out, the path chosen for each process can be dependent upon the data provided. In turn, the specifics of the order determine the fastest and most economical means of production as well as the time necessary to produce the end product. All of these steps are also readily traceable.

Ultimately, therefore, the generic framework objects provide a common data model that can nevertheless be used in an unlimited number of industry-specific solutions. These solutions include the mechanisms of planning and scheduling events almost instantaneously, with or without human intervention. The power of various framework embodiments is achieved not only by the design of individual objects, but also by creating objects that freely and consistently interact. FIG. 30 provides only a "snapshot" of what one moment in time might look like in accordance with framework 502a. However, the intricacies of the framework and the restraints of a two- dimensional 8 ^lA x 11 page do not allow for a total picture of all the inter-relationships. FIG. 30 provides an abbreviated look at how a business process might be modeled using the design features of the framework. Using the formulas and reference data contained in a descriptive process, a decision could be made to begin an operational process (and use a resource) and that decision could also justify subsequent orders that would, in turn, involve additional processes and resources. Along the way, the behavior of each order, resource, or process can be examined at various stages. (In FIG. 30, the current state of a resource element is represented.)

In considering just a few of the numerous varying embodiments that might be utilized in accordance with the invention, the following brief overview of framework 502a feature implementation considerations might be useful.

A framework 502a descriptive process contains unbound parameterized formulas that tell how a resource should and can be used, with the descriptive process data being used as reference information for decision-making. For example, a descriptive process might provide parameters for how much of a Resource Element is to be used or how long a resource element should be employed. This information can then be used to plan and schedule an Operational Process that would have specific requirements.

Using the information contained in a descriptive process, an associated order element (operating in a decision making, communicating or other or combined capacity) can determine how the required resource elements will be utilized during a proposed operational process. The operational process stores these decisions made on the descriptive process and can maintain data regarding a predicted process or actual process. At the same time, once the decision aspect has determined operational requirements and an operational process has begun, the progress aspect of that same order element can collect data from the ongoing process. Every order may also generate subsequent orders, creating an Order Net. (For example, a customer order, for example, may cause a manufacturing order, which may, in turn, cause a purchase order for needed resources. The justification aspect coupling order elements carries this causal information.) In addition, all core components (resources, orders, processes) can be aggregated into groups (or disaggregated if you reverse the thought-process) using the group aspect, and all core components can have their behavior represented in an associated state model, using the state behavior aspect.

The reusable generic software (or hardware) parts that form the set of building blocks that are framework 502a allow for the most complex business situations to be modeled by reducing them to their most basic components. By beginning with an understanding that all business processes can be abstracted in such a manner that they can be represented, at their base, by the same elements and associations, we can start to determine the patterns that recur within those associations. Subsequently, it is the utilization and the re-utilization of these patterns that enables framework 502a to be efficiently applied to multiple industries while tackling multiple enteφrise-wide challenges.

In other words, the ability to model a myriad of specific business circumstances is made possible in part because the generic model contains all that is necessary as a foundation for any business situation. What is applied in the specific is created first in the abstract. At the most abstract level of the framework, therefore, it is important to remember that each of the core components represents a unique data structure. The associations that are developed between the core components are based on their primary attributes and on the nature of their domain. These relationships form the design of the framework, and within that design certain patterns emerge that further define the nature of these relationships. In other words, after beginning with the core components, the framework takes its shape from the attributes of those core components, the operations performed by the core components, and the way in which the core components can be related to each other.

Implementational Considerations

The following include additional considerations or features utilized in a particular Skyva implementation example that was actually constructed. As with the above overview, the following is intended to facilitate a better understanding and should not be construed as limiting.

Group Type The group type (e.g. see FIG. 31) provides for distinguishing between different hierarchies and groups, and was implemented as a Java String. The Skyva implementation provided, for user convenience, the seven static group type examples given by chart 5.

Using the Group Type, objects in different groups are identified as different types and can subsequently be more easily distinguished within the application. An example of this can be seen in an application that wants to distinguish between two types of orders. The application illustrated by FIG. 32, for example, keeps track of the two types of orders by having a super order element that has two groups, an aggregated manufacturing order or "AMO" group and a distributed manufacturing order or "DMO" group. In FIG. 31 , the type of the order element has been encoded as the group type of the groups to which the order elements belong. Using this configuration, individual order elements may be in either or both groups. While this grouping is possible for order elements, it is unusual and the grouping mechanism of FIG. 33 is more likely. FIG. 33 illustrates how, when the order type is encoded by the order element that owns the group aspect (instead of the groups themselves), individual order elements can have either an AMO type or a DMO type. This configuration insures that each AMO or DMO group member belongs to only its particular group. Connections between Order Aspects

The three primary Aspects associatable with order elements are interrelated and provide data that defines how an order element operates in association with operational processes and how that order element relates to other order elements. As FIG. 34 demonstrates graphically, the OperationalRequirement class is directly associated with both the JustificationAspect and the DecisionandProgressAspect classes, but the JustificationAspect has no association with the OperationalProcess itself. Because the justification aspect holds the reason for creating the order element, that reason does not need to be linked to the subsequent process; however, any decision that must be made regarding the order and any data involving the order's progress will need a means of connection to the process. Requirements, on the other hand, can provide constraints for any of the order aspects.

Order Decisions The order element's decision aspect is used to record the decisions made about the order. The Skyva provides two complementary mechanisms to do this. First, an operational process may be attached to the decision aspect, and a planning or scheduling component that has made a decision about the disposition of the order typically generates this process, but the process may be instituted manually by a user. Second, requirements can be attached to the decision aspect to indicate what resource elements have been selected, the time frame, quantity, or whatever other properties are required These requirements typically summarize or highlight the process if one is attached. Otherwise, the requirements themselves are the decision. The requirements attached to the order's decision aspect and those attached to its justification aspect(s) do not have to be identical.

Order Decisions and Operational Processes

By attaching an operational process (which has been derived from a descriptive process) to the decision aspect of an order element, the data available from that operational process provides information needed for a decision to be made. FIG. 35 illustrates an example of how this could work in a straightforward shipping situation where a process that ensures overnight delivery of in-stock merchandise has been instituted. As shown, the

"ensuring" process, in its description, might involve several procedures (such as contacting a carrier and scheduling a pickup) and requirements (such as the need for loading equipment or packing materials), all of which should be considered in the planning stage for the process to move smoothly. Once the process is placed into operation (becomes an operational process), the decisions made upon receipt of a request to ship should be predefined ones. The data provided to the decision aspect through its coupling to the operational process includes time factors and the resources required (not shown). Consequently, this information is used to decide the next step(s) to be taken. In this case, an order for the carrier and a request for a forklift operator are generated.

Order Decisions and Requirements

Turning to FIGS. 36 and 37, An order's decision aspect may be connected directly to a requirement rather than to a process (FIG. 36). When this is the case, the requirement itself can provide the basis for the decision. However, because a decision aspect may be connected to multiple requirements (FIG. 37), this decision may involve multiple resources. In both cases, the requirement and the decision aspect may include data about time scheduling as well as the resource being used and the duration of the requirement. In the FIGS. 36 and 37, a time attribute (for scheduling) is assumed to be immediate.

Order Tracking

Just as an order's decision aspect can link with an operational process or requirement to record the decisions about an order, the order's progress aspect has similar links to give applications a point where information may be added about the progress of the order. In other words, the progress aspect of an order collects data about that order as it is executed. This data is provided directly in the form of actual processes (a subclass of operational processes) or requirements describing resource usage.

Order Networks

The nature of order elements generally creates a situation where one order leads to another order element, and so on. While in some cases, a more conventional processing system solution (e.g. data passing) might suffice, the propagative characteristic of order elements is found to be more flexible and reliable (e.g. enabling successive decisions to be made in accordance with better information from all pertinent intra or extra-enteφrise sources.

The FIG. 38 simple hiring situation example illustrates how, even in a smaller organization, the hiring of a new person might begin with a department supervisor issuing a hiring request (a type of order within with the order element abstraction) that is sent to a person in the personnel department who, in turn, issues a job order that sets certain operations in motion (outside agencies and internal personnel working to fill the order) and perhaps concludes with the extension of a job offer (another type "order" within the order element domain) to a qualified candidate (as determined by the criteria in the job "order"). This pattern of hiring request - job order -> job offer demonstrates how each decision/communication can be seen as relating to an order element and how associating each subsequent order in the network via a justification aspect by the order that precedes it provides a reliable and traceable mechanism.

The order network, therefore, is a series of orders coupled to each other through their justifications. Within a larger organization, it is easy to see how this scenario can be extended through several orders and a very complex order network might result. To add to this complexity, an order may have more than one other order justifying it, and an order may justify more than one order. When an order justifies more than one other order, an order split scenario results. When more than one order combines to justify an order, an order merge scenario results.

One possibility is that an order may be split into two or more subsequent orders that have a common requirement that must be divided in some way. For example, a planning order may generate two orders that have the same requirement except that the quantity has been divided between these derived orders according to some decision rule.

The FIG. 39 scenario example shows an operational requirement 3901 for 1000 Widgets being balanced between different production lines with an original order 3902 being split into two orders 3903, 3905 that are more detailed. Requirements 3904, 3906 of detailed orders 3903, 3905 remain requirements for widgets, but the quantities are different. The split quantities do not, however, necessarily have to sum up; for example, the planning component may consider economical order quantities to round up to the planned quantity. (In FIGS. 39- 42, "D" refers to a decision, while "J" refers to a justification.)

FIG. 40 further illustrates how it is also possible to have an order split when the resources required by the justified orders are different. This scenario can be found, for example, when sub-assemblies are ordered to be manufactured within one organization at the same time that they are purchased from a second organization. In this example, an assembly order for widgets 4001 requires two handles and one box for every widget. The handles are manufactured by a production line while the boxes are ordered from an outside vendor. The original assembly order is split so that both of these subsequent orders 4003, 4005 can take place independently and concurrently.

Continuing with FIG. 41, another possible order scenario occurs when two or more orders are merged, creating a mirror image of the order split scenario. In this scenario, two or more orders combine to justify a subsequent order. All the orders are for the same resource in this case, but they have different quantities. This scenario can be used, for example, when aggregating purchase requests (e.g. 4102a, 4102b) into purchase orders (e.g. 4103) using some rule of economical order quantities.

FIG. 42 illustrates a further scenario example in which order split and merge are combined. Two or more purchase requests, for example, can join to justify two or more purchase orders for the same resource but for different quantities. Because requirements are associateable with the justification aspects, such order- varying scenarios are easily accomplished, and further in accordance with distributable decision making. However, the important distinction here is that, because the requirements are associated with the justification aspects, the contributions to the justifying purchase requests can be readily determined.

In the FIG. 42 scenario, for example, purchase request- 1 4202a justifies 200 widgets for Purchase order- 1 4203a and 200 widgets for Purchase order-2; at the same time, Purchase request 2 4202b justifies 400 widgets 4204a for Purchase order- 1 4205a and justifies 200 widgets 4203b for Purchase order 2 4206b. As this example suggests, the split and merge scenario is used when repackaging one set of orders into another set of orders, such as can occur in some batch and lot scenarios (since batch or lot size may be established by some economical or physical constraint).

An order network can also be extended across several stages of production, for example, from a planning level to a more detailed scheduling level, as well as to other non- production systems. For simplicity, we'll examine the example depicted by FIGS. 43 and 44, that has three stages of production. While each of these stages involves a different process, it is important to remember that the focus of this example will be on the order elements. To keep the example somewhat generic, the stages will be called roughing (an early manufacturing stage), customizing, and finishing.

FIG. 43 illustrates how, at the planning level, the system outputs aggregated manufacturing orders ("AMOs"). All of these AMOs are coupled to each other by their justifications ("J"). The initial order, a line item from a customer's purchase order, will not be discussed within the context of the diagrams. "Finishing" order 4301 justifies a split order 4302, 4303 at the "Customizing" stage and one of those orders justifies a "Roughing" order 4304. Note that the arrows point from a justified order toward the justifying order, while the stages of production begin on the left with the final stage and end on the right with the initial stage. In other words, the customer's request for the finished product generates requests for the customized parts, and one of those parts creates a request for some materials that have gone through the roughing process.

While AMOs 4301-4304 are created during the planning stage, additional detailed manufacturing orders or "DMOs" 4401a-4404 are generated during scheduling (FIG. 44). Each of these DMOs is coupled to an AMO that provides the justification for that DMO. In FIG. 44, each AMO justifies two or more DMOs. Apparently, the "Customizing" AMOs must be combined during the "Finishing" stage to be able to complete an order for 200 widgets. Notice, too, that the items produced as a result of the DMOs generated by the "Roughing AMO" do not equal the number of items required by the "Customizing A" AMO. This would be a common occurrence where lot sizes or batch quantities are preset due to physical or otherwise practical constraints.

Groupings of Orders

Turning to FIG. 45, order elements are grouped using the grouping mechanism of core components (the association between the CoreComponent class and the GroupAspect class). Groupings of orders are useful for bringing orders into the same semantic context so the user can treat all the orders in a group as if they are one order. An example of this might occur in the ordering of different supplies from the same vendor. In this case, each individual order 4501a-d is grouped together to form purchase order 4502. Other examples of such grouping occur when, for example, customer line item orders are grouped in a customer order, when manufacturing orders can be grouped because they are going to run on the same resource at the same time, when transfer orders can be grouped together due to mutual transport, and so on.

Alternately, subclasses of an order or an attribute may be used for typing. Grouping is used when the typing of orders involves more than one class of order or core component, or where dynamic typing is required because the type changes during the life cycle of the order.

For example, it is possible to type processes and orders with the same type marking (the same group type) called "outsourcing type". This makes clear that the processes are not executable, but need the generation of an outsourcing order type -the purchase order. When customers or vendors need to be referenced by the order (as with customer orders or purchase orders), the head order (the order element that heads the group) can have an order element header aspect that couples to the customer or vendor.

Resource Element Groups and the Chain of Responsibility The most prevalent concept involved in the Company Hierarchy is the "Chain of

Responsibility" pattern. All Company objects (including Enteφrises) are Property Containers, and, as such, utilize the Chain of Responsibility pattern in the retrieval of attributes held as properties. This utilization enabled each level of a core component hierarchy, and particularly a resource element hierarchy, to have a set of attributes assigned to that individual level.

Resource Elements and Requirements

Requirements are capable of capturing all the needed descriptions about how resource elements are influenced by process elements, including descriptions regarding time and variable-change. The two types of requirements, descriptive requirements and operational requirements, both describe how process elements or order elements use resources. Both types of requirements also provide a mechanism with which a process can reference a resource element, a time point or a time period, and a change to the time-based variables of the resource element. The ResourceElement class has a collection of all requirements that apply to it called

"Requirement" (FIG. 46). The Requirement class, a subclass of the CoreComponent class, has a relation to the resource element to which it applies called resourceElement. Note that each requirement is coupled to exactly one resource, but each resource can have any number of requirements. If a requirement can be applied to a choice of different resources, those choices can be grouped together and the requirement coupled to a resource element that is at the head of that group. Descriptive requirements can be fully parameterized, and, as their name implies, define the manner in which a resource is to be used. Operational requirements are typically derived from descriptive requirements and utilize the specific details of an actual or predicted process.

Time-Based Variables

A time-based variable is a data type that the Skyva implementation uses to represent data that can change over time. It is used to hold data that is historical, current, or forecasted and can be used by data historians to record events and sensor readings. Attributes of core components can be configured to be time-based variables. Predictive systems such as planning and scheduling systems can, for example, use time-based variables to: find feasible resource element combinations, compute changeover times and costs, record the plans or predictions about the future, and so on. The TimeBasedVariable class is a subclass of SkyvaEntity and holds a Dmap collection of time-based profiles. This design is to enables applications to have several profiles associated with one time-based variable.

The TimeBasedProfile class is also a subclass of SkyvaEntity and holds a sorted array of snapshots (FIG. 47). The VariableSnapshot class is, in turn, a subclass of SanFrancisco 's Dependent class, and owns the SanFrancisco TimePoint class (IBM SanFrancisco is one example of a suitable persistor, as discussed with reference to FIG. 4.) The VariableSnapshot class aggregates operational changes that occur at the same time and has a DSet collection of the changes that it aggregates named change.

In effect, each snapshot is an aggregation of the operational value changes that occur at that time. The snapshots define segments of the profile. One way of thinking of the segments is as the region between infection points in the time-based profile curve. Variable snapshots are managed by the Skyva framework through the API's provided by the time- based variable and the time-based profile. Application programs (and, therefore, users) should never create and delete this kind of an object. Both time-based variables and time- based profiles provide methods for manipulating the operational changes, and thus the variable snapshots. Generally, the methods on time-based variables delegate to the appropriate time-based profile, which, in turn, manages the variable snapshots. The snapshot owns a SanFrancisco time point that indicates the start of the validity interval of the snapshot. The interval ends when the next interval begins. In other words, the validity intervals are closed to the left (toward the past) and open to the right (toward the future). Formulaically, this reads: tstart < t < tend,

FIG. 48 illustrates simple example of how a time-based variable works in conjunction with its profiles and the snapshots can be seen with a time-based variable "VI" 4801 that has two profiles: one for predicted data (called PREDICTED) 4802 and one for actual data (called ACTUAL) 4808. In this example, the predicted profile has two snapshots in time order, the first occurs at 13:00 hours, when one operational change increases the value by 3. The second snapshot occurs at 13:11 hours and is an aggregation of an increase by 4 and an increase by 3.2. In contrast, the actual profile has one snapshot. As shown in FIG. 49, there are three types of time-based variables in the Skyva implementation: decimal time-based variables (which store SanFrancisco 's DDecimals objects), quantity-unit time-based variables (which store SanFrancisco 's DQuantityUnit objects), and string time-based variables (which store Java String objects). They are all conceptually very similar; the decimal and quantity-unit time-based variables only differ in the data-types in the method signatures. In addition, the string time-based variable only supports absolute changes at time point, and therefore has a reduced API (Application Program Interface). Typically, the value of a time-based variable will change frequently over time. That change may be visually logged in something like a Gantt chart. In addition, it may be important to record what causes each change. In this case, a variable-change object, the link between the time-based variable and the process that causes the change, represents the change.

Variable Changes The variable-change object is the link between the time-based variable and the process that causes the change. There are two types of variable changes: variable-change points and variable change periods. A variable change point is instantaneous, such that there is no time elapsed during the change and the change is valid from the point of change until the next variable change. A variable-change period involves a value change that takes place over an interval; the shape of the change, such as in the example of a step or ramp, is configurable. The variable change can also be absolute in nature, or it may be incremental (also called a delta change).

The variable-change object has four parameters: a time-based variable to which it applies, a process that causes the change (in particular, the requirement that causes the change), the time of the change (e.g. a time-point for a variable change point and a time- period for a variable change period), and the value of the change. The type of the value of the time-based variable can be: discrete from an open set as can be encoded in a string, continuous variables (i.e., real numbers), continuous change can be relative to a reference value or absolute. For example, you can fill 10 more gallons of fuel into a car, or you can "fill it up."

The following examples illustrate the way in which variable changes can operate. In a first example, the variable change object is a product that comes in the different sizes (the time-based variable) of unknown, small, medium, and large (the value of the change), and is produced by a machine that must undergo a change in setup (the process) that can occur at a set time, but also requires a certain amount of time to take place. The second example involves an account balance (variable change object) that includes different accounts (time- based variables) that undergo debits and credits (value changes) continuously at different periods of time. The first example illustrates a discrete-valued time-based variable change in a machine setup scenario. In this example (FIG. 50), a machine in the pet food industry is setup to extruded nuggets of raw material that eventually make up the pellets in the finished product. The machine could be setup for different product lines requiring three different sized nuggets (small, medium, and large), and changing the extruder from one size to another requires the nozzle to be replaced, an activity that takes a few minutes of time during which the machine cannot be operated.

In the Skyva implementation, the machine is represented as a resource element (5001) and has a time-based variable (5002) that represents the setup of the machine. The values of the setup will be discrete from the set of "small," "medium," "large," or "unknown." There are special processes called changeover processes used to change the setup time-based variable. In this example, these are very simple changeover processes that change the value of the setup time-based variable to the new target value. These processes also occupy the resource element for the predicted duration of the changeover.

The resulting products are also resource elements. The pellet sizes of the products are characteristics of the products, and, for puφoses of this example, we assume the pellet-size characteristic is stored as the value of the extruder size attribute on the product resource element. (Other possibilities include, for example, grouping products into product groups depending on their pellet size.)

FIG. 50 shows the three changeover processes scheduled. At time tl, a product is to be produced with small pellets. The to small process is used to change the setup from

Unknown to Small. Later, at time t2, the to large changeover process is used to go to a large pellet setup, and, finally, at time t3, a medium setup is needed and the to medium changeover process is used. (Note that graphic result indicators, or other multimedia indicators, can also be produced.) The second example illustrates a continuous-valued time-based variable change in a bank account scenario. In this example, a bank account is used to show how the values associated with a variable can be changed continuously during multiple points of time. While a bank account can have only one monetary value at any one time, this value can be changed frequently by a debit or credit, and when a customer has several bank accounts, transfers (simultaneous debits and credits) can be performed between accounts, resulting in offsetting debits and credits to that customer's various accounts. Within the bank itself, it is also possible for multiple customers to have transfers occurring between their accounts. In short, the nature of modern, competitive banking requires the ability to move currency values rapidly from one account to another.

As shown in FIG. 51, one way of representing a customer's bank accounts is by using time-based variables that hold currency values. In this representation, customers (or clients) are resource elements that are associated with a time-based variable for each account they own. The common account operations of deposit, withdrawal, and transfer are represented by three descriptive processes that change the account balances by their variable change. FIG. 50 shows that the client, John Doe 5101, has three accounts, checking 5102, savings 5103, and mortgage 5104 accounts. When a transfer from the checking account to the mortgage account occurs on September 9, 2000, the debit that is registered to the checking account occurs at the same instant and for the same amount as a concurrent credit to the mortgage account.

Time-Based Variables and State Models

The interaction between time-based variables and state models can be shown in the simple example of a manufacturing order of FIG. 52. In this example, the order has a state model that directs it through a series of business processes. The state model describes the valid states of the order and how the state of the order can change. The order element has an attribute called "Current State" which is the current state of the order. The state model defines the values that the current state can take on.

The progress of the order can be tracked through the manufacturing process by recording the completed quantity as it varies by time. Initially, this quantity should be zero, and it should increase as the manufacturing process reports progress. The progress through the manufacturing process is represented by a time-based variable that holds the quantity completed. The type of the values is DquantityUnit (a SanFrancisco class), and the time- based variable is called quantityCompleted. The value of the time-based variable is updated by the progress tracking function of the sate model as completion reports are processed. In the state model shown FIGS. 52 transitions to the In process state again using the specially marked transition.

As a final elaboration on this example, the order class may be configured so that the current lifecycle state is recorded in a time-based variable. The state changes are then recorded in a time-based variable and can, for example, be later displayed as time profiles in a Gantt chart (FIG. 53).

Descriptive Process Elements The DescriptiveProcessElement class is a subclass of the ProcessElement class and implements the RelativeTimePointer interface, used to define timepoints relative to other timepoints. The design of the DescriptiveProcessElement class provides for the parameterization of the values possible for the descriptive process element as well as an association with the DescriptiveRequirement class, which contains the information regarding how the descriptive process element utilizes a resource element.

As shown in FIG. 54, the DescriptiveProcessElement class owns the DescriptiveTimeSpecification class, where the start, end, or duration of the descriptive process element can be defined, and the ProcessInstructionsAspect, which can hold the instructions pertaining to the execution system. In addition, the descriptiveProcess Element class owns the ParameterContext class via the parameterContext relationship and the

ParameterValueContext via the ParameterValueContext relationship. The parameter context declares the parameters used by a descriptive process element and its group members, while the parameter value context defines the parameter values used by the descriptive process element and its group members. The DescriptiveProcess class, a subclass of the DescriptiveProcessElement class, provides a means by which multiple descriptive process elements may be grouped and allows for a number of descriptive processes to be created using the same descriptive process elements.

Process Instructions Aspect The ProcessInstructionsAspect class (FIG. 55) holds data required to execute a process element in an execution system within or outside the Skyva implementation framework. The ProcessInstructionsAspect class is a subclass of the ProcessElement Aspect class and is owned by the DescriptiveProcessElement class. A process instructions aspect has a list collection of process instruction descriptions.

Descriptive Requirement

The DescriptiveRequirement class (FIG. 56) has a relation to both the

ResourceElement class (through its superclass, the Requirement class) and the

DescriptiveProcessElement class. A descriptive process element has a list of descriptive requirements, and these requirements reference how a resource element or elements is to be utilized during a process. As shown, the DescriptiveRequirement class is a subclass of the Requirement class, which is a subclass of the CoreComponent class. The DescriptiveRequirement class owns a SanFrancisco Set collection of descriptive time-based variable changes called descriptiveVariableChange.

The descriptive requirement bundles the several viewpoints (called descriptive variable changes) of the impact on a resource element when it is linked to a process. These views are related to only one resource element and therefore do not result in many requirements.

Parameter Context & Parameter Value Context

Process descriptions (FIG. 57) can be made more generic through parameterization. Parameters can take values from numbers, strings, or other simple data types. Parameters can also have objects, such as resource elements, as values. For example, a forklift may be part of the parameters specified in a storage process (parameter = forklift and parameter = number). Allowing parameterization in processes drastically reduces the overall number of descriptive processes needed. The Parameter class and the ParameterValue class are subclasses of SanFrancisco 's Dependent class and implement SanFrancisco 's Distinguishable interface. The Parameter class is owned by the ParameterContext class, which itself is owned by the DescriptiveProcessElement class (see Figure ). In a similar fashion, the

ParameterValue class is owned by the ParameterValueContext class, an instance of which can be owned by either a descriptive process element or an operational process element. The ParameterValue class also owns a Java object as a value. The Parameter and ParameterValue classes reference each other implicitly via the same id attribute.

A parameter context owns a set of parameters. The class name "ParameterContext" refers to the way in which parameters are evaluated. In other words, a parameter by itself provides only a small piece of information. It is only when a set of parameters is viewed within the context of each other as well as the formula that employs them that the significance of parameterization materializes. These parameters can provide: alternative process paths, resource selection based on the evaluation of alternatives, material substitution, correlating decisions at different levels of aggregation, product configuration, product development, and so on. One of the simplest forms of parameterization occurs when order quantity parameterizes raw material consumption. In this example, each order increment necessarily consumes certain quantities of various raw materials. An increase in the size of the order brings about a corresponding (and formulaic) increase in the consumption of materials.

A parameter value stores the value for a parameter, and the parameter value context holds a complete parameter evaluation context, defining the values of several parameters together. Often, parameters and formulas need to be evaluated within this context. When the formula is evaluated, the concrete values from the parameter value context replace the parameters (which, in this sense, are symbolic placeholders) and the resulting value is sent to the descriptive process (or descriptive requirement).

Formulas

Formulas use parameters to compute the values of other parameters. When a value is chosen for one parameter in a formula, this limits the number of choices for other parameters (FIG. 58). The Formula class is a subclass of the SkyvaDescribableDynamic Entity class. The Skyva implementation Formula class has six subclasses, which are illustrated in chart 6.

Formulas are facilitated by the use of parameters in process descriptions. Parameters unify several process descriptions into one process description by providing a variable in place of a constant.

Descriptive Time Specification

Turning now to FIG. 59, descriptive time specifications allow time to be described in a variety of ways: as time points or time periods, as a formula or in relation to other time specifications, as a start-end pair, as a start-duration pair, or as an end-duration pair. The DescriptiveTimeSpecification class is an abstract subclass of SanFrancisco 's Dependent class. There are two subclasses of the DescriptiveTimeSpecification class: the

DescriptiveTimePoint and DescriptiveTimePeriod classes. This design enables a time point or time period to be determined in a generic way.

Time points in this implementation can be specified relative to other time points in the system according to one of three possibilities: (1) relative to the start or end time of another DescriptiveVariableChange in the same requirement, (2) relative to the start or end time of another DescriptiveRequirement of the same DescriptiveProcessElement, or (3) relative to the start or end time of the DescriptiveProcessElement to which the DescriptiveVariableChange belongs

Time periods, on the other hand, can be specified in one of four ways in the Skyva implementation: (1) through a single duration formula, (2) through one formula determining the relative start time of a VariableChange and another formula determining the duration, (3) through one formula determining the duration of a VariableChange and another formula determining the relative end time, or (4) through one formula determining the relative start time of a VariableChange and another formula determining the relative end time. FIG. 60 shows the four described cases in a graphical way on a time axis:

The manner in which time can be represented by a formula or formulas can be shown in the example of a simple operation carried out within a manufacturing process. In this example, a machine and a person are required to complete the operation that turns a raw material into a finished product. The times used here are only relative to each other since we are dealing with descriptive data and do not have concrete times. The time relationships are as follows: the duration of use of the primary resource (RESS) is defined in a formula, the duration formula of the operation (OP) depends on the results of the duration formula described above, the person (PERS) who supervises the manufacturing operation is needed 5 minutes after the operation's start time (5a) until the end of the operation (5b), the time point formula for the consuming of the raw material (MATraw) depends on the start time of the operation, or the time point formula for the production of the material produced (MATprod) depends on the end time of the operation. (See FIG. 61).

Descriptive Changes

Descriptive changes are used to describe the influences of time-based variables, the data type used by the Skyva implementation to represent historical, current, or forecasted data over time, on the requirements of processes. In effect, descriptive variable changes link the data stored in a time-based variable with a descriptive process. A good example of a descriptive change is the change that takes place during the consumption of any raw material. The nature of the descriptive change depends how two sets of two characteristics are combined. Descriptive changes can be: instantaneous (at a time point) or occurring over time (during a time period), or absolute or incremental (delta). At present, the Skyva implementation defines the four types of changes illustrated in FIG. 62.

(In FIG. 62, the number "3" is being used solely for purposes of illustration.) Descriptive variable changes allow time and value specifications to be specified by formulas.

The VariableChange class (FIG. 63) is an abstract subclass of SanFrancisco's Entity base class and the DescriptiveVariableChange class is a subclass of the VariableChange class. As shown, the DescriptiveRequirement class owns a SanFrancisco Set collection of descriptive time-based variable changes called descriptiveVariable Change. The DescriptiveVariableChange class has three subclasses for the different types of data that need to be quantified: the DescriptiveQuantityUnitChange, DescriptiveString Change, and DescriptiveDecimalChange classes. The DescriptiveDecimalChange class (FIG. 64) is a subclass of the

DescriptiveVariable Change class and has a relationship to the DecimalFormula class, an instance of which symbolizes the value of the related change. There are four concrete subclasses and any one of them can provide the meaning of the value attribute:

• DescriptiveDecimalPointStepAbsChange - the value attribute is treated as an absolute and momentary change

• DescriptiveDecimalPointStepDeltaChange - the value attribute is treated as an incremental and momentary change • DescriptiveDecimalPeriodLinearDeltaChange - the value attribute is treated as a linear incremental change during a period of time

• DescriptiveDecimalPeriodStepDeltaChange - the value attribute is treated as an incremental step change and then a return after a period of time The two former descriptive decimal changes own a descriptive time point when they apply. The latter two own a descriptive time period when they apply.

The DescriptiveQuantityUnitChange class (FIG. 65) is a subclass of the DescriptiveVariable Change class and has a relationship to the QuantityUnitFormula class, an instance of which symbolizes the value of the related change. There are four concrete subclasses and any one of them can provide the meaning of the value attribute:

• DescriptiveQuantityUnitPointStepAbsChange - the value attribute is treated as an absolute and momentary change

• DescriptiveQuantityUnitPointStepDeltaChange - the value attribute is treated as an incremental and momentary change

• DescriptiveQuantityUnitPeriodLinearDeltaChange - the value attribute is treated as a linear incremental change during a period of time

• DescriptiveQuantityUnitPeriodStepDeltaChange - the value attribute is treated as an incremental step change and then a return after a period of time The two former descriptive quantity unit changes own a descriptive time point when they apply. The latter two own a descriptive time period when they apply.

The DescriptiveStringChange class (FIG. 66) is a subclass of the DescriptiveVariableChange class and has a relationship to the StringFormula class, an instance of which symbolizes the value of the related change. The DescriptiveStringPoint StepAbsChange is the only concrete subclass available to the DescriptiveStringChange class. The subclass treats the string formula as an absolute and momentary change that provides the exact meaning of the value.

Operational Process Elements The OperationalProcessElement class (FIG. 67) is a subclass of the ProcessElement class. Operational process elements store the decisions made based on a chosen descriptive process element. The decision is often made in response to an order element. Operational process elements are also used to store information captured from process execution systems. As shown, the OperationalProcessElement class owns the OperationalRequirement class as well as the ParameterValueContext and OperationalTime classes. An operational process element may also refer to a process element as its originProcessElement, enabling an application to find out from what process element this operational process element was derived.

The OperationalProcess class is a subclass of the OperationalProcessElement class, so an operational process can serve as the group head for a number of operational process elements. The group identifier (for this type) is PROCESS_GROUP. The

OperationalProcess class also has a relationship with the OrderElement class via the DecisionAndProgressAspect, which enables the operational process to share data with an active or potential order. In addition, operational process elements may be associated with a process data container via the OPE_PDC_GROUP group type identifier or with an inteφretable data item via the PDC IDI GROUP group type identifier.

An operational requirement (FIG. 68) refers back to the operational process element that owns it through the OperationalProcessElement relationship. Unlike descriptive^" requirements, which are linked to the formulas and parameters of the descriptive process, these requirements describe specifically how an operational process element uses a resource element. The OperationalRequirement class is a subclass of the Requirement class, through which it has a relationship to the ResourceElement class. Operational requirements are linked to exactly one resource element and are derived from descriptive requirements.

Parameter Value Context The ParameterValueContext class is owned by the OperationalProcessElement class via the ParameterValueContext set. A parameter value context contains the evaluation of several parameter values and provides the operational process element (and thus the operational process) with a concrete value representing this contextual evaluation.

Operational Time Specification

Like the DescriptiveTimeSpecification class (see page 84), the OperationalTime

Specification class is an abstract subclass of SanFrancisco's Dependent class and has two subclasses, in this case, the OperationalTimePoint and OperationalTimePeriod classes. The design and use of the OperationalTimeSpecification class allows operational time specifications to be described as time points or time periods in several ways: using a formula or a relationship to other time specifications, having a time period with specific start and end points, as well as having a time period with a specific start or end point and a specific duration.

Operational Process

The design of the OperationalProcess class, as a subclass of the Operational ProcessElement class, allows a number of operational processes (with the same group type) to be created using the same operational process elements. In addition to this kind of forward grouping pattern, a backward grouping of multiple operational process elements (with different group types) can be associated with the same operational process.

And and Or Elements

The AndElement and OrElement classes (FIG. 69) are subclasses of the ProcessElement class that are used with the ProcessTransition class to provide parallel or alternative paths of action for a process. Using instances of the AndBranchElement and AndJoinElement classes, two or more processes can be expressed as performed independently or simultaneously. Execution control is essentially split at the and-branch element and resynchronized at the and-join element. Keep in mind that the process elements involved are connected to the and-branch and and-join elements by process transitions (and their conditions). Using instances of the OrBranchElement and OrJoinElement classes, two or more alternative process paths can be expressed. The choice of path is made at the or- branch element and can be reconnected to the overall process at the or-join element. Keep in mind that the process elements involved are connected to the and-branch and and-join elements by process transitions. The evaluation strategy of the alternatives is not defined by the OrBranchElement class.

Process Transitions

Process transitions (FIG. 70) are used to link process elements (and their subclasses). Process transitions are also used to signal the start or end of a process and conditional process transitions are used with or-elements to set up alternative process paths or to indicate that a conditional loop in the process exists. The ProcessTransition class is a subclass of the RelationshipAspect class. Process transitions optionally own a process condition via the processCondition relationship. The process condition, in turn, references a predicate formula that holds the transition condition via the predicateFormula relationship.

In addition to the instances of the ProcessTransition class that link process elements and instances of the ProcessElement subclasses, there are three specific subclasses of the ProcessTransition class which can also provide similar links with special functionality:

• The LoopProcessTransition class - an instance of this class forms a loop "back" to process elements that may already have been executed.

• The StartProcessTransition class - an instance of this class connects the super process element to the process element that is designated to start the process.

• The EndProcessTransition class - an instance of this class connects the last process elements to the super process element.

In FIG. 71, a start process transition, end process transition and unconditional process transition are used. The start process transition connects the process "Hole drilling" to the first operation in that process represented by the process element called "Drill hole." That operation is connected to the "Tap hole" process element by an unconditional process transition. The meaning of this arrangement is that when "Drill hole" has been completed "Tap hole" will proceed immediately. Finally, "Tap hole" is connected to the "Hole drilling" process by an end process transition. In general, a process may have more than one end process transition, but only one start process transition. FIG. 72 further illustrates how conditional process transitions can be used with or- branch elements. The or-branch element called "Choose" at the far left of the graphic signals the conditional. The alternatives have their conditions attached. In this case, we have two process transitions. The top process transition has the predicate "Summer?" and the bottom process transition has the predicate "Winter?" This means that if "Summer?" is true, the top alternative is selected and if "Winter?" is true, then the bottom is chosen. Loop process transitions, by their nature, are also conditional.

In FIG. 73, the or-branch element called "Branch" signals two paths: the "Done loading?" continues forward, while the "More to load?" alternative loops back to an or-join element. State Process Elements

State process elements (FIG. 74) combine with state transitions to form a state model. A state model defines the specific fixed or optional steps (called states) in the lifecycle of an object, and, by doing so, expresses the behavior of an object from a business point of view. The StateProcessElement class is a subclass of the CoreComponent class. A state process element is controlled by a state process element controller and may be represented by only one state at one time. This definition is provided through the StateDefinition class, which is owned by the StateProcessElement class. The state definition object can refer to any serializable Java object, which gives the user a chance to attach an application-level object to the state process element.

The state behavior aspect is an aspect that is owned by another core component whose current state is referenced in the state process element. In addition, a state process element (and most often a state process) may refer to another state process element as its initial state via the initialState relationship.

State Transition

State transitions (FIG. 75) connect two states in a state model, describing the event that may cause a transition, the conditions under which that event may occur, and the actions associated with the transition. The StateTransition class is a subclass of the

RelationshipAspect class (which is owned by the CoreComponent class). Through this design, a state transition links state process elements, and one state process element can have multiple state transitions linking it to multiple state process elements.

As an example of how a state transition works, examine the simple transition that takes place when the state of an order moves from being "Scheduled" to being "Launched." In FIG. 76, the state transition is represented by the arrow and the three elements that can make up the transition are undefined. The Event which is required for the object (in this case, the order) to move from one state (Scheduled) to another (Launched), the specific Condition(s) which must be fulfilled before the action is triggered, and the specific Action the system must perform when the condition(s) is/are fulfilled.

In this example, the Event might be that the scheduler has scheduled the order, the

Condition is evaluated as true, and the state of the order is changed to Launched. In other words, the system executes the action defined in the state transition. Conditions and Actions are optional elements of state transitions. If a condition and an action is not associated with a state transition, the object is automatically assigned the state defined in the state model when the defined Event occurs.

Trigger Rule A trigger rule (FIG. 77) determines if a state transition is valid. There are conditional trigger rules and timer trigger rules. The TriggerRule class is a subclass of SanFrancisco's

Dependent class and is owned by the StateTransition class.

A trigger rule defines a Boolean method isTrigger() that evaluates the trigger rule's condition. That evaluation is performed by delegating to the Java object owned by the ruleJavaObject relationship. That Java object must implement the JSkyvaEvaluatesTrigger interface, thus implement the isTrigger() method. JSkyvaExpressionTrigger is a concrete subclass of JSkyvaEvaluatesTrigger that uses the expression parser to evaluate a Boolean condition given in the expression attribute.

The Skyva implementation has a special kind of trigger rule to do with timers, the time trigger rule. The time trigger rule is a subclass of trigger rule. In addition to the above, timer trigger rule also has a relationship to JSkyvaTimers via the time$JavaObject relationship. JSkyvaTimer is an interface, the Skyva implementation defines two kinds of concrete timers: the absolute time JSkyvaAbsoluteTimer and the interval timer

JSkyvalntervalTimer. Both kinds of timers accept a time specification encoded as a Java long, but the meaning of the long is different. For the absolute timer it denotes a time point a certain number of milli-seconds after January 1, 1970. For the interval timer it denotes the number of milli-seconds in the interval.

Action The Action class (FIG. 78) contains the action performed in a state transition.

The Action class is a subclass of SanFrancisco's Dependent Class and is owned by the StateTransition class. An action connects a state transition to a Java object that implements the JSkyvaExecutesAction interface. In particular, an action implements the doAction() method, where the application places the action. The JSkyvaExpressionAction class implements the JSkyvaExecutesAction interface. It allows the user to code the action using the expression attribute. The foregoing description of preferred embodiments of the invention is provided by way of example to enable a person skilled in the art to make and use the invention, and in the context of particular applications and requirements thereof. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles, features and teachings disclosed herein. The embodiments described herein are not intended to be exhaustive or limiting. The present invention is limited only by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A framework system, comprising: behavior-independent core components; behavior components; and linking components associatively coupling the one or more behavior components with the core components.

2. A framework system according to claim 1, wherein the core components comprise propagative order elements, resource elements and process elements.

3. A method, comprising: providing one or more of order, resource and process objects to a distributed inter- enteφrise business system, and providing one or more state machines to the business system, the state machines being associated with ones of the objects for determining a behavior of the objects.