% $Id: related.tex 14757 2008-10-10 15:02:59Z amoghk $
\sqzsmall
\sqzsmall
%\sqzsmall
\section{Related Work}
\label{sec:rel}
\sqzsmall
Existing model transformation tools~\cite{Schurr:99,VIATRA:02,ATL:03}
support some form of higher order transformations. PROGRES and ATL allow
specification of type parameters while VIATRA allows development of
meta-transformations, \emph{i.e.}, higher order transformations 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.

%The model driven architecture (MDA)~\cite{MDA:01,MDABook:03} development 

% Amogh, something needs to be told about QVT here.
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}. 

Reflective model driven engineering (MDE) approach~\cite{Bezivin:03}
proposes a two dimensional MDA process by expressing model
transformations in a tool- or platform-indepe\-ndent way and
transforming this expression into actual tool- or platform-specific
model transformation expressions.  
% Amogh, I think the following can be safely commented out
%
% OK.
\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 change in platform-specific
technologies.   MTS, however, is concerned with managing and 
evolving model transformation variability in systems developed using an
MDA process. %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. 

% Amogh, do we need this. Does not seem to tried to transformations
%
% Actually it is quite similar. I had read the paper and the idea is
% different but similar in the final goal.
% Amogh, ok I included this.
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.
% MTS generates VMM from variability
% specification in the templatized transformation to automate the entire
% process. The population of VMM models itself, as shown in
% Section~\ref{sec:soln}, does not involve learning an entirely new
% language since all its modeling objects are part of a source (or target)
% modeling language of the transformation. 

% Previous version
%
%
%MDA~\cite{MDA:01,MDABook:03} development process centers 
%around defining application PIMs and applying (typed, 
%and attribute augmented) transformations to PIMs
%to obtain application PSMs. In the context of MDA, 
%requirements and challenges in generating specialized
%transformations from generic transformations are discussed
%in~\cite{Kovse:02}.
%
%% Amogh, please mention QVT if it is applicable. Also please refrain from using
%% non conventional short forms like PIT, PST, PLA etc and use their full forms.
%% 
%Reflective MDE approach~\cite{Bezivin:03} proposes a two dimensional
%MDA process by expressing model
%transformations in a tool- or platform-independent way and mapping
%(\emph{i.e.}, transforming)
%this expression into actual tool- or platform-specific
%model transformation expressions. There is return of investment 
%(ROI) associated with developing and maintaining mappings from 
%platform-independent transformations (PIT) to platform-specific 
%transformations (PST) in terms of reuse, composition, 
%customization, maintenance etc. and the authors argue that 
%ROI in two dimensional MDA process is greater than 
%conventional one dimensional MDA. 
%
%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
%(\emph{i.e.}, modified) with change in PST or technologies.  Transformation
%parameterization on the other hand, is concerned with managing and evolving
%configuration variability in systems developed using MDA process within single
%dimension.  Parameterization techniques supported by MTS can be highly effective
%in managing variability of mappings from PIT to PSTs in the context of above
%work.
%
%Asset variation points discussed in~\cite{Salicki:01} uses the 
%hotspot notation~\cite{Pree:94} for expressing variability in models of 
%Product Line Architectures (PLAs)~\cite{Clements:02,Parnas:76}.
%A variation point is identified by several 
%characteristics (\emph{e.g.} point reference, context and use 
%of variation point, 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.  Our notion
%of variability points on the other hand, is more specific to 
%%Amogh, say it more generically i.e., not just middleware platforms
%addressing variability concerns in highly configurable middleware platforms.
%
%% Amogh, as suggested make sure we cover some prog committee members.
%% For example, we can cite something we saw the other day from Tom Mens,
%% Laurence Tratt, Jon Whittle, Gregor Engels, et al.
