Abstract
This chapter presents an overview of the issues affecting and the tools used for the debugging of rule bases. It describes the challenges in debugging rules, presents a classification of the debugging methods developed in academia and the tools currently used in practice. This chapter explains the main debugging paradigms for rule based systems: Procedural Debugging, Explanations, Why-Not Explanations, Algorithmic Debugging, Explorative Debugging, Automatic Theory Revision and Automatic Knowledge Refinement.
TopIntroduction
The creation of rule bases, like the creation of any software system, is an error prone process. In order for a rule base to function satisfactory, (most of) the errors have to be found and need to be corrected. The most common way to find errors is by testing the rule base, discovering bugs in the way these tests are processed and then to find and correct the faults causing them - debugging. The debugging process is an important part of any non-trivial manual rule base development, indeed, a recent survey of 50 developers of rule based systems found that the difficulty of debugging was the most important issue hindering a rule base’s development.
This big role and difficulty of debugging stands in marked contrast to the often professed believe that rule languages are a simpler and more natural way to build computer systems - implying a lesser importance and difficulty of debugging. This idea of rule languages as a simpler way to program rests on three observations:
- •
Rule languages are (mostly) declarative languages that free the developer from worrying about how something is computed. This should decrease the complexity for the developer.
- •
The If-Then structure of rules resembles the way humans naturally communicate a large part of knowledge.
- •
The basic structure of a rule is very simple and easy to understand.
However, in particular in relation to debugging, this promise of simplicity remains elusive. The same survey mentioned above found that a large majority of developers of rule based systems felt that it was easier to debug a conventional (object oriented or procedural) program than a rule base.
In a study of three rule base development processes (Zacharias 2008b) we identified six reasons for this apparent mismatch between the promise of simplicity and the difficulty of rule base development; reasons that explain why the simple and well understood rules are nevertheless hard to develop and to debug.
Key Terms in this Chapter
Rule Base Explanations: Explanations are abstractions of the program trace that aim to explain the program execution to a user. Explanations are used to build confidence in the results of expert systems, to facilitate better understanding of rule based systems, to teach problem solving and for debugging.
Why-Not Explanations: Special explanations that can also explain why a particular result was not returned. Why-Not Explanations exist in two variants, in one they rely on the user to ask consecutive questions to find the root cause, in the second the system automatically identifies the root cause and presents an explanation for that.
Debugging: The diagnosis and removal of faults in a computer program based on error revealing values.
Knowledge Refinement: Automatic debugging approach that proposes changes to the rule base that would remove the fault.
Procedural Debugging: A procedural debugger offers a way to indicate a rule/rule part where the program execution has to stop and has to wait for commands from the user. The user can then examine the current state of the inference engine and give commands to execute a number of the successive instructions. In rule bases procedural debuggers are based on the execution of the inference engine.
Algorithmic Debugging: Algorithmic debuggers divide the program into hierarchical ordered parts, each part having a number of subparts that are used in this parts computation. Each part has some identifiable result. These approaches then try to identify the part(s) that create a wrong result even though its subparts return correct results.
Automatic Theory Revision: Automatic debugging approach that also changes the rule base to remove a fault.
Explorative Debugging: Manual Debugging paradigm in which the user explores the logical/semantic structure of the rule base’s execution.