2.3 What theoretical or practical insights might help to solve this problem?

The major insight into resolving this problem is, not surprisingly, that we need to have a more flexible idea of what it means for something to be a component, and how they relate to composed groups of components, or compositions. In a component-based software industry, we usually think of components as modular pieces of software, which can be composed using some primitive of the programming environment; typically, a mechanism like procedure calls (including remote calls) or method invocation is used to compose components. In object oriented systems, composition is already a bit more flexible; a class definition is often brought into a system by specialization or instantiation. The plan of a component-based industry is that each of these components can be described with some formal statement, and these statements can be used to reason about properties of the composition.

To understand the extension to this notion of component that I propose here, first notice that the notion of component in the last paragraph is described synthetically, that is, in terms of how the overall device can be constructed (synthesized) given the components. The proposed notion of composition, in contrast, can be described analytically, that is, given a system, what are the parts into which it can be decomposed (analyzed). To avoid confusion, we no longer call these components, but instead, devices. A device is used for some particular purpose in the system in which it plays a part. This relationship can, of course, be used recursively, i.e., we can talk about devices made up of sub-devices made up of further sub-devices, etc.

One difference between viewing a system in terms of a device decomposition as opposed to viewing it as a composition of components (i.e., analytically rather than synthetically) is that the same system could be decomposed in many different ways; for example, we might view a system as being a combination of a memory manager and a memory mutator (this parlance is common in technical discussions of garbage collectors, where the rest of the program is simply viewed as a ``mutator'' of memory), or view the same system as a combination of a scheduler and an actuator, or as a combination of a traversal strategy and an action. All of these decompositions refer to the same system, but each brings a different perspective to how it can be understood in terms of constituent devices.

While a synthetic view of describing systems is useful for guiding the construction of a system (e.g., configuring a system out of components, either from a reuse library, or from well-specified custom components), an analytic view is useful for allowing a rich and varied set of descriptions of how software works. In particular, such an approach is useful for program understanding and capture of design rationale. This style of modeling comes from a movement in model-based reasoning in Artificial Intelligence called Functional Representation. We are applying a particular functional representation system, called ZD [Liv96] to the problem of representing design rationale for software through support of the DARPA Evolutionary Design of Complex Software (EDCS) programme. In the remainder of this section, we will describe how ZD works, and its relation to formal methods.

ZD is a formal system for describing complex intentional artifacts, that is, devices that were designed to achieve a particular purpose. A description in ZD describes a complex device in terms of subdevices, and describes each subdevice in terms of the role it plays in the intended functioning of a higher-level component. Although functional representations in general, and ZD in particular, are based on a new style of modeling the relationship of software systems to their parts, the formal mechanisms that are applicable to component systems are also applicable in a functional representation. ZD is also the name of a program implemented in CLOS, which provides assistance in creating, maintaining, and processing representations of software in ZD. The ZD program is linked to a theorem prover [BM88] to provide access to automatic means for processing formal descriptions of programs.

One benefit of the functional style of modeling software is that each functional decomposition reflects a particular perspective on a system. This means that the formal description of the subdevices, and their interactions, need not specify every aspect of the software. Typically, a small number of concerns is represented with a single decomposition, and only the properties of the software of interest with respect to that concern need be represented.