University of Washington, Bothell
CSS 482: Expert Systems
Fall 2010
Homework 4: Diagnosis and Backward Chaining
Assigned: Wednesday, October 20, 2010
Due: Wednesday, October 27, 2010
Consider the following JESS program for diagnosing causes of abdominal pain.
This program has two obvious limitations. First of all, the only output is an asserted fact. Second, all of the symptoms must be present in the initial state of the working memory for a diagnosis to ensue. Yet patients will typically mention only the most distressing symptoms first, such as pain, and may not mention other symptoms, such as swollen ankles, right away.
I ask you to modify the program in two different ways so that it asks about missing symptoms.
The easiest way to do gather information incrementally, based on other information we know, is to add rules that have as their sole condition a pain symptom, such as
and whose actions put questions to be asked into working memory. You will then need a rule to ask those questions and place the right sign facts into working memory, depending on the answer received. Here is a template for the “question” datatype:
Produce a version of this diagnosis program that asks questions for missing signs using forward chaining and outputs its diagnosis.
Diagnosis problems are natural for a backward chaining approach, as what we typically want to do is have our reasoning process and search for additional information driven by the partial rule matches we already have. You will of course need to indicate that sign facts can use backward chaining. Instead of using question facts, you will use need-sign facts to trigger question asking rules that will satisfy those needs (or fail to, if the answer received says that that isn’t a symptom). As in the forward chaining approach, your program should output its final diagnosis.
Please submit your program, with documentation (in which you outline your approach, ordered in the steps given above) and example runs (that illustrate each of the grading criteria given), to our CollectIt drop box. Your written documentation should be concise, but should allow the reader to understand your design without reference to the code.
Your code should be easy to read and understand. Use consistent indentation. Each file should start with a comment that includes the file name, your name, the date and a summary of the file purpose/contents. Each deftemplate, defrule, etc. should have a useful comment string and comments indicating what each slot means. The gist of your written documentation should be included in comments in your file(s).
There are a total of 100 points available in this assignment. The forward chaining part is worth 50 points and the backward chaining part is worth 50 points. Within each part, I will award 10 points for your program asking the user questions and printing out a final diagnosis. The remaining 40 points will be awarded based on my assessment of how close your program is to complete functionality. Therefore, it is essential that your documentation be clear about what is and is not working, and that you include test runs that support your assertions.