3 Comparison

Functional representation represents quite a departure in modeling philosophy compared to other model-based reasoning paradigms in AI. In terms of software composition, its application also represents something of a departure in terms of viewing program composition analytically rather than synthetically, as described above. However, an analytic approach to software engineering is not new; there are a number of movements that share this point of view.

There has been a recent movement in software engineering towards explicit manipulation of software architectures, and the introduction of software architecture definition languages (ADLs) (e.g., Rapide [LKA⁺95] and ACME [GMW96]). An architecture definition differs from a program specification in that it does not describe the particular components from which a system will be built; instead, it defines the types of components and the responsibilities of the connections between them. This feature of an ADL has cause many of them to be described informally as ``box-and-arrow languages.'' Like a functional representation, an architecture can be defined and evaluated before any decision has been made to realize any of it in terms of actual software components.

In this respect, ZD plays a similar role in the design process as an architecture definition language (another functional representation language, SBF [Str94] is being used explicitly as an ADL). We have also done some preliminary research in which ZD has been used to represent a reference architecture for two-phase commit (a problem that is often used to show off ADL features). ZD's flexible treatment of constraints seem to make it possible to represent certain aspects of this architecture more flexibly than is possible in other ADLs.

A similar approach to system design can be found in the expert systems development community in frameworks for formal knowledge system design. KARL [Fen95], $\hbox{(ML)}^2$ [vHB92] and Desire [Tre94] are frameworks for working ``at the knowledge level'', which entails specifying a expert system without reference to implementation details. These frameworks are typically based on logical inference languages. While they are very flexible in their ability to describe complex interactions, and have formal support (often supported by inferencing tools), they are typically not component oriented, and do not provide any insight into how formal methods can be applied to component-based software engineering.

All of these analytical approaches, including functional representations, share a problem that is particularly important to component-based software, namely, although it is possible to evaluate the correctness of an architecture specified in an ADL, or a knowledge base specified in a language like KARL, or a functional representation of a system, this leaves open the problem of deciding whether a particular piece of software is accurately described by this formal description. In the case of the knowledge based design formal systems, there is a specific step in the lifecycle, called the ``design phase,'' where this gap is crossed. In a component-based software reuse industry, this bridge need not be crossed, since the formal descriptions correspond directly to pieces of code. Program generation approaches (e.g., Jakarta [Bat97]) address this problem directly, by providing a system whereby a design can be developed using a high-level specification language, from which software can be automatically generated.

A particularly interesting form of generative technique goes under the name ``adaptive programming'' or ``aspect oriented programming'' [Lie96,Kic97]. In an adaptive program, the system is decomposed not into modules that inter-operate according to some calling sequence provided by the programming language, but rather into interacting aspects or concerns. For example, in Demeter, an object-oriented program is divided into a traversal strategy (a ``strategic aspect'') and a set of actions (``visitors''). These two aspects interact in complex but predictable ways. The Demeter system generates a program from independent descriptions of these two aspects.

In the sense described above, the multiple-aspect decomposition used by Demeter is a functional decomposition. Although Demeter gets much of its power from the independence of these aspects, in reality, the correctness of a traversal strategy depends to some degree on the details of how the traversed nodes are to be visited. Although Demeter can synthesize a program from these aspect descriptions, it cannot reason about the correctness of the composition at the higher level. We are currently collaborating with the Demeter team to apply ZD to this kind of composition.