Published in Proceedings of 10th European Conference on Artificial Intelligence, 1992, Vienna, Austria.

Dj Vu: A Hierarchical Case-Based Reasoning System for Software Design

Barry Smyth Hitachi Dublin Laboratory Trinity College Dublin 2 Ireland. Tel. 01-6798911 Fax. 01-6798926 E-mail: bsmyth@vax1.tcd.ie Pdraig Cunningham Hitachi Dublin Laboratory Trinity College Dublin 2 Ireland.

Abstract
Dj Vu is a case-based reasoning system for software design. This paper describes the hierarchical case-base in Dj Vu and the blackboard based architecture that controls reasoning with this case-base. The case-base is structured as a partonomic hierarchy. Each complete solution in the case base is represented by a top-level case describing the outline of the solution. This top-level case contains pointers to several 'detail cases' representing the modules that make up the solution. In addition the case base has a taxonomic structure that facilitates case retrieval. The partonomic structure of the case base requires that the case base reasoning process is multi-stage rather than the singlepass retrieval process that is normal in case-base reasoning. In Dj Vu a solution is built by first retrieving and adapting a top-level case and then retrieving and adapting detail cases to build up this solution. The control issues introduced by this multi-stage case-base reasoning is addressed by organising the system as a blackboard system with dedicated control agents organising the reasoning process.

Published in Proceedings of 10th European Conference on Artificial Intelligence, 1992, Vienna, Austria.

1.

Introduction

This paper describes a case-based reasoning system for software design. The system is novel to the extent that using it to generate a new solution involves several interations of the case-base reasoning (CBR) process. This requires that the case-base have a hierarchical structure and means that the control process is more complex than in single-pass CBR systems. Case-based reasoning is motivated in large part by the intuition that much of human expert competence works by retrieving and modifying previously solved problems stored in memory. One promising area of application for CBR is in software engineering. The intuition about human expert competence working by retrieving and adapting past solutions holds - the systems programmer who wishes to produce a script for a particular purpose will retrieve a similar script and adapt it. The question for CBR research in software engineering is can this process be formalised into an automatic software development system. Attempts at using CBR in software development have the advantage that the software development process can be formalised and there has been extensive research in automatic programming and formal methods. Indeed the main difficulty in automatic programming is the huge search process involved in transforming the specification into executable code. This is precisely the issue that is addressed by using CBR in software design - in that transforming the retrieved solution to solve the target problem is expected to be easier than producing that solution from transformations on the initial specification. This advantage of formalization is offset to some extent by the 'brittleness' of the programming domain. A piece of code cannot be slightly wrong; this is in contrast to other CBR applications where a family of solutions are acceptable. Our experience has been that this problem of brittleness is exacerbated if the solution is to be in a comparatively low level language. The more remote the solution is from the input specification the more difficult it is to automate the adaptation process. The Dj Vu system described here works with a control programming language that is very high level and consequently the adaptation process is more tractable. This plant control problem domain will be described in the next section before discussing the details of the CBR system. Dj Vu's hierarchical case base structure is described in section 3 and its blackboard control architecture in section 4.

2.

Problem Domain

As mentioned in the introduction, the main difficulty in using CBR for software design is the problem of adapting the solution in the base case to fit the requirements of the target specification. This problem is relieved in our situation because the solution is expressed in a very high level representation. The solution is consequently closer to the problem specification so reasoning from specifications to solutions is more tractable. We are concerned with plant control software for controlling autonomous vehicles in loading and unloading metal coils in a steel milling process. Much work has already been done in automating the actual generation of the plant controller code [Sakurai '90] thus providing a large amount of initial cases for the case base. The input to this code generation system is a network representation of the operation procedure, an example of which is shown in the solution window in Figure 1. The code generation system compiles this network representation into executable code.

Published in Proceedings of 10th European Conference on Artificial Intelligence, 1992, Vienna, Austria.
{ CB } Edit Instance: F-BUGGY-1S Child of FORWARD-BUGGY

Slot Names:

Selected Feature

Slot:

DESTINATION
Filler:

Case Id. Internal Features

TENSION-REEL
Solution: Buggy Fast Forward Position Check Decelerate (200m Before Tension Reel) Buggy Slow Forward Stop (Tension Reel Position) Buggy Stop

Feature Value

Network Representation

Figure 1. An example case from the Dj Vu case-base as presented in the case browser. This example is a detail or module case that is part of a top-level solution in the case-base. The toplevel case to which it belongs involves removing a coil of worked steel from a steel mill. All the cases under consideration involve loading or unloading empty spools or coils of material and moving them to storage areas. The different cases involve different arrangements of the spindles on which the reels are loaded and different layouts of the storage areas for reels and empty spools. The objective with Dj Vu is to receive a problem statement such as "Remove Spool from tension Reel with Single Speed Buggy" given a particular shop floor layout and to produce a solution that can be compiled into executable code. The first step involves producing a full specification of this case that will be the basis of the CBR process.

3. Hierarchical Case Base

We mentioned already that the case shown in Figure 1 is a detailed case that is part of a more elaborate solution. Each solution in the case-base is stored as several cases, one top level case and detailed cases representing the components of the top level case (the architecture will support intermediate levels if necessary). In Figure 2 f-buggy-1s is a detailed case and r-spool-1sbuggy is a top-level case. This is in contrast to traditional CBR systems where each case represents a complete solution at the level of the planners's primitive actions. This partonomic structure adds greater flexibility to the CBR component of Dj Vu and supports the recursive nature of a Dj Vu problem solving episode. When presented with a target problem Dj Vu retrieves a 'best' plan, a top-level case (TLC), from the case-base. The adaptation of this TLC invokes further retrievals corresponding to its internal low-level components. However the detailed cases (DCs) retrieved will typically be different from those indicated by the retrieved TLC since retrieval will be on the basis of some element of the target specification. Thus, numerous retrievals guided by the initial TLCs structure will result in a collection of code components which are adapted to conform to the target situation, and then integrated to form a complete target solution (see Section 4). Individual cases are indexed by a set of classification features which locate the case within a taxonomy of case types reflecting the functionality of plant-model planning [Hammond '89] (see Figure 2). Each classification feature is represented by a type node in the case-base and defines a particular set of internal features. Actual cases are stored in case nodes and contain both the case solution and an internal feature set providing a description of the case goals. The features available to a case node are those inherited from its superclasses. The main advantage of this taxonomic structure is the increased efficiency of the retrieval process. 3

Published in Proceedings of 10th European Conference on Artificial Intelligence, 1992, Vienna, Austria.

*Program*

Stepping

Buggy

Forward-Buggy @

f-buggy-1s f-buggy-2s

Detailed Case

Back-Buggy @ Spool r-spool-1s-buggy

b-buggy-1s b-buggy-2s

Remove-Spool @ Load-Spool @ UnLoad-Spool @

r-spool-1s-buggy l-spool u-spool r-spool-1s-buggy Forward-Buggy @

Top-Level Case

Removal f-buggy-1s l-spool b-buggy-1s u-spool Move

Remove-Spool @ Forward

f-buggy-1s f-buggy-2s

Key: Type Node

Case Node

Figure 2. A portion of the case base viewed as a taxonomy, the insert shows the partonomic structure of one of the top-level cases. The retrieval process is a two-step operation. The first step uses the classification features of the target specification to locate a number of case-clusters. The classification features reflect the structure of the problem domain and thus this first retrieval step will retrieve a set of cases which are similar to the target problem. The second stage matches the internal features of the target against the internal features of each case retrieved by the previous step and results in the retrieval of a single, 'best' case. Determination of 'best' case is based on a similarity metric which estimates the adaptation distance from the base to the target case (i.e. a measure of the 'work' needed to adapt the base case to the target case).

4.

Blackboard Solution

The fact that the Dj Vu is a multi-pass rather than a single pass system as is normally the case in CBR introduces a problem of control into the system. This problem is addressed by organising the system as a blackboard with the solution being built upon the panels of the blackboard by the different knowledge agents (see Figure 3). There are four knowledge agents in the current system. Two of these agents are high level agents controlling the dissection of the problem and the composition of the solution; these are the Specification Analysis and Integration Agents respectively. The two low level agents are the Retrieval agent and the Adaptation agent; these perform the details of the CBR. (see also [Nii '86] and [Cunningham '91] on blackboards)

Retrieval Agent

Case Base

Adaptation
Retrieved Case (f-buggy-2s)

Solution
f-buggy-2s l-spool b-buggy-2s u-spool

Case Specification
f-buggy-2s Operation: Move Forward Object :Buggy Speeds : 2

(Buggy Fast Forward Start Node 1) (Buggy Slow Forward Node 1 Node 2)

? ? ?

Target Specification
Detailed Problem specification

Integration Agent Adaptation Agent Specification Analysis Agent

Figure 3. The blackboard based control structure in Dj Vu. 4

Published in Proceedings of 10th European Conference on Artificial Intelligence, 1992, Vienna, Austria.

The problem solving action of Dj Vu works as follows: The problem specification is formulated as a frame structure that reflects the system configuration and layout - this is the target specification. This is passed to the retrieval/adaptation agents and the best top-level case is adapted and returned. This TLC acts as an integration template on which the solution is built. The Specification Analysis agent works on this adapted top-level solution resulting in a number of CBR retrieval-adaptation cycles that fill out the details of the solution. The result of each CBR cycle is the passing of a solution component to the solution panel for integration into the evolving target solution. For example consider the problem "Remove Spool from Tension Reel using 2 Speed Buggy"; this is the problem shown in Figure 3. The TLC retrieved is r-spool-1s-buggy, the main difference between this and the target case being that the transport buggy in this case is capable of two speed operation so the modules controlling the buggy will have to be changed. The retrieved TLC has the components Forward*1s-Load-Back*1s-Unload and this is adapted to Forward*2s-LoadBack*2s-Unload. The Specification Analysis breaks this down into its 4 constituents and passes each of these to the Retrieval/Adaptation Agents in turn. The Load and Unload detail cases retrieved are those corresponding to the retrieved TLC but different detail cases are retrieved for the 2-speed moves (in fact f-buggy-2s and b-buggy-2s ). These partial solutions are picked up by the Integration Agent and integrated into the solution. In this situation the detail cases require no adaptation; this will not always be the case.

5.

Conclusion

This multi-pass CBR process reflects the human expert's process of design by successive refinement. However, the increased complexity of the CBR process introduces an added problem of control. The blackboard structure adopted in Dj Vu shows considerable promise in handling this added complexity. The process of successive refinement in the CBR require that the case-base contain cases at different levels of detail. These are organised into a partonomic hierarchy. In the current implementation this hierarchy contains just two levels; however intermediate levels can be added in the future. The cases are stored as frames which form a taxonomy that facilitates the retrieval process. Current research efforts concentrate on experimenting with the organisation of the blackboard process. In the future our intention is to develop the system as an interactive man-machine system with the user interacting in the adaptation process.

References
[Cunningham '91] Cunningham P., Veale T., "A Flexible Blackboard Architecture for Automatic Knowledge Elicitation form Text", in Proceedings of Fifth European Knowledge Acquisition for Knowledge Based Systems Workshop, Crieff, Scotland, May, 1991. [Hammond '89] Hammond K., "Planning from memory" in Case-Based Planning, ed., B. Chandrasekaran, Academic Press, 1989. [Nii '86] Nii H. P., "Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures", AI Magazine, Vol.7. No.2, pp39-53, Summer, 1986. [Sakurai '90] Sakurai T., et al. "An Automatic Programming System based on Modular Integrated-Concept Architecture (MICA)", in Proceedings of International Conference on Industrial Electronics, Control and Instrumentation, pp1303-1308, Monterey, California, 1990. 5

Published in Proceedings of 10th European Conference on Artificial Intelligence, 1992, Vienna, Austria.