% $Id: conclusions.tex,v 1.12 2006/01/04 20:21:56 schmidt Exp $
\section{Concluding Remarks}
\label{sec:conclusions}

This section focuses on our experience gained and lessons learned
when integrating MDD tools and QoS-enabled component middleware
technologies and applying them to a case study in the warehouse
management domain. In general, our development and experiments of
ITS case study shows the complementary relationships between CoSMIC
MDD tools ({\em i.e.}, WMGL/PICML) and underlying component
middleware and D\&C frameworks ({\em i.e.}, CIAO/DAnCE). The lessons
learned thus far include:

\sqzhuge\paragraph*{$\bullet$ The component middleware paradigm
elevates the abstraction level of middleware to enhance software
developer quality and productivity.}  It also introduces extra
complexities, however, that are hard to handle in an {\em ad hoc}
manner for large-scale DRE applications.  For example, the OMG
Lightweight CCM~\cite{LWCCM} and Deployment and Configuration
(D\&C)~\cite{DandC:03} specifications have a large number of
configuration points, which we handle with advanced MDD tools.

\sqzhuge\paragraph*{$\bullet$ Large-scale systems are rarely developed
from scratch and often are composed of smaller systems.}  The MDD
paradigm expedites application development with the proper integration
of the modeling tool and underlying technical infrastructure, such as
the DAnCE D\&C framework.  In our ITS case study, if the warehouse
model is the primary changing concern in the system (which is typical
for end users), little new application code must be written, yet the
complexity of the generation tool remains manageable due to the
limited number of well-defined configuration {\em hot spots} exposed
by the underlying infrastructure.  Likewise, when component deployment
plans are incomplete or must change, the effort required is
significantly less than using the raw component middleware without MDD
tool support since applications can evolve from the existing set of
PICML and WMGL models.

\sqzhuge\paragraph*{$\bullet$ Domain-specific modeling techniques can
help reduce the learning curve for end users.}  For example, warehouse
modelers in our ITS project needed little or no knowledge of how to
write component software since they used higher-level models that
correspond to the language understood by domain engineers and visual
modeling environments, such as WMGL. In addition to the warehouse
configuration aspects, WMGL embodies certain assumption and rules
about the mapping (usage patterns) from problem domain of warehouse
management to the solution domain of component middleware.  The
mapping rules understood by WMGL are defined by experienced software
architects and then enforced by the WMGL modeling and code generation
environment.  These enforcement mechanisms reduce the probability of
architectural rules violation discussed in Section~\ref{sec:overview}
and ensure the proper usage of component middleware.  Conversely, our
experience applying PICML to model the ITS deployment structure
indicated that it raised the level of abstraction at which developers
work, enabling them to concentrate on certain aspects ({\em e.g.},
deployment structure) in the multidimensional problem space associated
with applying component middleware for DRE systems. This separation of
concerns in turn eliminated many sources of accidental complexities
and improved overall system quality.

While we were generally successful in integrating and applying MDD and
component middleware into our ITS case study, we also felt addition
R\&D is warranted to enable broader adoption of these technologies:

\sqzhuge\paragraph*{$\bullet$ How to optimally and effectively
configure and deploy each product instances.}  Despite the fact that
PICML facilitates the configuration of enterprise DRE systems based on
Real-time CORBA and Lightweight CCM, developers are still faced with
the question of what constitutes a ``good'' configuration and they are
still ultimately responsible for determining the appropriate
configurations.  We observed that scheduling analysis and verification
tools would be helpful in performing this evaluation and should be
integrated into CoSMIC's MDD toolsuite to help system designers
address such challenges.  In addition, despite the benefits of using
visual MDD tools to describe different aspects of the large scale DRE
systems, it is still labor intensive and error-prone to manually show
all $\sim$400 connections for the number of components in our ITS case
study.  This observation motivates the need for further research in
automating the synthesis of large-scale DRE systems based on the
different types of meta-information about assembly units, such as
components or services.

\sqzhuge\paragraph*{$\bullet$ How to reuse legacy code when
transitioning from object-oriented to component-based architectures.}
Porting existing object-oriented DRE systems to component-based
systems is an important concern for production systems that achieve
reuse in an {\em ad hoc} manner at the source code level.  We observed
that such reuse is ineffective without advanced MDD tools to support
this porting effort.  Our experience with the ITS case study indicated
that these tools should enable application developers to identify (1)
which part of the legacy code originally compliant to traditional
object-oriented middleware is still compliant to the new
component-based middleware, (2) which part of the legacy code is no
longer needed since it has been factored into reusable component
middleware frameworks, and (3) which part of the legacy code should be
refactored and configured through other tools and frameworks, such as
PIMCL and DAnCE.  Developing these tools requires analysis capability
for both the object-oriented and component-based programming models at
the source code level.

\sqzhuge\paragraph*{$\bullet$ How to handle challenges associated
with domain evolution.}  Using MDD technologies effectively requires
practical and scalable solutions to the domain evolution problem,
which arises when existing software products are extended and/or
refactored to handle unanticipated requirements or better satisfy
existing requirements.  For example, changing metamodels can
invalidate models based on previous versions of the metamodels.
While software developers can manually update their models and/or
components developed with a previous metamodel to work with the new
metamodel, this approach is clearly tedious, error-prone, and
non-scalable. Although MDD tools remove many complexities associated
with handcrafted solutions, developers are still faced with the
challenge of evolving existing models when the respective domain
evolves. Although model evolution tools, such as
GReAT~\cite{GReAT:03}, exist they are hard to use and only provide
partially automated solutions. Since these modifications
significantly complicate domain evolution efforts, they can outweigh
the advantages of system development compared to traditional
development methods based on handcrafting solutions using third
generation languages.  To rectify these problems, compositional
architecture patterns are desired to guide the design of MDD tools
component middleware, so they can modularize system concerns and
reduce the effort associated with domain evolution.

Our experiences described above motivate the need for further research
on automated techniques to uncover effective heuristics to guide the
complicated process of developing and evaluating DRE systems, reusing
legacy code, and migrating models and metamodels as knowledge of a
domain expands. We are exploring all of these open R\&D issues in the
context of our ITS case study and other large-scale DRE system
projects.


%%% Local Variables:
%%% mode: latex
%%% TeX-master: "isorc06-its"
%%% End:
