Java Code for Blocks World Example

return ruleBase; } The Drools class F if oConf lictResolver is not so well named, but a first-in first- out FIFO strategy is like depth first search. The default conflict resolution strategy favors rules that are eligible to fire from data that has most recently changed. Since we have already seen the definition of the Java POJO classes used in the rules in Section 5.4.1 the only remaining Java code to look at is in the static main method: RuleBase ruleBase = readRule; WorkingMemory workingMemory = ruleBase.newStatefulSession; System.out.println\nInitial Working Memory:\n\n + workingMemory.toString; Just fire the first setup rule: workingMemory.fireAllRules1; IteratorFactHandle iter = workingMemory.iterateFactHandles; while iter.hasNext { System.out.printlniter.next; } System.out.println\n\n Before firing rules...; workingMemory.fireAllRules20; limit 20 cycles System.out.println\n\n After firing rules.; System.out.println\nFinal Working Memory:\n + workingMemory.toString; iter = workingMemory.iterateFactHandles; while iter.hasNext { System.out.printlniter.next; } For making rule debugging easier I wanted to run the first “start up” rule to define the initial problem facts in working memory, and then print working memory. That is why I called workingM emory.f ireAllRules 1 to ask the Drools rule engine to just fire one rule. In the last example we called workingM emory.f ireAllRules with no arguments so the rule engine runs forever as long as there are rules eligible to fire. After printing the facts in working memory I call the f ireAllRules 20 with a limit of 20 rule firings because blocks world problems can fail to terminate at least the simple rules that I have written for this example often failed to terminate when I was debugging this example. Limiting the number of rule firings is often a good idea. The output from this example with debug output removed is: Clearing: remove C from B to table 89 Moving B from A to C Clearing: remove B from C to table Moving A from table to C Moving C from table to B Done Note that this is not the best solution since it has unnecessary steps. If you are interested, here is the output with debug printout showing the facts that enabled each rule to fire: [Block_11475926 C on top of: B supporting: ] [Block_14268353 B on top of: A supporting: C] Clearing: remove C from B to table [Block_3739389 B on top of: A supporting: ] [Block_15146334 C on top of: table supporting: ] [Block_2968039 A on top of: table supporting: B] Moving B from A to C [Block_8039617 B on top of: C supporting: ] [Block_14928573 C on top of: table supporting: B] Clearing: remove B from C to table [Block_15379373 A on top of: table supporting: ] [OldBlockState_10920899 C on top of: table supporting: ] [Block_4482425 table on top of: supporting: A] Moving A from table to C [Block_13646336 C on top of: table supporting: ] [Block_11342677 B on top of: table supporting: ] [Block_6615024 table on top of: supporting: C] Moving C from table to B Done This printout does not show the printout of all facts before and after running this example.

5.5 Example Drools Expert System: Help Desk System

Automating help desk functions can improve the quality of customer service and reduce costs. Help desk software can guide human call operators through canned explanations that can be thought of as decision trees; for example: “Customer re- ports that their refrigerator is not running – Ask if the power is on and no circuit breakers are tripped. If customer reports that power source is OK – Ask if the light 90 is on inside the refrigerator to determine if just the compressor motor is out. . . ”. We will see in Chapter 8 that decision trees can be learned from training data. One method of implementing a decision tree approach to help desk support would be to capture customer interactions by skilled support staff, factor operator responses into standard phrases and customer comments into standard questions, and use a machine learning package like Weka to learn the best paths through questions and answers. We will take a different approach in our example for this section: we will assume that an expert customer service representative has provided us with use cases of common problems, what customers tend to ask for each problem, and the responses by customer service representatives. We will develop some sample Drools rules to encode this knowledge. This approach is likely to be more difficult to implement than a decision tree system but has the potential advantage that if individual rules “make sense” in general they may end up being useful in contexts beyond those anticipated by rules developers. With this greater flexibility comes a potential for less accuracy. We will start in the next section by developing some POJO object models required for our example help desk expert system and then in the next section develop a few example rules.

5.5.1 Object Models for an Example Help Desk

We will use a single Java POJO class for this example. We want a problem type, a description of a problem, and a suggestion. A “real” help desk system might use additional classes for intermediate steps in diagnosing problems and offering advice but for this example, we will chain “problems” together. Here is an example: Customer: My refrigerator is not running. Service: I want to know if the power is on. Is the light on inside the refrigerator? Customer: No. Service: Please check your circuit breaker, I will wait. Customer: All my circuit breakers looked OK and everything else is running in the kitchen. Service I will schedule a service call for you. We will not develop an interactive system; a dialog with a customer is assumed to be converted into facts in working memory. These facts will be represented by instances of the class P roblem. The expert system will apply the rule base to the facts in working memory and make suggestions. Here is the Java class P roblem that is defined as an inner static class in the file DroolsHelpDesk.java: 91