%$Id: stepII.tex 14757 2008-10-10 15:02:59Z amoghk $
\sqztiny
\sqzsmall
\subsection{Step II: Generating Variability Metamodels from Constraint Specifications}
\label{sec:gen-VMM}
\sqztiny

% Amogh, although I wrote this para, I am myself now not convinced as to
% why VMM i.e., how does VMM help in providing the rules/patterns. Can
% you refine this please.
%
% Andy, i have removed the "`patterns"' usage below and have simply
% reiterated that the execution of the engine does not alter with
% use of MTS. Does this make sense? 
Although the constraint specifications discussed in Step I capture the
variability in the transformations, the notation used is not
recognized by the model transformation tool. %, which instead requires the
%rules in the form of patterns comprising elements of source and target
%modeling languages.  
The next step in MTS therefore converts the constraint specifications
into a \emph{Variability Meta Model} (VMM) using a higher order
transformation.  It is used to create source and target model objects
in the VMM that correspond to the variabilities in these specifications.
A VMM modularizes the variabilities and decouples them from the model
transformation rules to promote independent evolution.

Algorithm~\ref{algo:vmm} depicts the higher order transformation for
generating the VMM.  The basic idea behind the algorithm is as follows:
Recall from Section~\ref{sec:variab} that the structural variability is
concerned only with capturing the (source and target) model objects (or
their cardinalities) used in composition of family  variants.  For every
structural variability block, the algorithm creates the corresponding
model objects in VMM.  The quantitative variability, on the other hand,
captures the dissimilarities in values of model object attributes.
Therefore, for these variabilities the algorithm creates model objects
and their attributes as well. 

\begin{algorithm}[hbt]
\bfcaption{Generating Family-specific VMM from Constraint Specifications.}
\label{algo:vmm}
{
\scriptsize
%\footnotesize
%\tiny
\dontprintsemicolon
\Indm
\Setnlskip{0.17in}
\linesnumbered
\SetCommentSty{textsf}
\KwIn{source modeling language $S$,
			target modeling language $T$,
      templatized transformation (set of its rules) $R$
      }

\KwOut{variability metamodel $V$
		 }
      
\Begin{
  transformation rule $r$;
  constraint notation block $cnb$;
  set of constraint notation blocks $CNB$; 
  structural variability $cm$;set of structural variabilities $CM$;
  quantitative variability $qm$;set of quantitative variabilities $QM$;
  pattern $p$; modeling object $ob$; attribute $at$;
  modeling object type $type$;attribute type $atttype$;
  integer $c$; \;
   
  $initializeVMM(V);$\nllabel{algo1:init}\;
   
   \ForEach{$r \in R$}{
   			\uIf{$r.cnb() \neq \emptyset$}{
   			  $CNB \leftarrow r.cnb()$; \tcp{populate all constraints
            specifications for that rule}
   			}
   			\ForEach{$cnb \in CNB$}{
   			  \uIf{$cnb.structuralVariabilities() \neq \emptyset$}{
   			    $CM \leftarrow cnb.structuralVariabilities();$\;
   			    \ForEach{$cm \in CM$}{
   			      $p \leftarrow cm.SRC();\nllabel{algo1:src_pat}$\;
   			      \ForEach{$ob \in p$}{
   			        $parseLanguage(S,ob,type);$\nllabel{algo1:parse}
   			        $createSRCObject(V,ob,type);$\;
   			      }
\iffalse   	
% Amogh, I commented this out		      
% Andy, OK.
   			      $p \leftarrow cm.TGT();$ \;
   			      \ForEach{$ob \in p$}{
   			      $parseLanguage(T,ob,type);$ 
   			      $createTGTObject(V,ob,type);$\;
   			      }
\fi
            \tcc{Do similar steps for patterns in target}\;
   			    $composeVariabilityAssociation(V);$  \tcc{creates a
              connection between source and target objects created
              earlier}
   			}
   		}
   		
   		\uIf{$cnb.quantitativeVariabilities() \neq \emptyset$}{
   		\tcc{Similarly, create model objects for quantitative variabilities.}
   		%%
%   			    $QM \leftarrow cnb.quantitativeVariabilities();$\;
%   			    \ForEach{$qm \in QM$}{
%   			      $p \leftarrow qm.SRC();$\;
%   			      \ForEach{$ob \in p$}{
%   			      $parseLanguage(S,ob,type);$
%   			      $createSRCObject(V,ob,type);$\;
%\   			      \ForEach{$at \in ob$}{
%   			        $parseObject(ob,at,atttype);$
%   			        $createSRCAttribute(V,ob,at,atttype);$\;   			        
%   			        }
%   			    }   			      
%   			      $p \leftarrow qm.TGT();$ \;
%   			      \ForEach{$ob \in p$}{
%   			      $parseLanguage(T,ob,type);$
%   			      $createTGTObject(V,ob,type);$\;
%   			      \ForEach{$at \in ob$}{
%   			        $parseObject(ob,at,atttype);$
%   			        $createTGTAttribute(V,ob,at,atttype);$\;   			        
%   			        }
%   			    }
%   			    $composeVariabilityAssociation(V);$ /*creates a connection between source and target objects created earlier*/  			       			    	  
%   			}
   		}
   	$createContainingObject(V);$\nllabel{algo1:contain} \tcc{name of the
      containing object is a combination of rule name, and constraint
      block name, each of which must be unique}
   	}
   	$CNB \leftarrow \emptyset ;$ \tcc{constraint blocks from previous
      loop are deleted, s.t. those from the next rule can be read}
  }
    
}      
}
\normalsize
\end{algorithm}

% The higher order transformation %contains $\sim$83 rules and 
% operates on GME and GReAT metamodels, the templatized 
% transformation itself, and source and target DSMLs (of the 
% templatized transformation).  
The function $initializeVMM (V)$ on Line~\ref{algo1:init} creates a new
VMM, $V$, and initializes its internal variables.  This is necessary so
that in the following rules the syntax and semantics of $V$ can be
defined in GME.  Line~\ref{algo1:src_pat} reads the source patterns that
correspond to every structural variability in the templatized
transformation $R$.  Next, the types of each modeling object for the
pattern read in the previous rule are deduced by parsing the modeling
language as shown in Line~\ref{algo1:parse}.  This type information is
used to create appropriate modeling objects corresponding to the
specified source patterns.  Similar logic is carried out for patterns in
the target language. 

Once the source and target objects are created in the VMM, the function
\texttt{compose\-Variabi\-lityAssoc\-iation (V)} creates a simple
connection between these objects to denote their association.  In a
similar fashion, VMM modeling objects are generated for quantitative
variabilities in $R$.  Additionally, for quantitative variabilities,
attributes of the corresponding modeling  objects are also created.  The
final rule creates a new model object, that contains each of these
source and target objects created in earlier rules, as shown on
Line~\ref{algo1:contain}. 

We applied Algorithm~\ref{algo:vmm} to the templatized model
transformation of our QoS configuration case study to automatically
generate a VMM.  Figure~\ref{fig:vmm-meta} shows a screenshot of the
generated VMM in GME.  
% In this figure,  \texttt{SourcePattern} and
% \texttt{TargetPattern} denote, respectively, the source and target
% language patterns.   
The variabilities are modeled as pairs of
\texttt{So\-ur\-ce\-Pa\-tt\-er\-n} and
\texttt{Ta\-rg\-et\-Pa\-tt\-er\-n}, and annotated by whether they are
\texttt{St\-ru\-ct\-ur\-al} or \texttt{Qu\-an\-ti\-ta\-ti\-ve} using
Boolean attributes.  The figure corresponds to the
\texttt{Qu\-an\-ti\-ta\-ti\-ve} variability rule of Figure~\ref{fig:ttr}
in that the attributes of a \texttt{La\-ne} are dependent on the
\texttt{mu\-lt\-i\_se\-rv\-ic\-e\_le\-ve\-ls} attribute of
\texttt{RT\-Re\-qu\-ir\-em\-ent}.  The \texttt{Th\-re\-ad\-Po\-ol}
attribute values, on the other hand, can vary among each
configuration (\emph{e.g.}, \texttt{Co\-nf\-ig\_1},
\texttt{Co\-nf\-ig\_2} etc. in Table~\ref{table:scv}), and are generated
in the VMM.  

% Amogh, the circled object in this figure is not visible in printed
% copy. Is there anything we can do about this?
\begin{figure}[htb]
\vspace{-0.2in}
\centering
\includegraphics[width=0.8\textwidth,keepaspectratio]{VMM}
\vspace{-0.1in}
\bfcaption{Excerpt of Generated VMM for QoS Configuration Family.}  
\label{fig:vmm-meta}
\vspace{-0.2in}
\end{figure}

%%%%%%%%%%%%%%%%%%%
% Commenting out dialog case study.
%%%%%%%%%%%%%%%%%%%
\iffalse
dialog family.   Figure~\ref{fig:vmm-meta} shows a
screenshot of the generated VMM in GME.  In this Figure,
\texttt{SourcePattern} denotes the source language pattern while
\texttt{TargetPattern} denotes the target language pattern.  The same
input dialog specification is refined as it is transformed in our case
study, thus the \texttt{SourcePattern} model does not contain any
elements.

\begin{figure}[htb]
\vspace{-0.2in}
\centering
\includegraphics[width=\textwidth,keepaspectratio]{VMM}
\vspace{-0.1in}
\bfcaption{Generated VMM for communication dialog family using
the Algorithm~\ref{algo:vmm}.}  
\label{fig:vmm-meta}
%\vspace{-0.2in}
\end{figure}

Variabilities are separately modeled and contained in the
\texttt{St\-ru\-ct\-ur\-al} and \texttt{Qu\-al\-it\-at\-iv\-e} elements.  
For example, the \texttt{Call} and \texttt{Documentation} elements 
are contained in the \texttt{Structural} element, and do not 
contain any attributes. The \texttt{In\-vi\-ta\-ti\-on}, \texttt{To\-pi\-c},
and \texttt{Re\-sp\-on\-se} elements are contained in the \texttt{Qu\-al\-it\-at\-iv\-e} 
element. Further, since the values of their attributes are dependent on 
the communication endpoint (as per the requirements of the insurance 
enterprise case study listed in Section~\ref{sec:dialogs}), these elements
also contain their corresponding attributes as shown in
Figure~\ref{fig:vmm-meta}.
\fi
%%%%%%%%%%%%%%%%%%%
% Commenting out dialog case study.
%%%%%%%%%%%%%%%%%%%
