%$Id: stepIV.tex 16755 2009-02-09 02:48:42Z gokhale $
\sqzlarge
\subsection{Step IV: Specializing the Transformation Instances}
\label{sec:specialize}
\sqztiny

To realize the actual transformation for a family variant,
transformation tools like GReAT must combine the VMM models developed in
Step III along with the (original) templatized model transformation
rules and the invariant rules.  This is akin to a C++ compiler using the
programmer-supplied implementation of the $\leq$ operator for a
user-defined type and instantiating the remaining parametrized class
with the given type.   The templatized transformations, however, do not
contain any transformation rules for the variability in the visual
language.  How is it then that the instantiated variability in the form
of a VMM model can be recognized by the templatized transformation
rules?   To address this question, MTS  provides a second HOT that (1)
reads the input VMM model for a family member, and (2) adds temporary
objects at appropriate points in the templatized transformation rules,
which serve as placeholders to insert the instantiated variability of a
family member (corresponding to the current VMM model). 

Algorithm~\ref{algo:specialize} defines the translation rules for a
transformation from a VMM model.
Lines~\ref{algo2:init}--\ref{algo2:create_tmp} create a new model
transformation instance $R^\prime$ from the input templatized
transformation $R$, read the containing model objects in VMM $V$, and
for every  model object $ob$ search the corresponding rule in the
transformation $R'$.\footnote{For creating application family instances,
  it is not necessary to create a new instance $R'$, but is done only
  for Algorithm~\ref{algo:specialize} to avoid modification of the
  original templatized  transformation $R$.} 
This rule denotes the location where the variabilities contained in $ob$
were specified in Section~\ref{sec:variab}.

%\sqzsmall
\begin{algorithm}[htb]
\bfcaption{Specializing the Model Transformation from a VMM model.}
\label{algo:specialize}
{
\scriptsize
\dontprintsemicolon
\Indm
\Setnlskip{0.17in}
\linesnumbered
\SetCommentSty{textsf}
\KwIn{variability metamodel $V$,
      templatized transformation $R$
      }

\KwOut{specialized instance of input templatized transformation $R'$
		 }
      
\Begin{
  transformation rule $r$; set of model objects $OB$,$IO$;
  pattern $p$; modeling object $ob$,$io$,$tmp$; attribute $at$;
  modeling object type $type$;attribute type $atttype$;\;
   $R' \leftarrow R;$
   $OB \leftarrow containingModelObject(V);$\nllabel{algo2:init}\;
   \ForEach{$ob \in OB$}{
       $r \leftarrow searchRule(R',objName(ob));$\nllabel{algo2:create_tmp}
       $createTempObject(tmp,r);$
       $deleteCNB(r);$\;
       $IO \leftarrow parseSRCPattern(ob);$       
       
       \ForEach{$io \in IO$}{
         $createObjectRefs(io,tmp);$
         $assignCardinalities(io,tmp);$\nllabel{algo2:structural}\;
         $createAttribs(io,tmp);$
         $assignValues(io,tmp);$\nllabel{algo2:quantitative}
       }
       \tcc{do similar steps for target pattern}
\iffalse
% Commented out to save space
       $IO \leftarrow parseTGTPattern(ob);$\;
       
       \ForEach{$io \in IO$}{
         $createObjectRefs(io,tmp);$
         $assignCardinalities(io,tmp);$\;
         $createAttribs(io,tmp);$
         $assignValues(io,tmp);$\;
       }   		
\fi	
  }
    
 }      
}
\normalsize
\end{algorithm}
%\sqzsmall

Once rule $r$ is known, the constraint block is deleted from this rule
in function $deleteCNB(r)$.  The function $createTempObject(tmp,r)$
creates a temporary object $tmp$ inside this rule.  For every
\texttt{Structural} variability in  the source pattern in $ob$, object
references are read from $V$, and created in  $tmp$ and in addition,
their cardinalities are assigned as shown in
Line~\ref{algo2:structural}.  Similarly,  attributes in VMM that capture
\texttt{Quantitative} variabilities are read from  $V$, and created and
assigned values in $tmp$ in Line~\ref{algo2:quantitative}.  The 
same rule is also  repeated for all target patterns in $ob$. 

We applied Algorithm~\ref{algo:specialize} to our QoS configuration example.
One of the rules in this case study assigns specific data values
to the attributes of \texttt{Lane} (target) depending on whether
or not the  \texttt{mu\-lt\-i\_se\-rv\-ic\-e\_le\-ve\-ls} (source)
value is set to {\sc true}.  Further, as identified earlier in 
Section~\ref{sec:variab}, there is a quantitative variability
involving these two elements.  The same variability is also given in
Figure~\ref{fig:specialization} for reference.  The attributes in
\texttt{tempObject} are assigned values from the values of the
corresponding attribute in the VMM model.  Similarly, for the structural
variability, the model object references are also created by parsing and
reading the VMM model.  

\begin{figure}[htb] 
\centering
\includegraphics[width=0.75\columnwidth,keepaspectratio]{specialization}
\bfcaption{Specialization of a QoS configuration rule using MTS.} 
\label{fig:specialization}
\vspace{-.1in}
\end{figure}

Thus, the rule
\texttt{se\-rv\-ic\-e\_le\-ve\-ls\_at\-tr\-ib\-ut\-e\_ma\-pp\-in\-g}
(and in effect, the model transformation itself) need not change, when
some of these data values/model object cardinalities have to be altered.
This is because the modifications can now be done simply by modifying 
the appropriate VMM model.

