Design for Reuse and Object Oriented Reuse Methods

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.

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:

1. 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.

2. 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.

3. 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.

4. Parameterization
   • Use parameterization to abstract away contextual variability.
   • Use instantiation to generate components.