software components, we will be able to develop informations systems by modeling ..... Framework for Accounting Systems in a Shared Data Environment," The.
Going beyond MDA: Business Process Modeling for Software Reuse Hafedh Mili1,2, Guitta Bou Jaoude1,2, Éric Lefebvre1,3, Guy Tremblay1,2 1
Laboratory for Research on Technologies for eCommerce (www.latece.uqam.ca) Département d’informatique, Université du Québec à Montréal, Montréal, Canada 3 École de Technologie Supérieure, Montréal, Canada
2
Abstract. Enterprises build information systems to support their business processes. Some of those business processes are industry or entreprisespecific, 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 subprocesses, 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 informations 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 (see e.g. [Carlson, 1979]), but earlier attempts suffered from the lack of tools, conceptual and otherwise, to perform this mapping. In this paper, we describe an object-oriented process modeling language, and propose a method for classifying and specializing generic business processes. This method should allow us to derive, from a catalog of generic processes and process specialization operators, an enterprise-specific process , which corresponds closely to MDA’s computation independent models or CIMs.
1 Introduction Enterprises build information systems to support their business processes. Some of those processes are industry or entreprise-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 litterature to talk about a hierarchy of reuse levels, with the following characteristics [Mili et al., 2001]: 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 a domain functionality and that embody a design. Such components are domainspecific, 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 need to be instantiated from the domain at hand. Figure 1 illustrates this process. 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
spec GP
GP5
GP6
Figure 1-b. Modelers find the process they need by using one of the stored ones asis (e.g. GP5), or by specializing it using specialization operators (e.g. GP6)
GP1
GP2
GP3
spec GP4
GP5
GP6
Inst.
P6,
Figure 1-c. The generic process (GP6) obtained by specializing a process in the catalog
Figure 1. A methodology for generating application-specific platform-independent models.
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. We conclude in section 4.
2 Process modeling
2.1 What is process? Curtis defined a process as a partially ordered set of tasks or steps undertaken towards a specific goal [Curtis et al., 1992]. Hammer and Champy define business processes as a set of activities that, together, produce a result of value to the customer [Hammer & Champy, 1993]. 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.” [WfMC,1999]. 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 an other). The actors operate within the context of organizational boundaries. Organizations perform specific business functions. Roles can support functions.
fun ctiona l d ec om p * su bp ro ce ss
h ierarchy *
*
*
F un c tion
O rg an izatio n
perfo rm s
*
P ro c ess 1
*
*
* 1 co m po se d-of trigg ers
*
*
*
s up ports
m em b er o f
*
*
*
pe rfo rm e d by E v en t
R o le *
*
plays
Activ ity
gen erates * *
*
c ons um e s
p ro du ce s
*
R e so u rc e
*
Ac to r *
*
*
Figure 2. A first-cut business process metamodel.
We will refer again to this meta-model when we present our classification procedure.
2.2 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 [Curtis et al.,1992]: 1) The functional view: this view presents the functional dependencies between the process elements (activities, sub-processes, etc.). Typical dependencies include producer-consumer dependencies—one activity consumes a resource produced by another. 2) The dynamic (behavioral) view: 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—including UML 1.x—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. Furthermore, 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. This is an important distinction that is discussed below. An important difference between business process modeling and information system modeling is the fact that a business process includes both automated (computerized) activities and processes, and manual ones, whereas information system modeling focusses on the computerized part. In fact, a business process model need not even include automated processes or activities (as implemented by information systems), and when they do appear in a business process model, the computerized systems appear as black boxes1 in the overall business process model. Isoda refers to business process models (with or without a computerized component) as real-world models whereas the information system models are called pseudo realworld models [Isoda, 2001]. To see the distinction, consider the following description of the process of borrowing a book from the reference desk of a library: “the user searches the reference index for a document by title, prints the entry and gives it to the reference librarian. The librarian brings the document from the shelves, hands the document to the user, and updates the document and the user files on the system”. In this process model, we have one entity to model the user, and one to model their file on the computerized library system. We also have two entities for the book: one entity for the physical book, and another for its on-line record. The representations of the two entities (user and book records) are the things that will show up in an information system object model, usually simply as ‘Book’ or ‘User’. Confusing the two can lead to serious modeling errors [Isoda, 2001].
2.3 Our choice Ould argued that business process modeling is useful for three basic reasons, which may in turn support several business goals [Ould,1995], 1) describing a process for various target audiences (humans, machines), 2) analyzing a process, which consists of studying its properties—a task that can often be mechanized with formal languages, and 3) enacting a process, either for simulation purposes or to provide some level of support for process execution. Language designers may put the emphasis on one of these basic usages, often at the expense of the others [Mili et al., 2003]. In our case the emphasis is clearly on description, with two target audiences: 1
The input/output relations of such black boxes are nothing but the user requirements.
1) humans, who need to develop and validate process models, and 2) machines, that need to apply different operations on them, including classification and transformation to analysis models. 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 [Murata, 1988]), to business process management languages (role-activity diagrams or RAD, [Ould,1995], Resource-Event-Agents, or REA, [McCarthy, 1982], Event-Process Chains, or EPC, [Keller et al., 1992], Business Process Modeling Language, or BPML [BPMI,2003]), to workflow modeling languages (e.g. PIF [Lee et al., 1996]), to e-business process interconnection languages and frameworks (Rosettanet [Rosettanet, 2003], ebXML [OASIS,2001], BPEL4WS [Andrews et al.,2003]) to object-oriented languages and dialects (UML 1.x, OORAM [Reenskaug, 1996], EDOC [OMG,2001], and UML 2.0). Because we want to ultimately map our process models to object models, objectoriented 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 [OMG, 2001] 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 [OMG,2002]. 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 business 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 dependencies2, and some minor extensions to support the representation of variation points, or hotspots in the model (see [Clauss, 2001]).
2
Interestingly, DFDs were part of OMT, but were critized for the difficulty to link them to object constructs. Activity diagrams do embody some functional dependencies, but are control oriented and are less abstract.
3 An approach to business process classification
3.1 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. Figure 3 shows a simplified functional view of the process.
Process request for product
Identity suppliers
Process purchase order
receive ordered product
Pay supplier
Figure 3. The functional view of a basic ordering process.
Ordering starts by first filling out a request for 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. 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 flavours 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 don’t 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 brifely. 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 catalogs. These classifications are for the most part high-level, often based on Porter’s framework [Porter, 1985], and refer to broad functional areas such as production, logistics, support, or planning (see e.g. [Lefebvre,1996], [IBM, 1998], [Coad & Lefebvre,1999]). These 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 litterature) 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, labor intensive [Mili et al., 2003]. Structural classifications would help us answer the second question, i.e. generate, on the fly, process specializations based on a catalog of generic processes and a catalog of elementary specializations. Let us look at a simplified model from the informational view of the ordering process. We are showing attributes in those cases where it helps understand the containing class. 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.
-requester
-order
-order
Requester
-supplier
Order 1
Supplier 0..*
*
1
1
-supplier
*
Terms priceSchedule deliveryDelay : Date
-product
1..*
*
-product Product
LineItem -quantity : int
1
*
Figure 4. Basic (partial) informational view for the ordering process.
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. Contract
-contract
-contract
-startDate : Date -endDate : Date -buyer
0..*
0..*
-order
-order
1
1 -requester
Requester
Order 1
Supplier 0..*
*
-supplier
-supplier
1
1
-supplier
*
Terms priceSchedule deliveryDelay : Date
-product
1..*
*
-product LineItem -quantity : int
Product 1
*
TangibleProduct
Service
-weight : float -volume : float
Figure 5. The informational view for a specialization of the purchasing process
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, subclassing. That covers but 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 drastic changes in the dynamic model [Lubars et al., 1992]. 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 catalog of elementary specialization operators, but that catalog will have to include far more than the typical objectoriented ones (composition, inheritance). The answer to the third question above (specializing software artifacts based on the specialization of the corresponding business processes) is beyond the scope of this paper. The general idea is to develop a catalog 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.
3.2 Classification using meta-model hotspots Our analysis of the business process classification problem (see previous section) showed that there are no simple specialization operators that can be applied on any of the views that would yield systematically meaningful specializations. One of the approaches that has been taken in the past 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 [Carlson, 1979]. The data and the operations supported by the information systems depend on the business model and on the way the organization works. Carlson has reduced these variations to the answers to seven questions (yes/no) whose answers determine the kind of process, and thus information system, we have. 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 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 in [Lefebvre, 1996], and used them to help identify component archetypes [Coad & Lefebvre, 1999]. Wohed proposed a similar set of questions [Wohed, 2000]. 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 all the processes and the corresponding information systems. The MIT process handbook also used the question approach to specialize processes [Malone et al.,1999]. 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 handside of the figure can be further specialized using more specific questions.
Figure 6. Part of the classification scheme used by the MIT Process Handbook. From [Malone et al., 1999]
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 roughly outlined the model fragments specific to each view3. Functional/dynamic view subprocess
functional decomp *
*
*
hierarchy
* Process
Function *
1
Organization
performs
1
*
* Location
composed-of
*
*
supports
member of
location triggers
*
*
*
*
*
performed by Event
Activity
generates
Role *
*
plays
* *
*
consumes
produces
*
Resource
*
Actor *
*
Organizational view
*
Informational view
Figure 7. A partitioning of the business process metamodel.
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 potentially 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. 3
Naturally, this is not an exact partition as the different views cross-reference each other via shared entities.
•
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 (5) organizational, four (4) functional, and six (6) 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). Having identified the questions, now the task is 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 are developing one set of transformations per view. Some of these transformations consist of removing model fragments that follow a specific pattern (e.g. 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 (e.g. [Fowler, 1997], [Coad & Lefebvre, 1999]). We are validating and refining the transformations by applying them to existing generic processes. This is a tedious and labor intensive step. However, this is a onetime effort, as the so validated questions and transformations can be applied to any business process. Further, in the process of doing that, we are gaining lots of insights into the problem of mapping process models to software artifacts—starting with analysis models.
4 Discussion Enterprises build information systems to support their business processes. Some of those business processes are industry or entreprise-specific, but most are common
to many industries and are used, modulo a few modifications, in different contexts. Our long-term research goals are: 1) be able to start reusing “software” as early as the business process modeling phase, where we are specifying the context of usage of our system, and 2) use a transformational approach à la MDA throughout. We envision a development model and a set of tools that would enable us to develop informations 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 3) assemble a software system by mapping the process model over the library of software components. This is not a new idea (see e.g. [Carlson, 1979]), but earlier attempts suffered from the lack of tools, conceptual and otherwise, to map business processes to software components. 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, resulting in greater reuse and inter-operability.
5 Bibliography [Andrews et al., 2003] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Aivana Trickovic, Sanjiva Weerawarana, Business Process Execution Language for Web Services (BPEL4WS) version 1.1 , 5 May 2003. [BPMI,2003] Business Process Modeling Language, Business Process Management Institute, January 24, 2003, 96 pages [Carlson, 1979] W.M. Carlson, "Business Information Analysis and Integration Technique (BIAIT) - the new horizon." Data Base, 10 (4), p. 3-9, Spring 1979. [Coad & Lefebvre,1999] Peter Coad, Eric Lefebvre, and Jeff Luca, Java Modeling In Color With UML: Enterprise Components and Process, Prentice-Hall, 1999. [Curtis et al., 1992] Curtis, B., Kellner, M.I. and Over, J.: “Process modeling”, Communications ACM, 35, (9), pp. 75- 90, 1992 [Fowler, 1997] Martin Fowler, Analysis Patterns, Addison-Wesley, 1997. [Hammer & Champy, 1993] Hammer M., and Champy, J., Reengineering the Corporation, Harper Business, 1993, New York. [Isoda, 2001] Sadahiro Isoda, “Object-Oriented real-world modeling revisited,” Journal of Systems and Software, vol. 59 (2001), pp. 153-162.
[Keller et al., 1992] Keller, G; Nüttgens, M, Scheer, A.-W, “Semantische Prozebmodellierung auf der Grundlage, publication of the Institut für Wirtschaftsinformatik, paper 89, Saarbrucken, 1992. [Lee et al., 1996] J.Lee, M.Gruninger,Y.Jin, T.Malone, A.Tate, G. Yost, and other members of the PIF Working Group, The PIF Process Interchange Format and Framework (May 24,1996),1996, http://ccs.mit.edu/pif8.html. [Lefebvre, 1996] Eric Lefebvre, doctoral thesis, 1996 [Lubars, 1992] Mitchell Lubars, Greg Meredith, Colin Potts, and Charles Richter, "Object-Oriented Analysis for Evolving Systems," in Proceedings ofthe 14th International Conference on Software Engineering, pp. 173-185, ACM Press, Melbourne, Australia, May 11-15, 1992. [McCarthy, 1982] William 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 [Malone et al.,1999] T.W. Malone, K. Crowston, J. Lee, B. Pentland, C. Dellarocas, G. Wyner, J. Quimby, C.S. Osborn, A. Bernstein, G. Herman, M. Klein, and E.O'Donnell, “Tools for inventing organizations: Toward a handbook of organizational processes,” Management Science 45(3) pp 425-443, March, 1999. [Mili et al., 2001] Hafedh Mili, Ali Mili, Sherif Yacoub, and Edward Addy, Reuse-Based Software Engineering, John – Wiley & Sons, N.Y, 2001, 650 pages. [Mili et al., 2003] Hafedh Mili, Guitta Bou Jaoude, Guy Tremblay, Eric Lefebvre, and Alex Petrenko, “Business Process Modeling Languages: Sorting Through the Alphabet Soup,” TR LATECE, november 2003, 55 pages. [OASIS, 2001] Business Process and Business Information Analysis Overview v1.0 (ebXML), May 11, 2001, http://www.ebxml.org/specs/bpOVER.pdf [OMG,2001] OMG, EDOC: UML Profile for Enterprise Distributed Object Computing, Document ptc/2001-12-04, December 2001 [Ould, 1995] M.A. Ould, Business Processes: Modelling and Analysis for Re-engineering and Improvement, 1995, John Wiley & Sons. [Reenskaug, 1996] Trygve Reenskaug, Working with Objects: The OORAM Software Engineering Methodology, Manning, 1996. [RosettaNet,2003] http://www.rosettanet.org [WFMC,1999a] Workflow Management Coalition, Interface 1: Process Definition Interchange Process Model. WfMC-TC-1016-P, Version 1.1, October 1999.
