\documentstyle[12pt]{article} 

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


\begin{document}

\title{A Top-Down\\
Software Reuse\\
Support Environment}

\author{Sukesh Patel, William Chu, Rich Baxter, Brian Sayrs, and Steve Sherman\\
Lockheed Software Technology Center\\
Lockheed Palo Alto Research Laboratories\\
3251 Hanover Street, B/254E, O/96-10\\
Palo Alto, CA. 94304-1191\\ \\
patel@stc.lockheed.com}

\date{}

\maketitle

\begin{abstract}
The true potential of software reuse lies in providing facilities for reusing 
large scale software systems. Given appropriate tool support software engineers 
can leverage existing software investments by recovering the design of the 
software and then systematically partitioning and extracting reusable 
components from existing systems. It is also suggested that reusable components 
must be subjected to a {\em certification}
process prior to inclusion in a reuse 
library. Moreover, simply retrieving large scale reusable components from a 
library is not enough and appropriate software understanding tools must be 
provided to permit interactive component understanding and selection. 

\vspace{0.3in}
\noindent
{\bf Keywords:} Reuse, Certification, Reverse Engineering, Design Recovery, 
Restructuring.
\end{abstract}

\section{Introduction}

The potential benefits of Software Reuse has been extensively reported, both in 
commercial and defense publications and in conferences world wide
\cite{bigg89a,free87,trac88a}.
Libraries of mathematical functions (e.g., the IMSL library collection of 
mathematical routines \cite{imsl87} and Booch components \cite{booc87}
are instances of successful 
(albeit limited) reuse programs. This is what we term {\em bottom-up reuse}:
the 
development of compact general purpose software components that can be combined 
to synthesize a class of applications.

We believe that the true potential of software reuse is in exploiting the reuse 
of very large scale software systems \cite{bigg89a}. 
Although one would like reuse to 
inform the complete software life-cycle, many times such investments are cost 
prohibitive and software engineers must turn to existing systems/components for 
reuse opportunities. Disparagingly, such reuse has been termed code scavenging. 
But given appropriate tools, our belief is that incremental component 
identification and improvement supports evolutionary development and is a cost 
effective means of leveraging existing software investments. Large scale reuse 
requires {\em top-down reuse}: 
the development of tools and techniques to understand, 
certify, extract, and restructure components from existing software systems.  
Our research suggests that solutions to the following problems must be pursued 
to facilitate top-down reuse $^{(1)}$:

\begin{enumerate}
\item
	Reusable Component Extraction: Tools and techniques to understand and 
extract components from existing software systems.
\item
	Reusability Certification Procedures/Metrics: A set of documentation, 
coding, quality and reusability checks that instill confidence in reusable 
software.
\item
	Component Location and Composition Support: Processes and tools for 
designing new applications by glueing together reusable and newly developed 
software components.
\end{enumerate}

We believe that (1) and (2) are critical technologies for leveraging existing 
software investments. Issue (3) provides a framework to put pieces of the 
puzzle together, and although important, must be established in the context of 
particular applications and will not be addressed here in any depth.  This 
paper is organized as follows. We cover our key technology thrusts in Sections 
2 (software re-engineering and restructuring) and 3 (reuse certification). 
Section 4 illustrates our overall top-down reuse support environment and 
provides a context for our technology thrusts. Section 5 summarizes our 
progress.

\section{Software Re-Engineering and Restructuring}

Our first key technology thrust is software re-engineering and restructuring 
\cite{arno86}. 
Software re-engineering and software restructuring are techniques that 
facilitate the process of {\em design recovery} \cite{bigg89b}.  
Design recovery attempts to 
create design concepts and relationships based on analyzing source code and 
available software artifacts. Our approach recognizes that full scale 
automation for design recovery is difficult and instead supports tool 
development that emphasizes automation of ``routine'' chores like system 
partitioning and fact finding tasks. The principle steps that have been 
implemented are:

\begin{enumerate}
\item
	Partitioning systems based on minimizing the coupling relationships.
\item
	Extracting ADTs that act as communication links between independent 
components.
\item
	Exploiting the visibility relation to yield sets of independent 
components (If A and B both, call C and C does not contain state information, 
then copies of C can be made to yield two components \{\{A,C\},\{B,C\}\}. If C 
contains recognizable traits for state information, then \{\{A,B,C\}\} must be 
treated as a primitive component).
\item
	Exploiting cohesion properties to identify misplaced components (e.g., 
a integer add operation in a STACK package can be identified and moved to some 
INTEGER-OPS utilities package that can be with'ed)
\end{enumerate}


Ultimately, isolation of independent components facilitates complexity 
management and permits reuse/maintenance personnel to acquire system knowledge 
on a piecemeal basis. This in turn provides knowledge of past systems that can 
be used to supplement domain analysis to define application architectures.

In summary software re-engineering and restructuring technology provide the 
following services for top-down reuse:

\begin{enumerate}
\item
	Software Understanding: Large scale software is selectively displayed 
and understood.
\item
	Software Selection: Independent components can be recognized and 
extracted and reused in different contexts.
\item
	Software Translation: Existing software must be super-imposed with 
different structural views (e.g., a system in C must be partitioned into CSCIs, 
CSCs, CSUs, ADTs etc.) before the system can be syntactically converted to 
Ada$^{(2)}$.
\item
	Software Generalization: Software components comprised of independent 
sub-components can be recognized and generalized by domain experts.
\end{enumerate}

\section{Reuse Certification}

Reuse certification seeks to extract domain specific characteristics of 
software components at all levels of abstractions that help to facilitate 
reuse. In general, reusable software is quality software. Our strategy for 
certification has been to survey characteristics of software components that 
encourage reuse and then attempt to provide automated techniques for ensuring 
that reusable software complies with or displays the required characteristics. 
In cases where automated detection is ineffective or cost-prohibitive, 
check-lists must be designed and manual procedures must be outlined as part of 
a reusable software inspection process. For example, semantic checks can be 
developed to recognize incomplete or inconsistent components.

Aspects of the certification process that can be automated are:

\begin{enumerate}
\item
	Documentation Standards. Documentation prologues and certain 
consistency checks on documentation (e.g., checks can be automated to ensure 
that a module's call list is complete (all calls are mentioned) and consistent 
(mentioned names are called somewhere in the program body)). Enforcement of 
Variable and Type naming standards etc..
\item
	Identification of system dependent features like primitive type 
representations and the use of primitive I/O packages.
\item
	Path analysis to determine if functions and procedures return valid 
results on all logical paths.
\item
	Measurable system quality indicators (cohesion, coupling, and 
complexity)$^{(3)}$.
\end{enumerate}

Notice that the above checks not only facilitate software reuse but are also 
required to ensure quality software. Our research indicates that there are two 
facets of reusable software: (a) a quality facet that all software should 
satisfy (simple interface, minimal complexity, minimal testing complexity, 
etc.); and (b) a domain appropriateness facet that determines to a large extent 
whether a piece of software can be used in several applications (e.g., a 
generalized stack is such a component). The later facet is much more difficult 
to recognize and evaluate. Issues here include:

\begin{enumerate}
\item
	Component Granularity: Is this component a valid primitive in the 
domain, or does the component require further decomposition into primitive 
operations and primitive data elements?
\item
	Component Naming Conventions: Given a potentially reusable component, 
are the objects and operations named with semantically meaningfully taxonomic 
terms?
\item
	Component Flexibility: Are the objects and operations sufficient to 
synthesize required components in many situations?
\item
	Component Generality: Is the component applicable to various problem 
situations?
\end{enumerate}

In view of the difficulty of recognizing the domain specific attributes of 
reusable components we have initiated a research project for circumscribing the 
domain appropriateness facet. More specifically, we have initiated a pilot 
project whereby software engineers and researchers will interact with experts 
in particular domains and establish a set of enforceable guidelines that can 
help the process of identifying reusable software as (i) either one of the 
output of domain analysis, or (ii) extracting such components from existing 
systems. Certain progress has been made for (ii) at the Software Productivity 
Consortium \cite{arno90}  
and we shall extend both the scope and applicability of this 
research.

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

\section{Overall Approach}

Fig. 1 depicts the support necessary for depositing components into a reuse 
repository. As shown in Fig. 1 reusable components are generated from two 
primary sources: (1) the extraction and restructuring of components from 
existing systems written in conventional imperative languages (C, Fortran, and 
Ada), and (2) the development of domain specific components given broad 
knowledge of intended applications.

Given a collection of reusable components, we must provide for some means to 
organize these components in a user friendly manner. Software components can be 
organized as appropriate to the intended applications: (a) a large set of 
independent domain specific components for libraries, and (b) organization 
along application architectures for narrow domains. Library organization is 
common and is not discussed further.

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

Fig. 2 displays our vision of structures to support the reuse of existing 
components for narrow domains.  This vision follows the design memory metaphor 
outlined in \cite{mark91,mark90}  
and seeks to provide designers a platform for visualizing and 
inferring the consequences of design decisions. A user typically enters the 
reuse environment and is given a top level view of a typical application 
architecture. The architectures displays the principle top-level architectural 
components, their associated information flows and relationships, and the 
top-level storage structures. Components that be further decomposed into 
sub-components are shaded. Such components have sub-components that may be 
organized and controlled to perform the task required of the higher level 
component. Components that are hatched indicate that there is no available 
executable image associated with the module$^{(4)}$. 
This can occur when a component 
is {\em functionally coupled} \cite{stev74} 
to environmental objects that are likely to 
change; for example a set of routines that read radar sensors and organize the 
data in specific formats. 

For existing software systems without an associated knowledge base, the system 
hierarchy is generated by reverse engineering tools that act as selective 
display mechanisms. Here the system provides little inferencing ability but 
allows a user to traverse the system and select components of various 
granularity. 

	\section{Conclusions}

In this paper we have illustrated a promising architecture for solving problems 
associated with large scale reuse. Currently, we are tackling both angles of 
our overall approach (Figs. 1 and 2). We are in the process of developing a 
prototype system that can accomplish the objectives of Fig. 2 for the 
{\em target 
tracker domain}. Here our intent is to provide knowledge based support for 
enhancing reuse opportunity. We have made substantial strides in re-engineering 
and restructuring technology. We have applied our techniques to large software 
systems in C and Ada with encouraging results. Currently, we are actively 
involved in the following: (1) refining our re-engineering and restructuring 
capabilities and expanding the scope of our techniques by experimenting with 
other imperative languages like COBOL and FORTRAN, and (2) establishing 
cooperative efforts to flesh out reuse certification procedures.



\begin{thebibliography}{arno86b}
\bibitem[Arno 86]{arno86}
 R.S. Arnold (Ed.), Tutorial: On Software Restructuring, IEEE Press, Washington 
D.C., 1986.
\bibitem[Bigg 89a]{bigg89a}
 T. J. Biggerstaff, \& A. J. Perlis (Eds.), Software Reusability Volume 1: 
Concepts and Models, and Volume 2: Applications and Experience, ACM Press, 
Addison-Wesley Publishing Company, New York, NY, 1989.
\bibitem[Bigg 89b]{bigg89b}
 Biggerstaff, T. J., ``Design Recovery for Maintenance and Reuse'', IEEE 
Computer, July 1989, pp. 36-49.
\bibitem[Booc 87]{booc87}
 G. Booch, Software Components with Ada: Structures, Tools, and Subsystems, The 
Benjamin/Cummings Publishing Company, Inc., Menlo Park, CA., 1987.
\bibitem[Free 87]{free87}
 P. Freeman (Ed.), Tutorial: Software Reusability, IEEE Press, Washington D.C., 
1987.
\bibitem[IMSL 87]{imsl87}
 IMSL Inc., Library Reference Manual, Houston TX, 1987.
\bibitem[Mark 91]{mark91}
 Mark, W., ``Software Design Memory'', Proc. Workshop Notes AAAI-91: Automating 
Software Design: Interactive Design, AAAI, Anaheim, CA., July 15, 1991, pp. 
115-120.
\bibitem[Mark 90]{mark90}
 Mark, W., \& Schlossberg, J., ``Interactive Acquisition of Design Decisions'', 
Proc. 5th Knowledge Knowledge Acquisition for Knowledge-Based Systems, Banff, 
Canada, Nov. 1990.
\bibitem[Neig 87]{neig87}
 Neighbors, J.M., ``The Draco Approach to Constructing Software from Reusable 
Components'', In P. Freeman (Ed.), Tutorial: Software Reusability, IEEE Press, 
Washington D.C., 1987, pp. 181-191.
\bibitem[Pate 92]{pate92}
 Patel, S. J., Chu, W., and Baxter, R. W., ``A Measure for Composite Module 
Cohesion'', Submitted, Proc. 14-th Intl. Conf. Soft. Engr., Melbourn, 
Austrilia, 1992.
\bibitem[Prie 88]{prie88}
 Prieto-Diaz, R., ``Domain Analysis for Reusability'', InW. Tracz (Ed.), 
Tutorial: Software Reuse: Emerging Technology, IEEE Press, Washington D.C., 
1988, pp. 347-353.
\bibitem[Arno 90]{arno90}
 Software Productivity Consortium (Author: R.S. Arnold), ``Heuristics for 
Salvaging Reusable Parts from Ada Source Code'', SPC Tech. Report: Ada Reuse 
Heuristics-90011-N, Version 01.00.00, March 1990.
\bibitem[Stev 74]{stev74}
 Stevens, W. P., Myers, G. J., \& Constantine, L.L., ``Structured Design'', IBM 
Systems Journal, Vol. 13, No. 2, 1974, pp. 115-139.
\bibitem[Trac 88a]{trac88a}
 W. Tracz (Ed.), Tutorial: Software Reuse: Emerging Technology, IEEE Press, 
Washington D.C., 1988.
\bibitem[Trac 88b]{trac88b}
 Tracz, W., ``Software Reuse Myths'' in W. Tracz (Ed.),  Tutorial: Software 
Reuse: Emerging Technology, IEEE Press, Washington D.C., 1988, pp. 18-22.
\end{thebibliography}

\section{Notes}

\begin{enumerate}
\item
As noted in Tracz [15], management and economic reasons can also hinder 
software reuse. However, in the following we assume the existence of 
appropriate management structures that encourage and reward software reuse.
\item
Ada is a registered trademark of the U.S. Government (Ada Joint Program 
Office).
\item
We have successfully developed a metric for module cohesion [10]. We have 
also established some criteria that  lead to undesiriable coupling and are in 
the process of proposing a measure for module coupling.
\item
Note that it is not necessary to always have a executable object file of 
the component. Rather the component may itself be a application generator or 
some expert system that can synthesize the required executable image.
\end{enumerate}

\section{About the Authors}

Dr. Sukesh Patel is the  Principal Investigator for the Software Reuse and 
Maintenance project at Lockheed's Software Technology Center (STC). Sukesh 
received his B.S. in Electrical Engineering from Sardar Patel University
(India) and his M.S. and Ph.D. degrees in Computer Engineering from the Center
for Advanced Computer Studies at the University of Southwestern Louisiana. His 
primary interests are design automation, design recovery, and the development 
of evaluation techniques for large scale hardware and software systems. Sukesh 
is a member of the IEEE and AAAI societies.

Dr. William Chu received his B.S. degree from the Tamkung University (Taipei, 
Taiwan) in 1982 and his M.S. and Ph.D. degrees from Northwestern University, 
Evaston, Illinois in 1987 and 1989, respectively, all in computer science. He 
is currently a research scientist at the Software Technology Center of Lockheed 
Missiles and Space Company, Palo Alto, California. His current interests are 
software maintenance and reuse, with special focus on software re-engineering 
and restructuring, software engineering, and software quality.

Mr. Rich Baxter received his M.S. degree in Computer Science in 1985 from the 
New Mexico Institute of Mining and Technology (NMIMT). Mr Baxter joined 
Lockheed Missiles and Space, Co. (LMSC) Research and Development Division's 
Software Technology Center's (STC) Ada Technology group as a Scientific 
Programmer/Analyst in 1988. Mr. Baxter is participating in several Ada related 
internal research and development (IRAD) projects in the STC including the 
Software Reuse in Large Ada Systems project. As a member of the Ada technology 
group, Mr. Baxter is actively participating in the group's infusion of Ada 
technology into LMSC and other Lockheed companies. Mr. Baxter has co-authored 
several papers dealing with Ada Software topics while at Lockheed. Mr. Baxter 
has been a member of the ACM since 1981 and of the IEEE Computer society since 
1989.

Mr. Brian Sayrs is the principal investigator for Software Re-engineering at 
the Software Technology Center (STC). Brian has been involved with several 
software re-engineering projects and is currently developing methods and 
techniques for integrating forward and reverse engineering.

Dr. Steve Sherman is manager of the Software Technology Center (STC), Research 
and Development Division, Lockheed Missiles and Space Company (LMSC). Dr. 
Sherman received his B.S. in Mathematics from North Carolina State University. 
After working for Pratt \& Whitney in West Palm Beach, FL, Dr. Sherman joined 
the University of Wisconsin where he received his M.S. in Computer Science in 
1968. Dr. Sherman worked for Sandia Corporation in the systems and nuclear 
simulation groups in Albuquerque and subsequently received his Ph.D. in 
Computer Science from the University of Texas at Austin in 1972. His 
dissertation addressed the simulation of operating system heuristics for 
performance prediction.

Dr. Sherman taught at the University of Houston for 2 years in the Computer 
Science Department and left on leave in 1974 to work for the Institute for 
Computer Applications in Engineering at NASA Langley in Hampton, VA where he 
conducted research in data base management. In 1976, Dr. Sherman joined the 
University of Nevada at Las Vegas as a faculty member in the Computer Science 
department and was promoted to full professor in 1984.In 1985, Dr. Sherman 
joined LMSC working for the STC in Austin, Texas where he led the technology 
transfer group and the Ada environment project. In 1987, STC teamed with the 
Space Systems Division (SSD) of LMSC to merge the Ada environment with SSDs 
language independent software engineering environment. In 1988 Dr. Sherman led 
his group to support a Lockheed Space Operations Company proposal and training 
effort. Dr. Sherman led the Software Automation research group in Palo Alto and 
his current group, also in Palo Alto, is conducting research in software 
engineering.
\end{document}

