Classifying Business Processes for Domain Engineering

Abstract

Enterprises build information systems to support

their business processes. Some of those business processes are industry or enterprise-specific, but most are common to many industries and are used, modulo a few modifications, in different contexts. To the extent that we can, i) decompose complex business processes into composable generic sub-processes, ii) develop software components that implement such generic processes, and iii) map process specialization and composition operators to corresponding operators on software components, we will be able to develop information systems by modeling the business processes that they are meant to support, and using such models to guide the assembly of the corresponding software components. This is not a new idea, but earlier attempts suffered from the lack of tools, conceptual and otherwise, to perform this mapping. In this paper, we describe the principles underlying our approach and the status of the current implementation in the Eclipse environment.

I. INTRODUCTION Enterprises build information systems to support

their business processes. Some of those processes are industry or enterprise-specific, but most are common to many industries and are used, modulo a few modifications, in different contexts. To the extent that the information system depends on the underlying business process, we should be able to reuse most of the enterprise IT infrastructure. With a few exceptions, this is not happening. In fact, this seems to even contradict conventional wisdom in software reuse. Indeed, it is customary in the reuse literature to talk

about a hierarchy of reuse levels, with the following characteristics [15]: 1) Code-level reuse: small components, with little

benefit, but widely applicable, across designs and across application domains

2) Design-level reuse: higher-level components that embody a design (design patterns, technological frameworks such as GUI frameworks) that are also applicable across application domains, but they are design-bound

3) Analysis-level reuse: yet higher-level components that implement domain functionality and that embody a design. Such components are domain-specific, and design-bound.

It is generally accepted that we trade reuse leverage for applicability.

However, what do we mean exactly by domain? The process of selling computers is similar to the process of selling cars, much more so than to the process of manufacturing computers. In fact, because cars and computers share many characteristics (they are both tangible, reasonably high-priced, manufactured, configurable products), the processes are nearly identical. What distinguishes the two is the domain vocabulary (computers vs. cars, processors vs. engines, etc.). A good fraction, if not the majority, of the business processes of an organization do not depend on the industry within which it operates. However, the analysis models of the information systems that support them—the platform independent models—will be domain-specific.

We propose a methodology for, i) modeling the business processes that are specific to an organization, and ii) mapping the resulting business processes to platform independent (analysis) models. Our methodology relies on the existence of a catalog of generic business processes (e.g., sale) and a set of specialization operators that enables a modeler to specify (or select) the business process that best describes the way his or her organization works. This process will be domain-independent, and will then

Classifying Business Processes for Domain Engineering

Hafedh Mili, Mohand Frendi, Guitta Bou Jaoude, Louis Martin, and Guy Tremblay

Department of Computer Science, Université du Québec à Montréal, Québec, Canada

[email protected]

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

need to be instantiated from the domain at hand. Figure 1 illustrates this process.

In the next section, we describe the process modeling language that we will be using. Section 3 describes the process specialization approach in more

detail. Section 4 describes the status of the current implementation using the Eclipse environment. We conclude in section 5.

Figure 1. A methodology for generating application-specific platform-independent models.

GP1

GP2 GP3

GP4 GP5

Figure 1-a. We start with a catalog of generic business processes, some of which have software artifacts associated with them

GP1

GP2 GP3

GP4 GP5 GP6

spec

Figure 1-b. Modelers find the process they need by using one of the stored ones as-is (e.g. GP5), or by specializing it using specialization operators (e.g. GP6)

P6,a Inst.

GP1

GP2 GP3

GP4 GP5 GP6

spec

Figure 1-c. The generic process (GP6) obtained by specializing a process in the catalog is instantiated to get a organization/enterprise-specific process (P6,a)

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

II. PROCESS MODELING

A. What is a process Curtis defined a process as a partially ordered set of

tasks or steps undertaken towards a specific goal [6]. Hammer and Champy define business processes as a set of activities that, together, produce a result of value to the customer [8]. The workflow management coalition defines business processes as “a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships.” [22]-[23]. We adopt the definition embodied in the meta-model

of Figure 2. The activities of a business process are performed by actors playing particular roles, consuming some resources and producing others. Activities may be triggered by events and may, in turn, generate events of their own. The activities of a process may be linked through resource dependencies (producer-consumer dependencies) or control dependencies (one activity triggering another). The actors operate within the context of organizational boundaries. Organizations perform specific business functions. Roles can support functions. We will refer again to this meta-model when we present our classification procedure.

P rocess1

*subp rocess

Activ ity

1

*

com posed-of

Resource*

*

consum es

*

*

p roduces

Role

* *

pe rfo rm ed byActor

* *

plays

Organ ization

*

*

m em ber o f

*

*

h ierarchy

Function

* *

perfo rm s*

*funct iona l decom p

*

*

supports

Event

* *tr iggers

* *

generates

Figure 2. A first-cut business process metamodel.

B. Process modeling languages As our process metamodel suggests, there are a

number of things to represent about a business process. Curtis argued that there are four distinct views [6]: 1) The functional view presents the functional

dependencies between the process elements, such as producer-consumer dependencies.

2) The dynamic view provides sequencing and control information about the process, i.e. when certain activities are performed, and how.

3) The informational view includes the description of the entities that are produced, consumed or otherwise manipulated by the process. These entities include pure data, artifacts, products, etc.

4) The organizational view describes who performs each task or function, and where in the organization (functionally and physically).

Most object-oriented modeling methods cover the first three views. What is new, from an ontological point of view, is the organizational view, which includes a description of the participants in the process as well as a description of the physical (location) and organizational context within which this process is conducted. Further, whereas the informational view in object-oriented modeling represents only data entities, the informational view of business process modeling may represent tangible resources and artifacts that are used and produced by processes.

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

C. Our Choice We studied a dozen or so process modeling

languages that originated from a variety of scientific traditions, ranging from the IDEF family of languages, to formal languages (e.g. Petri nets), to business process management languages (role-activity diagrams or RAD, [18], Resource-Event-Agents, or REA, [14], Event-Process Chains, or EPC, [9], Business Process Modeling Language, or BPML [3]), to workflow modeling languages (e.g. PIF [10]), to e-business process interconnection languages and frameworks (Rosettanet [21], ebXML [16], BPEL4WS [1]) to object-oriented languages and dialects (UML 1.x, OORAM [19], EDOC [17], and UML 2.0). Because we want to ultimately map our process models to object models, object-oriented languages seemed to offer a good basis for a process modeling language that covers all four views (see § 2.2). We were then looking for useful additions from other languages, either directly, or through mechanized mappings.

When we started the project, the EDOC framework [17] corresponded best to our needs. EDOC is an OMG standard modeling framework aimed at simplifying the development of component-based enterprise distributed object computing (EDOC) systems. The modeling framework was based on UML 1.4 and conformed to OMG's MDA development. Two factors make this modeling framework particularly relevant to our needs: 1) an extension of UML to provide explicit

representation for business processes—the business process profile;

2) a built-in traceability mechanism that enables us to trace software components to the actors and activities of the processes that they support.

By the time we were done with the selection, the first drafts of UML-2 were coming out and it became clear that the most important contributions of EDOC were incorporated directly into UML-2 metamodel. Hence, we used UML-2. Because we will represent generic processes, we added data flow diagrams, to represent functional dependencies, and some minor extensions to support the representation of variation points, or hotspots in the model.

III. AN APPROACH TO BUSINESS PROCESS CLASSIFICATION

A. Principles For the purposes of illustration, we will use the

example of an ordering process. Supply chain management represents an important part of business processes, and has been the focus of many studies and

initiatives in business process re-engineering as well as enterprise frameworks and ecommerce suites. Ordering starts by first filling out a request for a product which then goes through a budgetary approval process. If it is approved, it goes to purchasing, who will identify suppliers for the product. Once a supplier is found, then a purchase order to that supplier is created and sent. When the product is received, it is inspected and sent to the requester. Then payment is made. Figure 3 shows a simplified functional view of the process.

This process is independent from the application domain, and at this level of abstraction, it can be used to order pencils or computers or airplanes. We could have many flavors of this process, regardless of the application domain. For example, for on-line purchases, we usually pay before receiving (or activating) the product, because of the anonymity—and impunity—of the internet. Second, if the buyer has a running contract with a supplier, then they do not look for suppliers each time: they order directly from the designated one. Third if the requester is also the decision maker, they do not need to ask for approval: they can just go ahead and order the product directly.

These are all variations that do not depend on the application domain, and that represent specializations of the basic business process. Naturally, we expect the software applications that support the purchasing process to exhibit similar variations. We ask three questions, which are increasingly harder to address: 1) is there a way to organize existing business

processes in a specialization hierarchy that makes it easy for users to navigate to find the business process that best fits their organization,

2) is there a way to generate some of these specializations on-the-fly based on some catalog of elementary specializations,

3) provided that we have software artifacts associated with the generic processes and process elements, if we generate a specialization of a stored (existing) business process, is there a way to similarly derive a specialization of the corresponding software artifacts.

We discuss each question briefly. The next section presents our approach.

There have been many initiatives aimed at cataloguing generic business processes, each proposing classifications of their own, including the MIT process handbook, the IBM San Francisco project, and various analysis patterns catalogues. These classifications are for the most part high-level, and refer to broad functional areas such as production, logistics, support, or planning (e.g. [5,12]). These

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

classifications are also descriptive in the sense that they are based on external properties of the process (meta-data that is referred to as facets in the reuse literature) as opposed to structural classifications, which are inherent in the structure of the models—and can be computed from it. The MIT process handbook uses a descriptive classification, in addition to a question-based classification discussed in the next

section. Descriptive (multi-faceted) classifications require little automation, and are thus easy to implement. They are, however, labour intensive.

Structural classifications would help us answer the second question, i.e. generate on the fly process specializations based on a catalogue of generic processes and a catalogue of elementary specializations.

Process request for product Identity suppliers Process purchase order receive ordered product Pay supplier

Figure 3. The functional view of a basic ordering process.

Figure 4 shows a simplified model from the

informational view of the ordering process; we are showing some attributes to help understanding the model. As mentioned earlier, the ordering process would depend on the existence of a contract between the buyer and the appropriate supplier regarding the terms of purchase (price, delivery delays, defect return policy, etc.), which will obviate the need for searching for a supplier. Second, the reception of the product will depend on whether the product is a tangible product (a chair, a computer, a book), or a non-tangible product, or service, such as internet access, phone service, etc.

Figure 5 shows a new object model (informational view) that accommodates both of these changes. The new model is similar to the original one, with two differences (noted in grey boxes): 1) we added a class (Contract) and two associations between the new class and existing ones, and 2) we specialized an existing class (Product) into two subclasses (TangibleProduct and Service). This very simple example raises a number of points that we discuss below.

Let us first start with the specialization of Product into TangibleProduct and Service. We, in the object world, are familiar with these kinds of specializations. In framework speak, these are called hotspots, which are well-defined points of extensions in object models (and class hierarchies) using well-defined extension mechanisms; in this case, sub-classing. Sub-classing or sub-typing only covers the simplest cases. With the contract example, we are adding a class and two associations, and there is no way of guessing that the addition actually specializes the process. Third, adding a contract between buyer and supplier actually removes one step from the functional view. It also modifies the dynamic view accordingly.

This is not a new problem. Objects have been originally sold on the intuitive belief that “small” changes in requirements result in “small” changes in the corresponding program, thanks to inheritance and encapsulation. However, as Lubars showed back in 1992, this tends to be almost true for the object model, but not so for the dynamic or functional model: small changes in requirements can result in dramatic changes in the dynamic model [11]. What all this means is the following: 1) what we might intuitively refer to as process

specialization may have a simple expression in one of the four views, but not necessarily in the others

2) the specialization operators depend on the view, and may not be related to the object-oriented specialization or extension operators

3) one specialization will affect several views differently.

The answer to our second question is then, yes, it might be possible to generate process specializations on the fly using a catalogue of elementary specialization operators, but that catalogue will have to include far more than the typical object-oriented ones (composition, inheritance).

The answer to the third question above (specializing software artefacts based on the specialization of the corresponding business processes) is beyond the scope of this paper. The general idea is to develop a catalogue of software model transformations that correspond to the process model specialization operators. This is not an easy problem because business process models cover both manual activities and activities that are to be executed by software systems! Some changes in the overall business process will not impact the software that participates in it, while others may result in significant changes in the software. This is work in progress.

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

B. Classification using metamodel hotspos Our analysis of the business process classification

problem above showed that there are no simple specialization operators that can be applied on any of the views that would yield systematically meaningful specializations. Some previous work has used questions to derive specializations of processes. Carlson argued that the purpose of any organization is

to offer a product or a service to a client, and hence, an information system that supports the organization would need to manage this “ordering” process [4]. The data and the operations supported by the information systems depend on the business model and on the way the organization works

Order

-quantity : intLineItem

Requester Supplier-requester

1

-order

*

1

1..*

-order

0..*

-supplier

1

Product

1

-product

*

priceScheduledeliveryDelay : Date

Terms*-supplier

*-product

Figure 4. Basic (partial) informational view for the ordering process.

Order

-quantity : intLineItem

Requester Supplier-requester

1

-order

*

1

1..*

-order

0..*

-supplier

1

Product

1

-product

*

priceScheduledeliveryDelay : Date

Terms*-supplier

*-product

-startDate : Date-endDate : Date

Contract

-buyer 1

-contract

0..*

-contract

0..*-supplier1

-weight : float-volume : float

TangibleProduct Service

Figure 5. The informational view for a specialization of the purchasing process

Carlson has reduced these variations to the answers

to seven questions (yes/no) whose answers determine the kind of process, and thus the information system needed to support it. We show below a couple of questions, and illustrate their implications on the business process and the corresponding information system:

• Does the supplier send an invoice to the customer, or does the customer pay for the product/service cash (or equivalent)?

If the supplier sends an invoice, we have an invoicing process and a payment process with checks, wire transfers and the like. Also, the information system will need to keep information about the customer, their

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

billing address, and their banking information. If the customer pays cash, no records need to be kept of the customer.

• Are the prices negotiated, i.e. they differ from one

customer to another, or are they fixed? Negotiated prices mean contracts, price schedules per customer, etc.

• Is the product or service leased to the customer by

the supplier, who conserves all property rights, or is property transferred to the customer?

If the product is leased, the organization needs to keep track of the leasee and manage the product or service throughout its lifecycle from the time of acquisition (or manufacture) until retirement. This also has major implications on accounting.

Lefebvre used a variation of these questions to help identify component archetypes [5]. Notwithstanding the fact that BIAIT’s seven questions may not be orthogonal—they are not—the questions are fairly coarse-grained, and alone cannot capture the level of detail required for the processes and the corresponding information systems. The MIT process handbook also used questions to specialize processes [13]. However, the questions are process-specific. Figure 6 shows two levels of the process specialization hierarchy. The middle-level corresponds to the question. The processes on the right hand-side of the figure can be further specialized using more specific questions.

Using process-specific questions has the advantage that both the questions and the resulting specialized processes are precise. It has the disadvantage that the classification is ad-hoc and cannot be generalized: whoever specifies a generic business process has to classify and encode all the variations manually. Further, we cannot generate process specializations on demand, on the fly.

By going over a number of processes from the MIT process handbook, and the associated questions, we realized the obvious: the questions are about the roles involved in the process (e.g. “customer”, “supplier”), the nature of the resources produced and consumed by the various activities (“product”, “service”, “tangible product”), or the organization within which activities are taking place. Thus, we can frame (or phrase) our questions generically about entities and associations in the process metamodel, and then “instantiate” them for specific processes (instances of the process metamodel) to get process-specific questions. Some of these questions are more related to the informational view, while others are related to the organizational view, while yet others are more related to the

functional and dynamic view. We reproduce in Figure 7 the (partial) business process metamodel where we outlined the model fragments included in each view.

We show below a couple of generic questions, how they impact a process, and see how they are instantiated for a specific business process. The view is shown between parentheses: • Can an actor play several roles within the process

(organizational)? when an actor plays several roles within the same process instance, the underlying process is generally simplified, e.g. by removing communication between the two roles, the need for authorizations, etc. In our purchasing example, we have three roles within the purchasing organization involved in the creation of the purchase order: the requester (end-user), the person responsible for the budget, and the purchasing agent. If the requester and the budget person are the same, we don’t need approval.

• Is information about the actors recorded (informational)? when information about an actor is recorded, the actor is represented internally in the system. Also, activities will be logged in the system. In the purchasing example, this question will be instantiated into several questions, one per actor: a) is information about the requester recorded?, b) is information about the budget approver recorded?, c) is information about the purchasing agent recorded? A yes in each case will have implications on the data and the processing of the application.

• Does the process execution follow an agreement or contract of some sort (functional)? in case there is an agreement, it means either that process parameters can be obtained from that agreement, or that process execution needs to be validated against the agreement. In the purchasing example, we have the case where a binding agreement exists between the purchaser and a supplier, which simplifies the search for suppliers and initializes some parameters (e.g. price), and the case where no such agreement exists, in which case the order goes to the lowest bidder, for example.

We have identified fifteen (15) questions in all, five organizational, four functional, and six informational. Some of the informational questions have to do with the nature of the resources (tangible vs. non-tangible, perishable or not, degradable through consumption or not, limited quantity or not).

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

Figure 6. Part of the classification scheme used by the MIT Process Handbook. From [13]

Figure 7. A partitioning of the business process metamodel.

Once we have identified the questions, we have to

determine the effect of the answer on the corresponding process models, and more specifically, on each view. Naturally, the questions may impact some views more than others. For each question, we need to develop a set of transformations per view. Some of these transformations consist of removing model fragments that follow a specific pattern, as in removing coordination activities between roles played by the same actor. Others consist of adding model elements (entities, associations, processes) to model fragments that satisfy a specific pattern, in much the same way that we apply analysis or design patterns to existing models. In fact, we are using some of the published analysis and process patterns to this end [5, 7]. In the next section, we discuss the status of the

current implementation.

IV. IMPLEMENTATION We first discuss the implementation of the four

representational views, and then the representation and instantiation of meta-model questions.

A. Implementing the representation of processes A tool that supports the representation and

classification of generic business processes needs to support modeling notations along each one of Curtis’s four views, namely, the informational view, the functional view, the dynamic view, and the organizational view. It will also need to support additional constructs to represent variation points in

Organizational view

Functional/dynamic view

Informational view

Process1

*subprocess

Activity

1

*

composed-of

Resource*

*

consumes

*

*

produces

Role

* *

performed byActor

* *

plays

Organization

*

*

member of

*

*

hierarchy

Function

* *

performs*

*functional decomp

*

*

supports

Event

* *triggers

* *

generates

Location

location

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

generic business processes, mutually exclusive specializations, model alternatives, and the like.

UML-compliant CASE tools, by definition, implement a UML meta-model, which has most, but not all of what we need. Thus, ideally, we should use a UML compliant CASE tool that exposes its meta-model so that we may extend it to add what we are missing. The Eclipse environment, with its various modeling plug-ins, and the Eclipse Modeling Framework, is the best combination we found. EMF is a modeling framework that supports code generation and XMI-based persistence within Eclipse. It includes a package—called ECore—that provides a simplified implementation of MOF. We used ECore to define our metamodel for generic business processes. In addition to the basic process metamodel entities such Process, Resource, and Actor, we added some constructs to represent variations points in generic models, and dependencies between variants.

Figure 8. A sample generic process model.

Figure 8 shows model excerpts from our purchasing

process. We see two alternatives for the variation point Resource: tangible resources (Tangible) or service-like resources (Service). The reception of a resource is itself a variation point, with two variants, Delivery, for the delivery of tangible resources, and ElectronicDelivery, for the delivery of services.

With regard to the dynamic view, we should point out that the ECore metamodel lacks the basic elements to represent dynamic behaviour, and would have required extensive additions to represent and

manipulate (e.g. edit graphically) dynamic models. Accordingly, we decided to use a separate action language that has rich semantics, and link it up with ECore, namely, the BPEL language. BPEL has several advantages, including, i) a de-facto standard for modeling business processes, and ii) a number of open source tools for editing, parsing, and interpreting BPEL processes, provided as Eclipse plug-ins.

B. Representing questions As mentioned in section 3.B, the questions that we

use to specialize generic processes are instances of generic questions. In the example of Figure 8, we have two alternative specializations, depending on whether the product is tangible or not. A question specific to this model would be phrased as “is the product tangible or not”. This question is itself an instantiation of a generic question that says “is the resource tangible or not”. To instantiate that question for a given process model, we look for all classes C in that model that are of (meta)type Resource, and ask the question “is C tangible”. Thus, the question can be seen as a boolean function that takes a Resource as an argument:

boolean isResourceTangible(Model model, Resource res)

The first argument represents the containing model.

When called with a given resource, this function prompts the user for a yes/no answer, and returns the answer. The result can then be used to specialize the input process. Similarly, the question “can two roles be played by the same actor?” can be represented as: boolean reTwoRolesPlayedBySameActor(

Model model, Role r1, Role r2)

For a given input (generic business process) model, for each question, we scan the model looking for model elements that are of the same type as the question argument types, and ask the corresponding question. Thus, a model that has three resources will be subjected to six potential specializations, two per resource corresponding to yes/no answers. Similarly, a model that has three roles will have six potential specializations by the question “are two roles played by the same actor”.

This implementation raises several issues, including the unnecessary proliferation of questions, and the dependencies between specializations. We are in the process of experimenting with the question instantiation mechanism with actual processes from the MIT process handbook to develop heuristics to

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006

filter out some questions that are not relevant or that have obvious answer. The dependency issue is more challenging as it involves both representational issues and business / application domain issues.

V. DISCUSSION We envision a development model and a set of tools

that would enable us to develop information systems by modeling the business processes that they are meant to support, and using such models to guide the assembly of software components from an existing library of so-called generic business components. To this end, we need to be able to, 1) support the specification of a business process from catalog of generic, customizable business processes, 2) develop a library of generic software components that implement elementary business functions, and 3) assemble a software system by mapping the process model over the library of software components.

This is not a new idea, and researchers from both MIS (e.g. [4]) and AI/software engineering tried to tackle (e.g. [2], [12], [20]). Earlier attempts from the MIS side suffered from the lack of tools, conceptual and otherwise, to map business processes to software components. Work from the AI side dealt with information that was either too granular (e.g. [20]) or too knowledge intensive ([2], [12]) to be practical.

The work presented in this paper addresses the first step. We propose a method for classifying and specializing generic business processes that generalizes the so-called question-based classification into a systematic method for specializing business processes. This work is still in its infancy, and has many conceptual hurdles to overcome. However, the approach appears to be promising, and would allow us to extend the MDA paradigm upstream.

REFERENCES [1] Tony Andrews et al. Business Process Execution

Language for Web Services, version 1.1 , 5 May 2003. [2] Guillermo Arango, Domain Engineering for Software

Reuse, PhD thesis, 1988, Univ. of California at Irvine. [3] Business Process Modeling Language, Business

Process Management Institute, January 24, 2003, 96 [4] W.M. Carlson, "Business Information Analysis and

Integration Technique (BIAIT) - the new horizon." Data Base, 10 (4), p. 3-9, Spring 1979.

[5] Peter Coad, Eric Lefebvre, and Jeff Luca, Java Modeling In Color With UML: Enterprise Components and Process, Prentice-Hall, 1999.

[6] Curtis, B., Kellner, M.I. and Over, J.: “Process modeling”, Com. of the ACM, 35, (9), pp. 75- 90, 1992

[7] Martin Fowler, Analysis Patterns, Addison-Wesley, 1997.

[8] Hammer M., and Champy, J., Reengineering the Corporation, Harper Business, 1993, New York.

[9] Keller, G; Nüttgens, M, Scheer, A.-W, “Semantische Prozebmodellierung auf der Grundlage, Institut für Wirtschaftsinformatik, paper 89, Saarbrucken, 1992.

[10] J.Lee et al. The PIF Process Interchange Format and Framework (24/5/1996), http://ccs.mit.edu/pif8.html.

[11] Mitchell Lubars et al., "Object-Oriented Analysis for Evolving Systems," in Proc. of the 14th ICSE, pp. 173-185, Melbourne, Australia, May 11-15, 1992.

[12] Neil A. Maiden and Alistair G. sutcliffe, ‘‘Exploiting Reusable Specifications Through Analogy,’’ Com. of the ACM, vol. 35, no. 4, pp. 55-64, April 1992.

[13] T.W. Malone et al., “Tools for inventing organizations: Toward a handbook of organizational processes,” Management Science 45(3) pp 425-443, March, 1999.

[14] W. E. McCarthy. "The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment," The Accounting Review (July 1982) pp. 554-78

[15] H. Mili, A. Mili, S. Yacoub, and E. Addy, Reuse-Based Software Engineering, John – Wiley & Sons, 2001.

[16] Business Process and Business Information Analysis Overview v1.0 (ebXML), May 11, 2001, http://www.ebxml.org/specs/bpOVER.pdf

[17] EDOC: UML Profile for Enterprise Distributed Object Computing, Document ptc/2001-12-04, Dec. 2001

[18] M.A. Ould, Business Processes: Modelling and Analysis for Re-engineering and Improvement, 1995, John Wiley & Sons.

[19] T. Reenskaug, Working with Objects: The OORAM Software Engineering Methodology, Manning, 1996.

[20] Charles Rich and Richard Waters, ‘‘The Programmer’s Apprentice: A Research Overview,’’ IEEE Computer, pp. 11-25, November 1988.

[21] RosettaNet, 2003, http://www.rosettanet.org [22] Workflow Management Coalition, Interface 1: Process

Definition Interchange Process Model. WfMC-TC-1016-P, Version 1.1, October 1999

[23] Workflow Management Coalition, Terminology and Glossary, Doc. num WFMC-TC-1011, February. 1999.

Proceedings of the 18th IEEE InternationalConference on Tools with Artificial Intelligence (ICTAI'06)0-7695-2728-0/06 $20.00 © 2006