will investigate how model-driven engineering techniques
can reconcile performance optimization with portability,
separation of concerns and tool support for domain evo-
lution. This paper should provide enough detail to adapt
existing MDA tools for achieving these goals.
3 Transformation Language
In this section, we start from a concise taxonomy of
model transformation to subsequently derive domain spe-
cific language constraints for the different kinds of transfor-
mations.
3.1 Model Transformation Taxonomy
Model transformation can be roughly divided into two
subdomains: rephrasing and translation [27].
Rephrasing is transforming a program into a different
program in the same language. The source and target meta-
model of the transformations are the same. Refactorings
(i.e. restructurings for object-oriented software) are prob-
ably the most widely known examples of rephrasings [10].
A restructuring is the transformation from one representa-
tion to another at the same relative abstraction level, while
preserving the subject system’s external behavior (function-
ality and semantics) [7]. Note that with a narrow definition
of functionality, program optimizations are restructurings
as well. Moreover, the aspect of behavior preservation is
not a transformation language property, but a transforma-
tion specification property.
Based on the above definitions, we can define a trans-
lation as the transformation of a program across different
metamodels. In program refinement (and its inverse anal-
ysis) a chain of translations is applied with metamodels at
different abstraction levels. Translations are also applied
to maintain consistency between specifications in differ-
ent languages, yet at the same level of abstraction. In this
context, Sch
¨
urr [23] has demonstrated how correspondence
rules between the graph grammars of two such languages
can be used for bidirectional consistency maintenance.
3.2 Language Requirements for Solving WODN
Languages for rephrasing need to support model trans-
formations within the same metamodel, whereas languages
for translation need to support mappings between abstract
and concrete metamodels. Graph rewriting [22] is an in-
teresting formalism for specifying restructurings as its for-
mal theory is a promising basis for correctness proofs [18]
and existing tools can be used to execute the constraint and
transformation specifications [26]. In Figure 1, the transfor-
mation of the Pull Up Method refactoring is specified in the
Figure 1. An executable refactoring specifica-
tion in the Story Driven Modeling language.
The execute method of the “The Pull Up
Method” class has one parameter, “target”,
representing the model element to which the
transformation applies. The node “method”
contains this parameter after casting it to
UMLMethod. The edges “methods”, “sub-
class” and “superclass” specify a pattern that
checks if the containing class has a super-
class. If so, the link to this class is destroyed
and a link to the superclass is created.
UML / graph rewriting language called Story Driven Mod-
eling [11].
As illustrated by our case study, languages for refine-
ment play a more crucial role in the generative MDA pro-
cess: how can we specify an automated transformation from
a platform independent business model to a detailed compo-
nent specification that is optimized for heavy server load?
1. It is desirable that different aspects of the refinement
process can be specified independently. This decom-
position of transformations enhances their understand-
ability and reusability. Moreover, our case study re-
quires a domain metamodel that has no notion of the
performance pattern, neither from other aspects such
as object to relational mapping. We need a language
to build automated translations between all models de-
scribing the system from different viewpoints and lev-
els of abstraction.
Therefore, we would expect the transformation lan-
guage to support mappings across different metamod-
els. Note that one could technically combine all these
domain specific metamodels into one large auxiliary
metamodel. In this case, metamodel packages would
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE