\markboth{Griss}{Griss}
%%%%%% GRISS93.TEX                                    %%%%%%
%%%%%% TEMPLATE.TEX for WISR'93, version 1.2, 4/22/93 %%%%%%
%%%%%% Updated by Jeffrey S. Poulin, May 1993         %%%%%%

\documentstyle[11pt]{article}

% Standard Spacing for WISR - do not change!!
%
% Page dimensions.
%
\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{Griss}{Griss}
\pagestyle{myheadings}
%
% Paragraph changes.
%
\parindent=0pt
\parskip=10pt
%
% can make the title box even smaller
%
\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}
}

\begin{document}

\bibliographystyle{ieeetr}

\title{Towards tools and languages for hybrid domain-specific kits}

\author{Martin L. Griss\\
\\
Software Reuse Department, Software Technology Laboratory\\
Hewlett-Packard Laboratories\\
1501 Page Mill Road\\
Palo Alto, CA 94301\\
Tel: (415) 857-8715\\
Email: griss@hpl.hp.com\\
\\
}
\date{}

\maketitle

\begin{abstract}

As part of HP Laboratories research into a systematic process for
domain-specific reuse, we are exploring the notion of Domain-Specific Kits.
Kits are comprised of compatible, domain-specific components, frameworks and
glue languages, supported by a variety of technologies and tools, such as
domain-specific languages, builders, generators and domain-tailored
environments.  We are particularly interested in {\it hybrid} kits, which
combine both generative and compositional reuse, and domain-specific language
tools to support the generative part.  This paper describes our initial
thinking and investigations.

\vspace{0.2in}
\noindent
{\bf Keywords:} Reuse, kits, builders, generators, domain-specific languages,
hybrid reuse.

\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Learn more about domain analysis/engineering and
generative reuse methods; share and discuss information on our research
program.

\vspace{0.2in}
\noindent
{\bf Working Groups:} Kits, generative reuse, domain engineering

\end{abstract}

\newpage

\section{Background}

I have been involved with HP software engineering products and
processes since 1985, and with HP reuse efforts since 1989.  In
position papers at WISR'92 (Palo Alto) and IWSR'93 (Lucca), I described
our multi-disciplinary reuse research program started at HP
Laboratories in 1992\cite{griss92}.  This program complements HP's
Corporate Reuse Program, described at IWSR'91, WISR'92 and IWSR'93.
Key to our research program is an integrated approach to technology,
method, process and organization issues.  Our program has two major
themes: {\it domain-specific-kits} and {\it flexible software
factories}.  The domain-specific kit research focuses on the
technologies and methods for the production, use and support of kits,
while the flexible software factory work concentrates on the processes,
organization design, and software engineering and communication
infrastructures for kit-based software development.

At WISR'92, the Domain Analysis Working Group\cite{griss93a} explored the
different styles of domain analysis appropriate to either generative or
compositional reuse.  Purely generative approaches (e.g.
Draco\cite{neighbors84}) were deemed too complex for most cases, even though
the payoff is high.  Instead, one should try hybrid reuse, combining both
generative and compositional approaches.  However, current DA methods do not
facilitate systematic design for hybrid reuse, or tradeoffs as to which route
to take for which part of a complete application family.

At IWSR'93, the tutorial by Frakes, Batory and Devanbu on application
generators did not really address these issues, nor how to design appropriate
domain-specific languages for the level of generator technology chosen.
Instead, it focused primarily on a few commercially available implementation
techniques and tools. There were some useful experience reports, but no
guidelines for hybrid reuse tradeoffs\cite{frakes93,batory91}.

\section{Position}

It is my belief that there are several important issues involved here, and
that they should be addressed systematically. We need:

\begin{itemize}

\item methods and supporting technology to design and implement hybrid kits

\item guidelines and examples of a variety of simple and more complex ways
of using domain-specific languages and generators within hybrid kits

\item techniques and mechanisms to ensure openness and extensibility of the
kit, and to smooth the boundary between generative and compositional parts

\item methods and common mechanisms to produce frameworks which will ensure
that
independently developed can interoperate.

\end{itemize}

This position paper will summarize some of our work on kits, hybrid reuse,
domain-specific languages and related issues.

\section{Domain-Specific Kits}

Our goal is to develop for HP divisions the methods and technologies to
dramatically improve application construction tasks using reuse.  Most HP
reuse situations involve the construction of families of closely related
applications.  To encourage the coherent design, implementation and packaging
of a variety of comaptible domain-specific workproducts, we first identify and
structure the domain (``domain engineering'') and then use new methods (``kit
engineering'') to build a ``domain-specific kit'' consisting of
domain-specific components, supporting infrastructure and tools.  The kit is
then used to build one or more applications.

A typical ``hybrid domain-specific kit'' will contain (most of):

\begin{itemize}

\item A set of {\em components}, which are well documented, tested and
packaged sets of compatible software workproducts: C functions, C++ objects,
generator templates, test-files, software-bus connected mega-components, etc.

\item A {\em framework} within which compatible components can be combined with
hand-written or generated glue-language, and the addition of non-kit
workproducts.  The framework provides common services, key mechanisms and core
functionality, ensures appropriate interoperability and customizability, and
establishes conventions and mechanisms to add new compoents.

\item A {\em glue language} to combine components and add needed
functionality.  This could be general purpose, a flexible scripting language,
or highly domain-specific.

\item Exemplary {\em generic applications} are
pre-packaged, ready-to-run, standard applications built with the kit, with
interconnected framework, components and glue.  A complete application is
evolved or customized using built-in customization methods and adding or
replacing components, supporting a prototyping development
cycle\cite{fischer87a,johnson93}.

\item A {\em construction environment} provides
tools such as component browser, glue language editor, application builder and
generator.  Debugging, testing, and construction step recording tools aid
in quick assembly and modification.  Using a combination of techniques, one
can start from components, generic applications or from previously built user
applications.

\item An {\em execution environment} provides support for
customizing and running the application, with debugger, interpreter, graphical
display and monitoring, etc.
\end{itemize}

\section{Theory and Practice of Domain-Specific Kits}

We are trying to produce a theory and practice of domain-specific kits,
abstracting ideas from division studies and experiences in developing and
using several domain-specific kits.  A complete methodology should include:

\begin{itemize}

\item A philosophy of how and when to use domain-specific
kits, and guidelines on how to balance the cost and benefits between the
development of frameworks, reusable domain-specific components and languages,
and the use of traditional programming.

\item A taxonomy or catalog of kit models, styles, and
implementation techniques. For example, kits may be ``closed and complete'',
or ``open and extensible'', providing a some needed workproducts, and
instructions and mechanisms to create, declare and register new components.

\item Processes and methods to be used by kit developers and users,
workproduct supporters and managers, such as ``domain engineering,'' ``kit
engineering,''``framework design,'' ``component management,'' ``generator
design and implementation,'' ``using a kit,'' ``augmenting a kit,'' etc.

\item A set of (customizable) tools and core technology that can be used to
define and develop kits, such as domain analysis tools, language and generator
kits, library and browsing tools, glue language interpreters and compilers,
software-bus services, user-programming and customizing language kits, etc.

\item A set of case studies  which illustrate the principles, the practice and
the tradeoffs. It would be useful to know language sizes, number of
components, implementation costs, productivity and quality benefits, etc.

\end{itemize}

\subsection{Domain-specific languages for hybrid kits}

Language technology can be used in several ways to include domain-specificity
into a hybrid kit for different audiences and situation.  There are several
opportunies for domain-specific``little languages''\cite{bentley86}, such as:

\begin{itemize}

\item Component development and generation (from templates or rules)
\item Parameter generation for parameterized components
\item Glue/config language for component interconnection
\item Data file/table creation
\item Loader/builder scripts
\item Templates/declarations for registering new components in an open kit
\item End-user programming/customization
\end{itemize}

The following list illustrates some implementation choices:

\begin{itemize}

\item Conventional language + domain-specific library of code

Using Basic or C, the domain-specificity is offered as a library of parts.

\item Object-oriented language + domain-specific class library

C++ and Smalltalk make it easier to create frameworks and API's that shape
components by inheritance and polymorphism.

\item Extensible language or preprocessor + domain-specific library

Using macros or syntax extension capabilities in LISP and TCL, or using CPP,
AWK or PERL, Yacc, or STAGE\cite{cleaveland88} as preprocessor one adds
concise, domain-oriented expressions to a standard language. These simplify
parameter generation, consistent use of procedures and data, and creating data
files, symbol-tables and other workproducts.

\item Custom full domain-specific language and environment, with
domain-specific library.

Yacc and Lex, LISP-based meta-compilers, and C-based Tree-Meta have been used
in HP to produce a variety of instrument system programming languages. These
configure and select parts of an instrument, create front-panel display and
remote-port drivers, declare bindings to measurement routines,
establish interfaces to higher-level analysis routines, and fill in data
tables.
\end{itemize}

Within HP, practical systems combine several of these techniques at the same
time, leading to some issues of consistency and interoperability. One way to
ensure that several languages be consistent or interoperate, is to implement
them using the same language kit, which can be embedded with the development
and delivery environments. In addition to Lex and Yacc, small embedded
interpreters (Xlisp, TCL, PERL) and simple-meta compilers (Tree-Meta, Pmeta)
are quite attractive for this purpose.

\section{Next Steps and Summary}

We are defining and prototyping a series of small domain-specific kits to help
drive the development of our kit design and implementation methodology and
tools.

Our first kit is in the domain of task/dolist managers, using our software
bus\cite{beach92a} for component integration.  Following a minimal domain
analysis and kit design, components were written in several languages (LISP,
C++, TCL/TK) for item display, definition, time management, and dolist item
storage managment.  Alternative components and options are selected, and
data-structures are defined, using a simple (LISP-based) configuration
language, from which a complete application is generated.  A conversational
rule-based tool uses data derived from our domain analysis to present
decisions and consequences to the application builder to help generate the kit
configuration file.

In our next cycle, we will refine our DA method, and be more systematic about
the design of the kit architecture and style. We will use hypertext tools
(Kiosk\cite{creech91b}) to browse and display domain and kit workproducts,
issues and decisions and as an interface to the kit components and documents.

We are surveying the use of hybrid kits in HP, looking at language and
generator style and supporting technologies, and to better understand
divisional constraints and practices. We are collecting information on
available language, builder and generator technologies, and will do some
analysis and prototyping to understand several of these.

\section{Acknowledgments}

I had several useful discussions with Joachim Laubsch as I prepared this
position paper. Dennis Freeze, Jon Gustafson, Joe Mohan and Kevin Wentzel gave
useful comments on drafts of this position paper.

\bibliography{griss}

\section{Biography}

{\bf Martin L.  Griss} is Principal Laboratory Scientist for Software
Engineering at Hewlett-Packard Laboratories, Palo Alto.  As manager of
the Software Reuse Department, he leads research on software reuse,
domain-specific kits and flexible software factories.  He works closely
with HP Corporate Engineering to systematically introduce software
reuse into HP's software development processes.  He was previously
Director of HP's Software Technology Laboratory, researching expert
systems, object-oriented databases, programming technology,
human-computer interaction, and distributed computing.  Before that, he
was an Associate Professor of Computer Science at the University of
Utah, working on computer algebra and portable LISP systems (PSL).  He
received a Ph.D.  in Physics from the University of Illinois in 1971.

\end{document}
