%$Id: stepI.tex 16757 2009-02-09 05:03:03Z gokhale $

\sqzlarge
\subsection{Step I: Defining the Templatized Transformation Rules}
\label{sec:variab}
\sqztiny

\iffalse
Application families are defined by their commonalities, which
constitute the \emph{invariant} characteristics of the family.
They also are defined by their variabilities, which constitute family 
member idiosynchrasies or dissimilarities among the members.  The example of
Section~\ref{sec:scenario} can be considered an application
family that requires transformations for multiple variants of the family.
However, as noted in Section~\ref{sec:impediments}, due to shortcomings
in contemporary model transformation processes, developers must reinvent
many of the transformation rules for each variant of the family.
\fi
Section~\ref{sec:impediments} elicits the need for reusable model
transformation tools to handle variability in model transformations for
application families.  In programming languages like C++, mechanisms
like parametric polymorphism in the form of templates are provided to
handle variability.  A parametrized class and/or function is then
specialized for a concrete type (\emph{i.e.}, a variant).  Our solution
in MTS is influenced by C++ templates; specifically, we seek a solution
to support templatized transformations and their  specialization.  The
basic idea is that all the commonalities, which constitute the
invariants of an application family, are transformed directly from the
input models as family \emph{instance-independent} transformation rules
using the existing approach of defining the transformation rules.  The
variabilities are dissociated from the transformation rules to allow
independent evolution of the transformation and its variabilities.  

A noticeable trait in the transformations for the QoS configuration
example illustrates that variability is incurred in either the type and
number of structural elements that appear in the target model, and/or
the values that are assigned to the attributes of these structural
elements.   We leverage this observation and define two types of
variabilities for our templatized transformation
approach:\footnote{This observation was true for other use cases we
  studied.  Other forms of variability, such as those based on
  behavior, are also possible but are not addressed in this paper. They
  are part of our future investigations.} 

\noindent\textbf{(a) Structural variabilities}, where the basic building
blocks, \emph{i.e.}, model elements, or their cardinalities in every
family  member model are different.  Thus, the variation in family
member models emanates from dissimilarities in their structural
composition. 

\noindent\textbf{(b) Quantitative variabilities}, where the family member
models may share model elements but the data values of their attributes
are different.  

Both of these variabilities can be denoted as simple implication relations
that can be characterized by one of the following types of associations
between source ($s \in S$)  and target ($t \in T$) objects where, $P1$
and $P2$ denote patterns of source and target objects:

\begin{center}
%\vspace{-.1in}
{\scriptsize
\begin{tabulary}{\columnwidth}{||L|L||} \hline
\multicolumn{1}{||c|}{\textbf{Association}} & 
\multicolumn{1}{c||}{\textbf{Definition}} \\ \hline

one-to-one & 
injective function:
      $s \in S, t \in T \; \exists \;            
      f(s)\stackrel{\alpha}{\longmapsto}f(t)\;:if\; f(s) = f(t)\; then\;
      s = t. $ \\ \hline 

one-to-many &
      $s \stackrel{\phi}{\longmapsto} t,$ 
      where
      $s \in S$, and 
      $t = \{P2(t_1, t_2, ..., t_n) \mid t_{i = 1..n} \in T\}$.  \\ \hline
      
many-to-one &    
      $s \stackrel{\varphi}{\longmapsto} t,$ 
      where
      $t \in T$, and 
      $s = \{P1(s_1, s_2, ..,  s_m) \mid s_{j = 1..m} \in S\}$. \\ \hline

many-to-many &   
      $s \stackrel{\varphi}{\longmapsto} t,$ 
      where
      $s = \{P1(s_1, s_2, ..,  s_m) \mid s_{j = 1..m} \in S\}$, and 
      $t = \{P2(t_1, t_2, ..., t_n) \mid t_{i = 1..n} \in T\}$. \\ \hline


\end{tabulary}
}
\end{center}

How are these implication relations to be used by the developers in the
transformation rules, and how are the rules to be supported in a
minimally intrusive manner by the underlying transformation framework?
We address this question by exploiting the C++ code embedding feature
provided by GReAT (see CodePoint in Figure~\ref{fig:GReAT_sample}).  In
particular, we use C++ comments as a means to capture variabilty.
Because these are comments, it has no impact on the execution of the
GR-engine.   
\iffalse
Such techniques have been used to great advantage by document
generators, such as Javadoc.\footnote{To use Javadoc, documentation is
  inserted as comments in source code using a special annotations. See
  http://java.sun.com/j2se/javadoc for more details.} 
\fi

MTS defines a special syntax called the constraint specification
notation that is embedded as C++ comments to capture the relations
outlined above for the variabilities.  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\iffalse
% Amogh, due to space restrictions and suggestions from Gabor, I am
% commenting this out. Could be used in a journal later.
Figure~\ref{fig:cnb_syntax}
illustrates the syntax, which codifies the implication relations
described above.   The \texttt{Quantitative} block captures all the
attributes while the \texttt{Structural} block captures all the model
elements that vary between family members.  

%\begin{wrapfigure}[5]{R}{0.5\textwidth}
\begin{figure}[htb]
\vspace{-.2in}
\begin{center}
{\footnotesize
\begin{tabulary}{\columnwidth}{CLLL} \hline
1 \hspace{0.2in} & Structural \{ & \hspace{0.3in} & Quantitative \{ \\
2 \hspace{0.2in} & \hspace{0.1in} I1::O1;O2 & \hspace{0.3in} & \hspace{0.1in}I2:A1::O3:A1,O3:A2,O3:A3\\
3 \hspace{0.2in} & \hspace{0.1in} O7 & \hspace{0.3in} & \hspace{0.1in}I3:A3::O5:A6 \\
4 \hspace{0.2in} & ...\} & \hspace{0.3in} & \hspace{0.1in}O6:A7 \\
5 \hspace{0.2in} &   & \hspace{0.3in} & ...\} \\ \hline
\end{tabulary}
}
\end{center}
\vspace{-.2in}
\bfcaption{Syntax of Constraint Specification Notation to Capture Variability.}
\label{fig:cnb_syntax}
\vspace{-.2in}
\end{figure}
%\end{wrapfigure}

In the \texttt{Structural} block shown, there is an association defined
between source model object \texttt{I1}, and target model objects
\texttt{O1} and \texttt{O2} which implies that the composition of \texttt{O1} and
\texttt{O2} is dependent on \texttt{I1}.   The presence of \texttt{O7}
in the \texttt{Structural} block implies that the object is created in
the target model irrespective of the presence (or absence) of any
specific source model object(s).   

The \texttt{Quantitative} block captures many-to-many and one-to-one
relations between source and target elements. For example, the values of
\texttt{A1}, \texttt{A2}, and \texttt{A3}  of model object \texttt{O3}
are dependent on that of the \texttt{A1} attribute of object
\texttt{I2}, as shown in Line 2 of \texttt{Quantitative} block.  The
specification \texttt{O6:A7} states that the attribute \texttt{A7} is
directly mapped, \emph{i.e.}, it is hard-coded and is assigned
statically in the model transformation.
\fi
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Figure~\ref{fig:ttr} shows an excerpt of the templatized transformation
rules for the QoS configuration case study.  Notice how the
\emph{Structural} block notation captures the structural variability in
a transformation rule from the source element, \emph{i.e.},
\texttt{RTRequirement:mu\-lti\_service\_level}, to the target element,
\emph{i.e.}, \texttt{BandedConnection}.  The templatized rule will not
explicitly model a rule for creating a \texttt{BandedConnection}.
Instead, only the common parts, which includes the \texttt{Lane} and
\texttt{Threadpool} (not shown) are included in the templatized rule. 

\begin{figure}[htb] 
\centering
\includegraphics[width=0.85\columnwidth,keepaspectratio]{ttr}
\bfcaption{Templatized Transformation Rule in QoS Configuration Case Study.} 
\label{fig:ttr}
\vspace{-0.3in}
\end{figure}

However, notice that since the attribute values for \texttt{Lane} and
\texttt{Threadpool} may vary, they are captured separately in the form
of a \emph{Quantitative} block notation, which indicates what all
attributes and their values can vary.  Since this is a templatization
step, the concrete values for these attributes are not mentioned in this
step.  Section~\ref{sec:sprepo} explains how this is accomplished.
\iffalse
% AMogh, I removed this since one FASE reviewer was confused as to where
% we got these values from
The example specification implies the
following: for \texttt{Lane} attribute set
\{\texttt{st\-at\-ic\_th\-re\-ad\-s},
\texttt{dy\-na\-mi\-c\_th\-re\-ad\-s},
\texttt{la\-ne\_pr\-io\-ri\-ty}\}, \texttt{co\-nf\-ig\_1} in 
Table~\ref{table:scv} can have data values \{10, 20, 50\}, while
\texttt{co\-nf\-ig\_2} can have data values \{5, 2, 15\} to realize the
requirement that the server component should support multiple levels for
service invocations of its clients.
\fi


