\markboth{Wallnau}{Wallnau}
\documentstyle[11pt]{article}
\oddsidemargin  0.26in % Leave enough for binding margin
\evensidemargin 0.26in %
\topmargin      -1.00in % (adjusted for printer bias)
\headheight      .00in  % (no headers)
\headsep         .75in  % (top margin + headers + skip)
\footheight     12.0pt  % ??? (seems to work ok)
\footskip       25.0pt  % ??? ( "   "  )
\textheight     9.425in % (instructions: 9 1/8" min, 9 7/16" max)
\textwidth      6.5in   %

\markboth{Wallnau}{Wallnau}
\pagestyle{myheadings}

\parindent=0pt
\parskip=10pt
\def\@maketitle{\vbox to 2.6in{\hsize\textwidth
    \linewidth\hsize \vfil \centering
    {\large \@title \par}
    \vskip 2em
    {\normalsize
    \begin{tabular}[t]{c}\@author
    \end{tabular}\par}
    \vfil}
}

\input{epsf}
\begin{document}

%\bibliographystyle{alpha}
\bibliographystyle{ieeetr}

\title{Incremental Adoption of Software Architecture Technology for Reuse in the DoD\footnote{The views expressed in this position paper are those of the author and do not necessarily reflect the views of Paramax, the CARDS program, or its government spon
ors.}}

\author{Kurt C. Wallnau\\
\\
\\
Paramax Systems Corp.\\
1401 Country Club Road\\
Fairmont, WV 26554\\
Tel: (304) 363-1857\\
Email: wallnau@cards.com\\
}
\date{}

\maketitle

\begin{abstract}
Technologically sound and scaleable results
of research into software architectures and their representations are
beginning to emerge.  However,  the adoption of
these results to support a global DoD reuse strategy
is complicated by the business and organizational complexity of the DoD.
Architecture-based reuse technology adoption must
occur independently within numerous semi-autonomous product development
centers in the
DoD and within DoD contractor organizations.  This adoption must
support a gradual convergence to a common
architecture representation technology from widely divergent starting points.
This paper describes the use of a library of shared software architecture
ontologies to support: local architecture representation technology autonomy;
evolutionary adoption of common architecture representation technologies; and
evolutionary development of representation-independent {\em domain}
architectures from {\em product-line} architectures.

\vspace{0.2in}
\noindent
{\bf Keywords:} Software reuse; software architectures; architecture
description languages; shared ontologies.

\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Learn and share ideas about: design-level reuse;
the impact of reusable design representation on DoD reuse and software
procurement policies; and technology implications of organizational
complexity on design reuse.

\vspace{0.2in}
\noindent
{\bf Working Groups:} Reuse management, organization and economics; Domain
analysis/engineering; Design-level, model-oriented reuse.

\end{abstract}

\newpage

\section{Background}


The need for a disciplined, principled approach to software architectures
is as crucial to the DoD Software Reuse Vision and Strategy\cite{dodvision}
as the study of software
architectures is broad and multi-disciplined.  This need, when coupled with
the continual advances in a newly-emerging field of software
architectonics\footnote{Architectonics: the study of architectures.},
requires programs such as CARDS to play an active role in accelerating
technology transfer of DoD-sponsored architectonics research
efforts (such as the ARPA/DSSA program) into practice.

The Central Archive for Reusable Defense Software (CARDS) is a DoD-sponsored
program chartered to transition into practice the technology, processes and
business practices necessary to institutionalize domain-specific,
architecture-based, library-assisted software reuse \cite{crosstalk}.
The concepts and implementation of
the CARDS Command Center Library reflects this accelerated technology
transition.  The explicit representation of software architectures as the
principle organizing framework within the Command Center Library,
and the tools which manipulate these architecture models\cite{wallnau92},
represents the link between the theory and practice of architectonics.
\section{Position}

CARDS has had some success in representing software
architectures in a reuse library framework.  However, to achieve our
desired technology transfer objectives and to meet our customer's needs we
must first understand the nature of the organizations we are dealing with.
We recognize two distinct organizational dimensions which must be
addressed if we are to achieve
(and, possibly, sustain) domain-specific reuse in the DoD.  Both dimensions
(illustrated in Figure~\ref{fig:1}) must evolve in cooperation
to achieve an evolution from distributed, autonomous product centers
to a planned, managed and systematic domain-specific reuse capability of
DoD magnitude.

To support this evolution two different kinds of software architecture
representations are needed---one which captures detailed, technology-
and representation-dependent designs (i.e., product-line architectures), and
one which provides information-rich but technology-neutral correlations
among product-line architectures (i.e., domain architectures).  Current
research is already addressing the former; CARDS is developing an
ontology-based representation scheme to address the latter.

Section 2.1 elaborates Figure~\ref{fig:1} and discusses the
architecture representation requirements of product-line and
domain organizations.  Section 2.2 describes an
ontological approach supporting the domain perspective.  This
represents new and unique work as product-line architecture representation
technology is already being addressed by current research.

\begin{figure*}[t]
%   \special{PS: include "wallnau-fig1.ps"}
%\vspace{3.5 in}
\centering
\leavevmode\hbox{\epsfysize 3.7in \epsfbox{wallnau-fig1.ps}}
\caption{Product Line and Domain Organization Perspectives}
\label{fig:1}
\end{figure*}

\subsection{Architectures for two Organizational Perspectives: Into the Thickets}

\subsubsection*{Architecture Representation for the Product-Line Organizations}

The product-line organizations exist today,
and support specific DoD missions within specific application areas (for
example,
multiple product centers for Command and Control applications exist
in the DoD).  Each such organization may operate, maintain, evolve and
procure new systems as part of the normal incremental evolution and
accretion of DoD software systems.  It is important to note that there
are literally hundreds of product-line organiation within the DoD.

Organizational and technological diversity characterize the various
product centers.
Detailed expertise relative to specific products and
customers has been developed within each product center.  Lacking a
shared domain model, the terminology, concepts and approaches used
by these organizations varies tremendously.  Thus, independent of
development environment technology (which includes the use of software
architecture representation technology) there is a high-degree of
conceptual impedance mismatch among various product centers' perceptions
of the application domain.

To complicate matters further there is also great variety in the DoD
contractors which are used to
support product-line maintenance and development, the roles they play
in the product-line, and the technology and processes they use internally
(even within the scope of DoD-STD-2167a) to accomplish their objectives.
This both reflects and induces a large measure of technology diversity
among the product centers.  For example, development environment tooling
may be strongly influenced by the preferences and use of
commercially-available and proprietary software development tools and
processes by contractors.

The need to support product-center diversity in technology and procurement
is reflected in recent descriptions of the role of software architectures
in the DoD software procurement process\cite{saunders}\footnote{Actually,
Saunders does not explicitly tie the concepts in his paper to product
centers rather than domain centers.  However, applying the concepts discussed
in his paper in the current DoD organizational context---one which does not
have a strong domain management function---will result in product-line
diversity as indicated in this paper.}.
To support this diversity, any one
of a number of commercial (and research)-off-the-shelf
architecture description languages (ADLs) and toolsets might be used---the
author certainly claims no special expertise in making recommendations
about which ADL to use.

\subsubsection*{Architecture Representation for the Domain Organization}

Given the diversity of product-line specific terminology, application
concepts, development and target-environment capabilities and approaches
to software architectures, how will it be possible to evolve a coherent
domain architecture?

The domain organization, which does not currently exist (although plans
for developing domain centers do exist) will not have the luxury of
defining, from ``scratch,'' all-encompassing domain
architectures---i.e., generalizations and
unifications of the multiple product-line architectures.
Instead, domain-specific architectures will have to
evolve to accommodate the various product-line architectures because:
all of the DoD's software can not
be re-written at once; new systems (based on domain architectures) will
need to interoperate with existing systems (based on product-line
architectures), and; applications will continue to be procured
on an application-by-application basis for the forseeable future
(irrespective of the acclaimed role of domain analysis
in achieving domain-specific reuse).

One approach is to develop detailed, domain-specific technical reference
models.  Reference models, such as described in \cite{pseswg}, can provide
a wealth of information about interface standards, conventions, assumptions,
and usage models for applications; they can be used to support the
procurement of systems (or parts of systems) which adhere to some explicit
implementation characteristics.  In fact, the CARDS-defined component
qualification process makes use of a technical reference model (of command
center functional components) to evaluate the ``form, fit and function''
of components relative to domain-specific conventions and requirements.

However, technical reference models, though useful, are no substitute for
software architectures.  Architectures describe specific characteristics
of systems\footnote{It should be noted that some reference models masquerade
as software architectures, while some software architectures masquerade as
reference models: both disguises can introduce serious problems.},
including: component interconnections, data and control flow, throughput,
timing and
scheduling, fault-tolerance and security (to name a very few). Which
characteristics are described, the form in which they are described, and
the level of detail associated with their descriptions will vary across
application areas (embedded avionics will differ from information management),
product centers and systems within product centers.

There are several possible approaches to managing product-line developed
architectures within a domain organization.  First, the domain organization
could acquire the union of ADL processors and maintain the product line
architectures independently---this is a useless option.  Second, the
organization could invent or adopt a general, all-encompassing ``doomsday''
ADL, one which could
adequately express all of the characteristics described by all of the ADLs
in use across all of the DoD domains---don't hold your breath.  Third, should
no viable approach to managing architecture-representation diversity
emerge, the domain management organization could focus primarily on
technical reference models; however, this would represent a setback for
domain specific reuse within the DoD.

None of the above options are palatable.  The next section describes a
more practical and flexible approach.

\subsection{An Ontological Approach to ADL Adoption: Out of the Woods}

Rather than wait for the doomsday ADL, a more flexible approach is
to describe, in a formal model, specific characteristics of software
architectures and then map product-line software architectures
into this formal model.  This formal model would describe the elements
and relationships of the concepts which underly the representation of
software architectures---not the details of specific system
architectures.

Describing such a formal model as a {\em meta-}model for software architectures
would be accurate but not sufficiently descriptive.
This {\em meta}-model would model a theory of software architectures,
facilitate sharing and exchange (i.e., reuse) of design knowledge
(i.e., software architectures and designs)
across different technology bases (i.e., product center design tools)
and different product lines.  Such a {\em meta-}model
would in fact be an ontology\footnote{Ontology: a particular theory about the
nature of being or the kinds of existents. (Webster's Ninth New Collegiate
Dictionary.  More thorough definitions may be found in AI literature.)}
of (characteristics of) software architectures\cite{gruber}.

\begin{figure*}[t]
%   \special{PS: include "wallnau-fig2.ps"}
%\vspace{3.5 in}
\leavevmode\hbox{\epsfysize 3.8in \epsfbox{wallnau-fig2.ps}}
\caption{Ontology Fragment in Term Classifier Representation}
\label{fig:2}
\end{figure*}

A reuse library which defined, and was organized around, one or more
ontologies\footnote{For pragmatic issues related to the design of {\em good}
ontologies it may be more convenient to define several small intersecting
ontologies than to define one large ontology.} could provide numerous
encyclopedic reuse services:
\begin{itemize}
   \item{model and relate idiomatic architecture patterns such as those
         identified by Shaw and Garlan\cite{shaw}, and model
         (in the same formalism) actual systems as refinements/specializations
         of these idioms to support analysis of single systems and
         comparison of multiple systems.}

   \item{model the abstractions and semantics of specific architecture/design
         representation systems so that tool-specific semantics
         can, at least in a limited form, be normalized with
         respect to explicitly-defined, shared principles.}

   \item{relate, through formal term classification, various idiosyncratic
         vocabularies used to describe common domain ``concepts.''}
\end{itemize}

Such a reuse library might appear to be overly-visionary, but in fact
such libraries are within reach.  The reuse library framework employed
by the CARDS program--- RLF\cite{rlf}---makes use of a term
classification knowledge-representation formalism derived
from KL-ONE\cite{brachman}.  As such, the system provides a limited but
useful (certainly for the near-term) capability for describing architecture
ontologies.
A trivial fragment of an
ontology for software
architectures\footnote{The example illustrates only a fragment of an
ontology; it is not clear that this is even an ``interesting'' ontology.}
which might appear in a CARDS library is provided in Figure~\ref{fig:2}.
The reader should be able to see how some of the architectural idioms
described by Shaw, such as pipes and filters, can be represented as
specializations of components, connections and interactions.

\subsection{Summary: What's Real and What's Next}

The CARDS program has developed an architecture-based reuse library for
Command Centers.  The library makes use of a formally-encoded generic
command center architecture (GCCA), encoded in a knowledge-representation
scheme derived from KL-ONE.  The encoded software architecture
supports two automated reuse assistants.  One, the system composer, uses
the encoded GCCA to guide library users through an interactive architecture
refinement process to compose portions of the GCCA (related to message
processing); over twenty compositions are possible, with several
of these resulting in executable load images.  A second tool, the component
qualifier, uses the encoded GCCA to guide library administrators in an
architecture-tailored component qualification\footnote{We use the term
``qualification'' to avoid confusion with more widely known (but not
better understood!) term, ``certification.''} process.

The CARDS program does not {\em currently} employ an architecture ontology.
That is, we encoded the GCCA through the use of informal modeling
conventions.  As a result,
although we have developed impressive demonstration capabilities for
model-based reuse libraries, these capabilities are somewhat sensitive to
the particular form of the architecture as represented in the library model.
CARDS is undertaking
a kind of domain analysis (using Simos' Organizational Domain Modeling
approach\cite{simos}) on the field of software architectures.  Our
intention is to develop a ``starter ontology'' as a result of this work that
will allow us to generalize the composition and qualification tools, make
more systematic the development of CARDS reuse libraries by CARDS
franchisees, and provide
a basis for evolving the domain perspective illustrated in Figure~\ref{fig:1}.
As the space of possible of design notations is immense\cite{webster} the
scope of the CARDS efforts will be defined relative to a limited number
of reuse services provided by CARDS libraries; the more general discipline
of ``ontological architectonics'' will need to be elaborated elsewhere.

\section{Comparison}

\subsection{ARPA Domain Specific Software Architectures (DSSA)}

A number of
concepts being explored by the DSSA program are consistent with (and in
some cases provided the basis for) CARDS concepts.  The notion of a
domain-specific reference architecture and tool support for
the refinement of this architecture to support specific application needs
is a direct analogue to the CARDS GCCA encoding and system composer.
The notion of distinguishing between domain engineering and application
engineering functions is also shared between DSSA and CARDS.  The system
composition capabilities\cite{batory} and
type expression formalisms\cite{batorya} of the DSSA/ADAGE
system have many concepts related to the CARDS composition and modeling
formalism; however, more detailed description defies brief summary.

There are some interesting differences as well.  First, DSSA is chartered to
undertake domain analysis
and architecture definition efforts in several domains.  CARDS, on the other
hand, is not chartered to undertake domain
analysis efforts, but must instead seek out partnerships with product
centers in the DoD (a.k.a. franchises) and encourage and support them
in domain analysis, architecture recovery, and/or architecture definition.
Second, DSSA is in the process of defining a consensus ADL.
CARDS, as already mentioned, is more
interested in capturing and modeling the principles which underlie whatever
ADL(s) DSSA converges upon.  Last, DSSA is addressing a broad array of
system and software development issues, while the CARDS technology effort
is more narrowly focused on supporting architecture-based, library-assisted
software reuse.

\subsection{NASA/KAPTUR}

The notion of case-based reuse supported by KAPTUR represents a similar
view of incrementally evolving a domain knowledge base from a series
of specific application instances, as illustrated in Figure~\ref{fig:1}.
The KAPTUR system also provides a number of distinct architectural views
of systems---this is a capability which is currently under development
for CARDS libraries (in fact, the integration of KAPTUR or some of its
subsystems with RLF is being investigated by the STARS program to provide
the Army demonstration project technology support for ODM\cite{simos}).

The fundamental differences between KAPTUR and the CARDS effort---and these
differences may narrow as RLF/KAPTUR integration is explored and implemented,
concerns the use of the library toolset to support interactive architecture
refinement and system composition.  In KAPTUR the purpose of maintaining
architecture cases is to support the cognitive aspects of selecting among
design alternatives; in CARDS one purpose of encoding the GCCA was to support
library-assisted (i.e., semi-automated) composition of systems.

\subsection{ARPA Knowledge Sharing Initiative (KSI)}

The Knowledge Sharing Initiative is exploring the use of ontologies to
specify content-specific specifications shared among autonomous reasoning
agents.  The goal is to ``enable libraries of reusable components and
knowledge-based services that can be invoked over networks\cite{gruber}.''
This effort is clearly relevant to the development of software architecture
ontologies in support of the correlation and exchange of design information
developed by semi-autonomous product centers
(again, refer to Figure~\ref{fig:1}).

One significant difference in approach is that KSI
ontology specifications represent multi-lateral knowledge sharing
agreements among reasoning agents; in CARDS, the ontology is
uni-lateral and is intended (at least in the near-term) to support
systematic description efforts to support library assisted reuse. That is,
the ontology is not intended to support independently-developed
library assistance tooling.

%\newpage
\bibliography{wallnau}

\section{Biography}

{\bf Kurt C. Wallnau} is a research scientist for Paramax Systems Corporation.
He currently is system architect for the CARDS program, an Air Force program
in domain-specific reuse.  Prior to the CARDS program, Mr. Wallnau was a
member of the technical staff at the Software Engineering Institute, where
he performed research in the area of software development environments,
specifically in the area of environment integration.  Before that, Mr.
Wallnau was chief programmer of various STARS tasks, including interface
standards and user interface systems.  Mr. Wallnau was one of the principal
designers and developers of the RLF, a knowledge-based reuse library framework,
also developed by the STARS program.

\end{document}
