Towards MDA implementation based on a novel BPMN
metamodel and ATL transformation rules
Jaouadi Imen, Maha Khemaja
PRINCE Research Group, ISITC, Hammam Sousse,
GP1 Hammam Sousse 4011
University of Sousse, Higher Institute of Computer Science
and Management, ISIG
Kairouan, Tunisia
{amounaing, maha_khemaja}@yahoo.fr
Abstract—A few research works have proposed a BPMN
metamodel fully compliant to the BPMN specification. In a recent
project called PERCOMOM and based on MDA approach, we
have noticed the need to a BPMN metamodel and a
transformation tool to handle automatically transformations from
a BPMN model to an XML model. In this paper, we have
proposed a BPMN metamodel and a set of transformation rules
based on ATL to automatically handle those transformations. We
have also applied and validate our approach on some samples of
BPMN models.
Keywords- BPMN, metamodel, MDA, transformation rules,
ATL
I. INTRODUCTION
Software engineering is currently greatly influenced by
Model Driven Architecture (MDA) [1], which is a new
paradigm that claims to work at model and metamodel levels.
MDA has a potential to increase development productivity and
quality by describing important aspects of a solution with more
human-friendly abstractions and by generating common
application fragments with templates [2].
Moreover, software engineers are aware of the importance
of business processes modeling in a conceptual level because
firstly, it’s easier to get a representation consensus of business
processes and secondly, it is easier to validate them by
business domain experts. Languages used for that aim are
comprehensive to both computer scientists and/or business
users. Business process modeling languages are independent
from a specific implementation or a platform. An example of
these languages and which is widely used by many companies
is the Business Process Modeling notation (BPMN) [3].
Till now, there is no official published BPMN metamodel.
Indeed, all already defined metamodel cover only a subset of
the notation elements set. We aim in this paper to propose a
BPMN metamodel which is quite compliant to OMG’s
metamodel. Then, we try to validate the proposed metamodel
by using it within the industrial PERsonalization COnceptual
MOdeling Method (PERCOMOM) project [4]. Finally we
propose a translation approach allowing transformations from
978-1-61284-4577-0324-9/11/$26.00 ©2011 IEEE
Mourad Abed
Univ Lille Nord de France, F-59000 Lille, France
UVHC, LAMIH, F-59313 Valenciennes, France
CNRS, UMR 8530, F-59313 Valenciennes, France
mourad.abed @univ-valenciennes.fr
BPMN models to XML models accordingly to an MDA
approach.
The rest of the paper will be structured as follows: the
section 2 will introduce the MDA approach. In section 3 we
will deal with the BPMN language and we focus on some
related works. In section 4, we will present our BPMN
metamodel. In section 5, we will present our translation
approach related to BPMN models transformations to XML
models. In this section we will also expose the transformation
rules. Finally, we conclude and outline our future works.
II. THE MODEL DRIVEN ARCHITECTURE
The model driven architecture (MDA) starts with the well
known and long established idea of separating the specification
of one’s system abstract functionalities from the details of its
implementation’s platform. This approach promises a number
of benefits including improved portability due to separating the
application knowledge from the mapping to a specific
implementation technology, increased productivity due to
automating the mapping, improved quality due to reuse of well
proven patterns and best practices in the mapping, and
improved maintainability due to better separation of concerns
and better consistency and traceability between models and
code [2].
The MDA specifies a model based software engineering
approach that explicitly separates models at three abstraction
layers. The most abstract model, the Computational
Independent Model (CIM), deals only with concepts of the
application domain. A CIM is refined into a Platform
Independent Model (PIM) that contains already computational
information about a system but is free from Platform Specific
Model (PSM), which is a refinement of the PIM [1].
MDA is based on a layered architecture with the
metametamodel, metamodel, model and information layers.
Figure 1 presents the basic metamodeling architecture of MDA
with the relationships between different levels of models. In this
approach, everything is a model or model element. In level M0,
62
a real system is represented by a model in level M1, and a
model in level M1 conforms to a metamodel in level M2.
 
Figure 1. The layered MDA architecture [5]
It is well recognized today that model transformation is one
of the most important operations in the MDA approach. The
MDA guide [1] defines a model transformation as “the process
of converting one model to another model of the same system.
A transformation rule is a description of how one or more
constructs in the source language can be transformed to one or
more constructs in the target language. Rephrasing these
definitions by considering as illustrated in Figure 2, a model
transformation program takes as input a model conforming to a
given source meta-model and produces as output another
model conforming to a target meta-model. The transformation
program, composed of a set of rules, should itself be
considered as a model. Consequently, it is in turn based on a
corresponding meta-model, that is an abstract definition of the
used transformation language [5].
Figure 2. MDA’s transformation process [5]
III. THE BUSINESS PROCESS
MODELING NOTATION AND
SOME RELATED WORKS
A. The Business Process Modeling Notation (BPMN)
BPMN [3] is a graphical representation for specifying
business processes in a business process model. It is developed
 by the Business Process Management Initiative (BPMI). The
primary goal of the BPMN effort was to provide a notation that
is readily understandable by all business users, from the
business analysts that create the initial drafts of the processes,
to the technical developers responsible for implementing the
technology that will perform those processes, and finally, to
the business people who will manage and monitor those
processes.
Business process modeling is used to communicate a wide
variety of information to a wide variety of audiences. BPMN is
designed to cover many types of modeling and allows the
creation of end-to-end business processes. The structural
elements of BPMN will allow the viewer to be able to easily
differentiate between sections of a BPMN Diagram [3].
BPMN defines a Business process Diagram (BPD), which
is based on flow charting techniques tailored for creating
graphical models of business process operations. A BPD is
made up of set of graphical elements. These elements enable
the easy development of simple diagrams that will look
familiar to most business analysts. The elements were chosen
to be distinguishable from each other and to utilize shapes that
are familiar to most modelers. For example, activities are
rectangles and decisions are diamonds (figure 3). It should be
emphasized that one of the drivers for the development of
BPMN is to create a simple mechanism for creating business
process models, while at the same time being able to handle
the complexity inherent to business processes. BPMN provides
a small set of notation categories so that the reader of a BPD
can easily recognize the basic types of elements and
understand the diagram. The four basic categories of elements
are: flow objects, connecting objects, swimlanes and artifacts
[3].
Figure 3. An example of a business process [3]
63
B. Related works: already proposed BPMN metamodels because they don't have a significant role. Moreover, although
there are several event types [3], we have considered only
A metamodel is a language for defining models. It defines events pertaining to Timer, message and rule types.
the concepts and relationships needed to express models. Some
research works have proposed BPMN metamodels but all of
those works have done that for very specific needs and didn’t V. THE TRANSLATION APPROACH
cover all BPMN elements and constructs.
A. An industrial project background
We name for example [6] which have proposed a BPMN
metamodel based on Meta Object Facility (MOF ) [7]. This To validate our metamodel, we have applied it to the
metamodel proposed to automate the management of activities PERCOMOM approach. According to this approach, the
of a software development process specified by the SPEM BPMN is used to express the MDA CIM level and it has to be
(Software Process Engineering Metamodel).The SPEM translated to MDA PIM level which is expressed in the XML
activities are transformed in subprocesses of the standard language (eXtensible Markup Language). The target XML
BPMN. We notice that the metamodel describes only a subset model will therefore contain a set of task definitions with their
of BPMN elements; it doesn't describe the Gateway, Event, relationships. The table 1 illustrates XML definitions
Business process and Message flow concepts which are corresponding to BPMN element definitions. Those XML
considered as BPMN important concepts. element definitions are the result of the transformation process
from the CIM level to the PIM level.
[8] proposes another metamodel which presents major of
basic elements of the BPMN. However, this metamodel
presents some shortcomings. The concept attributes isn’t TABLE I. MATCHING BETWEEN BPMN AND XML ELEMENTS
defined and not all of the relationships between BPMN DEFINITIONS
elements are defined. Moreover, the relationships definition is Bpmn Notation Corresponding XML element
complex. model
element
Therefore, as a conclusion of this section, we can say that <pool id="xxx"
all the metamodels already presented, have shortcomings due name="yyy">
<lane id="xxx"
to the lack of some important BPMN elements and their name="yyy">
relationships. Our metamodel is thus much more complete. Siwmlane <task……….>
Let’s so present it. ::::::::::::::::::::::
</lane>
</pool>
IV. OUR PROPOSAL : A NOVEL BPMN <subprocess id="xxx"
METAMODEL type="Adhoc/loop
name="yyy">
First of all, to present our metamodel we should avoid all Subprocess <task………..>
: ::::::::::
the shortcomings previously detected and list all needed </subprocess>
BPMN concepts. <task id="xxx" type="task"
name="yyy">
A business process is composed of pools and messages Task <nexttask id="xxx"/>
flows. A pool is composed of lanes. Lanes are composed of </task>
flow objects which are connected by sequence flows. The flow <task id="xxx"
object represents: Gateway, Activity and Event BPMN type="eventbeginprocess"
Event start expession=''y"> <nexttask
concepts. A sub-process is composed of object flow elements id="xxx"/>
which are connected by sequence flows [3]. We have used </task>
those concepts to define our BPMN metamodel (Figure 4) <task id="xxx"
type="Gatewayxor"
We should stress that, the representation of events attached condition="yyy" <nextask
to activities is done via the event task reference concept. Gateway id="xxx"
exclusive evaluation="value1"/>
Finally, to facilitate the elements relationships management, <nextask id="xxx"
we have defined the following references: - (from) and (to) evaluation="value2"/>
represent respectively input and output ends of a sequence </task>
flow(inflow) and (outflow) describe respectively the set of <messageflow id="xxx"
message="zzz">
entrant and extran of object flow element.(frompool) and
< task frompoolid="x"
(topool) represent respectively the input and output pool of the Message fromflowobjectid="y"/ >
message flow. flow < task topoolid="xxx"
toflowobjectid="yyy" />
We should notice that we have omitted to represent Artifact
and Association BPMN elements within our metamodel

64
 Figure 4. The proposed BPMN metamodel

According to MDA approach, the transformation process uses

as its input a model which is conform to a source metamodel
and produces one or several other models as output. These
latter models are compliant to a target metamodel. The
transformation uses equally transformation rules. Both the
source and the target models must be MOF compliant [7].
Within the same context, our work is concerned by
transforming the Business Process Model pertaining to
PERCOMOM CIM level to an XML model having a defined
structure (table 1). Both models Business Process Model and
XML must be compliant to their corresponding metamodels
namely the BPMN metamodel and the XML metamodel which
are both compliant to MOF (figure 5).

Our metamodel meets the PERCOMOM approach needs. Figure 5. Transformation approach between BPMN and XML
Indeed, we can use it to establish the CIM level to PIM level
transformations. Let’s so present the transformation rules that
we have defined.
B. Transformation rules
Nowadays we can find many languages that can be used to
implement transformation rules. As examples, we can name
MOLA [9], UMLX [10], QVT [11] and ATL [12]. To
implement our transformation rules, we have chosen the ATL
language because it meets the following criteria: 1) it is simple
as well as flexible 2) it allows hybrid rule expressions
(declarative and imperative rules). This latter criterion is the
most important. Indeed, all the generated elements are

65
composed of other elements which are on their own generated
by other transformation rules (table 1). For instance, the
businessproces XML element generated from the Business
Process element according to the BPMN metamodel, is
composed of pool XML element and requires rules using other
ones to create the target elements. So invoking imperative rules
is an important requirement for our approach.

Besides, the big complexity of our transformation rules is

to find the suitable method to create the target model which
must have a tree structure where each element is composed of
other elements (children Nodes).Within our ATL code; we
provide a solution to that problem by using a helper add
Listing. 3. rule root
statement. The statement allows adding an element at the end
of a given list as showed in Listing 1. Where the element
"element" is added thanks to the function append (ligne4) at The rule Pool presents the ATL syntax for deducing the
the end of the list "list" defined at ligne1. XML pool element as showed in Listing 4.

Listing. 1. helper add

The Listing 2 shows the called Attribute rule aiming to

create an attribute having a name and a value, passed by
parameter to the rule.

Listing. 4. rule Pool

The loop for in Listing 4 allows to handle each lane element

of the source model. Thereafter, for each element lane in the
loop we call the called "Lanes" rule.

Listing. 2. The rule Attribute C. Experimentation

To experiment our approach we use:
 Our source metamodel that we have
The root rule (Listing 3) initiates our transformation process. designed by the eclipse EMF editor(figure 6)
The first part of that rule is declarative, its aims creating the
 Our target metamodel for XML also
target root element (ligne6) from the Business Process element
designed by the eclipse EMF editor
within BPMN metamodel (ligne4). The imperative block of
that rule (do{}ligne9), calls in an implicit manner the flowing  A business process model compliant to our
rules: 1) rule Attribute(ligne12 and 15), 2) rule BPMN metamodel :It is a business process
pool(ligne18) and 3) rule message(ligne22) for on line auction system (figure 7)

 A file containing all the ATL transformation

rules

66

Figure 6. Our BPMN metamodel designed by the eclipse EMF editor
Figure 7. Simple BPMN Business Process Diagram for An on line auction
system [13]
The result is then an XML model which is compliant to the
standardized XML metamodel designed by the eclipse EMF
editor (figure 8)
Figure 8. The result XML model designed by the eclipse EMF editor
67
VI. CONCLUSION AND FUTUR
WORKS
Our approach has firstly proposed a BPMN metamodel.
Secondly it focused on developing transformation rules
allowing automatic BPMN model to an XML model
transformations.
We aim to improve our metamodel by adding for example
the artifact concept and extending the implemented Event
concept by other possible process event types. We aim also to
implement the reverse transformation, so that we can be sure
that there isn't any lost information when shifting from a model
to another. We should also notice that the XML target
metamodel is very generic so that it could not meet specific
needs such as those related to BPMN2BPEL transformations.
VII. REFERENCES
[1] OMG, MDA Guide version 1.0.1, june 2003
[2] Slimane Hammoudi, Jérôme Janvier and Denivaldo Lopes. Mapping versus
Transformation in MDA: Generating Transformation Definition from Mapping
Specification. EDOC International Workshop on Vocabularies, Ontologies and
Rules for the Enterprise, Enschede, The Netherlands, September,2005.
[3] OMG. Business Process Modeling Notation (BPMN) specification,
January2008
[4] Arnaud Brossard. PERCOMOM : Une méthode de modélisation des
applications interactives personnalisées appliquée à l'information de voyageur
dans le domaine des transports collectifs, informatique thesis, university of
Valenciennes, France, 2008.
[5] Davide Di Ruscio, specification of model transformation and weaving in
model driven engineering, thesis in computer science, university Aquila, Italy
2007
[6] N.Debnath, F. A Zorzan, G. Montejano et D. Riesco, Transformation of
BPMN Subprocessses Based in SPEM Using QVT", IEEE EIT 2007
Proceedings
[7] OMG. Meta Object Facility(MOF)2.0 Query/View/Transformation OMG
Adopted specification, november 2005.
[8] Birgit Korherr, Beate List, "extending the EPC and the BPMN with
Business Process goals and performance measures
[9] Audris Kalnins, Edgars Celms et Agris Sostaks. Model Transformation
Approach Based on MOLA, university of LaTiva, IMCS
[10]GMT Consortium Edward D. Willink. Umlx : A graphical transformation
Language for mda. september 2003
[11] OMG. Meta Object Facility (MOF)2.0 Query/View/Transformation OMG
Adopted specification, november 2005
[12] ATLAS group LINA & INRIA Nantes. ATL:Atlas Transformation,
Language ATL User Manual , version 0.7, February 2006
[13] Martin Owen and Jog Raj, BPMN and Business Process Management
Introduction to the New Business Process Modeling Standard, 2003