This project will transfer the extant capabilities of both systems, adapting them as appropriate to the demands of design rationale capture, to form a new system called Familiar (Formal Alternatives Management Integrating Logical Inference And Rationales). The capabilities of Familiar will be enhanced by synergistic interactions between these two technologies. Drawing on the capabilities of ZD, Familiar will support the combination of designs for which the rationale is already known, drawing attention to conflicts, raising design obligations, or instantiating known design patterns as appropriate. Drawing on the capabilities of KAPTUR, Familiar will manage alternative designs and trade-offs; it will record and manage both informal rationales and those derived from analysis by external tools.

The Base Technologies

A number of features of the formal system ZD make it particularly appropriate for integration with an alternatives management system like KAPTUR. ZD provides the capability to verify the consistency of a combination of "devices" (i.e., components) that have been formally described, generating design obligations to compensate for any conflicts that have been found. Because ZD separates the description of devices from the semantics of their implementation, it can represent more than just program code, and it has been applied to several types of teleological artifacts (of particular interest for Familiar are data structures, design patterns, task structures, and business processes). ZD represents devices at several levels of detail. It is possible in ZD to have a formal description of a device, even if details are not known down to the level of program language semantics. This characteristic is one of the keys to integrating ZD with the alternatives management model of KAPTUR.

The main contribution of KAPTUR to Familiar is the notion of managing alternatives through a feature model. Alternative solutions to a design problem are characterized by their distinctive features. Each feature is associated with a set of tradeoffs in relation to the overall system goals. Judgment is typically required to decide which compromises will have the least negative impact on a design. KAPTUR currently allows for recording and managing informal rationales in the form of natural language annotations. In Familiar, we intend to support formal rationales (generated by ZD) within the alternatives management schema, and to support the incremental formalization of alternatives as a domain matures.

Technical Plan

Some of the work of this project will be to adapt the existing capabilities to a single design rationale system. ZD has been used primarily for diagnosis and repair of software systems, and will have to be modified to accommodate the different demands of design rationale. KAPTUR's user-interaction model for visualizing alternatives will be enhanced on the basis of lessons that were learned in the KAPTUR project.

The real value of Familiar, however, will follow from the integration of ZD and KAPTUR capabilities. Constraints generated by ZD will be used as features for the alternatives manager (the new incarnation of KAPTUR). Conflicts and design obligations can then be traded off against one another, or against other features, to provide a context for making a design decision. This can be done incrementally, without having to formalize all the alternatives to be considered, by taking advantage of ZD's abstraction capability. The more detail to which the alternatives are formalized, the more ZD can be used to generate decision criteria.

We will explore methods of hiding the ZD formalism through the visualization support capabilities of the alternatives manager. This would allow us free the user of the need to learn ZD. The user could, for example, pose questions of the form, "I want something like that, but in this context." Seen in this way, management of alternatives is not just an end in itself; it is, rather, the basis of a domain evolution path from informal to formal rationales.

We expect that ZD's abstraction capability and KAPTUR's support for informal rationales will enable Familiar to manage more than just design decisions. Tradeoffs, decisions, and rationales by a variety of stakeholders in a variety of contexts will be representable and manageable by the tool.

Features

• Knowledge schema representing component and system features, alternatives, tradeoffs, and rationales
• Formal representation of components at arbitrary levels of abstraction
• Formal inference of the functional rationale for a component within a system's teleology
• Automated propagation of formal obligations between components in a system design
• Representation of non-functional rationale either informally or by reference to external discipline-specific tools
• Migration from informal to formal representation of rationales as domain knowledge matures
• User interface emphasizing visualization of design alternatives and tradeoffs through thumbnails and related techniques

References

Bailin, S.C. KAPTUR: Knowledge Acquisition for Preservation of Tradeoffs and Underlying Rationales. CTA Inc., 1991.

Chandrasekaran, B., Goel, A., and Iwasaki, Y. Functional representation as design rationale. IEEE Computer, vol. 26, no. 1, pages 48-56, 1993.

Liver, B. and D. Allemang, "A Functional Representation for Software Reuse and Design", Journal of Software Engineering and Knowledge Engineering, vol. 5, no. 2, 1995.

To Design Rationale Capture at Knowledge Evolution, Inc.

To the Knowledge Evolution, Inc. Home Page

The MMDN will fuse the expressive and communicative power of multi-media with the explanatory and imaginative power of narrative to convey the contents of a cumulative design record.

In this project, Knowledge Evolution, Inc. (KEI), supported by the University of Southern California's Information Sciences Institute (ISI), is developing a Multi-Media Design Narrative (MMDN) capability that can fundamentally alter the way software design knowledge is communicated among designers and, indeed, all stakeholders of a software system.

The MMDN will build on three complementary technologies:

• KEI's case-based approach to software engineering, exemplified in the KAPTUR tool
• Work by ISI on applying multi-media to software documentation (the IDOC and MediaDoc projects), and
• Literate Programming, as introduced by D. Knuth and since adapted through numerous tools in industry and academia.

In the resulting environment, a software design will take shape as a compelling and continually embellished story that has purpose and meaning to those who make decisions about the system.

The project will introduce explicit narrative structure into the software design record and package it in a multi-media presentation similar to computer-based training. For any particular task, the narrative structure will lead the developer along the most relevant threads in the web of recorded decisions and artifacts.

At a more basic level, the narrative structure will raise the stakes of the design process in the eyes of the developer by engaging her in a dialog, inviting her to become an actor in the ongoing story, highlighting and giving substance to the implications of decisions she has to make.

Phase I Technical Objectives

The fundamental insight that we are using to structure the multi-media presentation is that the design record should tell a story. The idea of documenting software through a narrative about the decision process comes from Literate Programming. Knuth's contention was that program documentation should read like literature, if the author expects other developers to pay attention to it.

We are taking this observation a step further by proposing a dramatic (rather than strictly literary) paradigm, and taking advantage of multi-media in rendering it. The dramatic paradigm is distinguished from the strictly literary by the focus on actors (stakeholders) and their actions, and a more direct audio-visual presentation of the content.

Phase I of the project will establish a practical basis for constructing multi-media design narratives: a non-intrusive approach to data capture and composition of MMDN modules, and building blocks in the form of reusable design-narrative patterns.

While an ambitious designer could use the raw materials of the World Wide Web to construct a multi-media design narrative (by creating multiple pages and carefully structuring the links between them), he currently has no support in deciding what series of links will make an effective design narrative. The situation is analogous to creating a computer-based training course using a raw multi-media presentation tool: it can be done, but a good CBT authoring tool will provide added value by packaging the educational knowledge that is required in creating an effective course.

The need for such support is especially clear in the area of software design and explanation. Software developers are usually under severe time pressure, and they operate more often than not with tunnel vision directed at their immediate tasks. It is unlikely that a developer in these circumstances will take the time (much less achieve the cognitive distance) necessary to construct an effective design narrative - if she has only raw media-editing tools at her disposal. At best, she may construct some helpful Web pages and insert them into the larger network. The placement of the pages, and the overall effect on the implicit threads, are not likely to receive a lot of attention.

The technology we are developing, in contrast, will assist the designer in constructing effective design narratives. It will do so by providing narrative building blocks - reusable patterns that reflect proven ways of communicating a design narrative. The MMDN capability, through a set of templates and rules, will ensure that the design narrative conforms to such patterns both initially and as it evolves.

To Design Rationale Capture at Knowledge Evolution, Inc.

To the Knowledge Evolution, Inc. Home Page.

Technology Evaluation

• Software development as a cognitive activity
• Features of multi-media and virtual reality technology that impact cognitive performance

Technology Development

To Design Rationale Capture at Knowledge Evolution, Inc.

To the Knowledge Evolution, Inc. Home Page.

Software Reuse and Domain Engineering

KEI's approach to software reuse follows from our view of software development as knowledge creation. We view software reuse as the re-application of known solutions to known types of problems.

Software reuse, in this sense, is more than the reuse of code components, even more than the reuse of development-lifecycle products (such as requirements specifications, designs, and test plans). It is the reuse of software knowledge which may be embodied in any kind of lifecycle product or information artifact.

Our view of software reuse as knowledge re-application draws on ideas of case-based reasoning. The challenge is to solve a software development problem by relating it to previous efforts ("cases"), identifying the most relevant previous cases, adapting the previous solutions to the current problem, and finally adding the new case and its solution to the case base of available solutions.

This page describes our approach to:

• Domain Modeling - creating a reusable corpus of knowledge
• Knowledge Evolution - supporting change, discovery, and learning in software development
• Difference-Based Engineering - a reuse-based paradigm for the system development process

Domain Modeling

A key aspect of our approach to domain modeling is the identification and organization of features that distinguish cases from each other. An equally important aspect is the descriptive modeling of a domain: incorporating detailed information from existing systems ("exemplars") into the domain model, and paying close attention to the reasons for any differences between these exemplars.

Knowledge Evolution

It is fashionable in software engineering (and especially software reuse) circles to bemoan the occurrence of ad hoc decisions by a developer. We take a different view. If, as we believe, software development is largely a process of discovery and learning, then ad hoc or unprecedented decisions play an essential role. The key is to capture this knowledge and make it part of the evolving case base.

There are both organizational and technical challenges to capturing ad hoc discoveries and integrating them into the case base. Organizationally, the challenges have to do with transforming "private" knowledge into "shared" knowledge, and "tacit" knowledge into "explicit" knowledge. These issues are addressed in the LIBRA methodology.

Technically, the challenge is to develop the means to capture discoveries non-intrusively, and generalize them so they can be applied to similar problems. KEI is pursuing several avenues towards this goal, including our work in design rationale capture, and work in learning maintenance operations by example.

Difference-Based Engineering

We have combined the above-described approaches to reuse and evolution into an overall paradigm which we call Difference-Based Engineering (DBE). We have recently worked with Lockheed-Martin to integrate DBE into their Reuse-Oriented Software Evolution (ROSE) process model.

An organization practicing DBE approaches its software development tasks by relying heavily on its core competencies and its Experience Base, which is represented in the form of a Case Base. Members of a DBE organization have confidence that 1) they have done enough of "this type of work" in the past to be able to excel in any future tasks that come in, and 2) they have the resources to study, analyze, and draw conclusions about anything new in a given task. The Experience Base provides a record of past accomplishments and the way they were achieved, the decisions that went into them, the reasoning behind the decisions, lessons learned along the way, and encapsulated "how to" knowledge that summarizes the most useful experiences and packages them for future use.

The figure at the top of this page shows how systems are developed in a DBE organization. A task order comes in with a set of requirements for a new software system. The first thing that the engineers do is to interpret these requirements as a set of required features; in addition to requirements for the system itself, there may be other constraints that the engineers will have to work within, and these too are interpreted as features. With the feature specification at hand, the engineers surf the Experience Base to locate and retrieve the organization's most relevant knowledge - including, in particular, past systems that share many (if not all) of the current requirements, or systems that share some especially important requirements with the current task. The Alternatives Manager in FAMILIAR is intended to facilitate the process of evaluating the relevance of existing cases.

With the organization's relevant experience at hand, the engineers then assess just how relevant the experience really is. In the best case, the organization has "done this before" and the previous accomplishment can be rolled out and delivered. But if the answer is "we have never done exactly this before, but we have done similar things" then the engineers try to articulate the differences between the current task and the past accomplishments.

With the differences articulated, the engineers then investigate how any of the organization's past accomplishments can be modified to meet the current challenge. They will usually develop a number of alternative approaches to do this. As they define the alternatives, they study the implications of each approach and the tradeoffs between them. Then, on this basis, they select an approach. This is the classical systems engineering process, which lies at the center of DBE. The key observations of the analysis process are captured added to the Experience Base.

As the new system is developed, more decisions are made. These too become part of the design record of the new system, and are incorporated in the Experience Base for later playback and review, and to guide future efforts.

To the Knowledge Evolution, Inc. Home Page