% last changed 1/4/94
%Scope:  This group will focused on language-independent techniques for
%designing reusable lifecycle objects, to include object-oriented
%features and design techniques that enhance reuse.  The group will
%build on the list of design principles developed at WISR'92.
%
%Goals:  o Extend last year's work based on further experience.
%        o Establish a framework for continuing work.
%------------------------------------------------------------------------

%Date: Sat, 13 Nov 93 15:00:47 -0500
%From: frakes@sarvis.cs.vt.edu (Bill Frakes)
%Doug -- here are a few changes. Nice summary.

%Attendees:
%   John Beidler, Ted Biggerstaff, Silvana Castano, Pete Cornwell,
%   Maggie Davis, Pankaj Garg, Joe Hollingsworth, Voytek Kozaczynski,
%   Mitch Lubars, Eric Newton, Will Tracz.

The goal of this working group was to produce a set of language
independent principles for ``design-for-reuse'', while also capturing:
\begin{itemize}\itemsep -3pt
 \item common realizations of the principles as they apply in different
       languages (especially C++, C, and Ada),
 \item the rationale for each principle, the rationale against competing
       principles, and
 \item the decision/debate process by which agreement on each principle was
       reached.
\end{itemize}
This work built on two previous design working groups at WISR '91 and WISR '92.

In the course of discussion, the group made progress toward defining
an architectural reference model and accompanying terms and concepts
providing a conceptual framework for the design of reusable
components.
The ``3C'' (Concept, Content, Context) model %\cite{tracz92}
of component reuse was helpful in this work.
The following major points of reuse design are salient:
\begin{itemize}\itemsep -3pt
  \item Descriptive and computational properties are ENCAPSULATED into
      COMPONENTS (objects, modules, packages, subsystems).

  \item A component provides access to SERVICES by possibly many CLIENT
      components through an established INTERFACE specification
      representing a single ``concept.''

  \item To fulfill its role, a component may interact with possibly
      many HELPER components, as constrained by an IMPORT
      specification or CONTRACT describing invariants necessary in
      carrying out its implementational ``content.''

  \item A single PARAMETERIZED description suffices to GENERATE
      components with the same high-level import and export
      specifications, but under operating different ``contexts''
      (policies, control regimes, type substitutions, etc.).
\end{itemize}

About fifty design rules, principles, and ideas (most originating in
previous WISR meetings) were grouped into further categories based on
this model. The next level of grouping includes:
\begin{enumerate}\itemsep -3pt
 \item {\bf Component Structure}
 \begin{itemize}\itemsep -3pt
    \item Identify and encapsulate commonality and variability.
    \item Separate interfaces and implementations.
    \item Identify and isolate context and policy from functionality.
    \item Link documentation to code.
    \item Link tests to code.
    \item Use tools when target languages do not support sufficient
     interface, composition, and/or parameterization constructs.
  \end{itemize}

\item {\bf Interfaces}
 \begin{itemize}\itemsep -3pt
    \item Minimize the number of names per name space (scope).
    \item Minimize implementation-dependence of interfaces.
    \item Refine interfaces by extending and adding properties.
    \item Optimize components via specialization.
  \end{itemize}

\item {\bf Composition}
 \begin{itemize}\itemsep -3pt
    \item Identify and minimize import requirements.
    \item Identify and minimize interference among helpers.
    \item Use layering to define complex components using simple ones.
    \item Implement policy on top of mechanism.
  \end{itemize}

\item {\bf Parameterization}
 \begin{itemize}\itemsep -3pt
    \item Use parameterization to abstract away contextual variability.
    \item Use instantiation to generate components.
  \end{itemize}
\end{enumerate}
A more complete description of all principles, along with
operationalizations, rationales, examples, and discussion remains
unfinished, in large part because terminology, concepts and
classifications evolved in a bottom-up fashion during working
group sessions.

