%% $Id: approach.tex,v 1.53 2004/12/31 19:36:59 schmidt Exp $

\section{Approaches to Integrating MDD Tools for DRE Systems}
\label{approach}

Due to the magnitude and complexity of the DRE problem space, no
single MDD toolsuite yet provides solutions to all challenges of
large-scale DRE system development.  For example, CoSMIC did not
initially provide tools for analyzing and validating the functional
correctness and QoS properties of DRE systems.  Likewise, Cadena did
not initially provide capabilities for modeling elements and
procedures meaningful for important stages of the development of DRE
systems, such as installation, packaging, and deployment.  What we
therefore required was an {\em integrated} MDD toolsuite that
developers of DRE systems could use to compose, configure, and deploy
their applications end-to-end to help (1) identify bugs early in the
lifecycle, (2) reduce total development costs, (3) decrease time to
market, and (4) increase the reliability of DRE systems.

Integrating CoSMIC and Cadena required that (1) software components
and associated modeling artifacts could be manipulated via any of
their MDD tools, (2) changes to the components and modeling artifacts
made by one tool could be reflected in other tools, where applicable,
(3) any tool capturing unique information ({\em i.e.}, not captured by
any other tool) required special support to preserve this information
correctly, and (4) all the pieces of information captured by each
integrated MDD tool could be treated as parts of a single {\em global
project}.  Achieving this level of integration was hard since
different MDD tools captured different sets of properties.  For
example, certain CoSMIC tools captured certain parts of a project,
whereas other parts are captured by certain Cadena tools.\footnote{The
subset of the project captured by one tool is referred as the tool's
{\em model document}.}

The remainder of this section describes key challenges that arose when
integrating CoSMIC and Cadena and discusses our solutions to resolve
these challenges.  These challenges are discussed in order of
increasing complexity, where a subsequent challenge could be resolved
only when the previous challenge was addressed.
Section~\ref{casestudy} then presents a case study of a robot assembly
application that illustrates our experiences applying the integrated
CoSMIC and Cadena toolsuites to a representative DRE system.

\subsection*{Challenge 1: Identifying an Inter-tool Communication Model} 
\sqztiny
\subparagraph{Context.}
Different MDD tools provide different capabilities, {\em e.g.},
browsable models and visual modeling of deploy requirements
vs. rate-monotonic schedulability analysis and model-checking.
Large-scale DRE systems, however, may require the use of multiple MDD
tools.  What is needed is a communication model for interoperability
among various MDD tools.  An important goal of our work was therefore
to transfer model documents back and forth between CoSMIC and Cadena,
while minimizing user intervention.

\sqztiny
\subparagraph{Problems.}
Since Cosmic and Cadena were developed independently for several years
they had little/nothing in common with respect to the type of model
documents they used.  Moreover, under many aspects these tools do not
even capture the same type of information, {\em e.g.}, the {\tt
*.scenario} and {\tt *.IDL3} model documents of Cadena appear to have
equivalent representation in CoSMIC, but there are subtle differences
between the model documents.  Likewise, the {\tt *.profile}, {\tt
*.cor} and {\tt *.cps} model documents have no equivalent in CoSMIC.
Similarly, 80\% of the information in the CoSMIC model documents have
no direct equivalent in Cadena.

Many standard interoperability solutions available for tool
interoperability cater to a specific concern.  For example, the {\em
Analysis Interchange Format} (AIF)~\cite{Karsai:02a} provides
interoperability by promoting seamless exchange of only analysis data
among tools. Similarly, the {\em Hybrid Systems Interchange Format}
(HSIF)~\cite{MoBIES} provides model exchanges for those systems that
are modeled as hybrid systems, but does not support exchanging
analysis information.  In many cases, therefore, an interchange format
might not support a feature of a tool.  Hence, a decision to use such
an interchange format would preclude the use of that feature, thereby
decreasing the value of the tool.  It is also undesirable to create
point-to-point solutions since they do not scale as the number of
tools with different capabilities increases.  It is therefore
necessary to develop a framework that allows seamless interoperability
between desired features among tools without creating point-to-point
solutions.
 
\sqztiny
\subparagraph{Solution approach $\rightarrow$ An open tool integration
framework.}  Our approach for integrating CoSMIC and Cadena is based
on the {\em Open Tool Integration Framework} (OTIF)~\cite{OTIF}
\index{OTIF} developed by the Institute for Software Integrated
Systems (ISIS) at Vanderbilt University.  OTIF consists of a
backplane, an integration repository, application-specific tool
adapters, and semantic translators.  The backplane provides a
communication and subscription/\-notification mechanism for other
tools.  The backplane also acts as a common integration repository for
the data stored in a canonical syntactical format, but which may have
different semantics.  OTIF's tool integration repository stores data
in a format understood by at least one of the communicating tools.
Custom semantic translators and tool adaptors can then be plugged into
the OTIF backplane and used to (1) automatically convert data in a
format understood by one tool into of data for another tool and (2)
communicate between the tools.

A novel aspect of OTIF is its ability to integrate MDD tools that were
not initially intended to interoperate, which is why we selected it
for our CoSMIC$\leftrightarrow$Cadena integration.
Figure~\ref{fig:cosmic_cadena} illustrates the interworking of CoSMIC
and Cadena via the OTIF backplane.
\begin{figure}[htb]
\vspace{-0.2in}
\center{\includegraphics[width=3.5in]{eps/cosmic_cadena_otif_v2.eps}}
\vspace{0in}
\bfcaption{CoSMIC$\leftrightarrow$Cadena Interoperability via OTIF}
\label{fig:cosmic_cadena}
\vspace{0.1in}
\end{figure}
The OTIF backplane supports standard CORBA~\cite{CORBA:02d}
communication capabilities using TAO~\cite{Schmidt:97q}, thereby
allowing distributed interoperability, as well as platform-independent
interoperability.  Custom tool-specific adapters must be written by
developers who wish to export desired tool-specific data to the
backplane.  Other tools that want to interoperate with this tool must
provide an adapter that converts data on the backplane to the format
it desires.  We have developed appropriate tool adapters for CoSMIC
and Cadena, along with semantic translators that help these two
toolsuites interoperate via the OTIF backplane.

\subsection*{Challenge 2: Devising Effective Communication Protocols
and Data Interchange Formats} 
\sqztiny
\subparagraph{Context.}
An important concern for tool interoperability is ensuring that the
tools understand each other's data formats and their semantics.  What
is needed is a mechanism that allows exporting and importing
tool-specific data using a tool integration framework, such as OTIF.

\sqztiny
\subparagraph{Problems.}
There is often minimal overlap between tools, other than some common
aspects pertaining to DRE systems.  For example, the common
information in CoSMIC and Cadena is restricted to the fact that both
tools are tailored to support DRE systems build using the CORBA
Component Model (CCM)~\cite{CorbaComponents:02}.  These commonalities
are localized in certain artifacts, such as the IDL descriptions and
assembly information of CCM components.

The same problem seen from another perspective is that when tools are
integrated, they capture and contain in their model document two types
of properties: (1) {\em shared} properties, {\em i.e.}, properties
being captured also by other tools being integrated and (2) {\em
unique} properties, {\em i.e.}, properties not captured by any of the
other tools being integrated.  Shared properties must often be
transferred to other tools to synchronize the state amongst the tools.
In contrast, unique properties cannot reasonably be transferred to
another tool since they would not be understood.

The distinction between shared and unique properties implies a
separation of concerns that should be enforced by the two groups of
tool properties.  This, in turn, implies the following four problems:
\begin{enumerate}
\item The complexity of splitting properties in two groups ({\em
i.e.}, shared vs unique)
\item The task of transferring the shared group to remote tools
\item The choice of a common syntactical (not semantic) format for
performing the communication and 
\item The complexity of semantically merging the transferred
information into the information already present in the destination
tool.
\end{enumerate}
Problem 4 is the hardest since it requires the creation of semantic
translators that can understand the formats of both tools to enable
integration.

\sqztiny
\subparagraph{Solution approach $\rightarrow$ 
Minimizing inter-tool information exchange.} Problems 1 and 4 are
interrelated (1 being easier to solve than 4).  These were resolved
together using semantic translators and a merging algorithm, as
described in Challenge 3 below.

We resolved problem 3 by identifying an information model based on XML
for the data that is needed for the Cadena and CoSMIC tools.  For
example, CoSMIC generates information captured by the {\tt *.scenario}
model document in the form of XML descriptors and then creates a
plug-in to import this XML format into Cadena.  The reverse direction
for this format incorporates the changes suggested by the Cadena
analysis tools into the CoSMIC models.

Problem 2 is more complex than problem 3, so we resolved it using
OTIF, which allowed us to work at a significantly higher level of
abstraction.  For example, OTIF relieved us from many low-level
details, such as the complexity of handling a communication among
multiple tools.  Each tool can be started and shut down at any time,
can run in multiple instances, and might need to search for other
tools and (re-)establish connections to them at any time.

To function properly, OTIF requires support for document creation,
persistence, and navigation to make data interchange seamless.  OTIF
thus supports a {\em Universal Data Model} (UDM)~\cite{UDM:03}
interface to access and manipulate data on the OTIF backplane.  UDM
provides a development process and set of tools that generate C++
interfaces from data structures described using UML class diagrams.
These interfaces and the underlying C++ libraries enable convenient
programmatic access and automatically configured persistence services
for data structures described via UML diagrams.  We leverage these UDM
capabilities for the data exchange between CoSMIC and Cadena.

The modeling paradigms, such as CoSMIC's PICML, built using GME were
explicitly developed to expose a UDM interface.  The Eclipse framework
used by Cadena, however, does not support UDM natively, so we created
a UML class diagram that described the Cadena models.

\subsection*{Challenge 3: Achieving Lossless Semantic Transfers of Data}
\sqztiny
\subparagraph{Context.}
For any successful tool interoperability comprising data interchange,
it is important that the exchanged data be transferred without loss of
essential semantic information.  

\sqztiny
\subparagraph{Problems.}
Lossless semantic transfers of tool-specific data is hard since
different tools address different aspects of DRE systems and therefore
deal with different types of data, with their own semantics and
representation.  It is therefore possible (and common) for mismatches
to arise between data supported by individual tools and how they are
managed by the tool. For example, we outline the differences between
CoSMIC and Cadena formats below:
\begin{itemize}%\crunchlist
\item Cadena {\tt *.scenario} files support properties on connections
(such as event sources/sinks and invoke connections), whereas CoSMIC's
PICML does not.
\item Both PICML and Cadena support CCM connections types, such as
{\em emit}, {\em publish} and {\em invoke}, but PICML provides
specialized connector types for each of these in its CCM component
assembly metamodel, whereas Cadena infers the connector types from the
port types.
\item PICML supports QoS requirements on connections that are passed
to the deployment run-time for validity checks and potential
optimizations at deployment stage, whereas Cadena does not support
this capability.
\item PICML provides a specialized connector for a publisher/subscriber
connection involving multiple publishers and multiple receivers,
whereas Cadena uses mulitple connections for this case.
\item Cadena supports the {\tt STRING}, {\tt INT}, and {\tt BOOLEAN}
attribute types, whereas PICML supports {\tt Boolean}, {\tt Byte},
{\tt ShortInteger}, {\tt LongInteger}, {\tt Real\-Number}, {\tt
String}, {\tt GenericObject}, {\tt Generic\-Value\-Object}, {\tt
Generic\-Value}, {\tt Type\-Encoding}, and {\tt TypeKind}.
\end{itemize}

Given these constraints, it is straightforward to create simple lossy
export and import algorithms that would lose information not captured
by one toolsuite vs. the other.  This design, however, would force
users to reenter information twice for each toolsuite, thereby
increasing effort and the chance of inconsistencies in information
maintained across the tools.  What was desired, instead, is a {\em
write-once} approach, whereby once information was entered using
either CoSMIC or Cadena tools, the data transfer algorithm would
preserve the data and its semantics for all but a few exceptionally
rare circumstances.

One approach to handle these issues is to merge the different data
handled by individual tools to form a superset that is maintained by
the OTIF backplane.  Transferring the complete set of information
between the tools is not maintainable, however, since whenever a
feature should be added in {\em any one} of the tools being
integrated, the set of information being transferred across {\em all}
tools would change.  At that point, {\em all} the semantic translators
that convert documents from/to {\em any} two tools would need to be
updated to support the enlarged information set.

\sqztiny
\subparagraph{Solution approach $\rightarrow$ 
A graph-based diff-merge algorithm.}  \index{diff-merge algorithm} Our
solution uses information 
captured by individual MDD tools, focusing on the features that can
map between the tools, and applying graph transformation algorithms to
attain the desired interoperability.  The information we transferred
was contained in the CCM component assembly view of CoSMIC/\-PICML and
in the {\tt *.scenario} and {\tt *.profile} files from Cadena, as well
as the information conveyed in IDL3 files.

In the transformation algorithm, the information from PICML is matched
against the corresponding information in Cadena.  Differences are
detected and then depending on the direction of communication
(PICML$\rightarrow$Cadena or Cadena$\rightarrow$PICML), such
differences are imported into the destination tool, replacing earlier
information that was outdated.  This approach resembles a diff-merge
algorithm (\url{web.umr.edu/~gnudoc/single/emacs1934/ediff.html}),
thought it is performed on data from MDD tools that were stored as a
graph of interconnected information rather than sequential text.  We
therefore call our approach a {\em graph} diff-merge algorithm.

\BeginSidebar{\columnwidth}{CCM as Captured in CoSMIC and Cadena}
\label{ccmsidebar}
This sidebar explains key CCM concepts and terminology, and then shows
how they are supported by CoSMIC and Cadena when diverging from each
other or from the CCM specifications.

CCM components model units of software and contain {\em ports} for
communicating with other components. Ports are divided into (1)
asynchronous event-based ports ({\em EventSources} and {\em
EventSinks}) and (2) synchronous operation-based ports ({\em Facets}
and {\em Receptacles}), which can be connected together with {\em
Invoke} connections (for operation-based ports) and {\em Emit} or {\em
Publish} connections (for event-based ports).

{\em Publish} connections originating from an {\em EventSource} need
to pass through a {\em PublishConnector} element in PICML before
reaching any {\em EventSink} port, whereas Cadena has no concept of
{\em PublishConnector}. {\em Emit} connections can only connect one
{\em EventSource} to one {\em EventSink}, while {\em Publish}
connections can be many-to-many.  The explicit distinction between
{\em Publish} and {\em Emit} connections, however, only exists in
PICML, whereas in Cadena both are mapped to a generic {\em
EventSource-to-Sink} connection.

{\em Properties} are name/type/value triplets that can belong to {\em
Components} or to {\em Requirements} in PICML, whereas in Cadena they
can belong to {\em Components} and to {\em Connections} between
ports. {\em Requirements} (a.k.a. {\em Deploy Requirements}, PICML
only) are contained in {\em Components} and {\em PublishConnectors}
and serve to hold constraints (defined as a set of {\em Properties})
specifying where a {\em Component} or {\em PublishConnector} can be
deployed.

An {\em Assembly} (PICML only) holds {\em Components}, connections
between their ports, {\em PublishConnectors}, {\em Requirements}
associated to {\em Components} or {\em PublishConnectors}, and {\em
Properties} associated to {\em Components}. The correspondent of an
{\em Assembly} in Cadena is the {\em Scenario}, which contains {\em
Components}, {\em Connections} between their ports, and {\em
Properties} associated to these {\em Components} and {\em
Connections}.  In PICML and Cadena there can be multiple {\em
Assemblies}/{\em Scenarios} distinguished by a different path from a
so-called {\em RootFolder}.  \EndSidebar

The graph diff-merge algorithm for exporting PICML data to Cadena
follows the steps described below (Sidebar~\ref{ccmsidebar} explains
the CCM terminology used in these steps).

\begin{enumerate}%\crunchlist
\item Every CCM component assembly generates a separate {\tt
*.scenario} file. The full path name of the assembly from the {\em
RootFolder} is encapsulated in a property called {\em
PICML\_pathname}, which is stored by Cadena and eventually returned
to PICML unchanged.  This property is needed to match the same
source CCM component assembly on the PICML side when reimporting.
\item CCM component assembly-level properties are transferred to
Cadena as scenario-level properties if the type is supported by
Cadena, otherwise they are retained on the PICML side.
\item All the {\em PublishConnectors} are checked and the newly
created ones are flagged with a unique {\em ConnectorID}, which is in
a {\em DeployRequirement} having a magic name that is disregarded by
the DAnCE D\&C run-time system provided by CIAO.
\item All {\em PublishConnectors} are checked for the presence of a
{\em Requirement} with another magic name called {\em
CadenaProperties}. If found, all the properties encapsulated inside
such a requirement are output as properties on the {\em
EventSource-to-Sink} corresponding connection in Cadena, which
compensates for the lack of properties on connectors on the PICML
side.
\item All {\em Components} that have an output {\em Emit} or an {\em
Invocation} connection are checked for a property with a magic name:
{\em CadenaEIProperties} (where EI stands for ``Emit-Invoke''). This
property contains a string that is the dump of an XML file containing
multiple properties for each {\em Receptacle-to-Facet} or {\em Event
Source-to-Sink} {\em Emit} connection output from that component.  The
embedded file is parsed and the contained information is extracted and
sent to Cadena, which accounts for the lack of properties on emit and
invoke connections on the PICML side.
\item All component instances are browsed and their name and type are
transferred to Cadena. The attached properties are transferred to
Cadena only if they are a type supported by Cadena, otherwise they are
retained on the PICML side. For all components, each connection to a
remote port or to a {\em PublishConnector} is passed to Cadena.
\end{enumerate}
At this point, the XML file containing the information about the
scenario (and implicitly about the profile) is sent to the OTIF
backplane.  On the Cadena side it is fetched, de-encapsulated from
XML, and dumped to disk, possibly overwriting a preexisting version.

During Cadena export to PICML, the transfer across the OTIF backplane
acts in the reverse way.  The key points of the graph diff-merge
algorithm on the PICML side are as follows:
\begin{enumerate}%\crunchlist
\item Using the {\em PICML\_pathname} information, the same CCM
component assembly of the export is matched so that the modifications
can be performed in the correct place.
\item Based on the names of the component instance, the components are
matched. 
\item Based on the {\em ConnectorIDs}, the {\em PublishConnectors} are
matched.  On the PICML side, the components and the {\em
PublishConnectors} that have no match on the Cadena side are
considered deleted by the Cadena user and thus get destroyed on the
PICML side. The properties and requirement that only refer to those
are also destroyed.
\item The {\em Components} and {\em PublishConnectors} on the Cadena
side that are unmatched on the PICML side are considered newly created
and thus created on the PICML side.
\item All the emit and invoke connections at the PICML side are
deleted, and are recreated new from the information on the Cadena
side.
\item All the properties on PICML components and at the component
assembly-level are browsed. For those where the type could have been
passed to the Cadena side, a match to the properties on the Cadena
side is attempted. If the match fails, those PICML properties are
considered to be deleted by the Cadena user, so they are destroyed on
the PICML side.
\item For all properties on {\em Components} on the Cadena side, a
match is attempted on the PICML side. If the match succeeds, the value
is updated on the PICML side, otherwise this is considered a new
property created by the Cadena user so a new property gets created on
the PICML side.
\item Steps 7 and 8 are repeated again for properties on {\em
PublishConnectors}, with the difference that the match is attempted
inside the {\em Requirement} called {\em CadenaProperties}, if it
exists. The newly created properties are also created there (if a
requirement with such a name does not exist, it is created and
attached to the {\em PublishConnector}).
\item Steps 7 and 8 are also repeated again for the properties on {\em
EmitConnector} and {\em PublishConnector}, but this time the match is
attempted on the XML content of the magic property {\em
CadenaEIProperties} on the component that has the outgoing emit or
invoke connection, which is created if needed.
\end{enumerate}

To perform these steps for the two directions of communication, we
used the GReAT (Graph Rewriting And Transformation)~\cite{GReAT:03}
tool.  GReAT is a GME-based MDD tool that can be used to visually
define graph transformation among networks of objects that are
accessible with UDM.  GReAT shortened our development time
significantly since it is much more readable and maintainable than
using a third-generation programming language, such as C++ or Java.
Both GME project files and XML files whose schema can be defined with
an UML diagram can be accessed via UDM.

A GReAT transformation can be run interpretatively during development
and debugging.  It can also be used to generate C++ header and
implementation files that can be compiled for a release version of the
transformation.  The current version of the
CoSMIC$\leftrightarrow$Cadena import/export transformation contains
more than 2,000 elements (graph pattern nodes) and 13,500 lines of C++
code.  Figure~\ref{fig:cosmic_cadena} illustrates the architecture of
this transformation process, where a bidirectional {\em GReAT-based
tool adapter and semantic translator} converts PICML assemblies
to/from XML files conforming to the adopted interchange schema, which
was chosen to conform to the semantics of Cadena {\tt *.scenario} and
{\tt *.profile} files.  The schema, known to the OTIF backplane, is
used to read and validate the XML file upon arrival on the backplane.
At every upload of a new interchange XML file onto the backplane, the
tool adapters are notified of the availability of such new CCM
component assembly and are prompted for the download. On the Cadena
side, a simpler {\em Java-based Cadena tool adapter} converts the XML
to {\tt *.scenario} and {\tt *.profile} files and vice versa.  Our
graph diff-merge algorithm is activated during the backplane-to-PICML
import and is implemented inside the {\em GReAT-based PICML tool
adapter and semantic translator}.

