%% $Id: overview.tex,v 1.40 2005/01/05 04:42:58 gokhale Exp $

\section{An Overview of the CoSMIC and Cadena MDD Environments}
\label{overview}

This section presents an overview of the CoSMIC and Cadena MDD
toolsuites, highlighting the capabilities of each tool will emphasize
in the DRE system case study presented in Section~\ref{casestudy}.

\subsection{Overview of CoSMIC}
\label{cosmic}

The {\em Component Synthesis using Model Integrated Computing}
(CoSMIC)~\index{CoSMIC}~\cite{Schmidt:04a} toolsuite is an integrated
collection of MDD tools that address the key lifecycle challenges of
middleware and applications in DRE
systems. Figure~\ref{fig:tool-chain} illustrates CoSMIC's MDD tools
that address deployment and configuration lifecycle challenges of DRE
systems.
\begin{figure}[htbp]
\vspace{-0.3in}
\center{\includegraphics[width=4in]{eps/cosmic-hex.eps}}
\vspace{-0.1in}
\bfcaption{The CoSMIC MDD Toolsuite}
\label{fig:tool-chain}
\end{figure}
CoSMIC supports modeling of DRE system deployment and configuration
capabilities, their QoS requirements, and QoS adaptation policies used
for DRE system QoS management.  Its MDD tools are implemented via {\em
domain-specific modeling languages} (DSMLs) developed using the
Generic Modeling Environment (GME)~\cite{GME:01}, which is a
configurable toolkit for creating domain-specific modeling and program
synthesis environments.  CoSMIC uses GME to define the modeling
paradigms\footnote{A {\em modeling paradigm} defines the syntax and
semantics of a DSML~\cite{Janos:03}.} for each stage of its tool
chain.  CoSMIC ensures that the rules of construction -- and the
models constructed according to these rules -- can evolve together
over time.  Each CoSMIC tool synthesizes XML-based metadata that is
used by the CIAO QoS-enabled component middleware~\cite{Schmidt:03m}
described in Section~\ref{intro}.  In particular, CoSMIC supports
CIAO's implementation of the OMG's Deployment and Configuration (D\&C)
specification~\cite{DandC:03} and provides the following capabilities
shown in Figure~\ref{fig:tool-chain}: \sqztiny
\begin{itemize}%\crunchlist
\item {\em Specification and implementation}, which enables
application functionality specification, partitioning, and
implementation as components. CoSMIC provides the {\em Interface
Definition Modeling Language} (IDML), which is a DSML that can be used
to specify component definitions.  IDML also provides an importer that
can transform preexisting IDL definitions into modeling elements.
\item {\em Component assembly and packaging}, which can bundle a suite
of software binary modules and metadata representing application
components.  CoSMIC provides the {\em Platform Independent Component
Modeling Language} (PICML)~\cite{Schmidt:04z}, which is a DSML that
models the connections between various components to form assemblies.
PICML enables these assemblies to be composed into packages that can
be shipped to target nodes.
\item {\em Configuration}, which allows packages to be customized with
the appropriate parameters that satisfy the functional and systemic
requirements of applications.  CoSMIC provides the {\em Options
Configuration Modeling Language} (OCML)~\cite{Schmidt:04y} to model
the middleware configuration rules, which are then synthesized into a
rules engine and graphical environment that application developers use
to configure the middleware.
\item {\em Planning}, which makes appropriate deployment decisions
including identifying the entities, such as CPUs, of the target
environment where the packages will be deployed. The {\em Model
Integrated Deployment and Configuration Environment for Composable
Softwware Systems} (MIDCESS)~\cite{Schmidt:04a} DSML in CoSMIC can be
used to model deployment plans for DRE system components.
\item {\em Analysis and benchmarking}, which enables run-time
reconfiguration and resource management to maintain end-to-end
QoS. CoSMIC provides the {\em Benchmark Generation Modeling Language}
(BGML)~\cite{Schmidt:04y}, which models DRE systems QoS requirements
and synthesizes empirical benchmarking testsuites.  Additional
analysis capability is achieved via integration with external tools,
as described in Section~\ref{approach}.
\item {\em Deployment}, which triggers the installed binaries and
brings the application to a ready state.  CoSMIC is integrated with a
run-time framework called {\em DAnCE} (Deployment and Configuration
Engine), which implements the OMG's D\&C specification and can be used
to model the deployment of DRE system packages according to precisely
specified plans.
\end{itemize}
\sqztiny
\noindent The CoSMIC toolsuite also provides the capability to
interwork with model checking tools, such as Cadena~\cite{Hatcliff:03}
(Section~\ref{cadena}), and aspect model weavers, such as
C-SAW~\cite{Schmidt:03e}.  The integration of CoSMIC with Cadena is
the focus of Section~\ref{approach}.

The core DSML provided by CoSMIC is PICML, which figures prominently
in the integration of CoSMIC and Cadena described in
Section~\ref{approach}.  PICML allows developers to model packages of
components into assemblies that can then be configured and deployed
appropriately.  Configuration and deployment concerns crosscut
assemblies and systems.  These crosscutting concerns are captured by
the different aspects of PICML.  During the configuration and
deployment process, multiple concerns captured in the format of
metadata in the component development process are woven together by
PICML, as shown in Figure~\ref{fig:picml}.
\begin{figure}[htbp]
\center{\includegraphics[width=3.5in]{eps/picml_arch}}
\vspace{-0.1in}
\bfcaption{The PICML Architecture}
\label{fig:picml}
\end{figure}

PICML allows the specification of the component-based deployment and
configuration concerns outlined above by allowing users to model them
as elements in a GME paradigm.  Additional constraints are defined via
GME's {\em object constraint language} (OCL)~\cite{OCL:03} facilities
to ensure that the models built using PICML are semantically valid.
PICML's constraints check that the {\em static semantics} ({\em i.e.},
the semantics that are required to be present at design time) are not
violated.  For example, at design-time, PICML can enforce the CCM
constraint that only ports with the same interface or event type can
be connected together.

The generative capabilities of PICML enable the separation of
crosscutting deployment and configuration concerns, which are
represented in the form of XML metadata and whose semantics can be
validated automatically.  The DAnCE run-time framework provided by
CIAO is then responsible for weaving these concerns into component
middleware and applications.  The model interpreters in PICML target
the configuration and deployment of DRE components for CIAO.  We chose
CIAO as our initial focus since it is QoS-enabled component middleware
designed to meet the requirements of DRE systems.  As other component
middleware platforms (such as J2EE and .Net) mature and become
suitable for DRE systems, we will (1) enhance CoSMIC so it supports
platform-independent models (PIMs) and then (2) include the necessary
patterns and policies to map these PIMs to platform-specific models
(PSMs) for various component middleware platforms.

\subsection{The Cadena Model Driven Development Environment}
\label{cadena}

The Cadena MDD environment was built to provide a variety of forms
of support for development of component-based distributed systems
include component interface specification via CCM IDL, construction
of component assemblies using multiple system views, and generation
of configuration and deployment XML data.  A primary focus of 
the work on Cadena has been the investigatation of a number of
different structural and behavioral analysis techniques for
component-based systems.
% John, would it be possible to integrate the following sentences into
% the bulletized list below since they seem similar in spirit/scope to
% the list?  
% [Done]
% Also, is there a single diagram you could put here to
% show the ``architecture'' of Cadena, similar to what we have above
% for CoSMIC?
% [I agree we need that.  We'll insert something if given more time]

The following is a summary of the capabilities Cadena provides to
develop component-based systems.
\begin{itemize}%\crunchlist
\item A collection of lightweight specification forms that can be
attached to IDL to specify mode variable domains, intra-component
dependencies, and component state-transition semantics.  These forms
have a natural refinement order so that useful feedback can be
obtained with little annotation effort, and increasing the precision
of annotation yields more precise analysis.  In addition, Cadena
specifications allow developers to specify the same information in
different ways, achieving a form of \emph{checkable redundancy} that
is useful for exposing design flaws.
\item Dependency analysis capabilities that allow tracing
inter/\-intra-component event and data dependencies, as well as
algorithms for synthesizing dependency-based real-time and
distribution aspect information.
In essence, these dependency analyses provide different forms 
of architectural ``slicing'' that help developers identify
dependencies among components for system understanding and for guiding
component integration tasks, such as establishing event handling
priorities and locking policies.  

\item A novel model-checking infrastructure (based on the Bogor
model-checking framework~\cite{Bogor:03}) dedicated to event-based
inter-component communication via real-time middleware enables system
design models (derived from component IDL, component assembly
descriptions and annotations) to be model-checked for global system
properties.  This enables developers to perform simple simulations of
their systems to reason about, {\em e.g.}, high-level mode
transitions, and to check system designs against crucial system
requirements phrased in the form of invariants, event/\-state ordering
contraints and component interaction protocols phrased as regular
expressions or temporal logic formulas.

\item A component assembly framework supporting a variety of
visualization and programming tools for developing component
connections, such as hiding or changing the color of component
and connections that satisfy user-defined queries of component
and connection attributes.

\item A component deployment facility that auto-generates XML
deployment and configuration information.
\item Cadena is implemented as a set of plug-ins to IBM's Eclipse
IDE.  This facilities an uninterrupted workflow in which component
interface and architectural can be performed in the same tool as
component implementation (e.g., using the sophisticated Java
development environment of Eclipse).  Moreover, it enables easy
incorporation of analysis tools as plug-ins such as the Bogor
model checking engine.
\end{itemize}

In the integration with CoSMIC, we focus on using Cadena's system
configuration dependency analysis facilities.  Even with small systems
of $\sim$20-30 components, relationships between components and
component dependences are often hard to determine from visual
inspections of textual or graphical component assembly views.
Component-based DRE system can often have over 1,000 components, and
engineers at Boeing and Lockheed Martin with whom we collaborate have
identified the development of automated support for component
dependency analysis and visualization as a high priority.

Given a component library and component assembly description (along
with optional {\em Cadena property specification} file described
below), Cadena's dependency module builds a \emph{port dependence
graph} PDG = (N,E) where each node $n \in N$ is a component/port pair
($\ippair{c}{p})$\index{Port Dependence Graph (PDG)}.  Edges ({\em
i.e.}, dependences) between PDG nodes arise from two sources:
\emph{inter-component dependences} corresponding to port connections
specified in component assembly descriptions and \emph{intra-component
dependences} captured by CPS declarations in component property
specifications.  Cadena provides the following analysis capabilities
for dependency graphs: \sqztiny
\begin{itemize}%\crunchlist
\item {\bf Forward and backward slices}, which detects the
components that are affected by (forward) or affect (backward) a
particular component or port.  Note that slices can be computed at two
levels of granularity: (1) a {\em component-level forward slice} finds
all components that are affected by a given component vs. (2) a {\em
port-level forward slice} finds all components that are affected by a
particular port of a given component.  In either case, slices are
constructed by considering the reachability of components in the port
dependence graph described above\index{Slicing}.
\item {\bf Chopping}, which highlights all the ports and components 
that lie on a path between two given components/ports.  Intuitively,
given two components $C_1$ and $C_2$, a chop based on $C_1$ and $C_2$
finds all paths between $C_1$ and $C_2$ by intersecting the forward
slice from $C_1$ and the backward slice from $C_2$\index{Chopping}.
\item {\bf Mode-based slicing and chopping} which leverages 
specifications of dependences that capture the fact that some
dependences are only active when a component is in a particular mode.
This enables more precise views of system dependences that reflect
only those dependences that are active when the system is in a 
particular state.
\item {\bf Cycle detection}, which detects cycles along a series of
event connections in the dependence graph.  In certain computational
models, event cycles may indicate design flaws\index{Cycle detection}.
\end{itemize}

\begin{figure}[htb]
\vspace{-.1in}
\center{\includegraphics[width=4in]{eps/cadena.eps}}
\bfcaption{Cadena Dependency Analysis Interface}
\label{fig:cadena}
\end{figure}
Figure~\ref{fig:cadena} shows a portion of Cadena's interface for
issuing dependence-related queries over the graphical structure of a
system configuration.  The displayed pull-down menu allows developers
to select from among the dependence analysis capabilities described
above.  
% John, since the book will be printed in black and white can you
% please make sure that the figure and its associated discussion makes
% sense (e.g., I'm not sure if it makes sense to talk about ``color''
% here)?! 
% Doug, I think the "color" here refers to the display in the tool,
% not the figure.
The results of an analysis are displayed in the tool by changing the
color of relevant components, ports, and connections.  For example,
the results of a forward slice are displayed by rendering in gray all
the components, ports, and connections affected by the given
component.

Cadena decouples various aspects of modeling by requiring that these
crosscutting concerns be captured in the following types of files
located in a common project space:
\sqztiny
\begin{itemize}%\crunchlist
\item {\bf IDL3 file} {\tt *.idl}, which contains OMG's standard
interface description language metadata describing components and
their interfaces.

\item {\bf Scenario file} ({\tt *.scenario}), which describes an
assembly of interconnected CCM components, including the value of
their configuration properties.  Cadena provides a graphical
visualizer, a text editor, and a form view editor to manipulate {\tt
*.scenario} files.  The equivalent of a scenario file in CoSMIC's
PICML is the CCM component {\em assembly} view, which enables
graphical editing of properties.

\item {\bf Profile file} ({\tt *.profile}), which acts as a scenario
format definition and validation system by defining the type of the
properties that can be associated with different components and/or
connections.  Cadena supports three types for properties: {\sc
string}, {\sc int}, and {\sc boolean}. There is no equivalent for the
{\tt .profile} file on PICML, which is another motivation for
integrating CoSMIC and Cadena.

\item {\bf CPS (Cadena Property Specification) file} ({\tt *.cps}),
which contains light-weight semantic annotations to capture abstract
semantics that can be leveraged by Cadena's analysis facilities.  For
example, in DRE systems, a component's behavior is often organized
into a collection of \emph{modes} ({\em e.g.}, a component can be in
an {\tt active} or {\tt inactive} mode, or in a {\tt normal} or {\tt
fault-recovery} mode, etc.).  Modes can be used to represent the
abstract state of a component.  A component's mode state is often
implemented as a variable with an enumerated type that includes each
of the mode states, and a modal component typically varies its
behavior by branching to different implementations based on the
current state of its mode variable.  The {\tt *.cps} file provides a
means to capture the modes within a component and the internal
interconnections within each component that depend on the mode.
Information in this file includes conditional behavior, such as a set
of inputs of a component having an effect on a set of outputs only
when that component is in a particular mode/state.  Cadena {\tt *.cps}
files can also include simple state transition systems -- finite state
automata that describe the abstract control flow of actions on a
component's interface ({\em e.g.}, method calls and event publishing)
as well as transitions on mode state variables.  This information can
be used to generate finite state models suitable for simulation or
state-space exploration (model checking) of system designs.  There is
no equivalent for the {\tt *.cps} file in PICML or in CCM.
\end{itemize} 

