Design Rationale as Explanation Content Capture, and Use

Swartout [26, 27] first identified the potential utility of DR as explanation content. His work on the explainable expert system (EES) project was an attempt to address some of the explanation content deficiencies identified in early expert system research. In this earlier work, especially Mycin [4] and derivative projects [10], researchers found significant gaps between the problem-solving strategies systems built to replicate or enhance, and the structural properties of the systems created to realize these strategies. Clancey [10, 11] identified this missing link as the detailed support knowledge representing the translation of domain requirements into functional software systems. The nature of this support knowledge presented a knowledge engineering conundrum because it represented a huge and seemingly intractable base of knowledge that was not germane to the application domain per se, but which was required to explain to domain users how system functionality emerged in relation to their domain requirements.

Swartout’s attempt to mitigate the effects of this knowledge gap involved construction of an automatic expert system generator that tracked and logged decisions made by the system as it produced rules and control logic based on input in the form of relatively abstract, domain-specific problem-solving goals. The early XPLAIN system and later work on the EES relied on the existence of a domain model and problem-solving principles to translate goals into a system of productions, or rules. The log of automatic design decisions served as justifications for why the resulting system was appropriate given the domain model and principles and the problem-solving goals as expressed by the system developer.

One of the challenges faced by the EES developers was to elucidate the link between domain-independent, strategic concepts and the domain-specific or instance-specific information that is needed to apply a strategic concept in a particular goal scenario. For example, a design principle such as “simplify wherever possible” might be instantiated in a software design as “we can combine these two modules into one with no loss of cohesion.” The EES attempts to solve this linkage problem through the concept of capability descriptions, which relate system goals to operationalized plans to achieve those goals. Capability descriptions are used to define what the plan does, its competencies. System goals are mapped to plans and associated methods used to achieve those goals through these capability descriptions. The EES was thereby designed to ‘understand’ the goals that it might be called upon to explain.