In practice, an all too prevalent approach to software reuse has been to simply fill libraries with large numbers of "salvaged" software components, that is, with components removed from the context of a software architecture and provided, out of context, to other software developers. Although the premise of such a practice is that "valuable" components are being provided for reuse, our premise is that such components do not exist in a vacuum. Rather, they exist as part of integrated generic software architectures, each of which can be instantiated with context to form executable systems. Unless components are designed for reuse in this fashion, work expended in populating software repositories will go largely for nought. We call the the discipline by which we design and construct such generic architectures Generic Engineering.
A recent workshop on Reuse in Practice [SEI 89] focused on the problem of how to engineer components to be highly reusable. A resulting framework for thinking about such components was proposed, based upon the 3Cs model of a software component; its concept, represented by an abstract specification, its content, represented by a generic architecture, and context supplied by its environment.
Whereas the 3Cs model provides us with a way of thinking about software components, it does not provide us with a methodology to design and implement such components within the framework of a generic architecture. We thus add to our model the notions of separation of concerns and genericity, to suggest such a methodology.
In traditional software engineering methods, the notions of programming-in-the-small and programming-in-the-large are important ones in that they separate the concerns of component implementation from the concern of the interconnection structure between components in an architecture. But when systems become large, i.e., when they have a complex interaction structure, "higher-level" structure is needed to maintain a proper level of understanding. Similar issues arise when constructing generic architectures. As such architectures become complex with regard to the number of contextual choices and design decisions needed to instantiate a system, "higher-order" generic architectures are needed. Such generic generic architectures play a fundamental role in our ability to restrict a generic architecture to one that is usable within a particular domain.
We discuss the fundamental ideas of our approach using the relatively small examples of a generic Stack package and a generic quick sort algorithm. Included are a discussion of the problems of coupling and cohesion in generic components, and the related problem of generic architecture verification and language support. We next discuss the issues of "scaling-up" our approach to complex generic architectures, introducing the notions of nth-order generics and multi-level generic architectures. We do so using a generic database management system architecture as an example.
Although we use the Ada programming language [Ada 83] to present our examples, we recognize its deficiencies for describing generic architectures. We therefore extend the language at critical points in our discussion to illustrate our ideas.