Dean Allemang
Organon Motives, Inc.
1 Williston Road,
Belmont, MA 02178
Fax: +1 617 484 3363
Email:
dta@organon.com
Design Rationale refers to the decisions that underlie the design of a system; why it was made the way it was, and not some other way. These decisions are closely inter-related and often difficult to track. Design rationale information is important in software reuse for at least two reasons; first, the design decisions that went into a component will help to determine where it can appropriately and advantageously be reused, and second, the design decisions made in a system in which a component is to be re-used determine what components can be appropriately re-used. In this paper, we outline some of the problems inherent in the capture of design rationale, and describe an approach to representing rationale that addresses these problems. This work is part of a project in the DARPA EDCS (Evolutionary Design of Complex Systems) initiative.
Keywords: Design Rationale, Functional Representation, Alternatives Management.
Workshop Goals: Connect EDCS work to Reuse community, visit my hometown.
Working Groups: Rigorous Behavioral Specification as an Aid to Reuse, Domain Engineering Tools.
Dean Allemang comes to software reuse from the Knowledge Based Software Engineering community. He completed his dissertation on Functional Representation of Software [1], which extended the approach to software understanding pioneered by Lewis Johnson's PROUST. Development has continued on ZD [2, 3], a language for expressing functional representations of software. This work has led to a current project (Familiar) funded under the DARPA Evolutionary Design of Complex Systems programme to apply functional representation to capture and recording of design rationale. Familiar combines the formal functional representation capabilities of ZD with alternatives managment capabilities of Kaptur. The functional representation approach brings a valuable perspective to design rationale, and resolves certain problems for alternatives management. This position paper outlines the contributions that functional representation makes to understanding design rationale, culminating in a solution to the problem of ``legitimate alternatives'', that is, given some construct in one system, the problem of determining what constructs known from other systems can meaningfully be compared to it.
Design Rationale, roughly speaking, is the reasoning that supports design decisions. Capture of design rationale refers to any process that codifies this information, making it available for use later on. Design rationale includes reasons why a particular option was taken, as well as information about why certain other options were not taken.
Design rationale can be broadly divided into two categories, which we will refer to as internal and external rationale.
Internal rationale refers to the relation of parts of the design to other parts of the same design. The way in which a component interacts with other components or the way in which an algorithm makes use of a data structure are examples of internal relations. There are three interesting types of internal rationale for software:
External rationale refers to the relation of parts of the design to parts of different designs. External rationale has the added complexity over internal rationale that it concerns multiple systems. The matter is further complicated by the fact that the alternatives can be considered at any level - from alternative strategies for an overall application, to detailed decisions about the implementation of a particular operation. Two systems might be comparable at a highly detailed level, while two others might only be comparable at the gross strategic level. The entities to be compared might not even be of the same category; a data structure in one system might serve a purpose that is served by an algorithmic component in the other. At some level, two systems might not be comparable at all. One of the challenges of design rationale capture is to manage these various degrees of comparability.
Once the problem of managing the levels of comparison of multiple systems has been solved, external rationale is based mainly on trade-offs between the combined properties of the corresponding designs. The trade-off can be well-known classic ones (such as a choice between a fast, space-consuming algorithm and a slow, lean one), or project-specific. Details of how these sorts of issues and trade-offs can be managed in a design rationale setting can be found in [4].
Functional representation was originally developed [5] in the context of physical devices, to capture intuition about how a device works, in terms of other devices. In ZD, where the functional representation has been applied to software, the concepts have been modified somewhat, but the terminology has only changed slightly. The fundamental entity in a functional representation is still called a device. A device can have one or more functions that describe what it can do in various contexts. In [5], each function was associated with one or more behaviors, which described how the function could be achieved, by referring to functions of other devices. For software, we call this description an implementation. For the purposes of this paper, an implementation is any story (told as a flow diagram, a finite state machine, or even with pseudo- code) that explains how a function can be achieved, referring to the functions of other devices. For a particular device, the set of all its functions are bundled together into a specification called a service, while the set of functions it requires are called its requirements.
The intuition behind constructing a functional model is that it describes the roles that various parts of the device play in achieving some overall functionality. In the physical world, the devices are functional devices, and need not correspond to any physical components. In the software domain, devices need not correspond to any modular component in the software.
A functional representation is particularly adept at representing the three kinds of internal rationale of a system:
At first glance, it would seem that the functional representation, while well-suited for representing internal rationale of a single system, is not particularly helpful in representing external rationale across many systems. Strictly speaking, it is true that a functional representation does not represent comparisons between systems; however, a careful consideration of the meaning of a device in ZD will show that the functional representation can indeed organize information about multiple systems.
A device in ZD is a partial description of a system, in which certain design decisions have been fixed, and others left open to further specification. This means that a device in ZD represents not just one, but potentially an infinite number of systems; those that provide the same functions, and break them down into the same required functions. When some parameter is further specified, by filling one of the roles with a particular device (say D), then the combined representation refers to a subset of the original systems, namely, those which fill that role with something that breaks that function down according to the requirements of D. A functional representation of a program, in this way, is actually a representation of several programs. By representing alternative fillers for these roles, ZD can be used to manage alternative designs of several different systems; commonalities are represented by the common device components, while variations are represented by alternative fillers for each role.
In addition to its usefulness in representing relations between classes of composite systems, functional representations can also be used to resolve some questions that need to be managed when considering external rationale, based on alternative designs.
When examining two alternative systems, a major problem occurs when trying to decide how some construct found in one system appears in the other system. It can often be the case that the question is simply meaningless; some decision that was made in one system can completely preclude the necessity for the construct. For example, someone who is comparing two program development environments, one for a compiled language and one for an interpreted language, might wonder what, in the interpretive environment, corresponds to the disassembler that was found in the compiled environment. No component, strategy, or even design decision can be found to answer this question, because by the very nature of the language design, there is nothing that could be disassembled.
In other cases, there could be a very distinct component that corresponds from one system to another. For example, in comparing the outliner capabilities of two word processors, one of them might use a rotating triangle to show the state of an outline heading, as either open, closed or empty, while another uses a diamond. A legitimate question to ask in this situation is `what plays the role of the rotating triangle in the other system?' Since the systems are sufficiently similar at this level, this question has a well-defined answer.
The functional representation provides the infrastructure for deciding when such questions are well-formed, and for answering them when they are. If the functional representations of the two systems have a common functional structure down to the point where the comparison is made, then it is clear that the alternative is simply the device that fills the same role in the other architecture. This can be true, even if other parts of the architecture are very different. In the word processor example, the fact that the text substitution system of one system is very different from the other is not relevant to determining the alternatives for the outline indicator.
In the case where the functional descriptions do not coincide, strictly speaking, there is no legitimate alternative, and the question cannot be answered. This would be the case in the compiler/interpreter example above. However, even in this case, the functional representation can give some information; the degree to which the two architectures are common specifies common functional roles for both systems at that level. Although there might be no legitimate alternative for the lowest-level device, the functional representation can at least tell what is the alternative for the most detailed role for which there is a legitimate alternative. In the case of the interpreter, the nearest functional device that encloses the disassembler might be the tracing and debugging package.
A functional representation differs from non-functional representations in that it is not bound to represent the structure of a program. Contrast this with formally specified software components, where the specification corresponds to a particular module. In order for such a composition to `work', the composed components must be capable of interoperating as pieces of software. A functional representation, on the other hand, offers only a single particular point of view on a software composition. Verifying, through a functional representation, that a composition will satisfy its requirements does not guarantee that the composition will work; it only guarantees that the aspects modeled in the point of view represented by that representation will be honored.
ZD differs from informal representation systems in that it allows for automatic verification of the aspects it represents. Kaptur, for example, manages issues and trade-offs in design rationale. However, there is no way to make sure that the architectures and designs considered actually exhibit the properties as stated in the trade-offs as represented.
Future work in the FAMILIAR project will be to integrate a formal functional representation into an alternatives management system to facilitate the capture of design rationale information. The functional representation will provide a structure for recording the different sorts of design rationale, as well as providing a management system for the alternatives. Further goals of the project are to use the hybrid informal/formal representation to facilitate the migration of informal rationale to formal rationale.
Dean Allemang completed his PhD at The Ohio State University in 1990 applying functional representation to software. Between 1990 and 1995, he worked at the University of Zurich, the Istituto Dalle Molle di Studi d'Intelligencia Artificiale in Lugano, and the Swiss Federal Institute of Technology in Lausanne on knowledge acquisition and case-based reasoning for expert systems. He completed his tour of Switzerland with a year and a half at the Research and Development Division of Swiss Telecom, where, among other projects, he worked with Beat Liver on functional representation of software. In 1996, he joined Organon Motives where he contributed a chapter on knowledge acquisition to the ODM guidebook.