% $Id: motivation.tex,v 1.37 2006/04/29 19:21:18 gokhale Exp $
\section{Evaluating Model-driven Development Approaches to Developing
  Component-based Systems}
\label{sec:motivation}

MDD provides numerous benefits over programmatic approaches to large-scale
component-based distributed systems development~\cite{Schmidt:03n}.
However, MDD also incurs challenges due to scalability and crosscutting
concerns, similar to the challenges seen in programmatic approaches.
Hence, it is imperative to enhance MDD to address these challenges.

To illustrate the crosscutting and scalability challenges in MDD for
component-based distributed systems, we first present a brief overview of
MDD approaches highlighting a DSML we have developed for component-based
distributed systems.  We then use a component-based distributed system case
study to illustrate how the crosscutting challenges manifest themselves in
MDD.  Our case study is an emergency response system that uses multiple
unmanned air vehicles (UAVs) to perform aerial imaging, survivor tracking
and damage assessment.  Using the UAV scenario, we then highlight the
scalability challenges and crosscutting concerns a model engineer faces
when building a system like the emergency response system.

\subsection{Overview of Model-driven Development of Component-based
  Systems}
\label{sec:mot:overview}

MDD is a paradigm that focuses on using models to describe many system
development activities (i.e., models provide input and output at all stages
of system development until the final system itself is generated).  In MDD,
models are used to describe all artifacts of the system (e.g., interfaces,
interactions, and properties of all the components that comprise the
system).  These models can be manipulated in a number of different ways to
analyze the system, and in some cases to generate the complete
implementation of the system.  In order to capture the semantics in an
effective manner that is as close as possible to the domain of the
developed system, a DSML can be used. A DSML is a
five-tuple~\cite{Janos:03} consisting of:

\begin{itemlist}
\item {\bf Concrete syntax (C)}, which defines the notation used to
  express domain entities,
\item {\bf Abstract syntax (A)}, which defines the concepts,
  relationships and integrity constraints available in the
  language,
\item {\bf Semantic Domain (S)}, which defines the formalism used to
  map the semantics of the models to a particular domain,
\item {\bf Syntactic mapping (M$_{C}$: A$\rightarrow$C)}, which
  assigns syntactic constructs (e.g., graphical and/\-or
  textual) to elements of the abstract syntax,
\item {\bf Semantic mapping (M$_{S}$: A$\rightarrow$S)}, which relates
  the syntactic concepts to those of the semantic domain.
\end{itemlist}

Crucial to the success of DSMLs is {\em metamodeling} and {\em
auto-generation}.  A {\em metamodel} defines the elements of a DSML
that are tailored to a particular domain, such as the domain of
avionics mission computing or emergency response systems.
Auto-generation involves automatically synthesizing artifacts from
models, thereby relieving DSML users from the accidental complexities of the
artifacts themselves, including their format, syntax, or semantics.
Examples of such artifacts include (but are not limited to) code in
some programming language, and descriptors (in formats such as XML)
that can serve as input to other tools.

To support effective design and development of component-based
systems, we have defined the {\em Platform-Independent Component
Modeling Language} (PICML)~\cite{Schmidt:04z,Schmidt:05w,Schmidt:05cc}
using the {\em Generic Modeling Environment} (GME)~\cite{GME:01}.  GME
is a meta-programmable modeling environment with a general-purpose
editing engine, separate view-controller GUI, and a configurable
persistence engine.  Because GME is meta-programmable, the same
environment used to define PICML is also used to build models, which
are instances of the PICML metamodel.

At the core of PICML is a DSML (defined as a metamodel using GME) for
describing components, types of allowed interconnections between
components, and types of component metadata for deployment.  The PICML
metamodel defines the different types of modeling elements that are
essential to developing, composing, configuring and deploying
component-based systems.  The artifacts pertaining to configuration and
deployment of component-based systems that are generated from PICML are
then deployed using the Component-Integrated ACE ORB
(CIAO)~\cite{Schmidt:03m,Schmidt:04w}, which is an implementation of the
CCM.\footnote{PICML is currently being enhanced to model systems using
  other standards-based component middleware, such as J2EE and .NET, in
  addition to CCM.}

In terms of the five-tuple defined above, PICML uses bitmap-based icons
representing elements of the platform (e.g., CCM) as the concrete syntax.
For elements like components, PICML also uses enhanced visualizations
called ``decorators,'' which display the different ports of a component and
allow connections to be made between ports of different components.  The
abstract syntax of PICML is defined using a variant of UML class diagrams
available in GME.  In addition to the class diagrams, OMG's Object
Constraint Language (OCL) is used to enforce the semantics that are not
captured by the class diagrams.  The semantic domain of PICML is the CCM
platform.  Thus, the semantics of the different elements are governed by
the CCM specification, which defines the elements as well as valid
interactions between the different elements that make up a system built
using CCM.  The syntactic mapping between the different elements in the
abstract syntax to the elements in the concrete syntax is achieved by
associating each element in the metamodel with icons, or with a decorator
(in case of special elements like components and assemblies).  The semantic
mapping associating the elements in the metamodel with elements in the CCM
platform is performed partly using the OCL constraints, and partly using
the various model interpreters defined in PICML.  A {\em model interpreter}
is a GME plug-in written using a high-level language like C++, and can be
used to enforce the semantics not captured by OCL constraints alone.
Interpreters for PICML are also used to generate various artifacts like
component configuration files and deployment plans, which are needed for
the deployment of CCM components.

The PICML metamodel defines approximately 115 different types of basic
elements, with 57 different types of associations between these elements
grouped under 14 different folders.  The PICML metamodel also defines 222
constraints that are enforced by GME's constraint manager during the design
process.  Using GME tools, the PICML metamodel can be compiled into a {\em
  modeling paradigm}, which defines a domain-specific modeling environment.
From this metamodel, approximately 20,000 lines of C$++$ code (used to
represent the modeling language elements as equivalent C$++$ types) is
generated.  This generated code allows manipulation of modeling elements
(i.e., instances of the language types using C$++$) and forms the basis for
writing model interpreters.  Each interpreter is written as a DLL that is
loaded at run-time into GME and executed to generate the XML descriptors
based on models developed by the component developers using PICML.  PICML
currently has 8 interpreters using 222 generated C$++$ classes and
approximately 8,000 lines of hand-written C$++$ code to generate the
following descriptors needed to support the OMG Deployment and
Configuration (D\&C) specification~\cite{DandC:03}:

\begin{itemlist}
\item {\bf Component Interface Descriptor (.ccd)} -- Describes the
      interfaces -- ports, attributes of a single component.
\item {\bf Implementation Artifact Descriptor (.iad)} -- Describes the
      implementation artifacts (e.g., DLLs, executables) of a single
      component.
\item {\bf Component Implementation Descriptor (.cid)} -- Describes a
      specific implementation of a component interface; also contains
      component inter-connection information.
\item {\bf Component Package Descriptor (.cpd)} -- Describes multiple
      alternative implementations (e.g., for different OSes) of a single
      component.
\item {\bf Package Configuration Descriptor (.pcd)} -- Describes a
      component package configured for a particular requirement.
\item {\bf Component Deployment Plan (.cdp)} -- Plan which guides the
      run-time deployment.
\item {\bf Component Domain Descriptor (.cdd)} -- Describes the deployment
      target (e.g., nodes, networks) on which the components are to be
      deployed.
\end{itemlist}

\subsection{A Representative Case Study using PICML}
\label{sec:mot:application}

This section presents an emergency response system as the guiding example
to illustrate the MDD approach, and to illustrate the challenges that arise
in modeling distributed component systems.  This example models emergency
response situations (such as disaster recovery efforts stemming from
floods, earthquakes, or hurricanes) and consists of a number of interacting
subsystems.  Our focus in this paper is on the composition, integration and
deployment of a UAV, which is used to monitor terrain for flood damage,
spot survivors that need to be rescued, and assess the extent of damage.
The UAV transmits this imagery to various other emergency response units.
The software components of this UAV application are shown in
Figure~\ref{fig:uav} and described in detail in~\cite{Schmidt:04z}.

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.95\linewidth,keepaspectratio]{single_stream}
  \caption{Emergency Response System components }
  \label{fig:uav}
\end{figure}

The UAV application involves sending streams of images from each UAV to a
control center responsible for monitoring the image data.  Each image
stream is composed of a {\tt Sender} (e.g., the UAV), a number of {\tt
  Qosket} components, and a {\tt Receiver} component.  {\tt Sender}
components are responsible for collecting the images from each image sensor
on the UAV.  The {\tt Sender} passes the images to a series of {\tt
  Qosket}~\cite{Schmidt:03m} components.  Qoskets are software components
that encapsulate a set of contracts, a set of system condition objects and
performance adaptation behavior logic.  Thus, Qoskets perform adaptations
on the images to ensure that the images can be transmitted without
violating the quality of service (QoS) requirements.  Examples of Qosket
components include {\tt CompressQosket}, {\tt ScaleQosket}, {\tt
  CropQosket}, {\tt PaceQosket}, and a {\tt DiffServQosket}.  The final
{\tt Qosket} in the pipeline then passes the images to a {\tt Receiver}
component, which collects the images and passes them on to a display in the
control room of the emergency response team.

% Kitty, others - I made this title more generic - andy
\subsection{Scalability and Crosscutting Challenges in Applying MDD to
  Component-based Distributed Systems}
\label{sec:mot:challenges}

This section describes how DSMLs (e.g., PICML) applied to
component-based distributed systems (e.g., a UAV) incur different
scalability challenges and crosscutting concerns.  We illustrate these
challenges as they are manifested in each of the modeling stages
of systems development described below.
% Kitty, others - I tried to make a point here that although we
% describe this for PICML it
Although the description illustrates these challenges as they
emerge in PICML, we believe similar challenges will exist in any
DSML used to develop large-scale component-based distributed systems.

% Kitty, after reading these subsections carefully again and when
% looked at from the reviewer's perspective, I get a feeling that we
% have not made is very crystal clear how each challenge manifests
% itself. Moreover, what is missing here is how each subsection ties
% back to the UAV example. So please tie the figure in each subsection
% and description back to UAV example.
% An additonal thing we need to do very carefully is to showcase both
% scalability and crosscutting. Plus we need to explicitly say which
% is crosscutting and which is scalability - Andy
%
% I have marked potential places in the subsections where we can tie
% things back - Andy
%\vspace{-.2in}
\subsubsection{Crosscutting Concerns in Modeling Interface Definitions}
\label{sec:mot:idl}

PICML assists in modeling the individual component types of a system,
which involves either importing the component interface definitions
from existing interface definition language (IDL) files, or explicitly
modeling them using PICML.  In our example, this involves defining the
interfaces for the {\tt Sender}, {\tt Receiver}, {\tt Qosket},
{\tt SystemResourceManager}, and the {\tt LocalResourceManager}
components.

In order to deploy a system using component middleware, such as CIAO, the
individual components that together realize the application must be
specified.  This step is very crucial because the type (indicated by its
name, such as {\tt LocalResourceManagerComponent}) of the individual
monolithic components is defined at this stage.  The interface of the
system with external entities is also defined during this stage.

% Folks, I split the figure into separate as opposed to side-by-side -
% Andy
% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=0.9\linewidth]{interface}
%   \caption{Interface Definition}
%   \label{fig:interface}
% \end{figure}

% Kitty, I added this line. Please see if it is correct. Moreover, we
% need to highlight things everywhere in these subsections - andy
% Andy, I have removed the sentence about variability since it is
% confusing. - kitty.
These definitions (including the names) serve as a bridge between the
entities defined at the modeling level and the corresponding
implementation.  Such component definitions are scattered throughout the
system model through the use of references to the individual component
types.  For example, the component instances that are used to define the
component interactions are instances of the individual component types.
% Kitty, here make a connection back to UAV example. Our goal needs to
% be to somehow tell the reader that here is an example of the
% challenge but that these challenges will occur generically - Andy
% Andy, done. - kitty.
Thus, it is the model engineer's responsibility to maintain the one-to-many
relationship between the component types and the different instances of the
same type that are scattered across the models.  If a component type is
modified/\-deleted, then the model engineer has to manually update/\-remove all
the references scattered in the remaining model.  This is an inherently
time-consuming and error-prone task when performed manually, and does not
scale when the number of components in the model increase.  For example,
addition of new ports to a component type that is part of a stream in the
UAV scenario results in a need to modify all the existing uses of that
component type throughout the model.
% Kitty, scalability arises when? i.e., when number of component
% definitions increase? If so, let us say so - Andy
% Andy, I have added an explicit sentence to this effect. - kitty.

\subsubsection{Modeling Implementation Artifact Definitions}
\label{sec:mot:artifact}

In this stage, a model engineer defines the implementation artifacts shown in
Figure~\ref{fig:implementation} for each monolithic component, which
involves defining the different implementation artifacts (e.g., shared
libraries) that each component depends on, as well as describing the
dependencies that each component may have on external system libraries.

% Folks, I split the figure into separate as opposed to side-by-side -
% Andy
\begin{figure}[htb]
  \centering
  \includegraphics[width=0.9\linewidth]{implementation}
  \caption{Implementation Artifact Definition}
  \label{fig:implementation}
\end{figure}

% Kitty, OK - here you do a good job. We need something like this for
% every challenge - Andy
For example, when building the UAV application using CIAO, a monolithic
component, such as {\tt SystemResourceManager}, is composed of three libraries,
(1) {\tt SystemResourceManager\_exec}, which contains the implementation of
the component functionality, (2) {\tt SystemResourceManager\_stub}, which
contains code that provides the marshaling and de-marshaling related
functionality for each component, and (3) {\tt
  SystemResourceManager\_svnt}, which contains the code to glue together
the component with other portions of the execution environment, such as the
underlying CORBA middleware infrastructure.  Any error in capturing
the dependencies will result in run-time failure of the components.
Although the number, names and kinds of implementation artifacts might
differ across different middleware implementations, each component in a
distributed system will end up having dependencies on the artifacts that
are necessary to provide the functionality of the component.  Thus, these
artifacts need to be modeled explicitly, an activity that does not scale
well as the number of components and their corresponding implementation
artifacts increase.
% Kitty, the above sounded a bit confusing. Moreover, is this a
% shortcoming of PICML or MDD for component systems in general. I
% added a qualifier as to when scalability will be an issue  - Andy
% Andy, the sentence looks fine. - kitty.
Moreover, the model engineer is also responsible for maintaining the
dependencies as the system evolves.  Any error in the
maintenance of the dependency will also result in a run-time error due to
unresolved dependencies on implementation artifacts of component instances.
% Kitty, make sure my sentence above telling what is the crosscutting
% challenge here is correct. We need such highlighting everywhere - Andy
% Andy, I have reworded the sentence. - kitty.

Another example of a concern associated with an implementation is the need
to follow specific naming conventions as imposed by the underlying
middleware, wherein the naming of implementation artifacts in the model
must mirror the naming conventions of the underlying component middleware
infrastructure.  For example, in the default configuration of CIAO, if the
three dependent libraries for {\tt SystemResourceManager} are not named
{\tt SystemResourceManager\_exec}, {\tt SystemResourceManager\_stub}, and
{\tt SystemResourceManager\_svnt} respectively, it will result in a
run-time error.  Another example from .NET related to naming is with the
manifest files associated with an assembly.  Each assembly in .NET
(equivalent to a component in CCM) is associated with a manifest file.  A
manifest file is an XML file that can be used to configure the behavior of
the assembly.  Before the .NET run-time loads an assembly, it searches for
any manifest files associated with the assembly.  This search is designed
to look for manifest files that follow a specific naming convention, and
only in specific directories:  For each assembly implemented as a shared
library, say Foo.dll, the .NET run-time searches for a manifest file named
Foo.dll.manifest; for each assembly implemented as an executable, say
Foo.exe, the .NET run-time searches for a manifest file named
Foo.exe.manifest.  If the manifest files are given different names, the
.NET run-time does not load the manifest, which might result in a different
behavior for the assembly Foo.
% Kitty, please comment on the generality of such a concern. It looks to me
% this is very much PICML-specific - andy
% Andy, I have added an example from .NET, and also rephrased the following
% paragraph. - kitty.

Yet another naming related crosscutting concern is with the specification
of the entry point for loading a component implemented as a shared library
in a language like C$++$.  Because the C$++$ compiler mangles the names of
the methods in classes, method names that need to be exported are marked
using special {\tt extern "C"} tags.  Only names that are marked using
these tags are available for invocation by clients that dynamically load
these components.  In order to ensure that a component can be dynamically
loaded, the model engineer must make sure that the definitions of the entry
points defined in the implementation artifacts of a component actually map
to entry points defined in the shared libraries.

\subsubsection{Modeling Interaction Definitions}
\label{sec:mot:interact}

In this stage of development, a model engineer defines the different
interactions between components, which involves composing the application
from a set of individual components.  The components are connected using
their ports to form assemblies, which could be nested.  In PICML,
assemblies contain monolithic components that are connected together.
Assemblies can also be hierarchical (i.e., an assembly can contain other
assembly components).  In our example, each stream of images is modeled as
an assembly by connecting the {\tt Sender}, {\tt LocalResourceManager},
{\tt Qoskets}, and the {\tt Receiver}, as shown in
Figure~\ref{fig:interaction}.  This assembly is then instantiated multiple
times depending on the number of UAVs, along with the {\tt
  SystemResourceManager}, and the {\tt ControlCenterDisplay}, to form the
complete UAV application.

\begin{figure}[htb]
    \centering
    \includegraphics[width=0.9\linewidth]{interaction}
    \caption{Interaction Definition}
    \label{fig:interaction}
\end{figure}

% Kitty, I am unable to figure out what the challenge is here w.r.t to
% scalability and tangling. Is it the need to instantiate the same
% number of times as the number of UAVs the crosscutting concern - andy
% Kitty, ok but didn't we describe these dependencies in the previous
% subsection - andy
% Kitty, please tie this to the UAV example by giving an example on
% what needs to be done if such as such change is to be made in the
% UAV model - andy
% Andy, I have addressed all these crosscutting and tangled comments - kitty.
There are several cases when much effort is required to manually add (or
remove) new links between components:
\begin{arabiclist}
\item If a component is removed from an application,
\item If a new port is to be connected to all external uses of a component,
\item Or, if a component is replaced by another component.
\end{arabiclist}
In cases where the number of components is large, the amount of effort
required to perform these modifications manually is equivalent to starting
the modeling effort from scratch.  In the UAV example, the addition of a
new management interface to all the {\tt Qosket} components will result in
extensive changes to every assembly that models a stream.  The amount of
effort grows exponentially because a single assembly is instantiated
multiple times, depending upon the number of UAVs that are desired.  Even
if the required changes are performed manually, it is necessary to ensure
that the changes are correct by checking the constraints in the model.  In
case there are violations, the correction of the constraint violation also
needs to be done manually.  Thus, changes to the interactions between
components necessitate similar changes at multiple locations - scattered
across the whole model - in a repetitive fashion.

\subsubsection{Modeling Package Definitions}
\label{sec:mot:package}

The packaging of component assemblies involves defining the relation
between units of deployment called {\em packages}, and the individual
assemblies that are the output of the composition process defined earlier.
A package is associated with a top-level assembly, and is used to bootstrap
the deployment of the application.  For example, in the UAV application,
the top-level assembly that contains many individual streams as
sub-assemblies needs to be associated with a package so that the UAV
application can be deployed.  Packages are the units of deployment in CCM.
It is also true for other middleware technologies like EJB (e.g., EJB uses
an .ear file to initiate deployment).  In order for a deployment tool to be
successful in deploying an application, each package needs to be associated
with metadata that describes the capabilities of each package.  Examples of
such metadata include the interfaces that are implemented by the
component(s) that are contained in a package, dependencies on the run-time
environment by components in a package, and any startup ordering
dependencies on external components.

% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=0.9\linewidth]{package}
%   \caption{Package Definition}
%   \label{fig:package}
% \end{figure}

Thus, it is necessary to maintain the consistency of a package during system
evolution.  For example, any change in the interface definition needs to
result in an appropriate change in the packages containing components
that implement that interface.  Any change in the dependent implementation
artifacts of a component implementation also requires that the
corresponding component package be updated with these artifacts.  For
example, in the UAV application, any change to the composition of a stream
by addition or removal of a {\tt Qosket} component necessitates
appropriate changes to be made to the component packages.  The need to
ensure that changes to some elements are propagated to a dependent element
indicates the emergence of another crosscutting concern.
% Kitty, OK, I see this but again tell this how it manifests for UAV.
% Andy, I have added sentences to this effect. - kitty.

\subsubsection{Modeling the Domain Definition and Component Mapping}
\label{sec:mot:domain}

Domain definition involves modeling the elements of the target domain and a
mapping between component instances and the target domain.  This task is
usually done by a domain administrator who has knowledge of the physical
infrastructure on which the application is to be deployed.  After the
elements of the target domain are defined, a mapping between the individual
component instances and assemblies onto elements of the target domain
is specified.  This activity results in the creation of a deployment plan,
which is used by the run-time infrastructure to deploy the
application.

In order to ensure successful deployment of the application, the mapping
between the component instances (or assemblies) and nodes of the target
domain needs to be consistent.  Although constraints can help in matching
the capabilities of each node with the requirements of the individual
components, all the components (or assemblies) need to be assigned to
nodes, and this assignment needs to be updated when the definitions of the
component assemblies change.  Any error in this process shows up only at
run-time, which is very late in the lifecycle and proves to be very
expensive to correct.  For example, in the UAV example, if a new type of
Qosket (e.g., {\tt DiffServQosket}, which assists in enforcing network
priorities) is added to each stream, it is necessary to ensure that the
{\tt DiffServQosket} is mapped to a UAV.  Without the {\tt DiffServQosket},
a UAV will not be able to perform QoS adaptations based on network
priorities, and images that are critical to a mission might show up in the
control center after images that are peripheral. This would potentially
undermine the importance of the images sent by the UAV.
% Kitty, please tie it back to UAV example. -andy
% Andy, done. - kitty.

The use of MDD to develop systems like the UAV application provides a
significant improvement over programmatic approaches based on using only
component middleware.  However, as outlined in the UAV context, a number of
tangled concerns and scalability issues emerge in the modeling of
component-based distributed systems.  The concept of a component pervades
these artifacts, and the challenges that occur are due to the tangling of
the concerns associated with a component at multiple places in the model.
If left unresolved, these challenges can hamper developer productivity, and
also negatively affect the correctness of the system being modeled.
Section~\ref{sec:solution} describes our solution to these problems.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "IJSEKE05"
%%% End:
