Next: Reuse Tools and
Up: WISR'93: 6th Annual
Previous: WISR'93: 6th Annual
Bill Frakes, Virginia Tech
frakes@sarvis.cs.vt.edu
Doug Lea, Syracuse CASE Center and SUNY Oswego
lea@sunyo.edu
The goal of this working group was to produce a set of language
independent principles for ``design-for-reuse'', while also capturing:
- common realizations of the principles as they apply in different
languages (especially C++, C, and Ada),
- the rationale for each principle, the rationale against competing
principles, and
- the decision/debate process by which agreement on each principle was
reached.
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
of component reuse was helpful in this work.
The following major points of reuse design are salient:
- Descriptive and computational properties are ENCAPSULATED into
COMPONENTS (objects, modules, packages, subsystems).
- A component provides access to SERVICES by possibly many CLIENT
components through an established INTERFACE specification
representing a single ``concept.''
- 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.''
- 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.).
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:
- Component Structure
- Identify and encapsulate commonality and variability.
- Separate interfaces and implementations.
- Identify and isolate context and policy from functionality.
- Link documentation to code.
- Link tests to code.
- Use tools when target languages do not support sufficient
interface, composition, and/or parameterization constructs.
- Interfaces
- Minimize the number of names per name space (scope).
- Minimize implementation-dependence of interfaces.
- Refine interfaces by extending and adding properties.
- Optimize components via specialization.
- Composition
- Identify and minimize import requirements.
- Identify and minimize interference among helpers.
- Use layering to define complex components using simple ones.
- Implement policy on top of mechanism.
- Parameterization
- Use parameterization to abstract away contextual variability.
- Use instantiation to generate components.
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.
Next: Reuse Tools and
Up: WISR'93: 6th Annual
Previous: WISR'93: 6th Annual
Larry Latour
Mon Aug 21 17:23:03 EDT 1995