\documentstyle[12pt]{article} 

\topmargin=-0.25in
\textheight=8.75in
\oddsidemargin=-0.25in
\evensidemargin=-0.25in
\textwidth=7.0in


\begin{document}

\title{ Process and Products for Software Reuse and Domain Analysis}

\author{Sholom Cohen\\
Software Engineering Institute\\ 
Carnegie Mellon University\\
Pittsburgh, PA 15213\\ \\
email: sgc@sei.cmu.edu}

\date{}

\maketitle

\begin{abstract}
The adoption of reuse into software development will include the definition of
new products and processes.  On the product side, we must identify the form of
deliverables that can support reuse; on the process side, the approach needed
to develop and apply those products.  In order to move from the current, 
{\em ad-hoc} 
approach to reuse, to a systematic reuse process, we must be able to both 
abstract a problem domain and create reusable solutions.  The solutions can
then be used in the development of a range of systems in the domain.

Each of the next three sections will examine the processes and products that
can lead to successful reuse.  The first process, one widely used today, is to
adapt an existing system to meet a new set of requirements.  The second, a
relatively new practice, identifies families of programs, providing support for
parameterization of commonality, and customization for unique requirements. 
The third process is an abstract-based engineering approach to discover and exploit
commonality in software systems as the basis for software development.  Figure 1
compares these three approaches.

Each process offers its own set of benefits and risks.  The {\em 
adaptive} approach
(Figure 1-a) requires little new investment by an organization, and,
can support new developments, provided they require only incremental changes
from previous applications.  However, applications that require major
modifications and upgrades typical of most aerospace applications, will only
achieve marginal benefits from adapting old software.  The 
{\em parameterized}
approach (Figure 1-b) establishes a framework for all new
implementations, a major investment for an organization.  There is a
significant pay-off, provided the framework is stable.  However, in areas with
rapidly evolving technology, there is no stable framework.  The investment in
establishing standard products may be at risk if new requirements do not fit
previously established standards.  Like the parameterized approach, 
{\em engineered reuse} (Figure 1-c) requires a large investment.  The 
domain resources must meet the requirements of a wide range of applications or
this investment will also be at risk.  If the resources are properly developed
this approach offers a greater degree of flexibility than the
parameterized method, and can adapt to changing requirements.  The following
discussion explores each approach in depth.
\end{abstract}

\section{The Adaptive Approach to Software Reuse}

The most common form of reuse in practice is the sharing of design and
code between similar projects.  Most organizations performing software
development build new applications using previous developments as a starting
point.  In some cases, such as prototyping or modification, this adaptive
approach is planned, and reuse of software is a natural occurrence.  In others,
the ability to reuse software from one development to the next is assumed, but
often not fully realized due to inconsistencies between current and previous
projects.  
                                                                       
In adapting previous designs to new requirements, developers must be aware that 
these new requirements will mean significant modification to the existing
application.  If the application was not built to support subsequent
modification and reuse, the adaptation may be as costly as a complete redesign. 
This was the lesson learned from the P-7A project, and it applies in software
development, as well.

\begin{figure}
\vspace{11in}
\end{figure}

A process model for adaptive software reuse (Figure 1-a) shows
different paths that this approach may support.  For example, a developer may
wish to modify an existing software system to incorporate new requirements. 
The software taken from the original system is ``reused software,'' in the sense
that it has come from a previous development.  Similarly, when porting an
existing system to a new platform, developers reuse the old software, making
necessary changes to achieve compatibility.  While the reuse of software not
explicitly designed for reuse has been called ``software
scanvenging'' such reuse is very common \cite{trac90}.

The adaptive approach can be systematized for process improvement by:

\begin{itemize}
\item
Applying standard software engineering techniques to build modular software to
increase adaptability
\item
Classifying existing software by projects, and indexing that software to 
increase awareness and lead to more effective reuse
\item
Organizing test and evaluation software to support decisions about
applicability
\item
Utilizing CASE tools and re-engineering to facilitate customization and
integration of reused and new software
\end{itemize}

While the adaptive process can be ad hoc, these steps will improve the value of
existing software and increase the ability to reuse that software.

\section{Parameterized Reuse and Program Families}

The identification of classes of program families can lead to significant
levels of reuse.  This approach has proved to be extremely successful in 
organizations that deliver large systems to a broad range of customers to meet
similar sets of requirements.  The successes in reuse attributed to the
Japanese all stem from establishing a common architecture for a family of
systems that can be applied through parameterization to a wide class of users.

This approach is illustrated with a particular program family, that of the
Air Traffic Control (ATC) system.  The reuse work on these systems done by
Thomson-CSF shows the potential payoff of the parameterized form of reuse. 
The approach is illustrated in Figure 1-b.  Under this process,
standard products can be used to create new systems, through parameterization. 
A second use of these products is for more traditional reuse, following the
adaptive approach.

\subsection{Identifying the family}

The successful identification of a family of related systems in the ATC domain
is illustrated by by reuse technology developed by the Thomson-CSF company. 
The first step in applying the process to the ATC domain is to scope the domain
according to its generic properties (i.e., what features do all systems in the
domain have in common).  The feedback diagram of Figure 2
illustrates the common features of most ATC systems.

The real world environment, labeled Actual System State, consists of all of
the entities controlled or used by the ATC system.  These entities include:
aircraft, radars, flight planning operational input, weather reports, etc.  The
data managing function must handle these entities, organizing them into a
coherent representation of the system state, and making them available to other
system functions.  The long-term planning function will use this data to
establish the desired state for the area controlled by the ATC system over a
long-term (on the order of hours) basis.  The controlling function performs
similar operations, over a duration measured in minutes.  Commands from the
controlling function to effect the desired system state go to system elements,
such as aircraft or to the database to update the current state.  These
commands will, indirectly, update the actual system state, as well.

By illustrating the primary components of an ATC system, the feedback diagram
provides support for scoping the domain for further analysis.  In the work done
by Thomson-CSF, the domain of interest covered three areas:

\begin{enumerate}
\item
Radar operations: processing radar sensor return data to establish aircraft
tracks and reports.  This data is labeled as the sensor feedback from the
actual system state in Figure 2
and is handled by the data
management function.
\item
Flight operations: flight plan, weather and other information forwarded to the
ATC system.  This includes the data labeled as observer feedback in Figure
2
and also covers output labeled as element actions on the
figure, which is also fed back to the data managing function.
\item
Operator interface: software facilitating the processing performed by ATC
operators.  This interface permits the operator to obtain current information
about the system state, via the data managing function, and to
perform controlling functions.
\end{enumerate}

\begin{figure}
\vspace{6.0in}
\end{figure}

\subsection{Developing a parameterized architecture}

The next step in the parameterization process is to establish common
functionality and data flow within the domain areas defined within this scope. 
Figure 3 illustrates the need of all ATC systems for both flight
plan and radar tracking data in order to provide operators with the information
required to support air traffic control activities.  The figure also provides
information on the interfaces of components of the system and a context for
each of the three domain areas.

Recognizing that this functionality is common across a range of systems built
for ATC, Thomson-CSF has constructed a generic architecture of large scale Ada
components to implement new systems.  This architecture is represented in
Figure 4, and currently accounts for 20\% reuse among installed
systems.  The company hopes to achieve 50\% reuse, the approximate figure also
attained by Japanese firms, by supporting reuse within the operator interface
subsystem.

The Thomson-CSF architecture uses three sets of reusable packages in
constructing its ATC systems.  These correspond to support packages for each of
the three domain areas (radar, flight planning, operator interface) described
above.  The domain analysis approach also supports identification of
commonality between the individual areas.  This commonality is captured in
a common utilities package that is a part of the architecture within each
domain area.


\begin{figure}
\vspace{5.0in}
\end{figure}


\section {Engineered Reuse}

While parameterized reuse is appropriate in mature domains, reuse in domains
that rely on emerging technology cannot standardize at the same level of
parameterization.  Applications within such a domain, sometimes called
``unprecedented applications,'' rely on new techniques such as domain analysis to
establish commonality and enable software reuse.  Implementation approaches,
such as objected-oriented design and programming also play a significant role
in the support of reuse.  These techniques form the process of Engineered
Reuse, as shown in Figure 1-c.  Engineered reuse in terms of domain
analysis is discussed below using the ATC problem as an example.

\subsection{Domain Analysis}

The  systematic discovery and exploitation of commonality across related
software systems is a fundamental technical requirement for achieving
successful software reuse.  Domain analysis is one technique that can be
applied to meet this requirement.  By examining related software systems and
the underlying theory of the class of systems they represent, domain analysis
can provide a generic description of the requirements of those systems.  It can
also propose a set of approaches for implementation of new systems in the
class.

The development of complex aerospace software systems requires a clear
understanding of desired system features and of the capabilities of those
features.  Software reuse, which has long promised improvements in this
development process, will become feasible only when the features and
capabilities within the domain of a particular system can be properly defined
in advance of formal software development of the system.  Thus,
the need to develop domain analysis technology and apply it within specific
software development programs is a factor that can promote software reuse for
those programs.  


\begin{figure}
\vspace{5.0in}
\end{figure}


\subsubsection{Domain Analysis Process}

Domain analysis gathers and represents information on software systems that
share a common set of capabilities and data.  Three basic activities
characterize this process:


\begin{figure}
\vspace{8.5in}
\end{figure}


\begin{itemize}
\item
Scoping: defining a domain for analysis
\item
Domain modeling: providing a description of the requirements met by software
within the domain
\item
Architectural modeling: creating the software architecture(s) that implements
a solution to the problems in the domain
\end{itemize}

The domain analysis process must also be integrated into the more general
process for software development.  The domain analysis can then support
implementation of applications in the domain, creation of reusable resources,
and support for creation of domain tools and training.  Figure 5
illustrates the support that domain analysis provides to the software
development process.


\subsubsection{Domain Analysis Products}

The domain analysis method should provide specific representations to document
the results of each of the domain analysis activities.  These representations
should describe the problems solved by software in the domain and architectures
that can implement solutions.  

For each of the three phases of the domain analysis process, there is a
separate set of representations or views of the domain.

\begin{itemize}
\item
Scoping: The results of this phase should provide the context of the domain. 
This requires representing the primary inputs and outputs of software in
the domain as well as identifying other software interfaces.  Figure
2 illustrates the scoping of the ATC domain.
\item
Domain modeling: The products of this phase describe the problems addressed by
software in the domain.  The products provide the typical vocabulary of domain
experts, document the entities embodied in software, and establish generic
software requirements via control flow, data flow, and other specification
techniques.  Figure 3 supports domain modeling.

Architectural modeling: This phase establishes the structure of
implementations of software in the domain.  The purpose of these
representations is to provide developers with a set of models for constructing
applications.  They can also guide the development of libraries of reusable
components.  Figure 4 provides the basis of a common architecture
for ATC systems.
\end{itemize}

The next subsection describes a specific method for domain analysis that covers
the three phases of domain analysis.

\subsection{Feature-Oriented Domain Analysis}

The Software Engineering Institute is currently refining a method for
discovering and representing commonalities among related software
systems \cite{kang90}.  The {\em Feature-Oriented Domain Analysis}
(FODA) method
stresses the identification of prominent or distinctive {\em features} of a
software system.  These features are user-visible characteristics of the domain
and include both common aspects of the domain as well as differences among
related systems in the domain.  Features are also used to define the domain in
terms of the mandatory, optional, and alternative characteristics of these
related systems, leading to the creation of a {\em feature model}.  The feature
model establishes rationale for selecting a feature, rules concerning the
composition of two or more features, and the effect of {\em binding} time of a
feature within an application.

\subsubsection{The feature model concept}

Figure 6 illustrates each of the concepts regarding features, their
interrelationships and attributes:

\begin{itemize}
\item
Horsepower and transmission are mandatory features.  All cars must have a power
supply and a way to turn that power into forward motion.
\item
Air conditioning is an optional feature.
\item
The selection of manual or automatic transmission represents a choice between
alternative features.
\item
If the air conditioning feature is selected, it may require a more powerful
engine, illustrating the concept of composition of features.
\item
The choice between transmission features could be based on issues such as fuel
efficiency or ease of operation. 
\item                          
The choice of transmission may be bound, i.e., installed, at the factory. 
Porsche, however, offers a special feature called the Tiptronic transmission,
that offers binding of the transmission feature while the car is in operation.
The driver may select automatic transmission for ease of operation in heavy
traffic and can {\em shift} to manual for open road driving.
\end{itemize}


The next subsection describes the application of the feature method to
domain analysis.  A domain analysis of window manager software, fully
documented in \cite{kang90}, illustrates the use of the method.

\subsubsection{Applying the feature method to domain analysis}

The FODA method establishes a {\em context analysis} phase as the process for
scoping a domain.  There are two products of this phase:

\begin{enumerate}
\item
Context diagram: data flow showing primary inputs and outputs of the domain. 
Figure 7 shows a context diagram for the window manager
domain.  
\item
Structure chart: showing related software.  For the window manager domain, the
structure chart shows the relationship between window manager software, other
applications, graphical user interface software (e.g., OpenLook, Motif),
toolkits, and programming interfaces (e.g., Xlib), protocols, servers, and
clients.
\end{enumerate}


\begin{figure}
\vspace{11in}
\end{figure}


The products of the domain modelling phase define the operations, mission, and
interfaces of the domain:

\begin{enumerate}
\item
Entity relationship model: defining the entities (objects) of the domain.  For
the window manager, these include the screen, main window, icon, pointer and
process.  The model also defines relationships and constraints on these
entities.
\item
Feature model: shows the operations and mission of software in the domain. 
For the window manager the operations include: create, destroy, move, resize,
iconify (optional), deiconify (optional), etc.  This model also includes
composition rules and textual documentation of feature definitions.  For
example, if a window manager has the optional iconify feature, it must also
have the deiconify feature.  Mission information includes information about user
feedback, the ability to move windows off a screen, horizontal/vertical
constraints on the move operation, etc.  Figure 8 shows the
model of the window manager domain for the move feature.  The boxed in regions
identify features of particular window managers.  Note the selection of both
alternatives under interactive feedback for the X10/uwm window manager; this
illustrates a binding time attribute of the feature.  A user may select either
type of feedback before executing the move.  In the other feature model, this
binding to the feature occurs when the window manager is initiated; it cannot
be changed during execution.
\item
Functional model: control and data flow for each operation in the domain
\item
Domain terminology: a dictionary of standard terms 
\end{enumerate}


\begin{figure}
\vspace{5.0in}
\end{figure}

The FODA report presents a method for defining an architectural model of the
domain.  For the window manager domain, this architecture relies upon the Xlib
and toolkit.

\section{Lessons Learned}

The methods and products of both the parameterized and engineered processes can
lead to successful reuse.  Under both approaches, the goal is to create a
common structure for application development.  For air traffic control 
systems, this structure was the basic architecture for a complete
implementation; from this base level, up to half of a system can be built. 
Using these two approaches for guidance, reuse methods can succeed when:

\begin{enumerate}
\item
The domain of applicability is appropriate, large enough to meet the needs of
typical applications, yet tractable in scope;
\item
The analysis attempts to abstract the requirements from the application level
(ATC or window manager) to the problem level (control of system state); and,
\item
The products provide documentation of the problem abstraction and guidance in
tailoring the abstraction to meet specific requirements.
\end{enumerate}

Nonetheless, software reuse does not come without some costs.  The building of
reusable resources, or of mechanisms to improve reuse of existing resources,
requires a major investment.  Furthermore, the reuse process must limit or
eliminate inappropriate reuse.  A failure in reuse engineering could result if:
the wrong software is assumed capable of reuse in a new development, or
reusable software is used incorrectly in a new development

There are several general goals that must be addressed to achieve a successful
method for domain analysis, as well.

\begin{itemize}  
\item
Developing domain analysis products to support implementation
of
new applications.  This goal will be met when domain analysis products are used
in new implementations.             
\item
Establishing domain analysis methods to produce these products.  This goal will
be met when domain analysis methods are incorporated into the software
development process.
\end{itemize}

Given the results of domain analysis, the process of engineered reuse must now
create specific resources--software components.  The application of reuse
design principles is covered in several other technical
reports \cite{cohe90,palm90}.

A model of software reuse must include both a process and products to ensure
the availability of the correct software and support for using it correctly. 
The software engineering community must identify a standard process for
developing and applying software for reuse to overcome technical barriers to
the widespread adoption of reuse.  The product development must promote a
common understanding of: (1) the problem space of applications in a domain; and
(2) the solution space for implementing new applications.

To establish an appropriate model for reuse, the software engineering
community can take the following steps:

\begin{itemize}
\item
identify major application areas appropriate for establishing a model of the
problem domain and its context 
\item
perform analyses of these problem domains (i.e., domain analysis)
\item
establish one or more generic architectures that can be used for implementation
of applications in each domain (i.e., architecture modelling)
\item
establish and adopt a common approach to design for reuse in Ada
\item
build resources to support reuse (e.g., code generators, components, reference
models) within and across domains
\item
provide guidance to the practitioner through handbooks that capture reuse
knowledge and document the means of applying that knowledge \cite{trau89}.
\end{itemize}

These steps can help advance the state of the technology of reuse from its
current {\em ad hoc} position to a managed and controlled state.  Moreover, by
building reuse into an overall model for software development, these steps
will promote an approach to software engineering that is built upon reuse
technology. 


\begin{thebibliography}{cohe90}
\bibitem[Cohe90]{cohe90}
Sholom, G. Cohen. {\em Ada Support for Software Reuse}, Special report
CMU/SEI-90-SR-16, Software Engineering Institute (also available
via ftp from ajpo.sei.cmu.edu), Pittsburgh, PA, October, 1990.
\bibitem[Kang 90]{kang90}
Kyo C. Kang, Sholom Cohen, James A. Hess, William Novak, A. Spencer
Peterson. {\em Feature-Oriented Domain Analysis (FODA)
Feasibility Study}.  Technical report CMU/SEI-90-TR-21,
Software Engineering Institute, Pittsburgh, PA, November, 1990.
\bibitem[Palm 90]{palm90}
Constance Palmer, et al.  {\em Developing and using Ada parts in 
real-time embedded applications}.  CAMP-3 Report Contract
No. F08635-88-C-0002, McDonnell Douglas
Astronautics Company, St. Louis, MO, April, 1990.
\bibitem[Trac 90]{trac90}
William Tracz.  Where does reuse start?  {\em ACM SIGSOFT 
Software Engineering Notes} 15(2):42-46, April, 1990.
\bibitem[Trau 89]{trau89}
Joseph Traub. {\em Scaling up: a research agenda for software engineering}.
National Research Council. National
Academy Press, Washington, D.C., 1989.
\end{thebibliography}

\end{document}

