\markboth{Bhansali}{Bhansali}
\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{Bhansali}{Bhansali}
\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{Reusing Software Design : A Generic Architecture-based Approach}

\author{Sanjay Bhansali\\
\\
Knowledge Systems Laboratory, Stanford University\\
701 Welch Road, Building C, Palo Alto, CA 94304\\
Tel: (512)-331-3541,(415)-723-8387\\
Email: bhansali@austin.slcs.slb.com, bhansali@hpp.stanford.edu\\}
\date{}

\maketitle

\begin{abstract}

We are attempting to build a framework and computational
environment to assist software designers in designing software systems
efficiently and reliably. Our approach is based on abstracting the
design as well as the process involved in designing a software system
and reusing them to design new systems. The emphasis is on building an
environment in which the system acts as an assistant that delivers the
relevant knowledge to a designer so that he or she may make informed
decisions. Our work  may be characterized as a semi-formal approach
that aims to create a system that would be usable by software designers who
are not well-versed with formal methods.

\vspace{0.2in}
\noindent
{\bf Keywords:} Reuse, software design, domain analysis, software process.

\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Networking and exchanging ideas with other
researchers in similar areas, identifying problems of
practical as well as  theoretical interest in software reuse.



\vspace{0.2in}
\noindent
{\bf Working Groups:} Domain analysis/engineering, Tools and
environments, Reuse process models.

\end{abstract}

\newpage

\section{Background}


I am interested in the application of novel techniques and tools for
improving the efficiency and quality of software development through
reuse. My earlier research in this area was concerned with issues of
reuse in the context of program synthesis. Specifically, I
investigated how a program synthesizing system could be made more
efficient by reusing the derivation history of analogous programs that
had been
synthesized earlier\cite{BhHa93}.
Subequently, I have become interested in issues involved in the design
of large software systems.
 I am currently co-leading the KASE (Knowledge Assisted Software
Engineering) project at the Knowledge Systems Laboratory, Stanford
which is engaged
in building a knowledge-based environment that can assist software
designers to design systems by reusing generic software designs
represented as generic architectures \cite{BhNi92,Bha93}.

I am also interested in software processes and issues concerning the
reuse of processes in a process-driven environment.
I have been involved (in collaboration with
Pankaj Garg at Hewlett-Packard Laboratory) in the design and implementation of
a system that can support the automated generation of process
fragments by generalizing a sequence of user activities in a work
session \cite{GaBh92}.

\section{Position}

One of the most effective principle for reuse is the principle of
{\em abstraction}. Abstraction consists of extracting the inherent,
essential aspects of an artifact, while hiding its irrelevant or
incidental properties. It fosters reuse by providing a class of
artifacts that can be instantiated or customized to produce several
different artifact instances meeting different requirements.
The abstraction principle can also be used to automate the
construction of artifacts that would normally require a creative
process. Examples of successful application of this principle can be
found in commercially available expert system shells, application
generators, and more recently in algorithm synthesis \cite{Smi90} in
the KIDS system which contains abstractions of several different
classes of algorithms in the form of algorithm theories which can be
(semi-) automatically instantiated to synthesize specialized
algorithms for different problem instances.

The goal of the KASE project is to support software designers in
designing software systems more efficiently and more reliably. We believe
that designing software systems is a creative and ill-understood
process that is performed by a small group of designers. However, the
process and the final design is typically not well documented leading
to poor reuse and expensive maintenance. Our approach to this problem
is based on abstracting
both the software system design and the design process. In brief, our
approach consists of (1) identifying useful classes of software
systems and the problems they solve, (2) abstracting the design of the
system as a generic architecture for that class of problems, (3)
abstracting the design process in the form of rules and procedures for
customizing the generic architecture based on specific problem
descriptions, (4) providing a computational environment that enables
designers to construct specific systems semi-automatically by
customizing the generic architecture.

A guiding theme in our research is to provide a set of software tools
that support the way humans design. The objective is to produce a
mixed-initiative system in which the design task is divided between a
human designer and the system. Typically, KASE provides design
alternatives and default suggestions for architectural parameters,
explanations for its suggestions, dependency maintenance between
different design decisions, and consistency checking. The human
designers determines the order in which the various design actions are
initiated, the final choice for each design decision (which may or may
not be based on the suggestions offered by KASE), and steps to be
taken when a design inconsistency is reported. In essence, KASE acts
as an assistant that delivers the relevant knowledge in the
appropriate context to a designer so that he or she can make informed
decisions and helps the designer in detecting errors early in the
design process.

Figure ~\ref{f:overview} shows an overview of the KASE system. The
shadowed boxes represent knowledge components that are part of KASE.
Figure~\ref{f:process} illustrates the process of synthesizing systems
using KASE.


\begin{figure}
\centering
\leavevmode\hbox{ \epsfbox{bhansali-fig1.ps}}
%\vspace{4in}
%\centerfig{bhansali-fig1.ps}
\caption{Overview of the KASE system}
\label{f:overview}
\end{figure}


\begin{figure}
\centering
\leavevmode\hbox{ \epsfbox{bhansali-fig2.ps}}
%\vspace{2in}
%\centerfig{bhansali-fig2.ps}
\caption{Process model for synthesizing software systems using KASE.}
\label{f:process}
\end{figure}

A designer initiates the design process by first selecting a {\em generic
architecture} from a library based on the {\em problem class} for his
particular problem and the desired {\em solution features}. Each problem
class has an associated specification in the form of a {\em problem-class
schema} as well as a {\em problem-class model}. An individual {\em
problem instance} is
specified by instantiating the problem class schema; the problem class
model contains the vocabulary of terms that help in the instantiation.
Associated with pairs of generic architectures and problem classes is
{\em customization knowledge} which contains knowledge for customizing
the generic architecture and is the basis for KASE's intelligent
support. Finally, the {\em constraint checker} is used to check for
the consistency of the design with respect to certain
architecture-specific constraints.

Our approach may be characterized as a semi-formal approach. It is not
completely formal where the semantics of a problem specification and
architectural descriptions are contained entirely within a set of
mathematical equations. Nor is it completely informal where the name
of a symbol carries all the information for a human is in, e.g.
systems like IBIS \cite{CoBe89}. Our approach does use keywords and
assumes the availability of an accepted domain-specific ontology which
is not formally defined. However, there are explicitly represented
constraints and rules that provide some semantics to the symbols. We
were motivated in adopting this approach because we wanted to create a
practical system that could be used by software designers not
well-versed in formal, mathematical notation; and, at the same time we
wanted a representation that is interpretable by a machine so that it
could provide intelligent assistance to designers.

\section{Comparison}

KASE shares the general  goal of the Domain Specific Software
Architecture (DSSA) project sponsored by DARPA which is to demonstrate
the benefits of synthesizing software systems by reusing domain
specific architectures. We have demonstrated the applicability of our
approach in two different domains \cite{BhNi92,Bha93}: a tracking
domain and a graphical interface domain. In each of these domains a
common generic architecture and customization knowledge was used to
generate specific  designs for different problem instances.

The LEAP project at Lockheed \cite{Gra91} and the ROSE-2 system
\cite{Lub90} represent two other works that aim to synthesize
systems by reusing high-level design abstractions.
In LEAP there is a greater emphasis on code generation from a high
level specification whereas in KASE and ROSE-2 there is a greater
emphasis on high-level design issues and their representation.

Other related work on software architectures includes the work by
 researchers at Carnegie Mellon University
(e.g. \cite{Sha91,Lan90}). Their work includes the identification of
commonly used architectural paradigms, the relationship between
various architectural paradigms and problem classes, and analysis of
trade-offs involved in choosing one design over another /cite{Sha91}.
Lane \cite{Lan90} describes a user-interface software architecture and
design rules for building specific user interface systems. The
approach consists of creating a space of design alternatives and
formulating rules that indicate good and bad design choices based on
problem requirements - which is quite similar to the approach in KASE.
However, it seems that there is less support for semi-automated or
automated conversion of the resultant design into code.

There is some  similarity between our approach of
synthesizing software systems and parameterized programming. In
parameterized programming, a generic program represents a
parameterized algebraic theory which can be instantiated by using a
view (theory morphism) that binds actual and formal parameters.
from this perspective, KASE can be thought of as providing a library of
highly parameterized programs (the generic system design) as well as
tools to assist a user in instantiating them based on the requirements
of a particular application.

\bibliography{bhansali}

\section{Biography}


{\bf Sanjay Bhansali} is a research scientist in the computer science
department at Stanford University. He
has been co-leading the Knowledge Assisted
Software Engineering (KASE) project with H. Penny Nii
at the Knowledge Systems
Laboratory at Stanford for the past 2 years. The goal of the KASE
project is to build a knowledge-based software design tool that can
can act as an assistant to a human designer. Sanjay obtained his PhD in
Computer Science at the University of Illinois, Urbana-Champaign in
1991
and his Bachelor of Technology in Computer Science from the Indian
Institute of Technology, Delhi in 1986.
\end{document}
