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 speciﬁc aspect of the enterprise applica-

tion. Aligning software with business requirements,

for instance, is typically done using workﬂow model-

ing languages such as the Business Process Execution

Language (BPEL) (BPEL4WS, 2003). The technical

realization of each identiﬁed 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-speciﬁc 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

 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 identiﬁed 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 speciﬁc 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 deﬁned.

• Limited Extensibility. Modeling tools often pro-

vide a mechanism to deﬁne extensions for mod-

eling languages. The Uniﬁed Modeling Lan-

guage, for instance, introduces UML proﬁles and

stereotypes to allow developers to extend UML

with domain-speciﬁc modeling concepts (OMG

UML Speciﬁcation 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-speciﬁc 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 predeﬁned 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 deﬁne 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 deﬁne and insert

custom metamodels of domain-speciﬁc modeling

languages or language extensions that they have

deﬁned 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

veriﬁers or code generators. Therefore, the meta-

models on which our tool relies must be reusable

in these domains without modiﬁcation: we must

avoid polluting metamodels with dependencies on

components that are speciﬁc 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 deﬁne 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-

ﬁned 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-speciﬁc interfaces by inheriting gen-

eral functionality from abstract Pluto classes and by

ﬁlling in ER-speciﬁc 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 Speciﬁcation 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

speciﬁes 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

inﬂuence 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.

Relationship

, for instance, is invalid with-

out instances of

Role

being attached to it; such

a conﬁguration 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-reﬂexive 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-reﬂexive, 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-

iﬁcation 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-reﬂexive, 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-reﬂexive, 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 speciﬁcations 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) ﬁne-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 deﬁned 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-speciﬁc transformation strategies to that deco-

rator, whereas database modellers will select RDB- or

ER-speciﬁc strategies. This section ﬁrst 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-speciﬁc 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-speciﬁc 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

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 reﬂected

in the target model.

Transformation Rules. Given that our two validity

rules, V1 and V2, are satisﬁed, 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, (T1–T3), 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

satisﬁed, 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 speciﬁc 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 conﬁguration.

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

ﬁrst checks whether

ModelElement

has any parent

or dependees that have not executed their transfor-

mation, as required by T2. After discovering that

Parent

is not transformed, the transformation of

ModelElement

is preempted and a conditional trans-

formation request CT is forwarded to

Parent

Pluto repeats the CT procedure for that parent and

ﬁnds that

Parent

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

. 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

eventually reaches

ModelElement

, one

of the dependants of

Dependee

, so Pluto checks

whether

ModelElement

can transform itself. All pre-

conditions have been satisﬁed, since both its par-

ent and its dependee have successfully transformed,

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

and

Child

. 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 reﬁnement 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 Uniﬁed Modeling Lan-

guage.

YATL (Patrascoiu, 2004) is a language for deﬁn-

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 Speciﬁcation 2.0, 2006), YATL

provides support for pluggable metamodels, but the

transformation tool does not offer reusable concepts

for deﬁning 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 deﬁne model

transformations. This language is deﬁned as an ab-

straction above XSLT and, therefore, the transforma-

tion architecture of MTRANS is strongly inﬂuenced

by the XSLT speciﬁcation. 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 ﬁts 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 beneﬁ-

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 deﬁnition

of new metamodels by providing reusable concepts

for dependency management and model composition.

Furthermore, Pluto enables cross-model transforma-

tions by deferring model-speciﬁc transformation logic

to strategies containing localized execution plans.

The decoupling between metamodel-independent

constructs offered by Pluto and model-speciﬁc con-

cepts provided by developers decreases the develop-

ment time of new metamodels and increases their con-

sistency because modellers can focus on metamodel-

speciﬁc concepts while inheriting common modeling

functionality from Pluto.

ICSOFT 2007 - International Conference on Software and Data Technologies

324

REFERENCES

BPEL4WS Language Speciﬁcation:

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 Speciﬁcation 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 Speciﬁcation 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 Uniﬁed 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., Guelﬁ, 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 reiﬁcation 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