Fusion Rule Technology




Rule Tool

Support for engineering correct sets of rules is provided in the form of a rule tool. This tool incorporates a number of tests that help the user to engineer a set of rules that meet what might be condisidered minimal adequacy conditions on a set of well-engineered rules (see below). But perhaps its most important feature is that it relieves the user from having to compose and edit rules in raw XML, something which is cumbersome, and can be hard to do. Instead, the tool provides the user with a GUI and a number of dialogs, allowing her to select the components of rules, such as conditions, actions, variables, and constants, etc, and alter the order, both of arguments within an action or condition, and the order of actions and conditions within rules. Inputing the DTDs for both the input and the output reports allows the automatic generation of report branches, that can be used to construct schema variables and constants via drag and drop functionality, thus helping to minimize an obvious source of error--the mispecification of report branches. Combo boxes also provide easy access to a built in library of generic, multi-application condition predicates, and to the various actions used to construct the output reports.

The rule tool can be used to create a new rule, edit an existing rule, delete a rule from a rule set, reposition a rule in a rule set, and renumber the rules in a rule set. The rules constructed or edited can of course be saved in XML form for use with the fusion tool software.

The rool tool provides the following logical support for writing rules:

Automatic grouping of rules into subgroups. Rule sets can be subdivided into subroups, where the rules in a subgroup are intended to construct the same element in the output, merged report. The significance of these subgroups is that at most one rule per subgroup should be executed, on pain of one rule overwriting the result of another.

Pairwise comparison of rules in subgroups to check for inconsistency. For each subgroup, rules are checked pairwise for inconsistencies (the occcurence of "not" before a common condition name) to ensure that for any given set of input reports, at most one rule in the subgroup will execute.

Rule coverage. A minimum adequacy condition on the coverage of a set of rules with respect to the output merged report is that for each element in the output report, there is at least one rule whose actions are intended to construct that element and/or add information to it. This condition is checked, and an error message displayed naming any missing output report elements.

Output report structure. Rules are executed in the order in which they occur in the rule set. If the rules are in the wrong order, a rule may attempt to add some information to a component of the merged report tree that has not yet been constructed. This may also occur if a rule or action has simply been omitted. The tool checks the integrity of the output report tree by constructing from the rule set the tree, if any, that the rules would construct if executed. (This is displayed using the Java JTree component.) To check, further, that the report structure the rules would construct has the tree structure that the application is intended to construct, the tool also reconstructs and displays the tree that the output report DTD constrains. The user can then simply inspect the two trees to ensure they are the same.

Occurrence of Foundational Rules and Initialize Actions. Any well-engineered rule set must contain at least one Initialize action (so as to construct the root node of the output report), and it's a good idea if the rule with that action (at least) is given Foundational status. The rule tool checks this is so, and also checks that these rules and actions occur before other rules and actions. Screen shot of the rule engineering toolkit checking the structure of an output merged report.

Figure 1: Screen shot of the rule tool. The upper left window is used to display a rule that has just been created, but not yet added, to the rule set. The lower left window displays the set of rules being edited or checked (in this case a set of rules for merging weather reports). The two windows in the right half of the GUI are displaying, firstly, the structure of the merged report that the rules would create and, secondly, the structure of the merged report that, according to the DTD, they ought to create. Since, as can easily be seen, the two trees are not identical, we know that rules remain to be written to deal with some elements in the output report.

Screen shot of the rule tool editing a rule.

Figure 2: The top-level rule editing dialog. The complete rule is displayed in the top window. Tabs display the individual conditions and actions. The user can alter the position of these using the "up" and "down" buttons, as well as creating and deleting conditions and actions. Combo boxes allow the selection of condition or action names, and the sign of the condition. The user can also select the status of the rule (optional or foundational). To edit the arguments of a condition or action the user clicks on "Add/Edit".

Screen shot of the rule tool editing a the arguments of a rule.
Figure 3: This dialog is displaying the three arguments of an action. The user can alter their order using the "up" and "down" buttons, delete an argument using "remove", and add or edit an existing argument.

Screen shot of the rule tool editing a the arguments of a rule.
Figure 4: This dialog allows the user to edit or create a new argument. The name of the argument is displayed in the top text field. Often this name will be a branch from a report, in which case the appropriate branch can be dragged from the list in the right hand window and dropped in this text field. The next three combo boxes allow the user to specify the type of argument (variable, constant, or logical variable) and, where relevant, the kind of variable.
Contact a.hunter@cs.ucl.ac.uk or +44 20 7679 7295.

Back to Fusion Rule Technology homepage.