% $Id: scenario.tex 14757 2008-10-10 15:02:59Z amoghk $

\section{Highlighting the Need for Reusable Model Transformations}
\label{sec:reuse}
\sqzsmall
In this section we briefly discuss representative model
transformation case studies taken from two diverse problem domains.
Our goal is to highlight how two entirely different examples pose
similar challenges for model transformation processes irrespective of
whether the transformation is endogeneous or
exogeneous~\cite{Karsai:05}.  To that end we illustrate the
commonalities and variabilities in these diverse scenarios that their
respective transformation processes must account for.  

\subsection{Representative Motivational Case Studies}
\label{sec:motiv}

\subsubsection{Communication Dialog Creation for an Insurance Enterprise}
\label{sec:dialogs}
%\sqzsmall
Our first case study deals with the 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 (\emph{i.e.}, 
employees) in an enterprise, and publish (collect) important information
to (from) these decision makers.  Since the employees in an enterprise
may potentially be using several endpoints (\emph{i.e.}, devices), an
important consideration in delivering information content from the
workflows to the employees is the customization of communication dialogs
for individual endpoints, which is accomplished using model
transformations. 

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.55\columnwidth,keepaspectratio]{dialoguml}
  \bfcaption{A UML Representation of a Generic Communication
    Dialog.}   
  \label{fig:dialoguml}
  \vspace{-0.2in}
\end{figure}
Figure~\ref{fig:dialoguml} shows the communication dialog metamodel
used in our case study, which serves as both the source and target
metamodel for the transformation process used to customize the dialog 
thereby making it an endogeneous transformation.
\iffalse
% % Amogh, I am commenting out too many details
% %
% % Yes, I hope reader can get the details as we explain them in solution
% % section. 
% % Based on our MODELS reviews, it does not appear that people were left
% % wondering. So we are ok - Andy
% 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 the references relevant to the claim
% in question, (3) \texttt{To\-pi\-c} specifies details about the claim, 
% (4) \texttt{In\-vi\-ta\-ti\-on} contains information 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.
% In addition to simple {\sc yes} and {\sc no}, the \texttt{Re\-sp\-on\-se} element allows an employee 
% to suggest an alternate employee that can be contacted about the claim
% in question.  %This can be achieved by setting
% %\texttt{us\-er\_re\-sp\-on\-se} to %\textsc{false} and populating the
% %\texttt{su\-gg\-es\-t\_al\-te\-rn\-at\-e} 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{am\-en\-d\_in\-vi\-ta\-ti\-on} enumerated data type.
\fi
The model transformation process is concerned with
generating a dialog tailored to the properties of the communication end
point.  
% The transformation process is endogenous~\cite{Karsai:05} in 
% that both the source and target model elements belong to the same dialog
% metamodel.  
The transformation process must account for the following
commonalities and variabilities: (1) the dialogs for all the endpoints
contain, at the very least, the \texttt{topic\_info}, and \texttt{info}
(in  \texttt{In\-vi\-ta\-ti\-on\_br\-ie\-f} element) 
attributes; (2) the \texttt{Call}, \texttt{Documentation}, and
\texttt{Re\-sp\-on\-se} model objects may be present in some but not all
endpoints; and (3) the response to a communication dialog may be
\textsc{yes}, \textsc{no}, or may contain advanced options such as
\texttt{suggest\_alternate} or \texttt{amend\_invitation}. 

% \begin{figure}[htb]\centering
% \vspace{-0.4in}
% \subfloat[Generic communication dialog]
% { \includegraphics[width=0.5\textwidth,keepaspectratio]{dialoguml}
%   \label{fig:dialoguml} \vspace{-0.2in}
% }
% \subfloat[Middleware QoS configuration]
% {
%   \includegraphics[width=0.5\textwidth,keepaspectratio]{configurationuml}
%   \label{fig:configuml}\vspace{-0.2in}
% }
% \vspace{-0.1in}
% \bfcaption{Simplified metamodels for representative use cases.}
% \vspace{-0.2in}
% \end{figure}
\sqzsmall
\subsection{Middleware QoS Configuration for Component-based Applications}
\label{sec:qos}
\sqztiny
Our second case study requires an exogenous transformation which 
translates component-based application QoS requirements into the
underlying middleware platform-specific QoS configuration options.
Figure~\ref{fig:configuml} shows the UML representation of both the
source and the target metamodels used in the QoS configuration case
study.  As shown, the source 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 models the real-time
CORBA~\cite{RTCORBA:05} middleware configurations.
\iffalse
% and 
% 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 static thread (\emph{i.e.},
% those that remain active till the system is running) and dynamic
% thread (\emph{i.e.}, those threads that are created and destroyed as required)
% numbers using \texttt{Lane} element; (2) \texttt{ThreadPool}, which
% controls different 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; and (4)
% \texttt{Ba\-nde\-dCon\-nect\-io\-ns}, which defines separate
% connections for individual (client) service invocations. 
\fi

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.55\columnwidth,keepaspectratio]{configurationuml}
  \bfcaption{A UML Representation of Middleware QoS Configuration Metamodels.}   
  \label{fig:configuml} 
  \vspace{-0.3in}
\end{figure}
Transformations for middleware QoS configuration are applicable across a
number of application domains.  The individual configurations generated 
using the model transformation should be easily customizable for slight
variations in these domains.  Thus, the case study has the following
requirements for the generated middleware QoS configurations: (1) the
\texttt{Pr\-io\-ri\-ty\-Mo\-de\-lP\-ol\-ic\-y} object along with its
attributes are transformed from
\texttt{fi\-xed\_pr\-io\-ri\-ty\_se\-rv\-ic\-e\_ex\-ec\-ut\-ion} 
source attribute; (2) \texttt{Lane} object and its attributes are
transformed from \texttt{mu\-lt\-i\_se\-rv\-ic\-e\_le\-ve\-ls} source
attribute.  The \texttt{Lane} object cardinality and the exact values of
its attributes, however, can change; and (3) the cardinality of
\texttt{Ba\-nde\-dCon\-nect\-io\-ns}, the values of all the attributes
of \texttt{ThreadPool} except \texttt{stacksize} are assigned
statically, however, they may vary for different application domains. 

\iffalse
In the next section, we show how our approach can be applied in the context
of these two case studies. We also show how the requirements listed above are 
satisfied using our approach. 
\fi
