As a starting point in the development of our schema, we draw on the 3C model of component structure. We observe that the separation of concepts from their content has been relatively well explored and widely practiced, but that the isolation of contextual dependencies has not been as well explored, nor has it been subjected to a formal analysis.
It seems reasonable to assume that careful isolation of contextual dependencies in the modular structure of an integrated library/generic architecture can produce a framework that is not only capable of being instantiated to a large number of actual components/systems, but that can be easily extended and adapted by ``plugging in'' newly constructed modules embodying different contextual information. As we mentioned earlier, this approach has to an extent been explored in the CAMP and Stepanov and Musser work.
Our schema divides the modules in an LGA into several classes, similar to the abstraction classes defined by Stepanov and Musser. These classes are contextual abstractions, abstract algorithms, auxiliary abstractions, base abstractions, and view abstractions.
Contextual abstractions encapsulate various contextual design decisions such as data representation, storage management, concurrency control, device handling, persistence, and communication. They typically are characterized by hard coded design decisions with ``invariant context'' provided by with statements, but they can be services provided by an entirely different ``lower-level'' architecture, such as a database management system or network architecture.
Abstract algorithms incorporate the algorithmic content of the architecture. They are parameterized by a collection of theories, each describing a class of abstract data types. They typically fall into two categories:
Base abstractions are the canonical abstractions of the domain (the concepts of the domain), while View abstractions are derived from the base abstractions by mapping one language onto another. The terms view and base were again taken from the dbms domain, as they capture a similar mapping notion. Code in a View ``implementation'' is typically concerned with renaming procedures and types, redistributing procedure functionality, and tailoring a concept to a particular protocol of use. Such code has little ``algorithmic content'' in the sense that algorithms have simple complexity and little local resource utilization.
Auxiliary abstractions are structures that are convenient to build in order to provide concepts to algorithm theories not provided by existing contextual abstractions. Both base and auxiliary abstractions are constructed by composing a representation from auxiliary and contextual abstractions, defining an abstraction function, and then choosing a collection of generic algorithms that realize the abstraction function.
Note that a generic architecture embodies two types of content: algorithmic and structural. The development of algorithmic content is a programming in the small issue. It is concerned with the implementation of a single algorithm or family of algorithms, organized according to the structural and behavioral properties of the algorithms. Structural content is a programming in the large issue. It refers to the ``scaffolding'' or framework of the architecture, and is implemented by a particular modular decomposition. Generic architectures incorporate the structural content of a domain in the structure of the architecture, and isolate the algorithmic content of the domain in abstract algorithms.