% $Id: solution.tex,v 1.32 2005/12/07 20:52:00 kitty Exp $
\section{Applying Aspect-Oriented Model Weaving to PICML}
\label{sec:solution}

This section presents a solution to the crosscutting and scalability
challenges of modeling large-scale distributed systems
described in Section~\ref{sec:mot:challenges}.  Our approach to
resolving these challenges relies on the use of aspect-oriented model
weaving using C-SAW.  We first provide an overview of aspect-oriented
modeling and then describe our solution.

\subsection{Overview of Aspect-Oriented Modeling}
\label{sec:sol:aom}

A distinguishing feature of AOSD is the notion of crosscutting, which
characterizes the phenomenon whereby some representation of a concern is
scattered among multiple boundaries of modularity, and tangled amongst
numerous other concerns.  Aspect-Oriented Programming (AOP) languages, such
as AspectJ~\cite{gregor:01}, permit the separation of crosscutting concerns
into aspects.

We have found that the same crosscutting problems that arise in
code also exist in domain-specific models~\cite{Gray:01}.  For
example, it is often the case that the metamodel forces a
specific type of decomposition, such that the same concern is
repeatedly applied in many places, usually with slight variations
at different nodes in the model.  This is a consequence of the
``dominant decomposition''~\cite{Tarr:99}, which occurs when a
primary modularization strategy is selected that subjects other
concerns to be described in a non-localized manner.

% Jeff, Jane, Jing - please add a legend to this figure indicating
% what each of the shaded circle is about. The reviewer tried to
% understand what the model was about. But this figure is only
% illustrating crosscutting - andy
% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=0.75\linewidth,keepaspectratio]{crosscutting}
%   \caption{Modularizing Crosscutting Concerns in Domain-specific Models}
%   \label{fig:crosscutting}
% \end{figure}
Aspect-Oriented Modeling (AOM) is an AOSD extension applied to
earlier stages of the lifecycle.  Our specific perspective of AOM
improves the modeling task itself by providing the ability to
specify properties across a model during the system modeling
process.  This action is performed by using a weaver that has been
constructed for the GME modeling tool.
% JGG: The text below was originally commented out, but I suggest
% to keep it
We consider AOM to be much more than mere notations that provide
traceability to latter stages of development - a model weaver can
assist in the automation of the modeling process.

\subsection{Aspect Modeling with C-SAW}
\label{sec:sol:csaw}

% JGG: I think the text below is redundant when compared to the previous paragraph
% Our approach to AOM requires a domain-specific modeling weaver that
% processes the structured description of a visual model, which is different
% from traditional programming language weavers (e.g., the AspectJ
% weaver~\cite{gregor:01}) that support better modularization at a lower
% level of abstraction by processing source code.

We have designed C-SAW to provide support for modularizing
crosscutting modeling concerns in the GME.  This weaver operates on
the internal representation of a model (similar to an abstract syntax
tree of a compiler).  GME provides a framework
that allows DSML developers to register custom actions and hooks
with the environment.  These hooks can read and write the elements
of a model during the modeling stage.  GME also
provides an introspection API, which provides knowledge about the
types and instances of a model, without {\em a priori} knowledge
about the underlying DSML.  Utilizing this feature of GME, we have
implemented C-SAW as a ``plug-in,'' which is GME terminology for a DSML
independent hook.  Thus, the benefits of C-SAW are applicable
across a whole spectrum of DSMLs.

To be effective, C-SAW also requires the features of an enhanced model
transformation language.  Standard OCL is strictly a declarative language
for specifying assertions and properties of UML models.  Our need to extend
OCL is motivated by the fact that we require an imperative language for
describing the actual model transformations.  We designed a language called
the Embedded Constraint Language (ECL) to describe model transformations.
ECL is an extension of the OCL and provides many of the common features of
OCL, such as arithmetic operators, logical operators, and numerous
operators on collections (e.g., size, and select).  A unique feature of ECL
that is not provided within OCL, however, is a set of reflective operators
for querying models.  For example, aggregation operators (e.g., {\tt
  models(expression)} and {\tt atoms(expression)}) are used to select all
the models from a model container (and all the atoms from a model) that
satisfy the constraint specified by the expression.  These operators,
together with the {\tt select} operator, can be applied to first class
model objects (e.g., a container model or primitive model element) to
obtain reflective information needed to perform model weaving.  In
addition, ECL provides a set of transformation operators to change the
state of a model such as {\tt addModel, addAtom, removeModel, removeAtom}
and {\tt setAttribute}.  The operators can change the structure and
properties of a model.

The AOM approach that we have adopted in C-SAW can be summarized by the
diagram in Figure~\ref{fig:c-saw}.  As shown in this figure, model
transformations are performed between the source models and the target
models that belong to the same metamodel.  C-SAW weaves additive changes
into these source models to generate the target models relying on
transformation specifications written in ECL.

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.90\linewidth,keepaspectratio]{c-saw}
  \caption{C-SAW Aspect Model Weaver Framework}
  \label{fig:c-saw}
\end{figure}

\begin{itemlist}
\item {\bf Modeling Aspects:} A {\em modeling aspect} is a modular
  construct that specifies a crosscutting concern in a model hierarchy.  A
  modeling aspect describes the context of a strategy call (see the
  definition of strategy below), which can be a specific model, atom, or
  connection.  Like a pointcut designator in AspectJ~\cite{gregor:01}, a
  modeling aspect is responsible for identifying a set of model nodes
  across a model hierarchy in a modular way, and offers the capability to
  make quantifiable statements across the boundaries of a model.

  % Andy, this reference and a bunch of other references in related.tex
  % needs to be updated to use LaTeX. - kitty.
  % Kitty, which one is this? - andy
\item {\bf Strategies:} A {\em strategy} is used to specify transformation
  logic (e.g., constraint propagation, and the application of specific
  properties) to the model nodes\footnote{``model nodes'' refer to modeling
    elements that are defined in the metamodel, and serve as visualization
    elements in the domain model}.  Each metamodel will have unique
  strategies that can be applied to a model through C-SAW.  A strategy
  provides a hook that the weaver can call in order to process
  node-specific application and propagation.  Thus, strategies offer
  numerous ways for instrumenting nodes in a model with crosscutting
  concerns.  A strategy call in an aspect implements the binding and
  parameterization of the strategy to all the model nodes specified by the
  aspect.
\end{itemlist}

% Folks, please explain in more greater detail each of the listings
% below and how they apply to the UAV scenario
\subsection{Resolving UAV Crosscutting Modeling Challenges with C-SAW}
\label{sec:sol:appln}

% I am not sure we want to say orthogonal below - some reviewers might get
% confused and think it is already properly modularized and not in need of
% an aspect
% JGG: removed "orthogonal" below
As described in Section~\ref{sec:mot:challenges}, the modeling concern
related to application deployment has been decomposed into multiple views
along the dimension of the underlying CCM run-time.  However, this
modularization results in related concepts from the dimensions of
individual components and assemblies to be non-localized and split across
multiple entities.  This section describes how C-SAW is used to modularize
the concepts related to individual components and assemblies.  The approach
takes advantage of aspect-oriented model weaving to fill in the information
into the various artifacts that are necessary to deploy the UAV
application.

\begin{Aspect}
  \caption{\footnotesize{Deployment Modeling Aspect}}
  \label{aspect:deployment}
  \begin{Verbatim}[frame=none,fontsize=\relsize{-2}]
    1:  aspect Deploy()
    2:  {
    3:   // Create a folder called "ImplArtifacts"
    4:   implementationArtifactsFolder
    5:     := rootFolder().addFolder("ImplementationArtifacts", "ImplArtifacts");
    6:
    7:   // Create a folder called "Packages"
    8:   packagesFolder := rootFolder().addFolder("ComponentPackages", "Packages");
    9:
    10:  // Retrieve component assembly, and invoke strategy
    11:  rootFolder().findFolder("ComponentImplementations").models()
    12:    ->select(f | f.kindOf() == "ComponentImplementationContainer")
    13:      ->models()->select(p | p.kindOf() == "ComponentAssembly")
    14:        ->models()->select(c | c.kindOf() == "Component")
    15:          ->WeaveDeploymentArtifacts();
    16: }
  \end{Verbatim}
\end{Aspect}

The task of modularizing the concerns of deployment begins with defining a
modeling aspect in C-SAW.  Aspect Listing~\ref{aspect:deployment} shows a
snippet of the definition of the {\tt Deploy} aspect.  This modeling aspect
defines the tasks that a model engineer typically performs manually. It
enables creation of different folders, which will contain the different
orthogonal entities (e.g., implementation artifacts and component packages)
needed to deploy an application using CCM.  The initial creation of these
folders is similar to inter-type declarations in
AspectJ~\cite{gregor:01}. Specifically, lines 4 and 5 create a new {\tt
  ImplementationArtifacts} folder called {\tt ImplArtifacts} (note that the
first parameter of the {\tt addFolder()} function indicates the folder type
and the second parameter represents the name of the folder) under the root
folder of a UAV model. Similarly, line 8 creates a new {\tt
  ComponentPackages} folder named {\tt Packages}.  This aspect has been
extended to cover all the different activities that were discussed in
Section~\ref{sec:mot:challenges}.  Due to space constraints, we have not
shown all of the different entities that are created by this aspect.

After creating the required folders, the {\tt Deploy} aspect determines all
component assemblies, which contain the definitions of the component
interactions.  The component assemblies are discovered by the weave-time
introspection facilities that are provided by ECL.  As shown from line 11,
a component assembly can be retrieved from the top level {\tt
  ComponentImplementations} folder's {\tt ComponentImplementationContainer}
models.  For each component model in the component assembly, the {\tt
  WeaveDeploymentArtifacts} strategy is applied, as shown in Strategy
Listing~\ref{strat:weave}.  Thus, this strategy is applied across model
boundaries.

\begin{Strategy}
  \caption{\footnotesize{Weave Deployment Artifacts Strategy}}
  \label{strat:weave}
  \begin{Verbatim}[frame=none,fontsize=\relsize{-2}]
    1:  strategy WeaveDeploymentArtifacts()
    2:  {
    3:    ImplementationArtifacts();
    4:    PackageDefinition();
    5:  }
  \end{Verbatim}
\end{Strategy}

{\tt WeaveDeploymentArtifacts} aggregates the different strategies
that need to be applied to each individual component.  For
brevity, we illustrate just two such strategies~--- {\tt
  ImplementationArtifacts} (as shown in line 3) and {\tt
  PackageDefinition} (line 4) ~--- which are necessary to solve the
challenges described in Section~\ref{sec:mot:artifact} and
Section~\ref{sec:mot:package}.  Several other deployment strategies
have been created, but are not shown here in order to keep the
example concise.

\begin{Strategy}
  \caption{\footnotesize{Implementation Artifact Strategy}}
  \label{strat:implart}
  \begin{Verbatim}[frame=none,fontsize=\relsize{-2}]
    1:  strategy ImplementationArtifacts()
    2:  {
    3:    component := self;
    4:    componentName := component.getName();
    5:
    6:    // Create an instance of model ArtifactContainer
    7:    artContainer := rootFolder().findFolder("ImplArtifacts")
    8:      .addModel("ArtifactContainer", componentName);
    9:
    10:   // Create Foo_exec, Foo_stub and Foo_svnt
    11:   ia_exec := artContainer.addAtom("ImplementationArtifact", componentName + "_exec");
    12:   ia_stub := artContainer.addAtom("ImplementationArtifact", componentName + "_stub");
    13:   ia_svnt := artContainer.addAtom("ImplementationArtifact", componentName + "_svnt");
    14:
    15:   // Set the attribute "location" of Foo_exec, Foo_stub and Foo_svnt
    16:   ia_exec.setAttribute("location", componentName + "_exec");
    17:   ia_stub.setAttribute("location", componentName + "_stub");
    18:   ia_svnt.setAttribute("location", componentName + "_svnt");
    19:
    20:   // Create a reference to Foo_stub
    21:   ia_stubRef
    22:     := artContainer.addReference("ImplementationArtifactReference", ia_stub);
    23:
    24:   // Create a connection between Foo_svnt and Foo_stub reference
    25:   artContainer.addConnection("ArtifactDependsOn", ia_svnt, ia_stubRef);
    26:
    27:   // Create a connection between Foo_exe and Foo_stub reference
    28:   artContainer.addConnection("ArtifactDependsOn", ia_exec, ia_stubRef);
    29: }
  \end{Verbatim}
\end{Strategy}

The {\tt ImplementationArtifacts} strategy shown in Strategy
Listing~\ref{strat:implart} is responsible for creating the
different auxiliary shared libraries that are needed to implement
a single monolithic component.  Specifically, the strategy first
retrieves the component (line 3) and its name (line 4). It
then adds an ArtifactContainer model with the component name under
the {\tt ImplementationArtifacts} folder that was created
in the {\tt Deploy} aspect.  From line 11 to line 18, three
different component libraries are built within the
ArtifactContainer model as {\tt ImplementationArtifact} atoms by
extending the component name with different suffixes (i.e., {\tt
  \_exec}, {\tt \_stub} and {\tt \_svnt}).  Lines 21 and 22 create a
reference to {\tt \_stub}.  Finally, two dependencies are established
in line 25 and line 28 as connections between the library atoms.
It can be seen that this strategy modularizes:
\begin{itemlist}
\item Creation of all implementation artifacts mandated by the underlying
  run-time,
\item Creation of implementation artifacts that adhere to a specific
  naming convention,
\item Keeping track of dependencies between a single monolithic component
  and its associated implementation artifacts,
\item Setting attribute values (e.g., location and entry points) in shared
  libraries.
\end{itemlist}
By modularizing the different activities associated with defining
implementation artifacts and allowing for customizability based on
idiosyncrasies of specific run-time environments, C-SAW helps resolve the
challenge described in Section~\ref{sec:mot:artifact} by modularizing artifact
definitions for all available components.  This is a very time consuming and
error prone task if performed manually across multiple components.

\begin{Strategy}
  \caption{\footnotesize{Package Definition Strategy}}
  \label{strat:package}
  \begin{Verbatim}[frame=none,fontsize=\relsize{-2}]
    1:  strategy PackageDefinition()
    2:  {
    3:    component := self;
    4:    componentName := component.getName();
    5:
    6:    // Create an instance of model PackageContainer
    7:    pkgContainer := rootFolder().findFolder("Packages")
    8:      .addModel("PackageContainer", componentName);
    9:
    10:   // Create an instance of atom ComponentPackage
    11:   compPackage := pkgContainer.addAtom("ComponentPackage", componentName);
    12:
    13:   // Create a reference to the current component
    14:   componentRef := pkgContainer.addReference("ComponentRef", component);
    15:
    16:   // Create a connection between ComponentPackage and component reference
    17:   pkgContainer.addConnection("PackageInterface", compPackage, componentRef);
    18: }
  \end{Verbatim}
\end{Strategy}

The {\tt PackageDefinition} strategy shown in
Strategy~\ref{strat:package} is responsible for creating a
package and associating a component assembly with the component
package.  Line 11 creates a component package as an atom within
the package container that was constructed in line 7.  Line 17
builds an association connection between this component package
and the component reference that was created in line 14.  Similar
strategies were defined to solve the challenges outlined in
Section~\ref{sec:mot:idl}, Section~\ref{sec:mot:interact} and
Section~\ref{sec:mot:domain}.  By combining specification
aspects and strategies, C-SAW enhances the utility of a DSML like
PICML, and resolves the challenges associated with a pure
MDD-based approach to improve development of component-based
distributed systems.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "IJSEKE05"
%%% End:
