A FRAMEWORK FOR EXECUTING CROSS-MODEL
TRANSFORMATIONS BASED ON PLUGGABLE METAMODELS
Geert Delanote, Sven De Labey, Koen Vanderkimpen and Eric Steegmans
K. U. Leuven, Department of Computer Science, 200A Celestijnenlaan, B-3000 Leuven, Belgium
Keywords:
Framework, metamodeling, model transformations.
Abstract:
The design of complex software systems requires developers to use a variety of modeling languages in order
to model various system aspects. The heterogeneity of these modeling languages gives rise to new challenges.
Design decisions must be communicated across heterogeneous models, thus creating a need for cross-model
communication. Furthermore, models must be transformable between different modeling languages, thus
creating a need for cross-model transformations. By supporting only a single modeling language and by
providing limited interoperability, however, the majority of today’s modeling tools cannot provide cross-model
communication nor transformation, as such jeopardizing the consistency of the design as a whole.
In this paper, we present the design of a transformation framework, Pluto, which supports cross-model trans-
formations based on pluggable metamodels. We discuss how Pluto eases the realization of concrete metamod-
els by offering abstract modeling constructs, and we show how it is able to execute transformations between
concrete instances of such metamodels.
1 INTRODUCTION
The design of complex enterprise applications im-
poses new challenges on software developers as well
as on tools supporting model-driven software design.
Such complex designs are typically created using dif-
ferent modeling languages, where each language fo-
cuses on a specific aspect of the enterprise applica-
tion. Aligning software with business requirements,
for instance, is typically done using workflow model-
ing languages such as the Business Process Execution
Language (BPEL) (BPEL4WS, 2003). The technical
realization of each identified BPEL process is then
modelled using UML interaction diagrams, whereas
the back-end database persisting the state of that
BPEL process is designed using Entity-Relationship
(ER) or Relational (RDB) database models. The het-
erogeneity of these modeling languages imposes new
challenges on modeling tools. For example, Plat-
form Independent Models crafted in earlier stages of
the design process must be transformable to models
written in different modeling languages, thus creat-
ing a need for cross-model transformations (Frankel,
2003). Also, general design decisions to be respected
by the whole project must be communicated to mod-
els written in different modeling languages, as such
creating a need for cross-model communication in or-
der to guarantee cross-model consistency (Rensink,
2005).
Current tool support can hardly cope with the
increased complexity introduced by heterogeneous
modeling languages as the majority of modeling
tools rely on hardwired, vendor-specific metamod-
els. By hardwiring their metamodels, such tools dis-
able transformations to other modeling languages.
Furthermore, by relying on proprietary metamod-
els, transformation tools obstruct metamodel reuse in
other modeling tools because those competing tools
rely on ad hoc metamodels that are in turn proprietary
and hence incompatible.
Being convinced that a lack of support for cross-
model transformations and vendor lock-in are serious
limitations of today’s modeling tools, we have de-
signed and implemented a transformation framework
with support for pluggable metamodels. By making
metamodels interchangeable, this tool allows mod-
315
Delanote G., De Labey S., Vanderkimpen K. and Steegmans E. (2007).
A FRAMEWORK FOR EXECUTING CROSS-MODEL TRANSFORMATIONS BASED ON PLUGGABLE METAMODELS.
In Proceedings of the Second International Conference on Software and Data Technologies, pages 315-325
DOI: 10.5220/0001348803150325
Copyright
c
SciTePress
ellers to introduce a metamodel for their own mod-
eling language and it provides a basis for executing
horizontal, cross-model transformations.
In this paper, we focus on the design of Pluto,
a framework providing reusable concepts for (1)
building concrete metamodels and (2) for transform-
ing concrete models between different modeling lan-
guages. The remainder of this text is structured as
follows. Section 2 elaborates on current tool support
for model transformations and discusses a number of
limitations, leading to a list of design goals, as de-
scribed in Section 3. Section 4 introduces our frame-
work, Pluto, and Section 5 shows how Pluto eases the
implementation of new metamodels. Section 6 shows
how Pluto models can be transformed to target models
written in other modeling languages. Finally, Section
7 discusses related work and Section 8 concludes.
2 MOTIVATION
Current tools for designing and transforming models
hardly support the functionality required for develop-
ing complex software systems. We have identified a
number of disadvantages that have led to the design
goals enumerated in Section 3:
Limited Applicability. Transformation tools are
often shipped containing a hardwired metamodel
of a single modeling language so as to (vertically)
transform models within that same language. Al-
though complex models may be realized using
such tools, it is impossible to design models in
any other modeling language than the one sup-
ported. This forces modellers to use a different
tool for each modeling language they are willing
to use. Threatened by the risk to scatter their
designs over incompatible tools, developers are
tempted to stick with a single, general model-
ing language such as UML, even though special-
ized modeling languages are often better suited
for modeling specific parts of a software system.
Limited Interoperability. Next to being hard-
wired in modeling tools, embedded metamodels
often contain proprietary constructs, for example,
to increase the performance of the transforma-
tion tool in which they are embedded. Although
economically feasible for the tool supplier, who
achieves a vendor lock-in, such proprietary con-
structs are awkward for the end users of that tool
because it becomes very hard to reuse their de-
signs in other modeling applications. Indeed, the
latter will not be able to understand the format of
the proprietary metamodel in which the original
version of the model was defined.
Limited Extensibility. Modeling tools often pro-
vide a mechanism to define extensions for mod-
eling languages. The Unified Modeling Lan-
guage, for instance, introduces UML profiles and
stereotypes to allow developers to extend UML
with domain-specific modeling concepts (OMG
UML Specification 1.5, 2003). Transformation
tools may provide similar extension mechanisms
to let developers extend the modeling language on
which that tool operates. The expressive power of
such mechanisms, however, is much weaker than
that of a pluggable metamodel system because the
semantics of metamodel-specific extension mech-
anisms are irreversibly linked to the semantics of
their base metamodel, thus obstructing the intro-
duction of new modeling concepts that are incom-
patible with that base metamodel.
Limited Support for Transformations. Hard-
coding a metamodel inside the transformation tool
disables transformations between modeling lan-
guages. This makes it impossible, for instance, to
transform a series of BPEL processes into a UML
interaction diagram. Indeed, tools used for creat-
ing such models will lack the ability to commu-
nicate design decisions to each other, thus jeop-
ardizing the consistency of the application being
designed.
Limited Reusability. Although specialized tools
exist that are able to transform between multi-
ple modeling languages, the set of supported lan-
guages is typically predefined and therefore not
extensible. Also, the logic for executing such
transformations is often too much tailored to the
base application, hence obstructing the reuse of
transformation algorithms in other tools.
3 DESIGN GOALS
The main objective of our research project is to build a
metamodel-independent transformation tool that sup-
ports transformations between models designed in
different modeling languages. This gives rise to a
number of design goals:
Pluggable Metamodel System. Developers must
be able to define their own metamodels and feed
them to the transformation tool, as such increas-
ing the applicability of the latter. For example,
if our transformation tool is running on a UML
metamodel, it must be able to accept an ER meta-
model or an RDB metamodel and then allow mod-
ellers to design their applications using the UML,
ER and RDB modeling languages. Next to adding
ICSOFT 2007 - International Conference on Software and Data Technologies
316
Figure 1: Overview of the Pluto framework for metamodeling.
metamodels of existing modeling languages, de-
velopers must also be able to define and insert
custom metamodels of domain-specific modeling
languages or language extensions that they have
defined themselves.
Cross-model Transformations. Next to trans-
forming between models that share a common
metamodel, our tool must support transformations
between different modeling languages (Mens et
al., 2005). This requires our tool to be able to
work with multiple metamodels simultaneously.
When fed with the ER and the UML metamodel,
for instance, it must be possible to transform a
UML class diagram into an ER schema, and vice
versa.
Reusability. Metamodels have a wide-spread ap-
plicability beyond the domain of model transfor-
mations as they can be used, for instance, in model
verifiers or code generators. Therefore, the meta-
models on which our tool relies must be reusable
in these domains without modification: we must
avoid polluting metamodels with dependencies on
components that are specific to model transforma-
tion logic.
Obliviousness. In order to allow the transfor-
mation tool and the metamodels to evolve inde-
pendently, a certain amount of obliviousness is
needed in both directions. On one hand, meta-
models should be entirely independent of the
transformation tool (as noted in “reusability”); on
the other hand, the transformation tool should not
depend on the technical details of a single hard-
wired metamodel (as noted in “cross-model trans-
formations”). Thus, we need to define a common
contract on which the transformation tool relies
when a metamodel is fed to it.
Realization. Given these design goals, we have de-
veloped Pluto, a framework with reusable concepts
for metamodels and model transformations. Section
4 outlines this framework. Its two main functions,
metamodel realization and model transformation, are
discussed in Sections 5 and 6, respectively.
Traceability. The need for horizontal, cross-model
transformations in turn creates a need for cross-model
communication so as to guarantee the consistency of
the design. Therefore, transformations must be trace-
able, meaning that our tool must be able to link target
elements to the source element(s) that triggered the
creation of the former. This also means that changes
to a target model must be communicated back to the
source model from which that target model was cre-
ated.
4 THE PLUTO FRAMEWORK –
OVERVIEW
Pluto is a Java framework providing abstract mod-
eling constructs to be reused by concrete metamod-
els. It is therefore typically layered on top of concrete
metamodels as shown in Figure 1. The upper part de-
picts a set of Pluto constructs providing general func-
A FRAMEWORK FOR EXECUTING CROSS-MODEL TRANSFORMATIONS BASED ON PLUGGABLE
METAMODELS
317
tionality for metamodels. The lower part of Figure
1 shows how interfaces of the ER metamodel are de-
fined as extensions of Pluto interfaces. Concrete re-
alizations of these interfaces represent elements that
occur in ER models. Such concrete classes imple-
ment these ER-specific interfaces by inheriting gen-
eral functionality from abstract Pluto classes and by
filling in ER-specific behaviour where necessary.
It is important to note that Pluto is in itself not
a metamodel of metamodels and neither is it a con-
crete metamodel. Rather, Pluto should be seen as an
abstract metamodel from which concrete metamodels
inherit common functionality. Therefore, in the Meta
Object Facility layering structure (The Meta Object
Facility Core Specification 2.0, 2006), Pluto is situ-
ated at the meta-level (M2) rather than the meta-meta-
level (M3).
The remainder of this text focuses on two key func-
tions of Pluto.
Metamodeling. Section 5 focuses on the left part
of Figure 1 and shows how Pluto offers reusable
concepts for composition and dependency man-
agement. To illustrate the wide applicability of
this transformation framework, we use the Entity
Relationship (ER) metamodel and the Relational
Database (RDB) metamodel as examples instead
of the UML metamodel.
Transforming Models. Section 6 reviews the
right part of Figure 1 and shows how Pluto trans-
forms models between different modeling lan-
guages. As an example, we show how the ER
metamodel can be extended so as to transform
models from the ER modeling language to the
RDB language, and vice versa.
5 DESIGNING CONCRETE
METAMODELS AS PLUTO
EXTENSIONS
Pluto offers constructs for building consistent, hi-
erarchical composition structures (Section 5.1) and
provides a reusable dependency management system
(Section 5.2) that can be reused by developers of
concrete metamodels. Both constructs provide func-
tionality that is paramount for Pluto’s transformation
logic (Section 6).
5.1 Reusable Composition Concepts
The existence of nested whole-part relations typically
causes models to be arranged into hierarchies. The
ERModel
instance in Figure 1, for example, refers
to a number of
Relationship
instances, and each
Relationship
in turn contains a number of relation-
ship ends (represented by instances of
Role
). Simi-
lar composite structures occur frequently in the ma-
jority of available modeling languages. Without hav-
ing reusable constructions for managing model com-
position, however, implementors of metamodels have
to implement similar structures over and over again.
We avoid this repetitive and error-prone work by in-
tegrating reusable functionality for managing hierar-
chies at the level of Pluto. This is achieved by struc-
turing its top level classes according to the Com-
posite design pattern (Gamma et al., 1994). This
composite structure is shown in Figure 2, where in-
stances of
WholeModelElement
refer to instances of
PartModelElement
. The basic version of the Com-
posite pattern is further extended by the introduction
of three
subinterfaces
that differentiate between the
root node, the intermediate nodes, and the leaves of a
model tree:
RootComposedModelElement
is used for ele-
ments that are not contained in other elements,
such as the root node of a model. In the ER meta-
model (see Fig. 2), for instance, this interface is
extended by the
ERModel
interface because ER
models cannot be contained in other model ele-
ments.
BasicModelElement
is used to represent those
model elements that are contained in other model
elements without containing elements themselves.
They represent the leaves of a model tree. An ex-
ample of such a basic model element is the rela-
tionship end of an
Entity
, as represented by
Role
in Figure 2.
NonRootComposedModelElement
inherits its be-
haviour from both
WholeModelElement
and
PartModelElement
, meaning that it contains
model elements while being contained in another
model element. Concrete realizations of this inter-
face represent internal nodes. The
Relationship
interface, for instance, is an internal node because
it is contained in an
ERModel
(see Figure 2) while
containing a set of
Role
instances.
Evaluation. By augmenting the semantics of
model composition, we allow metamodel developers
to reuse Pluto’s consistency and validity checks, as
such decreasing the odds for introducing structural
integrity violations (e.g. circular dependencies or de-
tached model elements) during the construction of a
new metamodel.
ICSOFT 2007 - International Conference on Software and Data Technologies
318
Figure 2: Parent/child and dependee/dependant relations in Pluto.
5.2 Reusable Dependency Management
The
whole/part
relation of Section 5.1 is too gen-
eral to cover different kinds of dependencies between
model elements. Therefore, this section further de-
composes that relation into two specialized depen-
dency relations. First, the parent/child relation is
used to specify interdependencies. Second, the de-
pendee/dependant relation is used to specify unidirec-
tional dependencies between different kinds of model
elements.
The Parent/Child Relation. This is a hierarchical
one-to-many relation used for expressing interdepen-
dencies between different kinds of model elements.
The following properties characterize the parent/child
relation:
One-to-Many. A parent can have multiple chil-
dren, but a child only has one parent. For
example, the realization of the ER metamodel
specifies that a
Relationship
(parent) contains
multiple relationship ends (i.e. instances of
Role
), but a
Role
(child) can only belong to one
Relationship
.
Interdependence. The parent/child relation is
used to express the existence of bidirectional de-
pendencies between different kinds of model ele-
ments. This means that parents and their children
influence each other:
Children depend on their parent. Children can-
not survive the removal of their parent. In the
ER metamodel, for instance, this means that in-
stances of
Role
cannot survive the removal of
the
Relationship
to which they belong. This
is exactly what the ER metamodel must enforce
because a role does not make sense when it is
not participating in any relation.
Parent depends on children. In parent/child re-
lations, the parent also depends on its children.
A
Relationship
, for instance, is invalid with-
out instances of
Role
being attached to it; such
a configuration would specify the existence of a
relationship without participants and this is not
sensible.
Transitive. Given three model elements α, β, and
γ, such that α is a parent of β and β is a parent of
γ, then α is an indirect parent (or ancestor) of γ.
Symmetric. A model element α is the parent of
A FRAMEWORK FOR EXECUTING CROSS-MODEL TRANSFORMATIONS BASED ON PLUGGABLE
METAMODELS
319
β iff β is a child of α. Combined with transitivity,
we get that α is an ancestor of β iff β is a descen-
dant of α.
Non-reflexive and Acyclic. The data structure in-
duced by the parent/child relation is acyclic. No
model element can be its own parent and a child
cannot be the parent of one of its ancestors.
Tree structure. The non-reflexive, transitive clo-
sure of the parent/child relationship induces an
acyclic tree structure on a set of model elements.
The Dependee/Dependant Relation. This rela-
tion models a hierarchical many-to-many relation-
ship, meaning that a dependant relies on one or more
dependees, which in turn have zero or more depen-
dants. The properties of the dependee-dependant re-
lation are summarized below:
Many-to-Many. Other than parent/child interde-
pendencies, where a child only has one parent, a
dependant can have multiple dependees.
Unidirectional Dependency Relation. Unlike
the parent/child relation, where a parent depends
on its children, dependees are independent of their
dependants. In the ER metamodel of Figure 2, for
instance, an
Entity
is a dependee of its
Role
in-
stances (and not a parent) because the ER spec-
ification does not require an
Entity
to partici-
pate in a
Relationship
to be valid. The re-
verse, however, remains unchanged: the deletion
of an
Entity
is cascaded to its
Relationship
in-
stances in order to ensure model consistency.
Transitive. Similar to the parent/child relation,
dependee/dependant is a transitive relation. In
Figure 2, for instance,
ERModel
is a dependee of
Entity
, which is in turn a dependee of
Role
.
Therefore,
ERModel
is an indirect dependee of
Role
whereas
Role
is an indirect dependant of
ERModel
.
Non-reflexive, Symmetric, Acyclic. The de-
pendee/dependant relation has the same mathe-
matical properties as the parent/child relation. By
installing a many-to-many dependency relation,
however, the non-reflexive, transitive closure of
the dependee/dependant induces an acyclic lattice
structure on a set of related model elements, rather
than a tree.
Reusable Dependency Management. It is clear
that mathematical properties such as
symmetry
,
tran-
sitivity
and the abscence of
cyclic dependencies
re-
quire rigorous specifications for managing the depen-
dencies between different kinds of model elements in
trees and lattices. Without a reusable infrastructure
for dependency management, metamodel implemen-
tors would have to implement these relations over and
over again, thus increasing the possibility of introduc-
ing inconsistencies in the metamodel. By integrating
dependency management at the level of Pluto, how-
ever, concrete metamodels extending this framework
inherit (1) fine-grained consistency guarantees and (2)
algorithms that automatically manage dependencies
based on lifecycle changes of model elements, thus
easing the implementation of new metamodels.
6 MODEL TRANSFORMATIONS
Next to offering reusable constructs for building
metamodels, Pluto incorporates concepts for trans-
forming models defined as concrete instances of those
metamodels. These concepts are shown in the right
part of Figure 1. The basic idea of model transfor-
mations in Pluto is shown in Figure 3, which shows
how transformable behaviour is attached to model el-
ements using the Decorator pattern (Gamma et al.,
1994). These classes decorate model elements with
transformable behaviour by pointing to a strategy
containing an execution plan for creating a target el-
ement. Developers willing to transform some source
model to a UML class diagram, for instance, attach
UML-specific transformation strategies to that deco-
rator, whereas database modellers will select RDB- or
ER-specific strategies. This section first explores how
transformation strategies are added to metamodels via
decorators (Section 6.1) and then shows how these
transformation strategies interact with Pluto’s generic
transformation algorithm (Section 6.2).
6.1 Decorating Model Elements with
Transformation Strategies
The upper right part of Figure 1 shows the key in-
terfaces exported by Pluto that attach transformable
behaviour to model elements. There is a one-to-
one mapping between transformation-specific inter-
faces (e.g.
TransformableModelElement
) and ba-
sic interfaces for metamodels (e.g.
ModelElement
)
as shown in Figure 4. There is also a default imple-
mentation for each transformation-specific interface
to be reused by decorators of concrete metamodels.
This is also shown in Figure 4, where a concrete dec-
orator,
TransformableEntity
, inherits from a Pluto
class in order to decorate
Entity
. Such concrete
decorators must be created only once for each meta-
model element because they are fully agnostic about
technical transformation details. They only serve as
a “bridge” between model elements and their exe-
cution plan. These execution plans provide map-
pings between source elements and target elements,
ICSOFT 2007 - International Conference on Software and Data Technologies
320
Figure 3: Transformation Overview.
so they are encapsulated into transformation strate-
gies, shown as circles in Figure 4.
Transformation Strategies. The main responsi-
bility of a strategy is to encapsulate an execution
plan for the transformation of a source element into
the corresponding model construct of a target lan-
guage. Figure 4, for instance, shows two differ-
ent transformation strategies that can be attached to
a
TransformableEntity
decorator. Each strategy
contains a different execution plan because they both
transform instances of
Entity
to a different target
modeling language –UML and RDB, respectively.
Each strategy publishes an operation
transform()
, which is called by Pluto through
the decorator to which the strategy is attached. The
execution of such a transformation strategy only
has a local effect; it transforms a single model
element, independent of its surrounding elements.
Any dependencies with related model elements
are handled by the dependency relations that were
integrated in Pluto, as discussed in Section 5.2. Such
localized transformations make the implementation
of strategies straightforward, as such making them
eligible for code generation. Although not a target
of this research project, it should be manageable to
add an extra layer above Pluto that converts model
transformation languages into strategies that can be
executed by our transformation algorithm.
6.2 Pluto’s Generic Algorithm for
Transforming Model Elements
The previous Section explained how transformation
strategies are attached to decorators in order to make
model elements transformable. This Section shows
how Pluto’s generic algorithm interacts with these
strategies in order to transform model elements. The
basic philosophy of this algorithm is to exonerate the
developer from taking care of all the technical “mid-
dleware” concerns of model transformations. Such
tasks include determining an execution order, manag-
ing cross-model consistency, ensuring source model
validity, etc. Instead, developers only have to provide
strategies
containing localized execution plans, which
are called by Pluto whenever they are needed during
the execution of its transformation algorithm.
This general idea is applied in Figure 5, where
instances of
Entity
are transformed to instances of
Relation
. The vertical arrow indicates the execution
of the algorithm and the horizontal arrow shows the
transformation of the model element. The transforma-
tion algorithm is explained in three steps: (1) transfor-
mation preconditions, (2) transformation rules, and
(3) the transformation protocol.
Transformation Preconditions. For the transforma-
tion algorithm to run correctly, we need to make some
assumptions about the source model:
V1 The model is valid, meaning that every model
element obeys its invariants and that all de-
pendee/dependant relations and parent/child de-
pendencies are wired correctly.
V2 The model is immutable during the transforma-
tion. Changes made to the source model during
the execution of a transformation are not reflected
in the target model.
Transformation Rules. Given that our two validity
rules, V1 and V2, are satisfied, we can execute the
desired transformation. The generic transformation
algorithm of Pluto uses three rules to specify a trans-
formation order among a set of transformable model
elements:
T1 Model elements can never directly transform
other model elements; they can only transform
themselves. It is only possible to start the trans-
formation of another model element indirectly, as
will be explained below.
T2 Elements can only transform themselves after
their parent and dependees have been trans-
formed. Thus, an element may have to wait
for other elements before it can transform itself,
A FRAMEWORK FOR EXECUTING CROSS-MODEL TRANSFORMATIONS BASED ON PLUGGABLE
METAMODELS
321
Figure 4: Reusable Transformation Concepts.
Figure 5: Strategies interact with the Pluto transformation algorithm.
which is called transformation preemption, as
shown in Figure 5.
T3 After its transformation, a model element indi-
rectly triggers the transformation of its children
and dependants. This is called transformation
propagation (see Fig. 5).
Two-Phase Transformation Protocol. Given our
transformation rules, (T1T3), by which concrete
transformation strategies must abide, every model el-
ement can decide whether or not to transform it-
self based on local information, i.e. by determining
whether its dependees and parent have been trans-
formed (T2). Therefore, the transformation of a
model element can be decomposed into two different
transformation steps:
CT Conditional Transformation Request. These
requests are sent by external model elements
to the model element that must be transformed.
These requests are termed conditional because it
is not guaranteed that the transformation will be
executed directly. Indeed, the request may be pre-
empted so as to conform to rule T2. Also, a CT
request will propagate new CT requests to all the
dependants and children of the model element af-
ter it has transformed itself (as required by T3).
The implementation of the CT operation is inde-
pendent of concrete transformations, so we have
encapsulated this logic in the Pluto framework.
AT Actual Transformation. Unlike the CT phase,
this second operation does not check preemption
constraints and it does not propagate calls to chil-
dren or dependants. Instead, it activates the ex-
ecution plan of the strategy that was attached to
the transformable model element, causing the tar-
get model to be manipulated. Therefore, this op-
eration is private to the model element and it is
called by CT when all preconditions have been
satisfied, i.e. when the parent and the dependees
of this model element have been transformed such
that preemption is no longer required. This is the
only phase that is specific to a model transfor-
mation, so these actual transformations must be
provided by the developers by means of a con-
crete transformation strategy object, as explained
in Section 6.1. The other steps of the algo-
ICSOFT 2007 - International Conference on Software and Data Technologies
322
rithm are transformation-independent, so devel-
opers can reuse them in concrete transformations
without further configuration.
6.3 Illustration
Given a set of preconditions, a set of transformation
rules, and the dichotomy between conditional and ac-
tual transformations, we now explain the generic ex-
ecution strategy of our transformation algorithm by a
simple example. Assume a conditional transforma-
tion request, CT, arrives at
ModelElement
in Figure
6 and assume that the model is
valid
according to
the transformation preconditions V1–V2. This Sec-
tion describes the steps taken by the transformation
algorithm of Pluto in order to create a target model
for
ModelElement
and its related elements. As noted
above, this target model can be written in any other
modeling language, depending on the contents of the
concrete transformation strategy instances that were
provided by the implementor of the transformation.
This illustration is therefore independent of the cho-
sen target language.
[Phases 1–6] Preemption of ModelElement. Pluto
first checks whether
ModelElement
has any parent
or dependees that have not executed their transfor-
mation, as required by T2. After discovering that
Parent
ME
is not transformed, the transformation of
ModelElement
is preempted and a conditional trans-
formation request CT is forwarded to
Parent
ME
.
Pluto repeats the CT procedure for that parent and
finds that
Parent
ME
can transform immediately with-
out being preempted (according to rule T2). Thus, the
strategy attached to that parent is executed and a target
element is created. Next, according to T3, the condi-
tional transformation request must be propagated to
all children, causing the call to reach
ModelElement
.
Due to the existence of a dependee that still needs to
be transformed, however,
ModelElement
is again pre-
empted and a CT request is sent to
Dependee
ME
. The
latter executes its transformation AT and propagates a
CT request to its children.
[Phase 7] Transformation of ModelElement.
Downward propagation of the CT request from
Dependee
ME
eventually reaches
ModelElement
, one
of the dependants of
Dependee
ME
, so Pluto checks
whether
ModelElement
can transform itself. All pre-
conditions have been satisfied, since both its par-
ent and its dependee have successfully transformed,
so
ModelElement
can execute its AT transforma-
tion according to T2. To do so, Pluto delegates to
the strategy that was attached to the decorator of
ModelElement
. This strategy now manipulates the
target model, possibly making use of the elements that
were already created by its parent and dependee.
[Phases 8–9] Propagation from ModelElement.
After the execution of
ModelElement
has completed,
Pluto propagates a CT request to all the children and
dependants, causing the transformation algorithm to
visit
Dependant
ME
and
Child
ME
. These elements
can transform themselves without being preempted.
Due to space limitations, we cannot give a more real-
istic example of this transformation algorithm. There-
fore, we refer to our technical report (Labey et al.,
2007) for more information about the technical details
of this algorithm in the context of multiple dependees
or transitive dependencies between model elements.
7 RELATED WORK
In (Sunye et al., 2002) and (Varro and Pataricza,
2003), the applicability of Action Semantics (AS)
(OMG, 2002) to model transformations is studied.
The authors conclude that AS can be used for trans-
forming between UML models, thus allowing for iter-
ative refinement of UML designs. Another advantage
of using AS is that design patterns can be encoded
as a sequence of transformation steps, thus allowing
to refactor designs. One shortcoming is that cross-
model transformations are not supported because AS
is irreversibly linked to the Unified Modeling Lan-
guage.
YATL (Patrascoiu, 2004) is a language for defin-
ing model transformations. It combines declarative
concepts for querying the source model with impera-
tive constructs for executing the transformation itself.
By relying on the Meta Object Facility (The Meta
Object Facility Core Specification 2.0, 2006), YATL
provides support for pluggable metamodels, but the
transformation tool does not offer reusable concepts
for defining those metamodels. Furthermore, it is not
clear how the transformation language can be applied
to concrete instances of such newly introduced meta-
models.
MTRANS (Peltier et al., 2001) is a model trans-
formation framework that provides both a develop-
ment environment and a language to define model
transformations. This language is defined as an ab-
straction above XSLT and, therefore, the transforma-
tion architecture of MTRANS is strongly influenced
by the XSLT specification. One major drawback of
this dependency is that many-to-one transformations
are not supported because XSLT inherently relies on
one-to-one mappings between source and target ele-
ments. Pluto, on the other hand, is independent of
A FRAMEWORK FOR EXECUTING CROSS-MODEL TRANSFORMATIONS BASED ON PLUGGABLE
METAMODELS
323
Figure 6: Illustration of Pluto’s transformation algorithm.
any transformation language and transparently man-
ages one-to-many and many-to-one dependencies for
model transformations.
UMLX (Willink, 2003) and VMT (Sendall et
al., 2003) are graphical transformation languages for
MDA, primarily developed in an attempt to increase
user-friendliness of model transformation languages.
The major advantage of UMLX and VMT is their
expressiveness, given their limited amount of graph-
ical modeling constructs. One problem, however,
is that these transformation languages are limited to
transforming UML models. As the UMLX compiler
is able to compile transformations into Java code,
however, it should be possible to attach this gener-
ated code to our transformation strategies. Indeed,
our model transformation framework fits into a larger
framework, Chameleon, (van Dooren, 2007), which
can be used to transform between programming lan-
guages. Concrete examples of such transformations
can be found in the work of (van Dooren and Steeg-
mans, 2005; Delanote and Steegmans, 2006; Labey
et al., 2007). By integrating Pluto’s support for lan-
guage transformations with the VMT compiler, we in-
tegrate a visual transformation language with cross-
model transformability, thus solving the problems of
the original VMT proposal, which relies on a hard-
wired metamodel.
Finally, a large number of transformation lan-
guages have been proposed, for example, Converge
(Tratt and Clark, 2003) and the work of Kuznetsov
(Kuznetsov, 2005). These languages are typically
compiled and executed on a transformation tool that
relies on a hardwired metamodel, thus disallowing
pluggable metamodels. We are investigating how
these transformation languages can be compiled to
our transformation strategy objects, which is benefi-
cial for both paradigms: (1) the transformation lan-
guage can be used for cross-model transformations
and (2) the developer is freed from having to program
strategies.
8 CONCLUSION
Modeling tools often rely on hardwired, proprietary
metamodels, as such obstructing
cross-model trans-
formations
and metamodel reuse. This leads to in-
consistent designs scattered over a variety of model-
ing tools. We have implemented Pluto, a framework
providing reusable concepts for metamodeling and
for model transformations. Pluto eases the definition
of new metamodels by providing reusable concepts
for dependency management and model composition.
Furthermore, Pluto enables cross-model transforma-
tions by deferring model-specific transformation logic
to strategies containing localized execution plans.
The decoupling between metamodel-independent
constructs offered by Pluto and model-specific con-
cepts provided by developers decreases the develop-
ment time of new metamodels and increases their con-
sistency because modellers can focus on metamodel-
specific concepts while inheriting common modeling
functionality from Pluto.
ICSOFT 2007 - International Conference on Software and Data Technologies
324
REFERENCES
BPEL4WS Language Specification:
http://www.ibm.com/developerworks. (2003)
Frankel, D.: Model Driven Architecture: Applying MDA
to Enterprise Computing. (2003)
Rensink, A.: Subjects, Models, Languages, Transforma-
tions. In: Dagstuhl Seminar. (2005)
OMG UML Specification 1.5
http://www.omg.org/technology/documents/. (2003)
Mens, T., Czarnecki, K., Van Gorp, P.: A Taxonomy of
Model Transformations. In: Dagstuhl Seminar. (2005)
The Meta Object Facility Core Specification 2.0:
http://www.omg.org/technology/. (2006)
Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design
Patterns: Elements of Reusable Object-Oriented Soft-
ware, Reading, Massachusetts (1994)
Sven De Labey and Geert Delanote and Koen Vanderkim-
pen and Eric Steegmans: A Framework for Executing
Cross-Model Transformations based on Pluggable
Metamodels. In: Report CW489 K.U.Leuven
http://www.cs.kuleuven.be/publicaties/rapporten/.
(2007)
Sunye, G., Le Guennec, A., et al.: Using UML Action
Semantics for Model Execution and Transformation.
In: The 13th IC on Advanced Information Systems
Engineering. (2002)
Varro, D. and Pataricza, A.: UML Action Semantics for
Model Transformation Systems. In: Periodica Po-
litechnica. (2003)
Object Management Group: ptc/02-09-02: UML 1.5 – Ac-
tion Semantics. (2002)
Patrascoiu, O.: YATL:Yet Another Transformation Lan-
guage. In: Proceedings of the 1st European MDA
Workshop, MDA-IA, University of Twente, the Ned-
erlands (2004)
Peltier, M., Bezivin, J., Guillaume, G.: MTRANS: A Gen-
eral framework based on XSLT for model transfor-
mations. In: WTUMLO1. Proceedings of the First
Workshop on Transformations in the Unified Model-
ing Language. (2001)
Willink, E. D.: UMLX : A graphical transformation lan-
guage for MDA. In: 2nd OOPSLA Workshop on Gen-
erative Techniques in the context of Model Driven Ar-
chitecture. (2003)
Sendall, S., Perrouin, G., Guelfi, N., Biberstein, O.: Sup-
porting Model-To-Model Transformations: the VMT
Approach. In: Technical Report TR-CTIT-03-27,
Twente. (2003)
van Dooren, M.: Abstractions for Improving, Creating, and
Reusing Object-Oriented Programming Languages
PhD Thesis. K.U.Leuven. (2007)
van Dooren, M., Steegmans, E.: Combining the Ro-
bustness of Checked Exceptions with the Flexibility
of Unchecked Exceptions using Anchored Exception
Declarations. In: International Conference on Object-
oriented Programming, Systems, Languages, and Ap-
plications. (2005)
Delanote, G., Steegmans, E.: Concepts for abstracting away
object reification at the level of platform independent
models (PIMs). In: Proceedings of The Third Interna-
tional Workshop on Model-Based Methodologies for
Pervasive and Embedded Software. (2006)
De Labey, S., van Dooren, M., Steegmans, E.: ServiceJ. A
Java Extension for Web Service Interactions. In: Pro-
ceedings of the Fifth IEEE International Conference
on Web Services (ICWS’07), Salt Lake City, Utah
(2007)
Tratt, L., Clark, T.: Model transformations in Converge. In:
Workshop in Software Model Engineering (WiSME).
(2003)
Kuznetsov, M.: Automated Model Transformation in MDA.
In: Colloquium on Database and Information Sys-
tems. (2005)
A FRAMEWORK FOR EXECUTING CROSS-MODEL TRANSFORMATIONS BASED ON PLUGGABLE
METAMODELS
325