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)
2
Département d’informatique, Université du Québec à Montréal, Montréal, Canada
3
École de Technologie Supérieure, Montréal, Canada

Abstract. 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. 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 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 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 as-
is (e.g. GP5), or by specializing it using specialization operators (e.g. GP6)

GP1

GP2 GP3
spec

GP4 GP5
GP6 P6,
Inst.

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 h ierarchy

* *
su bp ro ce ss
* *
F un c tion perfo rm s O rg an izatio n *
P ro c ess
1 * *

* *
1 s up ports m em b er o f
co m po se d-of

trigg ers
* * * * *
pe rfo rm e d by plays
E v en t gen erates Activ ity R o le Ac to r

* * * *
* *
* *

c ons um e s p ro du ce s

* R e so u rc e *

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 real-
world 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, 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 [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 -supplier

Requester Order Supplier

1 * 0..* 1

1 -supplier * Terms
priceSchedule
deliveryDelay : Date

1..* -product *
-product
LineItem Product
-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
0..* 0..*
-buyer 1 1 -supplier
-requester -order -order -supplier
Requester Order Supplier

1 * 0..* 1

1 -supplier * Terms
priceSchedule
deliveryDelay : Date
-product *
1..*
-product
LineItem Product
-quantity : int 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 object-
oriented 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 performs Organization *
1

* *

1 * *

composed-of Location supports member of

location
triggers
* * * * *
performed by plays
Event generates Activity Role Actor

* * * *
* *
* *

consumes produces Organizational view

* Resource *

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 one-
time 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.