% $Id: unused.tex 16691 2009-02-05 14:08:29Z gokhale $
% Placeholder, until paper is organized correctly.

%%% grabbed from abstract %%

% \sqzlarge
% \iffalse
% Model transformations have been shown to be useful in 
% a variety of processes in software development cycle. 
% They have been employed for defining progressive 
% refinements on application models to translate these 
% models from abstract, high-level views into 
% low-level, detailed views. Recently, they have been 
% successfully applied in the context of product-line 
% software development, owing to which reusability in 
% transformations has gained considerable importance. 
% Relatively fewer studies exist in literature that 
% specifically address reusability and extensibility 
% in model transformations.

% In this paper we discuss our model transformation 
% templatization %\& specialization 
% approach to 
% developing reusable model transformations. We 
% provide transformation developers with a simple 
% specification language for defining family 
% variabilities in their templatized transformation. 
% We define higher order transformations to 
% automatically synthesize family-specific 
% variability language, which is later used by 
% developers to define instance-specific variability 
% models. Finally, these models are used along 
% with the templatized transformation to create 
% specialized application instances. 
% \fi

%
%Despite the benefits of model-to-model transformations in software development
%processes, they incur substantial overhead from the lack of reusability and
%extensibility when a single source model is to be transformed into a class of
%target models that illustrate substantial commonalities among themselves.  This
%paper describes MTS, which is a model transformation tool suite that overcomes
%these challenges by supporting the concept of templatized model
%transformations.  Using MTS the variabilities of each target model can easily be
%captured  as models (as opposed to transformation rules), which are later
%provided as arguments to the templatized transformation for instantiating
%mappings for that target.  The principles and techniques supported by MTS can be
%implemented on existing model transformation tool suites.  We evaluate
%MTS in the context of automated middleware configurations, where system level
%quality of service (QoS) requirements are mapped by MTS to middleware
%configurations for two different middleware platforms supporting
%publish/subscribe semantics.
%\iffalse
%Middleware QoS configuration process involves a systematic
%study of configuration space in order to choose a subset of
%semantically compatible configurations and their values in 
%an application-specific manner in order to realize 
%application QoS requirements. Recent studies have 
%applied model transformation techniques in automating this 
%process and have shown significant scalability and reusability
%benefits. Large scale distributed real-time and embedded (DRE) systems are 
%composed of several interacting, and cooperating application
%sub-systems that are typically developed using different
%hosting infrastructure platforms. Thus, for performing QoS
%configuration activity for these DRE systems, irrespctive of the 
%solution approach taken to for its automation, individual 
%platform-specific QoS mappings must be developed and 
%maintained.
%\fi
%%%% Amogh, see if this is better
%\iffalse
%Correctly configuring a single middleware platform to satisfy a specific
%application quality of service (QoS) requirement, such as response time, is
%a hard problem due to the large middleware configuration space.  As the
%number of middleware platforms that applications are hosted on increases, and as
%the number of QoS requirements of applications increase, the middleware
%configuration problem becomes even harder.  Solutions based on model-based graph
%transformations offer a promising approach towards automating the configuration
%process.   However, such automation tools face challenges akin to programming
%language compilers that must provide a common, reusable solution for a wide
%range of back ends.  This paper describes XYZ, which is a middleware
%configuration tool chain that incorporates a novel parametrized graph
%transformation approach we developed.
%% Amogh, give some name, and fill the rest out making the abstract shorter.
%% Take whatever from the para below. The low level details you have in here can
%% go to the intro section where you explain the overview of the soln.
%\fi
%\iffalse
%Correctly configuring a middleware platform to satisfy application
%quality of service (QoS) requirements is non-trivial as involves a systematic study of configuration space 
%in order to choose a subset of semantically compatible configurations 
%and their appropriate values. Large scale distributed 
%real-time and embedded (DRE) systems that are typically developed using 
%several middleware platforms exacerbate the problem further. Recently introduced 
%model tr\-an\-sf\-or\-ma\-ti\-on-ba\-se\-d solutions offer a promising approach towards automating 
%the middleware configuration process. However, these solutions are developed
%in a platform-specific manner and therefore can not be easily extended.
%
%This paper provides the following contributions to generalizing
%middleware configuration process for DRE systems. First, it
%describes the challenges and problems in supporting 
%multiple, platform-specific QoS mappings. Second, it 
%introduces MTS, a tem\-pl\-at\-ized model t\-ra\-ns\-fo\-rm\-at\-ion approach
%that facilitates the development of platform-independent
%model transformations for mapping app\-li\-ca\-ti\-on-le\-ve\-l
%QoS requirements. 
%\fi
%\iffalse
%A simple, non-intrusive constraint notation is
%used in order to capture configuration mechanism variability in 
%transformation algorithms.
%\fi
%\iffalse
%Using MTS the variabilities of each platform can be easily captured 
%as models (as opposed to transformation rules), which are later 
%provided as arguments to the templatized transformation for instantiating 
%QoS mappings for that platform. We apply our approach in the 
%context of a case study and evaluate it against developing and 
%maintaining platform-specific QoS mappings.
%\fi
%

\iffalse
\section{Applying MTS to Representative Application Scenarios}
\label{sec:scenario}
In this section, we demonstrate the application of
the MTS approach to the facilitate the development 
of templatized transformations for two representative
case studies. The following two case studies have been
used: (1) synthesis of dialogs for a set of 
communication endpoints in an enterprise, and (2) 
creation of quality of service (QoS) configurations 
for a component-based application, from its QoS 
requirements.

\subsection{Communication Dialog Creation for an Insurance Enterprise}
\label{sec:dialogs}
Our first case study deals with creation of dialogs 
for a set of communication endpoints from \emph{workflow} 
decision points in an insurance company. As part of their operation,
modern enterprise workflows set up communications between
decision makers in an enterprise, publish (collect) important
information to (from) these decision makers. Since employees in
an enterprise may potentially be using several endpoints, an 
important aspect in delivering information content from 
workflows to the employees is customizing the communication
dialogs to individual endpoints.
\begin{figure*}[htb]
\centering
\includegraphics[width=0.75\columnwidth,keepaspectratio]{dialoguml}
\bfcaption{A Simplified UML Representation of a Generic Communication Dialog.} 
\label{fig:dialoguml}
\end{figure*}

Figure~\ref{fig:dialoguml} shows the communication dialog metamodel
in our case study.  We have simplified the communication dialog
by restricting the communications to a customer claim in the insurance
company. The following are some of the 
properties/attributes in this communication dialog: 
(1) \texttt{Call} specifies a number to call to 
retrieve a dialog, (2) \texttt{Do\-cu\-me\-nt\-at\-ion} 
contains further details about documentation pertaining to the claim in
question, (3) \texttt{To\-pi\-c} specifies details about the claim 
itself, (4) \texttt{In\-vi\-ta\-ti\-on} contains details about a 
conference call for discussing the claim, and (5) \texttt{Re\-sp\-on\-se}
allows an employee to reply to the invitation in the current
dialog. 

Additionally, the \texttt{Re\-sp\-on\-se} element allows an employee
to suggest an alternate employee that can be contacted about the claim
in question. The latter can be done by setting \texttt{user\_response} to
{\sc false} and populating the \texttt{suggest\_alternate} attribute
with an appropriate value. Similarly, a user can send a request for a
modified invitation to the workflow that initiated this dialog by using
the \texttt{amend\_invitation} enumerated data type.

In our case study both the source and target model elements
belong to the dialog metamodel and hence the same input 
dialog specification is specialized and transformed into a 
dialog for individual endpoints. 

\subsubsection{Identifying Variabilities in Communication Dialog.}
\label{fig:varib-dialog}
\begin{table*}[htb]
\centering
\caption{SCV analysis results for three representative communication endpoints}
\label{table:dialog-prop}
\scriptsize
\begin{tabulary}{\columnwidth}{|C|C|C|C|}
  \hline
  \textbf{Communication} & \multicolumn {2} {|c|} {\underline{Dialog properties/Attributes} } \\      
  \textbf{endpoint} & \textbf{Commonalities} & \textbf{Variabilities} \\  
  \hline \hline
  & & invitation\_detail, meeting\_date,\\
  Cell phone/Office phone & invitation\_info, topic\_info & meeting\_time, user\_response,\\  
   & & topic\_detail, claim\_id, customer\_name,\\
   & & customer\_id, claim\_date\\
  \hline
  Pager & invitation\_info, topic\_info& Call \\
  \hline
   & & user\_response, suggest\_alternate,\\
  Instant Messenger & invitation\_info, topic\_info & Documentation, invitation\_detail, \\   
   & & meeting\_date, meeting\_time, \\
   & & topic\_detail, claim\_id, customer\_name,\\
   & & customer\_id, claim\_date, amend\_invitation\\
  \hline
  
\end{tabulary}
\end{table*}

In the first step, transformation developers factor out the
commonalities and identify the variabilities in communication
dialog by performing SCV analysis. The SCV analysis for dialog 
profiles (where profile is denoted by properties required to 
create a dialog for an endpoint) is shown in 
Table~\ref{table:dialog-prop} for three representative communication 
endpoints. As shown, it tabulates the common and variable 
properties (which may be either be model object attributes, or
the model objects themselves) for each of the endpoints. Following
this analysis, the SCV analysis results are fed into the 
transformation, the following shows (an incomplete) constraint 
specification in MTS for the variabilities in Table~\ref{table:dialog-prop}:

{\scriptsize
\begin{verbatim}
Structural {
    Call
    Documentation
}
Qualitative {
    Response:user_response
    Response:suggest_alternate
    Response:amend_invitation
    Invitation:invitation_info
    Invitation:invitation_detail
    Invitation:meeting_date
    Invitation:meeting_time
}
\end{verbatim}
}
As shown above, \texttt{Call} and \texttt{Documentation} are specified
in \texttt{Structural} block to indicate that they may be present in
the dialog profiles of some endpoints. The \texttt{Qualitative} block
on the other hand, captures those model objects that are present across
all the endpoints, but the values of their attributes may be different
for every endpoint. Thus, even though the \texttt{Response}  element is 
present in both the cell phone and the IM, 
the \texttt{suggest\_alternate} and \texttt{amend\_invitation} attributes  
are not applicable and are omitted for the cell phone (because of limited  
capabilities of the endpoint). For a IM endpoint, however, these 
attributes can be used in its dialog and are available. A similar variability 
exists for the attributes of the \texttt{Invitation} element for the 
office phone and pager endpoints.

\subsubsection{Specialization of Communication Dialog.}
\label{sec:gen-VMM-dialog}
Following the identification of variabilities in communication dialog, the 
higher order transformation Algorithm~\ref{algo:vmm} is applied to the 
templatized model transformation in our insurance case study to 
automatically generate a VMM for the dialog family. 
Figure~\ref{fig:vmm-meta} shows a screenshot of the generated VMM in
GME. In this Figure,  \texttt{InputPattern} denotes the source language
pattern while \texttt{OutputPattern} denotes the target language
pattern. The same input dialog specification is refined as it is 
transformed in our case study, thus the \texttt{InputPattern} model does 
not contain any elements. 

\begin{figure*}[htb]
\centering
\includegraphics[width=0.65\textwidth,keepaspectratio]{VMM}
\bfcaption{Generated VMM for Communication Dialog Family using
the Algorithm~\ref{algo:vmm}.}  
\label{fig:vmm-meta}
\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.  The
specialization  repository can now be easily synthesized by developers
in terms of VMM models, where each model captures an individual dialog
profile (for example, as shown in Table~\ref{table:dialog-prop}). The 
VMM models are ultimately used in conjunction with our original 
(templatized) transformation to create dialogs as shown in 
Figure~\ref{fig:vmm-meta}.
% For each case study, provide the following:
%
% Brief context
% What is the input, what is the output
% Why you need a family of dialogs
% Explain meta-model
% Give dialog profiles, for a range of endpoints..
% show as if this is the output of SCV analysis, 
% with attributes distributed between commonalities
% and variabilities
% Give steps:
% First step: give constraint specification
% Next, show what gets generated from Algorithm explained
% earlier.
% Next, explain how this achieves what we set out to do in
% the first place.
\subsection{Middleware QoS Configuration for Component-based Applications}
\label{sec:qos}
\begin{figure*}[htb]
\centering
\includegraphics[width=0.75\columnwidth,keepaspectratio]{configurationuml}
\bfcaption{A Simplified UML Representation of Middleware QoS Configuration metamodels.} 
\label{fig:configuml}
\end{figure*}
Our second case study deals with automated mapping of component-based application
QoS requirements onto their realization in terms of platform-specific
QoS configuration options. Figure~\ref{fig:configuml} shows the UML representation
of both the input and the output metamodels used in the QoS configuration case 
study. As shown, the input metamodel contains the following Booleans for server
components: (1) \texttt{fi\-xed\_pr\-io\-ri\-ty\_se\-rv\-ic\-e\_ex\-ec\-ut\-ion} that 
indicates whether the component changes the priority of client service invocations, and
(2) \texttt{mu\-lt\-i\_se\-rv\-ic\-e\_le\-ve\-ls} to indicate whether the component
provides multiple service levels to its clients. The output metamodel, which models the
lightweight CORBA Component Model (LwCCM) real-time configurations, defines the following 
elements: (1) \texttt{Lane}, which is a logical set of threads each one of which runs at 
\texttt{lane\_priority} priority level. It is possible to configure \emph{static} 
thread (i.e., those that remain active till the system is running) and \emph{dynamic}
thread (i.e., those threads that are created and destroyed as required) numbers using 
\texttt{Lane} element. (2) \emph{ThreadPool}, which controls various settings of 
\texttt{Lane} elements, such as, \texttt{stacksize} of threads, whether borrowing of 
threads across lanes is allowed, and maximum resources assigned to buffer requests that 
cannot be immediately serviced. (3) \texttt{Pr\-io\-ri\-ty\-Mo\-de\-lP\-ol\-ic\-y}, which 
controls the \texttt{ThreadPool} policy model. (4) \texttt{Ba\-nde\-dCon\-nect\-io\-ns}, which 
defines separate connections for individual (client) service invocations.

\begin{table*}[htb]
\centering
\caption{SCV analysis results for three configuration profiles}
\label{table:config-prop}
\scriptsize
\begin{tabulary}{\columnwidth}{|C|C|C|C|}
  \hline
  \textbf{Configuration} & \multicolumn {2} {|c|} {\underline{QoS Options/Attributes} } \\      
   & \textbf{Commonalities} & \textbf{Variabilities} \\  
  \hline \hline
  Config\_1 & PriorityModelPolicy, & allow\_borrowing, allow\_buffering,\\  
  & EnvironmentConf, stacksize & max\_buffd\_reqs., max\_buff\_size,\\
  & &  Lane\\
  \hline
  Config\_2 & PriorityModelPolicy, & allow\_borrowing, allow\_buffering,\\
  & EnvironmentConf, stacksize &  max\_buffd\_reqs., max\_buff\_size,\\
  & &  Lane, BandedConnections\\
  \hline
  Config\_3 & PriorityModelPolicy, & allow\_borrowing, allow\_buffering,\\
   & EnvironmentConf, stacksize &  max\_buffd\_reqs., max\_buff\_size,\\
   & &  Lane, BandedConnections\\
  \hline
\end{tabulary}
\end{table*}

{\scriptsize
\begin{verbatim}
Structural {
    BandedConnection    
}
Qualitative {
    RTRequirement:multi_service_levels::Lane:static_threads,
           Lane:dynamic_threads,Lane:lane_priority
    ThreadPool:max_buffer_size
    ThreadPool:max_buffered_requests
    ThreadPool:allow_buffering
    ThreadPool:allow_borrowing
}
\end{verbatim}
}

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

\fi



%\section{Introduction}
%\label{sec:intro}
%% Amogh, I changed it to model-to-model.  I also refined things a bit.
%Model-to-model transformations are an integral part of many software
%development process.  For example it is used in model refinements of
%platform-independent system models in Model Driven Architecture
%% Amogh, is QVT a model transformation as we know it. If so, cite it too.
%(MDA)~\cite{MDA:01}.  In other cases it is used in the semantic
%translation of models of the system in one form to other forms of models
%of computations~\cite{Karsai:04} used for the purposes of analysis of
%system properties, such as correctness.  Our recent
%work~\cite{Gokhale_GTQMAP_RTAS:08} has demonstrated its use in
%component-based software engineering for automated middleware
%configurations that map system requirements to middleware quality of
%service (QoS) mechanisms.
%
%% Amogh, I added the ``particularly'' clause
%Model transformation techniques -- particularly those that use graph
%transformations -- work on labeled typed graphs~\cite{Andries:99} that
%can be augmented with attributes.  The typed graph structures can be
%used for representing the transformation input and output and are
%typically expressed using UML-style notations~\cite{Czarnecki:03}.  The
%transformation rules in such model transformations are expressed in a
%declarative, well-understood format in terms of \emph{source} and
%\emph{target} graph patterns, \emph{i.e.}, subgraphs of source and
%target graphs, and therefore can be validated for correctness.
%
%% Amogh, we could potentially move this para to relwork or in the soln
%% section where we talk about what underlying tool we are using
%Some well known examples of model transformation techniques include the Graph
%Rewriting And Transformation language (GReAT)~\cite{GReAT:03} and VIsual
%Automated model TRAnsformations (VIATRA)~\cite{VIATRA:02}.  These tools
%provide the mechanisms and required constructs to model and implement
%transformation rules.  Model transformations have several benefits such
%as reusability of translation rules since they are developed in terms of
%metamodels, maintainability, traceability between various views of the
%modeled system. 
%
%Despite their benefits however, lack of extensibility of model
%transformations remains a significant challenge.  For example, consider
%the case of model transformation-based development of a system software
%product line where the family of products share a significant number of
%common features.  Assuming that the product families go through
%refinement mappings before end product is synthesized, with the existing
%state-of-the-art transformation tools and techniques
%~\cite{GReAT:03,VIATRA:02,Lara:02,Schurr:96}, these mappings are
%realized as separate model transformations (as opposed to a single
%transformation that is \emph{specialized} based on variations in the
%product families).  Thus, it is difficult to extend model transformation
%for a set of mappings that share a number of \emph{commonalities} in
%translation.  
%
%Such a lack support for developing reusable (patterns of) transformation
%leads to several brittle mappings that are very difficult to evolve and
%maintain since modifications in transformation rules must be propagated
%across all these mappings.  Further it also leads to code duplication,
%since these mappings share  a number of commonalities amongst them. 
%% Amogh, give some existing work here i.e., these problems have been
%% addressed to some extent in ``model-to-code'' transformations e.g.,
%% JET, etc. But it continues to remain an issue in model-to-model
%% transformations.  Then say we address this challenge.
%
%% Amogh, what is the full form of MTS
%This paper describes MTS (), which is a higher order transformation
%process involving templatized (\emph{i.e.}, parametrized) model
%transformations.  MTS has been implemented within the Graph Rewriting
%And Trans\-form\-ation (GR\-e\-AT)~\cite{GReAT:03} model transformation
%toolchain and the meta-pro\-gr\-am\-ma\-ble Generic Modeling Environment
%(GME)~\cite{GME:01}.  MTS allows development of templatized model
%transformation by providing constraint notations that can be used to
%% Amogh, what does ``transformation instance'' mean?
%identify (and extract) variablity in transformation instances.  These
%% Amogh, ``non intrusive'' for whom?
%notations are non-intrusive in that they are present only for
%identifying  the variability points in the transformations, and are
%completely opaque to the underlying model transformation engine.   This
%enables the concepts of MTS to be be applied to other model
%transformation engines.
%
%\iffalse
%% For now I commented this out.  Can be moved to the soln section where
%% we give a quick idea of how things work.
%A modeling language is generated dynamically from 
%constraint notations of a model transformation, which is used in 
%defining instance variability models. The \emph{generality} of all
%implementation platforms is thus pushed into the instance-agnostic 
%transformation, while the \emph{specificity} of individual instances is 
%isolated as variability models. These variability models
%are used in compiling transformation instances.
%\fi
%
%% Amogh, I enhanced this. Please see.
%We demonstrate how MTS can be applied to automate middleware QoS
%configurations when variability in the target models is introduced by
%the heterogeneity in the underlying middleware platforms.  For our
%evaluations we focus on two representative middleware platforms that
%support publish/subscribe semantics, and demonstrate MTS' effectiveness
%in addressing the extensibility challenge.   We further evaluate MTS in
%terms of the impact on the development effort.
%
%The rest of the paper is organized as follows: 
%Section~\ref{sec:scenario} discusses middleware platform case studies and 
%motivate the need for a generalized approach to QoS 
%configuration; Section~\ref{sec:soln} gives an overview of our approach 
%and discusses supporting technologies we have used; 
%Section~\ref{sec:design} discusses details of our solution and illustrates
%the use of our templatization technique; Section~\ref{sec:rel} compares our 
%work with existing literature; Section~\ref{sec:conclusion} gives concluding
%remarks and planned future work.
%
%
%
%\iffalse
%% $Id: unused.tex 16691 2009-02-05 14:08:29Z gokhale $
%\section{Introduction}
%\label{sec:intro}
%\vspace{-0.1in}
%\iffalse
%A recurring property of a wide variety of applications found in
%domains such as total shipboard computing environment, avionics
%mission computing, intelligent transportation systems is their
%need for multiple quality of service (QoS) requirements, such as
%timeliness, high availability, fault tolerance and security. These 
%applications, their hosting infrastructure, and the environments 
%they operate in are often collectively referred to as distributed 
%real-time and embedded (DRE) systems. Realizing the capabilities of 
%these DRE systems requires deploying and configuring the application 
%mix of the DRE systems on the platforms that host them.
%\fi
%Distributed real-time and embedded (DRE) sytems are found in a variety
%of application domains such as total shipboard computing 
%environment, avionics mission computing, and intelligent transportation 
%systems. Due to enormous development costs, presence of legacy 
%software entities and their large scale, these DRE systems are heterogeneous and
%are typically \emph{composed} of several interacting, and co-operating 
%application sub-systems, as opposed to being built from scratch. Further, 
%these DRE systems also exhibit heterogeneity in the hardware components, and 
%the infrastructure platforms used in the development and deployment of 
%its application sub-systems. 
%
%Because of their heterogeneity with respect to the infrastructure 
%platforms, Quality of service (QoS) of such composed DRE systems is
%configured at various QoS dimensions (\emph{e.g.,} fault-tolerance, 
%real-time) and at each of these platforms such that ultimately QoS is 
%realized at global- (application) as well as local- (sub-system) level.
%Infrastructure platforms such as for example, contemporary middleware 
%platforms provide a rich set of configuration mechanisms including 
%different concurrency and synchronization models, prioritized handling 
%of requests, buffering requests using release guards, different connection 
%management models, among others to allow customization of the middleware 
%platforms that are tailored to the DRE system requirements. On account of 
%such a high degree of flexibility and configurability in these mechanisms, 
%achieving the desired QoS properties of middleware-based systems requires that
%their developers perform \emph{middleware QoS configuration}, which
%involves determining how their domain-specific QoS requirements
%map onto the right set of middleware-specific QoS configuration
%options and forces the developers to possess a comprehensive 
%knowledge of various configuration options supported by the 
%middleware, how individual configuration options impact the resulting 
%QoS delivered to the applications, and the inter-dependencies including 
%tradeoffs between these options. 
%
%Recent studies~\cite{Almeida:06,Zschaler:07,Gokhale_GTQMAP_RTAS:08} have 
%applied model transformation techniques to the automation of middleware 
%QoS configuration process. Using this approach, system QoS requirements 
%are expressed in terms of domain-level abstractions that are intuitive 
%thus eliminating largely the need for a comprehensive understanding of 
%the low-level configuration mechanisms provided by the middleware. These 
%system requirements are then transformed using platform-specific model 
%transformations to more refined and detailed configuration models of 
%system. This automated middleware QoS configuration approach has 
%been shown to have considerable benefits in terms of scalability and 
%evolvability of system QoS specification~\cite{Gokhale_GTQMAP_RTAS:08}, while 
%meeting the expected system QoS~\cite{Gokhale_QUICKER_ISORC:08}.
%However, since these transformation-based techniques 
%for QoS mapping have been developed for specific platforms, the 
%middleware QoS configuration process can not be generalized 
%and must be performed in a platform-specific manner. 
%
%This paper introduces MTS, a templatized model transformation
%approach for generalizing middleware QoS configuration for DRE systems across 
%all of its implementation platforms. MTS has been implemented in a 
%prototypical framework using the Graph Rewriting And 
%Trans\-form\-ation (GR\-e\-AT)~\cite{GReAT:03} model transformation
%toolchain and the meta-pro\-gr\-am\-ma\-ble Generic Modeling 
%Environment (GME)~\cite{GME:01}. MTS allows development
%of platform-agnostic model transformation by providing constraint
%notations that can be used to identify (and extract) 
%variablity in configuration mechanisms during QoS mapping. These notations 
%are non-intrusive in that they are present only for identifying configuration 
%variability points, and are completely opaque to the underlying model 
%transformation engine. A modeling language is generated dynamically from 
%constraint notations of a model transformation, which is used in 
%defining platform variability models. The \emph{generality} of all
%implementation platforms is thus pushed into the platform-agnostic 
%transformation, while the \emph{specificity} of individual platforms is 
%isolated as platform variability models. Finally, these variability models
%are used in instantiating platform-specific QoS mappings such that QoS
%configuration of that platform can be done.
%
%The rest of the paper is organized as follows: 
%Section~\ref{sec:scenario} discusses middleware platform case studies and 
%motivate the need for a generalized approach to QoS 
%configuration; Section~\ref{sec:soln} gives an overview of our approach 
%and discusses supporting technologies we have used; 
%Section~\ref{sec:design} discusses details of our solution and illustrates
%the use of our templatization technique; Section~\ref{sec:rel} compares our 
%work with existing literature; Section~\ref{sec:conclusion} gives concluding
%remarks and planned future work.
%\fi



% \begin{table}[htb]
% \vspace{-0.2in}
% \centering
% \bfcaption{SCV analysis results for case studies in Section~\ref{sec:scenario}.}
% \label{table:scv}
% \scriptsize
% \begin{tabulary}{\columnwidth}{|C|C|C|C|} \hline
%   & \multicolumn{3}{c|}{\centering \textbf{Properties/Attributes}}
%    \\ \cline{2-4}

%    \textbf{Family} & \textbf{Commonalities} & 
%    \multicolumn{2}{c|}{\textbf{Variabilities}} \\\cline{3-4}

%   \textbf{Variant} & & \textbf{Structural} & \textbf{Qualitative} \\  
%   \hline \hline  

% %%%%%%%%%%%%%%%%%%
% % Commenting dialog case study s.t. only one case study is fully explained
% %%%%%%%%%%%%%%%%%%

%   \underline{\textbf{\emph{Insurance Enterprise}}} & & & \\
%   & & & \\
%   & & & invitation\_detail, meeting\_date,\\
%   Cell phone/ & & & meeting\_time, user\_response,\\  
%   Office phone & & -- & topic\_detail, claim\_id, customer\_name,\\
%   & & & customer\_id, claim\_date\\
%   & invitation\_info, & & \\
% Pager & topic\_info & Call & -- \\
%   & & & \\
  
% %%%%%%%%%%%%%%%%%%
% % Commenting dialog case study s.t. only one case study is fully explained
% %%%%%%%%%%%%%%%%%%

%   %\hline
%   & & & user\_response, suggest\_alternate,\\
%    %Instant Messenger & invitation\_info, topic\_info & Documentation & invitation\_detail, meeting\_date, meeting\_time, \\      
%   Instant Messenger & & Documentation & invitation\_detail, meeting\_date, meeting\_time, \\      
%    & & & topic\_detail, claim\_id, customer\_name,\\
%    & & & scustomer\_id, claim\_date, amend\_invitation\\   
%    & & & \\
%      %Config\_1 & PriorityModelPolicy, & & allow\_borrowing, allow\_buffering,\\  
% %  & EnvironmentConf, stacksize & Lane & max\_buffd\_reqs., max\_buff\_size,\\  

%   \hline
%   \underline{\textbf{\emph{QoS Configuration}}} & & & \\
%   & & & \\
%   Config\_1 & & & allow\_borrowing, allow\_buffering,\\  
%   & & Lane & max\_buffd\_reqs., max\_buff\_size,\\  
%   & PriorityModelPolicy, & & \\
%   & & & \\  
%   Config\_2 & EnvironmentConf, & Lane, & allow\_borrowing, allow\_buffering,\\
%   & stacksize & BandedConnections &  max\_buffd\_reqs., max\_buff\_size,\\  
%   & & & \\    
%   Config\_3 & & Lane, & allow\_borrowing, allow\_buffering,\\
%    & & BandedConnections &  max\_buffd\_reqs., max\_buff\_size,\\   
%   \hline

% \end{tabulary}
% \vspace{-0.2in}
% \end{table}



\iffalse
% Amogh, even this goes since reviewers bashed us on how SCV is carried
% out etc.
To realize this, transformation developers must first carry out scope,
commonality and variability (SCV)~\cite{Weiss:98} analysis of their
application family.  The developers then express the results of SCV
analysis as constraint specifications, which is a capability in MTS we
discuss below.  The following two categories of variabilities can be
specified using our constraint notation specification:
\fi

\iffalse
%%%% commented out. FASE reviewer was questioning who does this -Andy
Table~\ref{table:scv} shows the results of the SCV analysis for the QoS
configuration case study presented in
Section~\ref{sec:scenario}.\footnote{Due to space constraints the MTS
  steps are shown only for the QoS configuration case study.} 

For example, in the dialog case study, we show three endpoint variants,
where each variant is denoted by properties required to create a dialog
for an endpoint.  It tabulates the common and variable properties for
each of these endpoints.  These dialog properties themselves may be either 
model object attributes (\emph{e.g.},
\texttt{su\-gg\-es\-t\_al\-te\-rn\-at\-e} and
\texttt{in\-vi\-ta\-ti\-on\_de\-ta\-il} attributes), or the model
objects themselves (\emph{e.g.}, \texttt{Call} and
\texttt{Do\-cu\-me\-nt\-at\-io\-n} objects).
For example, in the QoS configuration case study, we show three
configuration variants with their commonalities and variabilities.  The
variabilities are further classified as structural and quantitative. For
example, \texttt{Config\_1} includes only the \texttt{Lane} attribute in
its structure while the others include even the
\texttt{Banded\_Conn\-ections}.  Although the attributes in the
quantitative variability dimension are same across the three
configurations, they vary in the values of these attributes.

\begin{table}[htb]
\vspace{-0.2in}
\centering
\bfcaption{SCV Analysis Results for QoS Configuration Case Study.}
\label{table:scv}
\scriptsize
\begin{tabulary}{\columnwidth}{|L|L|L|L|} \hline
   \multicolumn{1}{|c|}{\textbf{Commonalities}} 
 & \multicolumn{1}{c|}{\textbf{Family}} 
 & \multicolumn{2}{c|}{\textbf{Variabilities in Family Variant}} \\\cline{3-4}

 & \multicolumn{1}{|c|}{\textbf{Variant}} 
 & \multicolumn{1}{|c|}{\textbf{Structural}} 
 & \multicolumn{1}{|c|}{\textbf{Quantitative}} \\  
  \hline \hline  

  \multicolumn{4}{|c|}{} \\
  \multicolumn{4}{|c|}{\textbf{\emph{Insurance Enterprise Family}}} \\ \hline

   invitation\_info,
 & Cell phone, Office phone 
 & -- & invitation\_detail, meeting\_date,meeting\_time,
   user\_response,topic\_detail, claim\_id, customer\_name, customer\_id,
   claim\_date \\ \cline{2-4}

   topic\_info 
 & Pager & Call & -- \\ \cline{2-4}

 & Instant Messenger 
 & Documentation 
 & user\_response, suggest\_alternate, invitation\_detail,
   meeting\_date, meeting\_time, topic\_detail, claim\_id,
   customer\_name, customer\_id, claim\_date, amend\_invitation\\ \hline \hline  
  \multicolumn{4}{|c|}{} \\
  \multicolumn{4}{|c|}{\textbf{\emph{QoS Configuration Family}}} \\ \hline

   PriorityModelPolicy, EnvironmentConf,
 & Config\_1 
 & Lane 
 & allow\_borrowing, allow\_buffering, max\_buffd\_reqs.,
   max\_buff\_size, \\ \cline{2-4}
  
   stacksize 
 & Config\_2 
 & Lane, BandedConnections 
 & allow\_borrowing, allow\_buffering, max\_buffd\_reqs.,
   max\_buff\_size \\ \cline{2-4}   

 & Config\_3
 & Lane, BandedConnections 
 & allow\_borrowing, allow\_buffering, max\_buffd\_reqs.,
   max\_buff\_size (Note: values differ from that of Config\_1 and Config\_2) \\ \hline

\end{tabulary}
\vspace{-0.2in}
\end{table}
\fi
