% $Id: related.tex 16757 2009-02-09 05:03:03Z gokhale $
\sqzsmall
\sqzsmall
%\sqzsmall
\section{Related Work}
\label{sec:rel}
\sqzsmall
Existing model transformation
tools~\cite{VIATRA:02,Jouault_ATL:08,Schurr:99} support some form of
HOTs. PROGRES and ATL allow specification of
type parameters while VIATRA allows development of meta transformations,
\emph{i.e.}, HOTs that can manipulate
transformation rules and hence model transformations.  Unlike MTS,
however, these tools do not provide mechanisms for separation of
variabilities from model transformations to facilitate automated
development of application families. 

A recent work synergistic to MTS appears in~\cite{Cuadrado_ICMT:08}. In
this work the authors propose (1) transformation factorization to
extract common parts of two or more transformation definitions into a
reusable, base transformation, and (2) composing transformation
definitions mapping from a single source metamodel to multiple target
metamodels, each representing a specific concern in the system being
transformed.  MTS differs from ~\cite{Cuadrado_ICMT:08} in that we focus
on composing the common (base) transformation by using the constraint
notation (as opposed to factoring out commonalities from existing
transformations), and automating the entire process of transformation
specialization (\emph{i.e.}, creating instances of transformations). 

\iffalse
% Amogh, I am commenting this out but it would be nice if we can add a
% line about QVT and where MTS could fit
The model driven architecture (MDA) development process is
centered around defining application platform-independent models and
applying (typed, and attribute augmented) transformations to these
models to obtain application platform-specific models.  In the context
of MDA, requirements and challenges in generating specialized
transformations from generic transformations are discussed
in~\cite{Kovse:02}. 
\fi

% JGG: The following could be rewritten better.

Reflective model-driven engineering (MDE)~\cite{Jouault_ATL:08}
proposes a two-dimensional MDE process by expressing model
transformations in a tool- or platform-indepe\-ndent way and
transforming expressions into actual tool- or platform-specific
model transformation expressions.  
\iffalse
There is return on investment (ROI)
associated with developing and maintaining mappings from
platform-indep\-endent transformations to platform-specific
transformations in terms of reuse, composition, customization,
maintenance etc.  The authors argue that the ROI for a two-dimensional
MDA process is greater than conventional one dimensional MDA.  
\fi
Although reflective MDE focuses on having durable transformation
expressions that naturally facilitate technological evolution and
development of tool-agnostic transformation projects, mappings still
have to be evolved with a change in platform-specific
technologies.   MTS, however, is concerned with managing and 
evolving model transformation variability in systems developed using MDE.
%Parameterization techniques supported by 
%MTS can be highly effective in managing variability of mappings from
%platform-independent to specific forms in the context of the above body
%of work. 

Asset variation points discussed in 
~\cite{Salicki:01} deal with expressing variability in models of 
product lines~\cite{Clements:02}. %,Parnas:76}.
 A variation point is identified by several 
characteristics (\emph{e.g.}, point reference, and context, use and
rationale of the variation point) that uniquely identify that point in
the product lines.  These asset variation points capture variation rules
of implementation components of a product line member. 

An aspect-oriented approach to managing transformation variability is
discussed in~\cite{Voelter:07} that relies on capturing
variability in terms of models and code generators. 
Another approach is model weaving~\cite{Gray:01}, which is used
in the composition of separate models that together define the system as
a whole.  
%Aspect models allow specifying variability that is weaved
%into a base model to form an instance of a product-line. 
Using the aspect-oriented approach requires developers to
learn a new modeling language for creating aspect models for their
product line.  In contrast, the VMM models generated by MTS use modeling
objects that are part of the source (or target) modeling languages
requiring no additional learning curve.

