% $Id: introduction.tex 14748 2008-10-09 19:55:53Z amoghk $
\section{Introduction}
\label{sec:intro}
\sqzsmall
%
\iffalse
% The industrial software development landscape has gradually transitioned
% from a strictly low-level, programmatic approach employing
% third-generation languages for various software development processes to
% a model-driven approach that relies heavily on the use of distinct
% application view models to better manage the system complexity.  One of
% the primary requirements in model-driven software development is the
% support for (1) evolution of models along various application views,
% each corresponding to a different level of granularity,  and (2)
% representation and translation of application into different models of
% computation (\emph{e.g.}, finite state automaton, discrete event systems).
\fi

Model transformations are key to the success of model-based software
development.  They are used to define progressive refinements of
application models from abstract, high-level views into low-level, 
detailed views that are used by the execution platform for different
purposes, such as application configuration, deployment, and code
synthesis.  They are also used in transforming models to representations
suitable for analysis tools that check various properties, such as
correctness or deadlock free behavior.
% Additionally, they are also used in the
% transformation of application models to different models of computation
% used by analysis frameworks to facilitate examination of the
% application's functional and non-functional properties, such as ensuring
% property correctness using a model checking framework.

Model transformations have been applied in significantly diverse use
cases as in (a) transforming XML documents from XSLT representation into 
XQuery representation~\cite{ATL:03}, (b) middleware quality of service (QoS)
configuration~\cite{Gokhale_GTQMAP_RTAS:08}, which involves
automatically mapping application-specific QoS requirements onto
the correct QoS configuration options for the middleware platform, 
(c) transforming Simulink/Stateflow models into their hybrid 
automata representation for formal verification~\cite{Karsai:04}, and
(d) synthesizing  dialogs for communication endpoints (\emph{i.e.},
hardware devices/software applications for communications, such as
cellphone, instant messenger (IM), pager) in enterprise workflows for
rapid decision making~\cite{Gokhale_Dialog_EDOC:08}.  

Despite the diversity in the use cases, a noticeable trait in the model
transformations for variants of individual use cases illustrates a
significant commonality in the transformations.  For example, in
the QoS configuration use case, many generated middleware configurations
are same across a class of applications that are related to each other
due to similarities in their QoS requirements and the implementation
platform.  Similarly, in the dialog use case, despite differences in the
communication endpoints, a number of dialog properties remain common.

\iffalse
% Commenting this out
The existence of multiple variants within each use case illustrates a
trait similar to product-line architectures
(PLAs)~\cite{Clements:02}. PLAs are identified by the scope,
commonality and variability (SCV)~\cite{Weiss:98} engineering 
process, and rely on reusing services and artifacts for building systems
rather than building them from scratch. 
\fi

Our study of the advances in model transformations
illustrates that despite the strong evidence of recurring patterns in
the transformations,  model transformation tools and
techniques~\cite{polack:08,VIATRA:02,Taentzer:04,GReAT:03} lack support
for reusability, modularization and extensibility of the model
transformation rules and algorithms.  These shortcomings force the
transformation developers to reinvent the transformation steps and the
translation logic leading to significant code duplication in the
transformations, and increased efforts in code maintenance and evolution
activities.  
% These observations lead us to seek solutions for reuse in
% model transformations. 

Recent research efforts~\cite{Voelter:07,gerard:08} have
demonstrated the use of model transformations to families of
applications or product lines~\cite{Clements:02}.   Yet,
the following research questions remain unresolved:   
(a) How can the commonalities in the transformation process be factored
    out such that they can be reused by the entire application family?  
(b) How can the variabilities be decoupled from the model transformation
    rules while maximizing the flexibility of the transformation process? 
(c) How can the model transformation process for an application family
    be extended with new variants, however, with minimally invasive
    changes to the transformation rules?
(d) How can all these capabilities be achieved with minimal to no
    changes in existing model transformation tools?

In this paper we present \emph{MTS (Model-transformation Templatization
  and Specialization)} to address these questions in the context of
visual model transformation tools.  MTS provides transformation
developers with a simple specification language to define variabilities
in their application family such that the variabilities are factored out
% Amogh, cite a paper for higher order transformations
%
% Andy, done. I have also added a clarification footnote since one of the
% reviewer had problem with the usage of this terminology - the citation and
% the accompanying explanation ought to be sufficient in explaining the choice
% of the verbage.
and are decoupled from the transformation rules.  MTS provides a higher
order transformation~\footnote{Since the transformation(s) themselves
  become the input and(or) output, we refer to the transformation
  process in MTS as higher order transformations.}~\cite{Bezivin:03a}
algorithm that automates the synthesis of a 
family-specific \emph{variability metamodel}, which is used by
transformation developers to capture the variability across the variants
of an application family.  Another higher order transformation algorithm
defined in MTS generates the specialized instances of the application
family variants.  MTS requires minimal to no changes to the underlying
model transformation engine.    

The rest of the paper is organized as follows:
Section~\ref{sec:scenario} discusses two representative case studies;
Section~\ref{sec:soln} describes the overall solution approach and 
demonstrates how it can be applied in practice;
Section~\ref{sec:eval} evaluates our approach;  Section~\ref{sec:rel}
compares our work with the existing literature;  and
Section~\ref{sec:conclusion} provides concluding  remarks.

