ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr7/workshop/WISR93-report/kitswg.tex

Text File | 1995-08-19 | 12KB | 321 lines

%Last change 1/5/94
%Group Leaders: Martin Griss, HP Laboratories
%               Kevin Wentzel, HP Laboratories
%
%Scope:  This group will explore the hypothesis that high-payoff hybrid
%reuse (combination of compositional and generative reuse) can be
%systematically addressed in the form of domain-specific kits
%(comprised of compatible, domains-specific frameworks, components,
%glue language and supporting tools).  The leaders will describe HP's
%proposed development process incorporating ``domain engineering'' and
%``kit engineering'', and will refine by comparison with participants'
%processes.  We will bring forth issues relating to how domain
%analysis, modeling and engineering need to be constructed so as to
%lead effectively to hybrid reuse, and collect other issues identified
%by participants will be discussed.  Our prototype framework for kit
%comparison (openness, extensibility, completeness, use and consumer
%style, ...)  will be used to collect and compare participants case
%study experience.  We solicit other such comparative frameworks from
%participants.  We will build on some of the discussion of the Domain
%Engineering Workshop at WISR'92.  Participants should prepare by:
%studying material on kit process and framework, (attempting to)
%describe one case study, and gathering other ``kit'' comparative
%frameworks for discussion.
%
%Goals:
%       o Describe kits concepts, methods and process
%       o Review and update framework for comparing kits
%       o Gather case-studies in different domains, compare using
%         framework
%       o Identify key process  and technology issues
%------------------------------------------------------------------------

%WISR Working Group Report: Hybrid Reuse with Domain-Specific Kits
%
%
\subsection*{Introduction: What is a Hybrid Kit}

The goal of this group was to explore the hypothesis that high-payoff
hybrid reuse can be systematically addressed in the form of
domain-specific kits, and that appropriate methods and technology
should be developed to support this integrated approach to delivering
reuse.

The leaders first described HP's notion of a kit, meant to be the
``complete'' and ``coherent'' packaging and delivery of (several
different) reusable work products to simplify application building.  A
kit is comprised of compatible, domain-specific frameworks, components,
glue language and supporting tools.  The notion of ``hybrid kits'' was
discussed in the domain-engineering WG at WISR'92.  We built on this
work by describing  kit ``style'' as ranging
from purely compositional to purely generative.  We identified hybrid
reuse, combining compositional and generative reuse, as having the
greatest payoff.  In this mode, generators and builders can be used to
produce a variety of workproducts (such as the glue language,
parameters for components, customized components, and data-tables).

We illustrated the concept and range of kits styles by discussion the
Calculator Construction Kit and a prototype HP labs software-bus based
kit for Task-list management.  The group discussed the notions of
frameworks, components and glue languages, which workproducts could be
reusable, where to place the domain-specificity, and the differences
between generators (automated generation or configuration from
specifications) and builders (graphical tools to aid in manual
composition of components).

\subsection*{Kit Taxonomy}

A prototype kit taxonomy and comparison table from HP was described.
This identifies a variety of kit attributes (such as style,
domain-specificity, openness and completeness), and is intended as a
taxonometric framework to compare the features of kits, and suggest
alternative ways of delivering reusable workproducts.  The use of the
analysis table was illustrated by comparing several systems (such as
Genesis, the Calculator Construction Set, and several HP systems).
Graphs were used to highlight useful clusterings by subsets
of the attributes (openness, completeness and domain-specificity).

\subsection*{Kit Development Process}

The leaders described HP's proposed development process incorporating
``domain engineering'' and ``kit engineering'', building on some of the
discussion of the Domain Engineering Workshop at WISR'92.  In the HP
process, domain engineering includes the overlapping phases of domain
analysis, domain design and domain implementation, focusing primarily
on application functionality.  We have introduced a set of parallel
and overlapping phases of kit engineering, called kit analysis, kit
design, and kit implementation, focusing primarily on the style and
technology of application development to be used by kit users,
following a customized application engineering process.  The
discussion brought forth issues relating to how domain analysis,
modeling and engineering need to be constructed so as to lead
effectively to hybrid reuse, how much the various phases of domain
engineering and kit engineering overlap and/or are distinct, how some
domain engineering techniques are now including part of what HP calls
kit engineering and whether it makes sense to split up these
activities at all.

Several draft papers on HP Labs notions of kit process and kit concepts
were distributed.  One of these, ``Hybrid domain-specific kits for a
flexible software factory'' by Martin Griss and Kevin Wentzel, will
appear in the proceedings of SAC'94, Phoenix, Arizona, Mar'94.  For
more details or a copy of this paper, contact either of the WG leaders.

\subsection*{Case Study Analysis}

As homework, and in breakout groups, the working group participants
used the kit analysis table as the starting point to collect
information about 13 kit-like systems.  In
the process, many improvements were identified, and a revised table
was proposed.

As motivation for developing, and using the table, the following reasons
were suggested; each could motivate a different level of detail:
\begin{itemize}\itemsep -3pt
  \item Sales job -- explain to people why they should kits in general,
                    or a particular kit

  \item Start DA of kit styles -- a tool, or reference diagram to allow kit
                           designers to pick mechanisms and styles
                           used as classification/reference

   \item Kit selection -- outline of a catalogue of kits, allowing kit-users
to elect
\end{itemize}

\subsection*{Original HP Kit Taxonomy Table}
\begin{small}
\begin{table}[t]
%begin{center}
\begin{tabular}{p{1.0in}p{2.5in}}
  Kit Name: & \\
  Domain:   & \\
  Domain Specificity:  &
  How specific to a particular application domain is the kit?\\
  Style:               &
  Are applications built from the kit in a compositional, generative
  or hybrid manner?\\
  Completeness:        &
  Can the complete application be built from the kit?\\
  Openness:            &
  How easy is it to add new functionality to applications developed
  using the kit?\\
  Target User:         &
  Who is expected to use the kit: application developers, system
  integrators, or end users?\\
  Granularity:         &
  How big are the kit components? Range from functions to processes.\\
  Quantity~of pieces:  &
  How many components are there in the kit?\\
\end{tabular}
\end{table}
\end{small}

\subsection*{Revised Kit Taxonomy Table}

Use as starting point for DA of kits: Collect and analyze information
about various kits, value of features etc.

{\bf GENERAL:}
\begin{small}
\begin{verbatim}
 Kit Name:
 Style:
 Purpose:
 Application User:
 Features of Merit:
    (coherence, ease of use, evaluability of
    results, distance from problem space,
    ... "compression")

 Notes:
    Interoperability with other kits
    Sub-kits used
\end{verbatim}
\end{small}

{\bf ANALYSIS:}
A two dimensional (matrix) model was chosen with kit elements on the
vertical axis and element attributes on the horizontal axis.
\begin{small}
\begin{verbatim}
  "kit elements" (work products list:)
     components
     architecture
     framework
     domain specific language
     glue
     generator
     builder
     tests
     end user document
     maintenance document
     kit use documents
     domain model
     feature set
     rationale
     generic application
     glue language

  Element (workproduct) attributes:
     present?
     completeness
     openness
       (includes openness of applications
       and of the kit itself)
     domain specificity
     binding time
     source
       (provided in kit, created,
        written by user)
     Application Engineering Life Cycle stage
       (How/when this element is used? --
        problem, solution, implementation)
\end{verbatim}
\end{small}

\subsection*{Kits analyzed by participants}

``Kits'' analyzed include:
\begin{itemize}\itemsep -3pt
 \item  Predator
 \item  Boulder design Environments
 \item  Marvel/Oz
 \item  Robot Control Software
 \item  Personnel Mgt Kit (MGIB)
 \item  MacApp
 \item  CCL
 \item  Process/1 ``Anderson''
 \item  DSSA-ADAGE
 \item  Movement Controller
 \item  PARTS (DEC)
 \item  KIDS
\end{itemize}

\subsection*{Revised Kit Process}

The discussion on the kit development and use process lead to several
observations and some suggested modifications:
\begin{itemize}\itemsep -3pt
  \item DA constrains kit analysis/design.
  \item KA constrains domain design.
  \item Some methods of DA/DE include parts of KE.
  \item Distinction between DE and KE is fuzzy.  What are some distinct
       work products?
\end{itemize}

The working group suggested that there was so little independence in
implementation that separating kit and domain implementation may
not make sense.  The constraint observation lead to a new model of
development in which Domain Analysis and Kit analysis overlap, both
affecting kit and domain design then merging in implementation.

{\bf Conclusions}
%\subsection*{Conclusions}

\begin{itemize}\itemsep -3pt
  \item Kit Taxonomy table was useful to collect and analyze cases.
  \item Developers could use a table like this to suggest extra elements in kits.
  \item Seems like KE/DE separation has validity.  (There are distinct, yet
  interrelated WP and processes.)
\end{itemize}

{\bf Next Steps}
%\subsection*{Next Steps}

\begin{itemize}\itemsep -3pt
  \item Kit Taxonomy
  \begin{itemize}\itemsep -3pt
      \item collect and analyze additional kits.
      \item do DA like analysis of kits.
      \item refine as a reference model.
      \item use to find design rules/criteria (for particular reuse scenarios).
      \item develop kit glossary, with terms such as ``kit'', ``framework'',
        ``domain''.
  \end{itemize}

  \item Kit Process
  \begin{itemize}\itemsep -3pt
      \item define distinct WP of Domain Engineering and Kit Engineering.
      \item identify steps in domain analysis/engineering process(es)
      as part of DE/KE.
  \end{itemize}

  \item Overall
  \begin{itemize}\itemsep -3pt
      \item link Taxonomy \& Process to relate to kit design.
  \end{itemize}
\end{itemize}

  Questions and suggestions when the final results were presented at the
plenary included:

\begin{itemize}\itemsep -3pt
  \item Need to look at several different kinds of systems.
  \item Are kits distinct from Application Generators or Generic
       Architectures?
  \item Why distinguish DE/KE?
  \item Look at Ed Berard view on Kits, because he used the term before.
\end{itemize}

%.0 WG Participants:
%
%    Martin Griss            <[e-mail]>,
%    Kevin Wentzel           <[e-mail]>,
%    W. (Voytek) Kozaczynski <[e-mail]>,
%     Sanjay Bhansali         <[e-mail]>,
%     Sholom Cohen            <[e-mail]>,
%     Kurt Wallnau            <[e-mail]>,
%     Jim-Qun Ning            <[e-mail]>,
%     Steve Wartik            <[e-mail]>,
%     Jeff Thomas             <[e-mail]>,
%     Scott Henninger         <[e-mail]>,
%     Satish Thatte           <[e-mail]>
%     Robin Burdick           <[e-mail]>
%     Vivek Singhal           <[e-mail]>
%     Pam Arya                <[e-mail]>
%     Lou Coglianese          <[e-mail]>
%     Andrew Tong             <[e-mail]>
%     Elizabeth Hobbs         <[e-mail]>