% $Id: intro.tex,v 1.14 2006/01/04 19:35:52 dengg Exp $

%            Comments from the 1st reviewer
%
% Generally, the case study described looks interesting and I would
% like to learn and read more about the approach, practical
% experience, and the concrete capabilities already realized.
% Unfortunately, the paper does - for me - not present the "right"
% aspects and details. The paper lacks in motivating and presenting
% the industrial perspective.

% Okay, one of the authors is from Siemens
% and thus may be practically involved in the presented domain. In the
% presentation of the content, however, the "real" practical insights
% are completely missing. That is, except for the numbers given (LoC,
% #components, ...) the case study is hard to distinguish from a case
% study just made up by some researchers who read some literature on
% the domain. Hence, the paper does not give enough practical insights
% and experience but presents a the technical approach developed by
% researchers.
%
%% According to this reviewer, "Lacking practical insights" is one
%% of the biggest problem of this paper. So I feel we should really
%% motivate well how variability and scalability really caused big problems
%% in the ITS case study, and how various technologies could address
%% these problems. -Gan

% The paper emphasizes product line *architectures* in the
% introduction and throughout the remaining text. The paper, however,
% does unfortunately not present the product line architecture. There
% are no architectural views, there is no description how the code
% generation is developed according to the architecture, that is,
% automates architectural concepts and patterns. From my perspective,
% the paper is *not* on product line engineering as indicated in title
% and text but is an MDD paper. Anyway, the paper lacks in describing
% the systematic approach for realizing such an approach (for example
% in another context or environment) but introduces many technologies
% and acronyms that negatviely affect the paper's clarity.
%
%%
%% We removed the PLA focus from the paper. -Gan
%%

%            Comments from the 3rd reviewer
%
% Although the CFP asked for experiences from software developers in
% industry, it is very hard to understand whether the case study meets
% that criteria. It is apparent that the system used as an example in
% the case study is based on requirements mined from similar Siemens
% projects and so could be considered representative of a realistic
% industrial system. However, it is never stated who the subjects of
% the study were - that is, the people who actually applied the new
% techniques to accomplish the development tasks. It does not appear
% to have been done by Siemens developers in a realistic Siemens
% environment; hence one important piece of information missing is how
% this potential solution would have been viewed by developers under
% real constraints. In particular for the experience track the paper
% should contain some information about whether the results of
% applying the method were considered useful for the job at hand and
% whether it could be applied with acceptable costs/effort.

\section{Introduction}
\label{sec:intro}

\sqzhuge\paragraph*{Emerging trends and challenges.} Developing
software for large-scale distributed, realtime and embedded (DRE)
systems of systems, such as a warehouse inventory tracking system
(ITS), is hard due to the numerous factors that must be addressed.
For example, ITS software must provide reliable, efficient, and
convenient mechanisms that manage warehouses and the movement of
inventory items in a timely and reliable manner.  An ITS should enable
human operators to configure warehouse storage organization criteria
and warehouse transportation facility criteria, maintain the set of
items known throughout a distributed environment (which may span
organizational and even international boundaries), and track warehouse
assets using GUI-based operator monitoring consoles.  Addressing these
challenges is crucial since it impacts the large set of users of an
ITS, which includes couriers (such as UPS, FedEx, and DHL), airport
baggage handling systems, and large trading and manufacturing
companies (such as Wal-Mart and Target).

Standards-based quality-of-service (QoS)-enabled {\em object-oriented}
middleware technologies, such as Real-time CORBA~\cite{RTCorba:02} and
Real-time Java~\cite{RTSJ:00}, have been successful in small- to
medium-scale DRE systems~\cite{Sharp:03a}, where they support the
provisioning of key QoS properties, such as (pre)allocating CPU
resources, reserving network bandwidth, and monitoring/\-enforcing the
proper use of distributed real-time and embedded DRE system resources
at runtime to meet end-to-end QoS requirements, such as throughput,
latency, and jitter.  Since object-oriented technologies tend to
tangle functional ({\em e.g.}, application business-logic) aspects and
QoS ({\em e.g.}, end-to-end latency and jitter requirements)
aspects~\cite{Subramonian:04c}, however, it remains hard to develop
larger-scale DRE systems, such as an ITS.  In recent years, therefore,
QoS-enabled {\em component}
middleware~\cite{LWCCM,Schmidt:03m,Sharp:98,Ritter:03} has emerged to
help developers of DRE systems enhance reuse by factoring out reusable
concerns, such as component lifecycle management, system resource
reservation and allocation, system authentication/\-authorization, and
remoting.  As a result, software for large-scale DRE systems is
increasingly being assembled from reusable and configurable
components.

Although QoS-enabled component middleware technology provides powerful
capabilities, however, it also yields the following challenges for
developers of DRE systems~\cite{Sharp:99,Sharp:03}:

\sqzhuge\subparagraph{1. Increased scale.}  As DRE subsystems are
joined together to form large-scale systems, developers rarely have
in-depth knowledge of the entire system or an integrated view of all
subsystems and libraries, which may cause them to implement
suboptimal solutions that duplicate code unnecessarily, complicate
system evolution, affect system QoS, and violate architectural
principles. For example, in an ITS new warehouses may be added at
remote locations, which will require reuse of existing ITS software
assets to work for the new warehouses and their incorporation within
the global ITS system. It is hard enough to satisfy ITS QoS
requirements independently at remote locations, and even harder to
satisfy them in concert.

\sqzhuge\subparagraph {2. Increased variability.} Additions to the
features of the system and/\-or availability of better
implementations of the same type of systems can further increase
functional and QoS variability.  For example, new types of warehouse
transportation facilities, such as forklifts or cranes, which may
have more sophisticated features and timeliness requirements may be
introduced in a warehouse, hence requiring appropriate changes in
the ITS software. It is hard to accommodate these changes within
individual components without complicating the solution and
affecting the overall QoS of the entire system.

To maximize software reuse and productivity, therefore, increased
scale and variability must be addressed by more effectively
combining technologies and tools that support system configuration
and integration.

\sqzhuge\paragraph*{Promising approach $\rightarrow$ Integrating
model-driven development and QoS-enabled component middleware.} A
promising way to alleviate the challenges of DRE system scale and
variability described above is to integrate model-driven development
(MDD)~\cite{Greenfield:04,Janos:03,Sharp:03,Schmidt:04a} techniques
with QoS-enabled component middleware~\cite{Schmidt:03m,Ritter:03}.
MDD helps resolve key software development challenges by combining (1)
{\em metamodeling}, which defines type systems that precisely express
key abstract syntax characteristics and static semantic constraints
associated with application domains, such as software defined radios,
avionics mission computing, and warehouse inventory tracking, (2) {\em
domain-specific modeling languages} (DSMLs), which provide programming
notations that are guided by certain metamodels to formalize the
process of specifying application logic and QoS-related requirements
in a particular domain, and (3) {\em model transformations and code
generation} that help automate repetitive, tedious and error-prone
tasks in the software lifecycle to ensure the consistency of software
implementations with analysis information associated with functional
and QoS requirements captured by structural and behavioral models.

In prior work, we developed (1) a MDD toolsuite called {\em
Component Synthesis using Model Integrated Computing} (CoSMIC)
(\url{www.dre.vanderbilt.edu/cosmic}), which is an integrated
collection of DSMLs that support the specification, analysis,
development, configuration, deployment, and evaluation of DRE
systems, and (2) a QoS-enabled component middleware platform called
{\em Component-Integrated ACE ORB} (CIAO)~\cite{Schmidt:03m}, which
combines Lightweight CORBA Component Model (CCM)~\cite{LWCCM}
capabilities with Real-time CORBA features~\cite{RTCorba:02}.  To
evaluate how well the integration of MDD tools and QoS-enabled
component middleware helps resolve the scale and variability
challenges described above, we developed an ITS case study that
provides logistics support to manage the flow of items and assets in
and across warehouses in a distributed and timely manner.

This paper presents our experience gained and lessons learned while
integrating MDD and QoS-enabled component middleware to address two
key variability concerns in designing the ITS: (1) warehouse
configuration and management concerns and (2) component management,
assembly, QoS configuration, and deployment concerns.  The goal of
our case study was to evaluate how well these technologies could be
integrated together to (1) modularize key functional and real-time
QoS concerns of ITS at higher levels of abstractions than
third-generation programming languages, such as Java and C++, (2)
handle variabilities at different levels of abstractions, {\em
e.g.}, by assembling a set of components to provision ITS
functionality based on particular warehouse requirements, and
configuring middleware and services via DSMLs, and (3) automate key
steps in the software lifecycle, such as automated ITS product
instance software assembly, deployment, and configuration based on
warehouse-specific deployment requirements.

\sqzhuge\paragraph*{Paper organization.} The remainder of this paper
is organized as follows: Section~\ref{sec:overview} provides an
overview of the ITS case study; Section~\ref{sec:integrate}
describes how we integrated and applied MDD tools together with
QoS-enabled middleware to resolve key technical problems faced in
our case study; Section~\ref{sec:eval} further evaluates our
approach; Section~\ref{sec:relwork} compares our work with related
efforts; and Section~\ref{sec:conclusions} presents concluding
remarks and summarizes lessons learned.

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