Early uses: Representing decision logic with decision tables predates the advent of expert systems, and probably the invention of the computer. They have long been employed in printed form as a device for communicating decision logic that is both transparent and unambiguous. They have also been used as a systems analysis tool for documenting and verifying software logic, especially in business applications, and their use for that purpose is described in many systems analysis textbooks. There is some variation in both terminology and technique in these texts. In this tutorial we will generally follow the treatment provided in the following reference:

Analysis and Design of Information Systems, 2nd ed.
James A. Senn
© 1989 by McGraw-Hill, Inc.
ISBN 0-07-056236-9

This book is no longer in print, but is available in libraries and in the used book market, and is highly recommended. Many systems analysis and design texts cover the topic, but most provide only cursory coverage compared to Senn.

The high cost of developing software has long motivated an interest in automated tools to support the computer programming process. Many of the attempts at automatic program generation, developed as early as the 1960's, employed decision tables as an input to software that could generate parts of computer programs. Rule columns in a decision table can easily be converted into if...then... program statements, and the decision table itself is an effective tool for defining and verifying decision logic with non-programmers. Decision tables are often employed in modern business rules applications, either as an input to program generators or to provide the input to a rule engine that operates as a forward-chaining inference engine.

Decision tables and rule-based expert systems: The connection between decision tables and rules in a rule-based expert system is easily seen in the following decision table adapted from the eXpertise2Go Mini-Course Knowledge Engineering module. "Y" and "N" in the condition stub represent "Yes" and "No" ("T" and "F" could be used representing "True" and "False") and an "X" in the action stub means the action is recommended. "-" in a cell means the condition or action is irrelevant:

Limited, extended and mixed formats: This form of a decision table is called a Limited Entry Form, employing only Y, N, X, and blank or irrelevant entries. An Extended Entry Form of the table allows multiple values for conditions or actions. Here is the automobile diagnosis decision table in this alternative format:

Although either decision table form is easily mapped into expert system rules, the extended entry form is probably most effective for this purpose as the following rules extracted from the three columns of the table illustrate:

It is possible to combine the limited and extended entry formats in a Mixed Form decision table, and e2gRuleWriter supports this approach.

Generating all possible condition stub combinations: The number of possible decision table rules that can be generated from a set of conditions is the product of the number of values of each of the conditions. To make sure all possible rules are considered, a step-by-step procedure for constructing condition stubs is useful. Here is an example that illustrates one such procedure:

Condition1 with 2 values: T and F for True and False
Condition2 with 3 values: A, B and C
Condition3 with 2 values: 5 and 10

There are 2 x 3 x 2 = 12 possible combinations of these three conditions' values. To generate the condition stub:

1. Write down the product of value counts, dropping the count for the first condition and adding a one (1) after the last condition: 3 x 2 x 1 for this example.
2. To produce the first row of decision table values, write down each value of Condition1, repeating the value according to the count from the product of the value counts: 3 x 2 x 1 = 6, so each value will be repeated 6 times: T T T T T T F F F F F F and there will be 12 columns.
3. Drop the left most value from the product of value counts and write down each value of the next condition, repeating the value according to the count from the remaining value counts: 2 x 1 = 2 so each value will be repeated 2 times: A A B B C C This sequence is repeated until all columns (12 in this case) of the table are filled in. The second row of the table will have the following appearance: A A B B C C A A B B C C again including 12 columns.
4. The process is repeated until all conditions have been incorporated into the table. Dropping the next value from the product of the value counts leaves a 1, so the final condition values are written down once, with the sequence repeated until the 12 columns of the table are filled in: 5 10 5 10 5 10 5 10 5 10 5 10.

Inserting these sequences of values for the three conditions into a decision table's condition stub produces the following result:

At this point, action rows can be added to the table and each rule column examined to determine the appropriate action value(s). If a rule column is considered irrelevant it is dropped from the table.

Decision table simplification: It will often be possible to simplify a decision table, eliminating unnecessary conditions or combining rule columns before generating a knowledge base. The table simplifications supported by the e2gRuleWriter will be presented in more detail in a later section of this tutorial, but to illustrate the point, consider the following example table:

Rule1 and Rule2 have the same actions, have the same condition values for all but one condition (condition3) and all values of condition3 are represented by the two rules. Condition3 is thus irrelevant, and can be set to blank ("-") in Rule1 and Rule2. Once this is done, the two rules are identical and either one of the rules may be removed from the table.

Rule validation: It is also possible to examine rules in the decision table for errors and contradictions. In the following table:

Rule1 and Rule3 have identical conditions, but different actions -- a contradiction if Action1 and Action2 are mutually exclusive. The possible contradiction should be resolved before generating a knowledge base from the decision table. If it is possible for both actions to be taken simultaneously, the table should be simplified by combining the two rule columns:

Rule aggregation during conversion to knowledge base format: Depending on the format permitted for rules used in a specific expert system shell, it may be possible to aggregate decision table rule columns when the knowledge base is generated. Since all conditions in a decision table column must be satisfied for the action or actions in that column to be recommended, the conditions are connected by the "and" logical operator. Expert system rules typically allow use of the "or" logical operator:

In this table, each rule has a single condition, and in all three rules the same action is concluded. Therefore, the three rules are equivalent to the following single rule that could be generated for an expert system knowledge base:

Benefits and limitations of decision tables for developing knowledge bases:

What's good:

• The decision table presentation is simple to understand because it is transparent and unambiguous. Each column may be interpreted separately, and has a single interpretation: if the conditions are satisfied, the specified action or actions should be taken.
• A decision table can be interpreted by individuals who have knowledge of the problem domain, but have little or no background in systems analysis or software development.
• Knowledge base maintenance may be easier to accomplish without errors if the knowledge base is derived from a decision table. Common errors in knowledge base maintenance such as editing that creates inconsistent spelling of attribute names or values may be easy to detect or prevent with well-designed decision table software.

What's not so good:

• Expert system rules typically provide a higher level of abstraction than decision table rule columns: the ability to use "or" logical operators illustrated in the last section provides one example. It may take many columns in a decision table to represent a single expert system rule. Extensions to the classic decision table format, permitting "or" logical operators, "else" actions and other features are sometimes implemented to minimize these limitations.
• Using a decision table to produce a knowledge base requires learning another piece of software beyond the expert system shell.
• The conversion from the decision table to the knowledge base is typically one-way: you can't derive the decision table from the knowledge base. If the knowledge base is edited outside the decision table software (perhaps to employ inference engine capabilities not accessible from the decision table format), many of the knowledge base maintenance advantages are lost.

	Purpose of e2gRuleWriter and disclaimers: This software has been developed and is being distributed for educational and experimental purposes. It is a work in progress, and will continue to be a development prototype for some time to come. No claims are made for its serviceability, and eXpertise2Go.com assumes no responsibility for financial or other harm that occurs due to the use of e2gRuleWriter or knowledge bases developed with the software to work with e2gRuleEngine or due to decisions made based on use of these knowledge bases. While reasonable effort is being expended in the ongoing effort to test and debug the program, when you download and use eXpertise2Go software you become an informal member of the test team!
	You may not sell e2gRuleWriter: e2gRuleWriter is free software: eXpertise2Go.com isn’t selling it, so you can’t either. It is OK to use e2gRuleWriter to generate knowledge bases you develop for compensation, but your client must understand that e2gRuleWriter is not part of what they are paying for.
	Re-engineering/reverse engineering e2gRuleWriter is prohibited: You agree that you will not de-compile and/or modify the e2gRuleWriter application.
	Use of e2gRuleWriter to develop commercial Web sites is allowed: You may use e2gRuleWriter to develop e2gRuleEngine knowledge bases that are incorporated in commercial Web sites.

The download package: For ease of installation, the download is in the form of a compressed (.zip) file. This file contains the software for both e2gRuleWriter and e2gRuleEngine in the form of archives (.jar files) and a collection of decision table and .htm files that will be useful in testing your installation and learning to use the software. Download e2g3g.zip by clicking on the link below the list of files in the .zip and choosing the "save file" option. Then, unpack e2g3g.zip into a subdirectory using a program like WinZip. In some versions of Windows, you can unpack the files by right-clicking the e2g3g.zip file name, then clicking on the "extract all files" option. You may also download the files individually by right-clicking the name of the file you want in the list below, then clicking the "save link" option and specifying the subdirectory into which the file should be saved. When you examine your target subdirectory, you will find e2gRuleEngine.jar and e2gRuleWriter.jar included with the .htm, .kb and .kbt files. Do NOT unpack these archives: they are intended to be used as .jar files, and none of the test files will work if they are unpacked. Here are the files that should be extracted into your subdirectory:

To use e2gRuleWriter (or e2gRuleEngine) you must have a recent version (1.6.x is current as this is written) of the Java Runtime Engine (JRE) installed and properly configured on your computer. Installing Java to work with a Web browser will normally accomplish the proper installation and configuration including setting the CLASSPATH variable.

e2gRuleWriter is a Java application, not an Applet. This means it does not run within a Web browser. To start the software, you should navigate to the subdirectory that contains e2gRuleWriter.jar. Then, using a command line entry such as the Windows "Run" command or the MSDOS window, type:

To provide a quick tour of the major features of the software, we will use e2gRuleWriter to redevelop the very simple "weather" knowledge base introduced in an earlier eXpertise2Go mini-course module. This presentation assumes the reader is familiar with the operation of e2gRuleEngine and the format of an e2gRuleEngine knowledge base.

Start up the software (java -jar e2gRuleWriter.jar) and you should see the following screen that represents the condition mode:

e2gRuleWriter navigation: Input screens representing three modes (condition, action and rule) are color coded: yellow for condition, green for action and blue for rule. e2gRuleWriter starts operation in condition mode. Clicking the left mouse button on an action row (green row) changes to action mode. Clicking on a rule number at the top of the table, or the gray row under the rule numbers (where rule names will appear) moves to rule mode. When you are in rule mode, clicking on a row in the left-most column (under the Condition or Action headers) moves back to condition or action mode.

The program always initializes with an empty decision table containing 5 conditions, 3 actions and 5 rules. Conditions, actions and rules may be added or deleted throughout the development process.

The currently selected row in condition or action mode is highlighted in blue. The currently selected rule column in rule mode is also highlighted in blue. A row or column is selected by clicking anywhere in the row or column. It is possible to drag-and-drop rule columns to rearrange them: click on a rule number and drag the column to the desired position while holding down the mouse button. Rules are output to the knowledge base in left-to-right order of the columns in the decision table.

To change the displayed width of a rule column, click on the bar between rule number headers and, while holding down the left mouse button, drag the bar left or right to decrease or increase the column's width.

Tooltips or "hints" are available for many of the data input fields. If the mouse pointer hovers above a control or data entry field, and a tooltip is available, it will be displayed in the vicinity of the mouse pointer location. To disable tooltips, uncheck the "Tooltips enabled?" checkbox.

The "weather" example problem: To help clarify the e2gRuleWriter development process, let's first examine the demonstration e2gRuleEngine knowledge base we will derive with our decision table example:

REM Test Knowledge Base (weather.kb) RULE [Is it going to rain?] If [precipitation] = "expected" and [the expected temperature] > 32 Then [the recommendation] = "wear a raincoat" RULE [Is it going to snow?] If [precipitation] = "expected" and [the expected temperature] < 33 Then [the recommendation] = "wear your boots" @ 95 PROMPT [precipitation] MultChoice CF "According to the weather forecast, precipitation is:" "expected" "not expected" PROMPT [the expected temperature] Numeric CF "The expected daytime temperature (degrees Fahrenheit) is:" "-30" "120" DEFAULT [the recommendation] = "wear whatever you want" @ 90 GOAL [the recommendation]

The elements of this example, in the terminology of a decision table are:

Conditions and possible condition values:

• precipitation
  • expected
  • not expected
• the expected temperature
  • number between -30 and 120

Actions and possible action values:

• the recommendation
  • wear a raincoat
  • wear your boots
  • wear whatever you want (default value if the recommendation cannot be determined)

Information requested from the user (prompts) and attributes of the prompts

• precipitation
  • multiple choice input
  • allow input of certainty factor (CF)
• the expected temperature
  • numeric input
  • acceptable range of input: -30 to 120
  • allow input of certainty factor

The steps required to define the "precipitation" condition include:

1. With the first condition row selected, click in the text entry field labeled EDITING
2. Type the value precipitation
3. Press the ENTER key: you should see precipitation displayed as the first condition label in the decision table
4. Click in the text entry field labeled NEW LIST VALUE
5. Type the value expected and press the ENTER key: you should see expected displayed in the list box to the left of NEW LIST VALUE
6. Repeat, typing not expected in the text entry field labeled NEW LIST VALUE then pressing the ENTER key
7. Select MultChoice as the prompt type by clicking the radio button beside this value
8. Type the prompt stem: According to the weather forecast, precipitation is: in the text entry field labeled Prompt:, press ENTER

Once you have saved the file, you can re-save by double clicking the file name in this dialog box. The dialog for loading a decision table (requested with the Load decision table button) is similar in appearance. When a decision table is loaded from a .kbt file, the file name is displayed in parentheses at the end of the frame header.

The decision table is saved in a format meaningful only to e2gRuleWriter. Attempting to modify this file in any way will likely render it ususable.

Similar steps are used to define the expected temperature as shown in the next screen image. Because this is a numeric quantity (determined by the selection of the Numeric prompt type) you may enter minimum and maximum acceptable values beside the Range, ENTER: label. The e2gRuleEngine inference engine will not accept a numeric input from the prompt unless it is in this range.

Also note the use of inequality operators in the list values: < 32 and > 33. When the relational operator in rules generated for e2gRuleEngine is the = for equality, the operator is not explicitly entered with the list values. When any other relational operator is employed, it is entered with the list value.

Defining actions: Inputs that are accepted when defining conditions but not used by actions are disabled or "grayed" on the action mode screen:

The steps used to define "the recommended action" action as shown above include:

1. With the first action row selected, click in the text entry field labeled EDITING
2. Type the value the recommendation
3. Press the ENTER key: you should see the recommendation displayed as the first action label in the decision table
4. This condition will be the goal for the expert system consultation, so click the checkbox labeled Goal?
5. Click in the text entry field labeled NEW LIST VALUE
6. Type the value wear a raincoat and press the ENTER key: you should see wear a raincoat displayed in the list box to the left of NEW LIST VALUE
7. Repeat, typing wear your boots in the text entry field labeled NEW LIST VALUE then pressing the ENTER key
8. Prompts are entered with conditions, not with actions. If it is necessary to set the data type to "True/False" or "Numeric" rather than the default "Text" for an action, this can be done with the radio buttons at the right side of the EDITING row of controls -- not necessary for this action
9. To specify a DEFAULT value for the recommendation provided as the result if e2gRuleEngine cannot determine a result from prompts or rules, type wear whatever you want in the text entry field labeled DEFAULT VALUE, then press the ENTER key: you should see wear whatever you want displayed in the DEFAULT field (the text field that has a gray background)
10. To assert this DEFAULT value with a Certainty Factor (CF) of 90%, choose 90 from the combo box at the left of the Set CF for DEFAULT button, then click the button and @ 90 will be displayed at the end of the DEFAULT value
11. The DEFAULT CF value may be changed by selecting a new value in the combo box and clicking the set CF for DEFAULT button: if the selected CF is the default 100%, no value is displayed beside the DEFAULT.

The steps used to build the rules shown above are:

1. Click on any rule number to navigate to e2gRuleWriter's rule mode
2. Click on the Rule 1 heading to select that rule for editing
3. Type the rule name Is it going to rain? in the text entry field named EDITING, then press the ENTER key: the rule name should appear below the rule number in the decision table
4. Double click in the precipitation row of Rule1 to open a combo box containing all possible values of precipitation
5. Click the desired value: expected in this case
6. Double click in the temperature and the recommendation rows and select the values > 32 and wear a raincoat
7. Build Rule 2 in a similar fashion using Is it going to snow? as the rule title and selecting the precipitation, temperature and the recommendation values shown in the screen above
8. To set the Confidence Factor (CF) of 95% for the recommendation in Rule 2, select the recommendation in the decision table, select 95 in the combo box to the left of the button labeled Set CF for selected action, then click the button: the @ 95 value will be added to the action in the decision table
9. The CF for an action may be changed at any time by selecting the action, selecting a new value from the CF combo box then clicking the button: if the selected value is 100%, the CF value will be blanked in the action (@100 is assumed for all actions by default)

After reviewing the knowledge base, you may generate the same text as an e2gRuleEngine .kb file by clicking the Save knowledge base button. A file dialog will open to allow selection of a knowledge base file name. This name must have a .kb file extension.

To test the weather.kb knowledge base, you will need a Web page with appropriate Applet tags. Here is a sample:

If this .htm file is in the same subdirectory as the weather.kb file generated by e2gRuleWriter and the e2gRuleEngine.jar file, loading it into a Web browser will run the weather expert system demonstration. When developing a knowledge base with e2gRuleWriter, an efficient procedure is to create a test .htm file for the application and store it in a working subdirectory along with e2gRuleWriter.jar and e2gRuleEngine.jar. Generating the .kb file in this subdirectory lets you quickly move between developing and testing your expert system application.

Rule generation and rule simplification: e2gRuleWriter supports automated creation of all possible condition stubs for a user-selected set of conditions. To illustrate this capability with the weather example, hold down the ctrl key while clicking the precipitation and the expected temperature entries in the Automatic rule generation list box to select both entries. Then, click the Generate rules for selected conditions button. There are two condition values for each of the selected conditions, so four rules are possible including the two already defined. The following screen shows the result of automated rule generation:

Rule names and actions could be added to the two new rules to extend the weather example.

Rule generation must be used with caution: the number of rules generated is the product of the number of values of each of the selected conditions, and it is possible to generate a very large number of rules with this capability. e2gRuleEngine will display a dialog box showing the number of rules that will be generated and provide an option to continue or cancel rule generation. If more than 500 rules would be generated, an error dialog is generated: clicking the "Cancel" key cancels the proposed rule generation process. When developing a knowledge base it is easy to ignore combinations of condition values that could represent important rules, and this function helps assure that all the possibilities are considered.

• Condition/action row controls:
  1. Add a condition button: Adds a new condition row to the decision table. If a condition row is currently selected, the row is added before the selected row. If a condition row is not selected (because an action row or one of the title rows is selected) the new row is added after the last condition row. A vertical scroll bar is added to the decision table when the height of the table exceeds the display area.
  2. Add an action button: Adds a new action row to the decision table. If an action row is currently selected, the row is added before the selected row. If an action row is not selected, the new row is added after the last action row.
  3. Move selected row up button: When e2gRuleWriter generates a knowledge base for e2gRuleEngine, rule conditions (the rule premise) and rule actions (the rule consequent) are output in the order they appear in the decision table (top to bottom). To change this order, condition or action rows may be repositioned by selecting the row, then clicking the Move selected row up button. Each click of the button moves the selected condition or action up one row in the decision table. When the row is at the top of its section of the table (condition or action) clicking the button moves the row to the bottom of its section. The e2gRuleEngine goal seeking process begins with the last goal in the GOAL statements in the knowledge base, then works backward through the goals. GOAL statements are output to the knowledge base in Condition statement order (top to bottom) so rearranging action rows that have the Goal? check box enabled allows control over this aspect of the inferencing process.
  4. Delete selected condition/action button: Clicking this button deletes the currently selected condition or action. If any values of the condition/action have been selected in rules, the following option is provided before the delete takes place:
     
     Clicking OK in response to the warning deletes the row, cancel ignores the deletion request.
  5. Tooltips enabled? check box: When this box is selected, a tooltip or hint will be displayed when the mouse pointer hovers near a control for which a tooltip is available. Checking or clearing the tooltip check box in condition/action mode also checks or clears the box for rule mode.
• Editing row controls:
  1. EDITING text field: Typing a name in this field, then pressing the Enter key, assigns this name to the currently selected condition or action row. Text may also be copied from another document and pasted into this field: use Ctrl-V to accomplish the paste action, then press Enter. The field is disabled if no condition or action is selected. Once a condition or action has a name assigned, the name cannot be changed to blanks: the row must be deleted with the Delete selected condition/action button if it is no longer needed. Only one condition and one action may have the same name: a row name is ignored, and the EDITING text field cleared, if the name already exists as a row in the same stub (condition or action) of the decision table.
  2. MAXVALS combo box: By default e2gRuleEngine allows only one value to be determined for a condition or action. Selecting a larger value from the combo box generates a MAXVALS statement for this condition or action when the knowledge base is produced.
  3. Text t/f Num radio buttons: The e2gRuleEngine inference engine deals with values as text, boolean (yes/no or t/f for true/false) and numeric. If a prompt is provided in the knowledge base for a condition, the prompt type determines the data type. If no prompt is defined, or the value is for an action that is not also a condition (prompts aren't allowed for actions), clicking one of these buttons determines the data type. If a prompt is defined later, this setting will be overridden.
  4. Goal? check box: If checked, a GOAL statement will be generated for the action in the e2gRuleEngine knowledge base. A condition that is not also an action may not be defined as a goal, so the check box is only enabled when an action row is selected in the decision table.
• Condition/action list value controls:
  1. Value list box: This list box contains all of the possible values that may be assigned to the currently selected condition or action. These values are made available for selection in a combo box when rules are constructed in rule mode.
  2. NEW LIST VALUE text field: Typing a value in this field, then pressing the Enter key, adds the value to the end of the value list box. Use Ctrl-V to paste a text string copied from another document. When the Enter key is pressed, the field is cleared and is ready for the entry of the next value. List value considerations include:
     • If the data type is boolean (yes/no or true/false) the only legitimate value list values are true and false. When a true/false prompt type is specified for a condition, these values are automatically generated in the value list.
     • In most cases, list values are simply entered as text. When this is done, e2gRuleWriter assumes the value will be used in a rule premise or consequent with an equality " = " relational operator, and will enclose the value in double quotation mark delimiters when it is output in a rule.
     • If the data type is text, and a non-equality relational operator is desired for a condition, the text value must be enclosed in delimiters following the relational operator. For example: ! "Monday" to indicate that the condition value is not equal to Monday. The allowable relational operators are: < for strictly less than, <= for less than or equal to, > for strictly greater than, >= for greater than or equal to, ! <> or != for not equal to, : for one of the values of and !: for none of the values of. The allowable delimiters, which must be used in pairs are: " ", ' ' and [ ]. Three pairs of delimiters are provided to accommodate embedded delimiters in text values.
     • If the data type is text, and an equality relational operator is desired for a value that includes embedded delimiters, the " = " relational operator can be explicitly included and alternate delimiters placed around the list value. For example the list value: the title is "Introduction to Expert Systems" could be specified as a list value with an equality relational operator as follows: = [the title is "Introduction to Expert Systems"]
     • If the relational operator for a text value is the " : " (one of the values of) operator or " !: " (none of the values of) operator, multiple comparison values may be provided in one value list entry, with each value enclosed in delimiters. For example: : "Monday" "Tuesday" "Friday" is interpreted as allowing the condition to have a value of Monday, Tuesday or Friday, and the rule generated for e2gRuleEngine will be of the form: condition-name : "Monday" "Tuesday" "Friday" and is interpreted as: one of the values of condition-name is Monday, Tuesday or Friday.
     • If the value is for a numeric data type condition or action with an intended equality " = " relational operator in the rules, e2gRuleWriter will output the value without delimiters when it is output in a rule.
     • If the value is for a numeric data type condition intended to use a relational operator other than equality when output in a rule, type the relational operator before the value. For example: < 50 for "strictly less than 50." The allowable relational operators for a numeric comparison are: < for strictly less than, <= for less than or equal to, > for strictly greater than, >= for greater than or equal to, = for equal to and ! <> or != for not equal to.
     • If the value is for a numeric data type condition, and a range of values is to be tested, represent the range as in the following example: >25 ^ <50 which means "greater than 25 and less than 50." The separator character is the caret found on the keyboard as the shifted " 6 " key. When the e2gRuleEngine knowledge base is generated, this list value will produce two and'd clauses in the rule premise: condition > 25 and condition < 50. This construct is only available for use with numeric data types.
     • Relational operators other than " = " make no sense in actions because they cannot be used in e2gRuleEngine rule consequents.
  3. Delete selected value from list button: When an entry is selected in the value list box by clicking on the entry, this button is enabled. Clicking the button deletes the value from the list.
  4. Edit selected list value button: When an entry is selected in the value list box by clicking on the entry, this button is enabled. Clicking the button loads the value into the New list value text field for editing. Once the value has been modified as desired, pressing the Enter key replaces the edited value in the value list. If the old value has already been assigned to conditions or actions in rules (as discussed in the rule mode details, below), those entries will be updated with the edited value.
  5. Move selected value up button: When an entry is selected in the value list box by clicking on the entry, this button is enabled. New list values are always added to the end of the value list. To move any value to a new location in the list, select the value and click the button. Each click moves the item up one position. When it reaches the top of the list, another click moves the item to the end of the list.
• Default value controls:
  1. DEFAULT VALUE text field: Typing a value, then pressing the Enter key sets the value as the optional default value for the selected condition or action and e2gRuleWriter will generate a DEFAULT statement for the condition or action in the e2gRuleEngine knowledge base. e2gRuleEngine assigns the default value to the condition or action if it is unsuccessful in determining a value from a prompt or rule. Use Ctrl-V to paste a text value copied from another document.
  2. Set selected value as DEFAULT button: When an entry is selected in the value list box by clicking on the entry, this button is enabled. Clicking the button sets the selected value as the optional default value for the selected condition or action.
  3. CF Value and Set CF for DEFAULT combo box and button: Selecting a Certainty Factor (CF) value from the combo box and clicking the button assigns the CF to the current DEFAULT value and will appear after the "@" symbol. If a CF less than 100 is selected before defining a DEFAULT value, the CF will be immediately assigned. A CF of 100 is implied for the DEFAULT and is never displayed with the default value.
  4. Clear current DEFAULT value button: The current default value of this condition or action (shown in the text field with a gray background) is removed.
• Condition prompt controls (optional prompts define how data will be requested from the user of an e2gRuleEngine knowledge base, and may be specified only for conditions):
  1. Prompt type radio buttons:
     • YesNo: Selecting this prompt type inserts true and false in the value list box and defines the data type for the condition or action as boolean (t/f). An opt-out in the form of an "I don't know/would rather not answer" is included with the Yes/No radio button choices when the prompt is generated by e2gRuleEngine.
     • MultChoice: This prompt type will create a multiple choice input in e2gRuleEngine, with each entry in the value list box associated with a radio button. Includes the "I don't know..." opt-out choice.
     • ForcedChoice: The forced choice in e2gRuleEngine is identical to the multiple choice input except that the "I don't know/would rather not answer" option is omitted, so the user must select among the available choices.
     • Choice: Similar to the MultChoice input with the alternatives presented in a drop down combo box instead of with radio buttons. Includes the "I don't know.." option.
     • AllChoice: Similar to the MultChoice option with check boxes instead of radio buttons so that multiple selections can be made. This form of prompt only makes sense for conditions that have a MAXVALS setting greater than one.
     • Numeric: This prompt accepts a numeric input with optional sign and decimal point.
  2. Numeric RANGE text fields: The acceptable range of a numeric prompt input may be specified by entering numeric values in the text fields labeled RANGE, Enter. e2gRuleEngine will only accept input values from the prompt that are within the inclusive limits of these values. The RANGE fields are disabled for prompt types other than numeric.
  3. Prompt text field: This field represents the question that will presented to the user of an e2gRuleEngine expert system as part of the prompt. Alternatively, a text value may be pasted that was copied from another document using Ctrl-V. Press the Enter key after typing or pasting a value.
  4. Allow CF Input check box: When this box is checked, a set of radio buttons will be generated as part of the prompt allowing the e2gRuleEngine user to specify the Certainty Factor (CF) associated with their response.
• Decision table load/save controls:
  1. Start new decision table button: Restores e2gRuleEngine to its startup configuration, clearing any decision table inputs. An option to save the current table is provided if it may have been changed since the last save:
     

  2. Load decision table button: Generates a file selection dialog box that allows loading of a file with the decision table (.kbt) extension. A save option may be displayed before a new table is loaded.
  3. Save decision table button: Generates a file selection dialog box that allows saving of the current table as a file with the .kbt extension. The generated dialog will not allow the table to be stored with any other extension. The decision table is saved as it is configured at the time of the save: when reloaded, the columns will retain their position and widths and the rules will be renumbered from left to right. Decision tables are always saved as Unicode (UTF-16) files and must not be edited outside of e2gRuleWriter.
  4. Save decision table (CSV) button: Saves the current decision table in Comma Separated Values (CSV) format with the .csv file extension. This format allows the table to be imported to a spreadsheet so that it may be formatted and printed for documentation purposes. Values from the decision table are output one row at a time, with each value enclosed in double quotes and with the values separated by commas. If a double quote character is embedded in a value, it is replaced with two double quotes. The file will be saved as a Unicode (UTF-16) file if the Unicode option is checked on the rule mode dialog screen.

Condition and action values are assigned to rules by double clicking a cell entry in the decision table, then clicking the desired value in the drop down combo box that opens at the cell. The combo box will contain the values that were entered in the value list for a condition or action while working in condition/action mode.

• Rule column controls:
  1. Add a rule: A new rule column is created and added at the right end of the data table and is selected as the current rule. The rule number will be one greater than the largest rule number used so far in working with the current decision table.
  2. Insert a rule: A new rule column is created, inserted on the left side of the currently selected rule and becomes the current selection. The rule number will be one greater than the largest rule number used so far in working with the current decision table.
  3. Delete selected rule: The currently selected rule is deleted and the rule on its right becomes the selected rule. If the rightmost rule in the decision table is deleted, the rightmost remaining rule is selected. One rule always remains in the decision table: if the last remaining rule is deleted, its contents are cleared and the rule column remains in the table. Rule numbers are not reused during a session working with the same table.
  4. Duplicate selected rule: The currently selected rule and all of its contents are replicated at the left of the currently selected rule, then the new rule is selected. A decision table may require several rules that differ in only a few values. Duplicating the rule, then updating these values, can speed the data entry process.
  5. Tooltips enabled? check box: When this box is selected, a tooltip or hint will be displayed when the mouse pointer hovers near a control for which a tooltip is available. Checking or clearing the tooltip check box in rule mode also checks or clears the box for condition/action mode.
  6. AutoExpand? check box: When this box is selected, the active rule is expanded to the maximum width of the rule title or the longest option value in the currently selected condition/action combo box. When another rule is selected, or condition/action mode is selected, the column is returned to its default width. When the AutoExpand check box is deselected, all columns are returned to the e2gRuleWriter default width. When this option is not selected, rule widths are adjusted by dragging the vertical bar between rule numbers and rules retain their adjusted widths.
• Editing rule controls:
  1. EDITING text field: Typing a name in this field, then pressing the Enter key, assigns this name to the currently selected rule column. The name will be displayed below the rule number in the selected column. Ctrl-V may be used to paste a text value copied from another document.
  2. CF Value and Set CF for selected action combo box and button: By default, actions are assigned a Certainty Factor of 100%. To have the generated e2gRuleEngine rule assign a different CF to an action, click the action to select it, choose the desired CF from the combo box then click the Set CF for selected action button. The CF will appear in the rule action in the format: @ 90 and may be changed at any time. Once again 100% CFs are implied, and are not displayed in the " @ " format.
• Automatic condition stub generation:
  1. Condition name list box: When the rule mode is selected, this list box contains the names of all of the condition rows for which at least one condition value was defined in condition/action mode. If a condition name does not appear in the list, it does not have any defined values. As the first step in automatic rule generation click each of the condition names to be included in the process while holding down the Ctrl key. All of the selected condition names will be highlighted.
  2. Generate rules for selected conditions button: Automatic rule generation produces rules with condition stubs defined by every combination of the values of the selected conditions. The new rules generated by this process are displayed in the decision table beginning at the currently selected rule column. The rule names and action stubs will be blank in the generated rules. If a rule already exists for one of the condition stub combinations it will be moved into the rule sequence, not generated. The number of rules produced by automatic rule generation is the product of the number of condition values for each of the selected conditions. If there are three selected conditions, and each condition has five values, 125 rules will be generated! Before rule generation begins, the following dialog provides an option to cancel the operation:
     
     If more than 500 rules would be generated, an error dialog is presented, and clicking Cancel terminates the process. If rules are generated that are not considered necessary in the final decision table, they may be automatically removed with the "incomplete rules" option in the decision table simplification process since they have no defined actions.
• Decision table load/save controls: These buttons and their functions are identical with those defined for the condition/action mode.