WO2003090165A1

WO2003090165A1 - Expert system with modified decision table

Info

Publication number: WO2003090165A1
Application number: PCT/GB2003/001635
Authority: WO
Inventors: Basil Rickard
Original assignee: Basil Rickard
Priority date: 2002-04-15
Filing date: 2003-04-15
Publication date: 2003-10-30
Also published as: GB0208613D0; AU2003226546A1

Abstract

This invention relates to a selection control structure for selecting an outcome in response to the status of a plurality of inputs, the selection control structure comprises plural sets of possible input entries each holding a respective possible input value each said set defining a unique combination of possible input values associated with that set, for each of said plural sets of possible input entries an outcome entry associated therewith, and holding a respective outcome value a one of said outcome entries being selected when the status of the inputs tallies with the possible input values in the set of input entries associated with said one outcome entry; whereby each said set of possible input entries is also associated with a unique index value which is determined in response to the possible input values stored for that set.

Description

EXPERT SYSTEM WITH MODIFIED DECISION TABLE

The present invention relates to a selection control structure for selecting an outcome. In particular, but not exclusively, the invention relates to a selection control structure which can be proposed, validated, updated and applied at run time.

There are four basic structures in computer software. Systems can be built by combining these into larger structures. The four basic structures are selection, iteration, sequence and recursion. Selection means rules, e.g. "If this condition and that condition, then do A, otherwise do B" . Each occurrence of such a rule creates two possible paths. Much of the routine drudgery of building all of these structures has been greatly reduced, but not removed, by developments such as relational databases, object oriented programming and visual programming languages. The structure least improved by any of these techniques until now has been selection.

There are two main techniques for building selection (rules) in computer software. One is to code them in a computer language (COBOL, BASIC etc), e.g. IF ACCOUN - BALANCE<0 THEN PERFORM OVERDRAWN- PROCEDURE, ELSE PERFORM IN- CREDIT-PROCEDURE. The second is to use a rule based expert system. Other techniques, such as decision table preprocessors, are little used.

The problem with coding is that a computer language permits anything to be coded, anywhere, regardless of what sense it makes, so long as it obeys the syntax rules for language. Thus any programming error can arise anywhere and human programmers are prone to error. Such errors, once made, may be very hard to find, since computer applications may be very complex, and in the case of commercial applications, enormous .

The number of possible paths through the program code will be 2n, where n is the number of possible true/false conditions. In many examples this can give to 2²⁵° to 2^1,000 possible paths. Even best practice cannot guard against a human programming error which effects just one of these paths. For all practical cases, the discovery of errors through testing so many paths is mathematically impossible. Current techniques consist of identifying just the most important paths for exhaustive testing, and inspection methods, all of which involve looking at the code to see if it is well structured (so clearer and less likely to conceal underlying errors) and free of apparent error.

Even assuming an originally 100% error free-application, an error in a one line change to an application could, theoretically, alter the outcome at some other point in any one of a potentially huge number of paths. Thus any change should, strictly speaking, result in a complete re-test of the entire system. Since testing costs, using the current techniques described in the previous paragraph, may easily be 40% of the entire development costs of a new system, this is financially unacceptable.

In systems such as avionics fly-by-wire, and other safety critical applications, the problems are even greater, since in addition to all the above, the application must respond to events happening (interrupts) , often in parallel and in unpredictable numbers and combinations, in the real world (hence the term "real time" systems) .

Rule Based Expert Systems exist largely to implement selection (rules) . The main techniques for holding rules is to use linked lists (otherwise known as "chaining"). Essentially the rules are held as data in a small database, instead of being coded and compiled as a program. Changes to rules can be made more rapidly, and the validity of proposed new rules can be checked to a greater extent than in program code .

Although far more flexible and easier to build and test than program code, beyond a modest size rule based expert systems prove to exhibit the same basic problems in testing all possible paths, degradation of structure and difficulty in making changes without having to re-test the entire system.

It is an aim of embodiments of the present invention to at least partly mitigate these above-referenced problems.

According to a first aspect of the present invention there is provided a selection control structure for selecting an outcome in response to the status of a plurality of inputs, the selection control structure comprises: plural sets of possible input entries each holding a respective possible input value each said set defining a unique combination of possible input values associated with that set ; for each of said plural sets of possible input entries an outcome entry associated therewith, and holding a respective outcome value a one of said outcome entries being selected when the status of the inputs tallies with the possible input values in the set of input entries associated with said one outcome entry; whereby each said set of possible input entries is also associated with a unique index value which is determined in response to the possible input values stored for that set.

According to a second aspect of the present invention there is provided a method for selecting an outcome comprising the steps of : in response to receiving input values indicating the status of each of a plurality of respective inputs, determining a unique index value and via said unique index value identifying one of a plurality of sets of possible input entries which tally with said input values; and outputting the content of an outcome entry associated with said identified one of said plurality of sets.

According to a third aspect of the present invention there is provided a system for real-time decision support comprising: an assessment system arranged to receive input data comprising a users answers to a plurality of questions; and an outcome generating system responsive to receiving the user answers as a plurality of inputs and for selecting an outcome in response thereto; wherein the outcome generating system further comprises: at least one selection control structure which contains a plurality of predetermined outcomes which are each indexed via a unique index value determined in response to said plurality of inputs. According to a fourth aspect of the present invention there is provided a method for creating a selection control structure comprising the steps of: providing a skeleton selection control structure; adding a set of possible input values along with an outcome value for that set to said structure and allocating that set with a unique index value which is determined in response to the possible input entries stored therein; adding subsequent sets of possible input values and respective outcome value to said selection control structure and allocating each new set with a unique index value; checking that no two sets of possible input values which have unidentical outcome values associated therewith are allocated the same index values.

According to a fifth aspect of the present invention there is provided a method for creating a selection control structure comprising the steps of: providing a skeleton selection control structure; adding a set of possible input values along with an outcome value for that set to said structure and allocating that set with a unique index value which is determined in response to the possible input entries stored therein; implying at least a portion of a further set of possible input values and allocating that further set with a unique index value ; adding a subsequent set of possible input values and respective outcome value to said selection control structure; checking that the values added to said selection control structure are consistent with the at least a portion of a further set ; and responsive to entries in said selection control structure not being consistent, indicating an error has occurred. Embodiments of the present invention provide the advantage that users and programmers do not need to understand or in fact see any trace of complexities required to provide these selection structures. The selection control structures can, for example, be built, validated, tested and run using purpose built middleware. This middleware is recursive and implements mathematical techniques in a modified decision table format. Rules can be proposed, validated, updated and applied at run times.

Embodiments of the present invention provide the advantage that testing of the rules for internal logical consistency, case coverage and identifying uncovered cases is an on-going process which can be carried out in real time between each key stroke during rule proposal. In this way the present invention removes from a programmer all possible discretion as to selection control structure design, selection control structure building and testing for all cases except for a single case needed to test each rule .

Embodiments of the present invention can provide the guarantee that all possible cases covered by a rule will produce an identical result to any one case which has been selected for testing the rule.

Embodiments of the present invention will now be described hereinafter by way of example only with reference to the accompanying drawings in which: Figure 1 illustrates a bounded fan out.

Figure 2 which includes portions 2A and 2B illustrates how selection control structures can be built. Figure 3 illustrates a Jackson structured diagram for proposing a rule.

Figure 4 illustrates a Jackson structured diagram for checking perpetual consistency.

Figure 5 illustrates how implied part rules are updated. Figure 6 illustrates a process for asking questions.

In the description like reference numerals refer to like parts.

Table 1 shows a decision table according to an embodiment of the present invention.

TABLE 1

This can be used to illustrate how an outcome to a particular question can be provided on a case by case basis. By way of example only the questions asked refer to a tax advisory service. It will be understood that embodiments of the present invention could be used with any form of expert system in which a user is asked questions to which a yes/no/don't care answer can be given and an outcome is provided .

Other embodiments of the invention can be used in any situation where users are taken through a question and answer situation using an automated system for example in a menu based telephone system. These need not be expert systems.

The table can be used to indicate whether a claimant is entitled to additional personal tax allowance. This question is Qn79 in the knowledge base of the system. The term knowledge base is meant to indicate a stored knowledge possibly in data base form in which an expert's knowledge on a particular subject is kept in a manner so that that knowledge is accessible. In the example a tax specialist has been used to provide an indicator of which questions are relevant to the question Qn79 and what answers to those questions will determine that the additional personal allowance can be claimed .

It will be understood that the Qn numbers referred to hereinafter have no specific order but merely are meant to illustrate that the knowledge base can include a large number of questions each of which is allocated a unique question number .

The first question which is relevant to Qn79 is question 10(Qnl0) which is "Is the claimant married". The questions upon which Qn79 depends are listed in the first column of Table 1 under Qn. Answers that a claimant, or user, can give are shown as rules in the right hand side column of Table 1. This column illustrates 6 rules with each rule being a combination of yes-no-don' t care states. Each rule starts with a yes or no. The first condition for Qn79 provided by the answer to the first question 10, cannot be a don't care.

Question 10 can be answered by a user simply without the need to refer to a further decision table. However it is sometimes the situation that some questions refer themselves to other decision tables for an answer. Table 1 illustrates this with question 184 Qnl84 which is "Has claimant a qualifying child?" . For the answer to this question the system must refer to a further normalised decision table 23. This table itself includes a set of questions and answers. Each decision table may include a number of spare entries which are provided to enable the table to be subsequently updated if the rules for determining an outcome change.

Referring to the first rule of table 1 we can see that if the answer to the first question (QnlO) is yes and the answer to the second question (Qn67) is yes then the answer to Qn79 is no. This would then be selected as the outcome. The question does not depend upon the status of the answers to Qn76 or Qnl84 because the first rule says that if the answer to QnlO and Qn67 is a yes the outcome is a N, representing a negative response, regardless of the remaining answers. For a case in which the answer to QnlO and Qn67 is Y, N respectively the rule to apply is not yet determinable . This is because any of the second, third or fourth rules could apply. The answers to Qn76 is therefore required. If this is an N then the fourth rule will apply and the outcome will be an N. In this way QnlO, Qn67 and Qn76 represent simple questions. These are questions which can be answered by database lookup, reading sensors, keyboard input or in fact any source other than a rule. Question 184 on the other hand represents a complex question which has an answer dependent upon other questions. Questions 10, 67, 76 and 184 are all conditions of the decision table which are used to form rules. The six columns on the far right of the table show the condition values which make up the six rules. In table 1 the six rules are:

TABLE 2.

These represent fully validated rules which can determine the answers to complex questions. They can also determine which actions should be carried out. Thus in any case or instance in which the answers to questions 10, 67, 76 and 184 are Y, N, Y, N respectively the answer or outcome (given by the third rule) is N. This is a goal in the sense that the system is attempting to find the answer. A main goal is a complex question which is not used as a condition. A sub goal is a complex question which is also used as a condition. For example question 184 is a sub goal since, whilst it is a complex question it is also a condition for question 79. It will also be understood that questions may be recursive since the answer to a question may have to be answered by reference to another question and so on.

The decision table shown in table 1 is thus divided into several portions. These are the title portion which provides a brief summary of the purpose of the decision table, a condition stub which holds the conditions upon which the answer is dependent, an action stub which holds the outcome which has to be described, so for table 1 the action stub is "Is the claimant entitled to additional personal allowance" and a rule store portion for that decision table.

A decision table (DT) is divided like this for efficiency. All the details of the questions may be held in a separate table. Thus several decision tables may use the same question. Each stores just the number of that question. In this way the question detail need be recorded only once. It will be understood that in embodiments of the present invention copies of each question could be held in each table.

Table 3 illustrates three further normalised decision tables arranged to provide an outcome for the goals "May claimant claim for house keepers allowance" , "Has claimant a qualifying child" and "Does child's training or education qualify" .

TABLE 3 .

The four DT's so far referred to are thus 10, 11, 23 and

24. These numbers are distinct from the question numbers stored in the far left columns and are used only as a method of reference when one of the questions requires reference to an NDT for its outcome.

The hierarchy of the four goals relevant for tables 1, 2 and 3 are set out below.

79 Is claimant entitled to additional personal allowance?

10 Is claimant married? 67 Is claimant female? 76 Has claimant's wife been 100% incapacitated the whole tax year? 184 Has claimant a qualifying child?

74 Has claimant a child resident for all or part of the whole tax year? 192 Was child born during tax year?

180 Was the child under 16 at the start of the tax year? 191 Does child's training or education qualify?

185 Is child 16 or over at the start of the tax year?

186 Was child receiving full time education during the tax year?

187 Was child being trained for a trade, profession or vocation? 188 Is the training for at least a 2 year period? 196 Does child's relationship to claimant qualify? Further ques tions (per NDT 25) not shown

87 May claimant claim for housekeepers allowance?

11 Is claimant widowed? 83 Has claimant a living in housekeeper?

84 Is housekeeper a relative of claimant or of a deceased partner? 215 Are any other tax allowances claimed for the housekeeper? Further ques tions (per NDT 21) not shown

86 Is housekeeper employed by the claimant?

The hierarchy has no physical existence it is simply a way of representing the path traced through the relevant questions as they are considered. Figure 1 illustrates in part the fan out of the questions . The term fan out refers to the number of conditions upon which a question depends. Figure 1 shows that the fan out of questions 79, 191 and 196 is 4 since they depend upon four conditions for an answer. The fan out questions 87 and 184 each depends on 5 conditions is 5.

Figure 2 including 2A and 2B illustrates how rules for a selection control structure such as those shown in tables 1 and 3 can be determined in accordance with the present invention. These can take the form of a decision table which can be proposed, validated, updated and applied at run time. This is achieved because the present invention permits testing of the rules for interval logical consistency, case coverage and identifying uncovered cases to be an on going process which is carried out in real time between each keystroke during rule proposal . This removes from a developer any discretion as to selection control structure design, building and testing. The resultant structure requires only one case to test each rule. This is selected by the developer. The present invention guarantees that all possible cases covered by a rule will produce an identical result to the one case selected to test the rule.

Figure 2 illustrates a skeleton selection control structure 10. This includes a condition structure 11 having 6 conditions indicating that the outcome to the goal associated with the control structure 10 will be dependent upon up to 6 conditions. These conditions are illustrated as being the answers to the six questions 12, 8, 34, 35, 14 and 7 stored in a knowledge base. It will be understood that the outcome may be dependent upon any number or combination of conditions. The action stub 12 indicates the action to which the decision table is associated.

Each new DT is set up so that sufficient columns are provided to accommodate as many rules as may be required treating the columns as elements on a direct organised and accessed structure such as for example a hash random organised array. The heading for each column 13_a-j is initialised with a rule number zero identifying it as unused. Each column includes an entry for each condition. The entry can be set to hold a value of a yes, no or don't care (-) status. Initially the entries in each column are initialised with a value of ?.

Each condition is allocated a unique weighting value 14ι_-6 which for the first condition has a weighting value 14ι of 32. For the second condition 2 the weighting value 14₂ is 16 and so on until the sixth condition weighting value 14_s is 1. For other numbers of conditions the weighting values should be allocated so that where there are a number i of conditions the i-th condition has weight

w (m-i) 1.1

where m is the number of conditions

Each control structure 10 is created and built up by a developer inputting predetermined rules into the skeleton structure 10. In control structure 15 the determined rule number three has been input .

This includes a yes (Y) for the entry for conditions 1 and 3, a no (N) for the entry corresponding to condition 5. The remainder of the entries for that column have don't care

(-) stored therein. The outcome entry 16 has a Y stored therein which is the outcome associated with the set of possible input values. In this way if the inputs for the conditions tally with the predetermined values stored for rule 3 then the outcome will be a Y. In this sense tally means either matches (for example a Y for a Y or N for an N) or else the predetermined value stored is indicative of a don't care in which case the input can be a Y or N or - .

Each rule is indexed by a unique index value (or rule number) . This is calculated in response to a combination of the weighting value for each condition and the input value stored in the input entry corresponding to the condition. The determined rule number (DRN) for any rule is calculated according to the equation

DRN = 1 + X 2^(m_i) 1.2 Where m is the number of conditions for that decision table and i is the number allocated for that condition and where the sum is over all condition values i such that rule x has an N condition i.

Referring to control structure 15 in figure 2A the first four conditions for the determining rule 17 being input have Y or - values stored in the set of entries for that rule. The fifth condition however has an N value stored in its respective entry. The rule number if thus increased from 1 to 3 by adding the weighting value 14 for that condition (a 2) since the final condition is a don't care the determined rule number 17 is 3 for that rule.

The input of a determined rule allows implied rules to be ^■ created. These are done automatically as determined rules are input. The developer is not required to input information for these part rules. Each proposed rule is allocated a proposed rule number (PRN) until a time when it is confirmed by entry of a corresponding DRN.

As seen in control structure 15 the inclusion of the rule having index number 3 implies three implied rules having index numbers 1, 9 and 33. This is because the input of a Y for condition 1 implies a rule in which the condition 1 status is N. Since an N is implied the weighting value for condition 1, which is 14, is added to 1 in accordance with equation 1.2 to give 32+1 = 33. The new implied rule 33 is entered into the skeleton control structure. Likewise the existence of a Y at condition 3 implies an N in a further rule. This condition has weighting value 8 so rule number 9 is implied. The existence of an N for condition 5 of rule 3 implies the existence of a rule having a Y status for condition 5. For such an implied rule, rather than add the weighting value to the implied rule number (IRN) the weighting value is subtracted to provide an implied rule having an IRN of 1. The control structure 15 illustrates the DRN 3 and all IRN' s associated therewith.

Next a further DRN is added to the control structure. Control structure 18 includes determined rule number 1. This includes the information of the IRN 1 together with a status value "-" for the input entry corresponding to condition 6 and an associated outcome value which is an N in outcome entry 19. Had any conflict with the implied rule 1 and determined rule 1 occurred this would have indicated an error had occurred and the control structure could have been checked by a developer to find the error. In this example the addition of the DRN 1 is a progression of the IRN 1 without any consistency conflict .

The introduction of the data associated with DRN 1 does not allow any further implied rules to be implied. The shaded columns indicate DR's each including their associated set of possible input values (Y, N or -) , their associated outcome entry holding an outcome value and associated DRN.

In the control structure 20 of figure 2A DR 9 has been added indicated by the entries for that rule being shaded. The DR is entered by a developer with each entry being filled one by one. As an entry is filled with a value the consistency of the values are checked as will be described hereinafter. The first three values stored in the entries corresponding to conditions 1, 2 and 3 have already been implied as Y, -, N respectively. Values for the entries for that rule for conditions 4, 5 and 6 and the outcome entry 21 are input as Y, Y, Y and Y respectively. The introduction of these new values enables further rules to be implied.

For instance the Y value for the condition 4 entry implies a rule having values Y, -, N, N. This has an N value for the third and fourth condition entries and thus an index value of 1 + 8 + 4 = 13 (referring again to equation 1.2) . Thus IRN 13 is added to the decision table as column 13_f. Likewise the Y value in the entry for the fifth condition of DRN 9 implies a rule having possible input values Y, -, N, Y, N. Referring to equation 1.2 this implied rule has an indexing rule number of 11. This is stored in column 13_e. Furthermore the Y value in the entry for the sixth condition implies a similar rule but having an N value for that sixth condition. This is allocated rule number 10 as shown in column 13_d-

In a similar manner new predetermined rules can be added to the control structure with implied rules being added and updated as each entry for the predetermined rule is filled. In the decision table 22 of figure 2B DRN 10 is added. In decision table 23 DRN 53 is added. In decision table 24 DRN 13 is added. In decision table 25 DRN 11 is added. In this way as determined and implied part rules are updated they will occupy that column whose address is given by hashing the rule number. The rule number will then head that column and the Y, N, - values will replace the ' ?' values as described below. Synonym handling can be by any usual method. Validation of each newly proposed rule takes place one condition at a time. The proposed rule number (PRN) is recalculated as each condition value is entered, using the DRN method. So in the tables in figures 2A and 2B, a proposed rule starting NY- N... would have PRN 33,33,33,37,39... using the algorithm of equation 1.2. Every rule must start with a Y or N (as with conventional decision tables) so no internal logical inconsistency is possible in the first proposed condition. The PRN is initially set = 1 and has the current condition weight added if the condition value proposed is N. It will be understood that rather than increasing the rule number for an N the invention could operate on Y's instead in which case rule numbers would be decremented.

Then for each subsequent proposed condition:

The proposed condition is validated to make sure it is Y, N, or -. Next the PRN is updated if the proposed value is N (add the current condition weight) .

Find that implied or determined rule number which is the same as the PRN (this will be the "home" rule) . If there is no such rule (the element found by hashing has rule number = 0) then the opposite implied/determined rule is found (to do this, if the current proposed condition is N, subtract its weighting, else add its weighting) . Whichever is used is the "found" rule. In this context hashing will be understood to mean converting a logical number into a physical address for example a column number .

If the found rule shows "?", the proposed condition value may be accepted. If the found rule shows a Y, N or - for the proposed condition, reject the proposed condition unless both the proposed and implied/determined condition is "-" (don't cares) or neither is"-" (a don't care) . Repeat until the found rule shows "?" or proposed conditions have formed a complete set of condition entries .

Accept any remaining proposed conditions for the rule. Add the action sub values (goal only, in first position only, then actions only in subsequent positions only) , then update the rule into that column given by hashing the DRN (DRN = final PRN value) and then update all the implied part rules on the DT . For example of this see the workings for DRN 53 in figure 2B. Finally update all relevant question statuses.

Figure 3 illustrates how rules can be proposed and updated according to embodiments of the present invention. Figure 3 is a Jackson structured diagram showing the process for rules to be proposed s300. A series of tasks are performed the first of these are placed to the left with each subsequent task being placed to the preceding tasks right. The final task is shown on the right of the upper tier. Some tasks are dependent upon sub tasks and these are shown in lower tiers.

Initially the proposed rule number is set to 1 (step s310) . The possible input value for the entry for the first condition is then accepted. This must be a Y or N state. It is not possible for the first state for the first condition in a rule to be a don't care (-) . If the first condition is a Y this is accepted at step s321. If the first condition is an N the weighting value for that condition is added to 1 to give a new PRN at step s322.

The remaining conditions which require logical consistency checks are then processed at step s330. This involves processing each condition at s331 until a found rule (when validating a proposed rule the found rule is whatever rule (or even empty column) is used for the consistency check as described hereinbelow) equals a ? or all conditions for that rule are completed. Each condition is processed until it is established as being valid via step s332. This validation is carried out by checking that only Y, N or - states are accepted (s333) . This is carried out by the steps of checking whether the condition is an N, in which case the condition weight is added to the PRN, or whether the condition value is a Y or - (at step s335) . Subsequently the consistency is checked between the new PRN, and existing entries in the control structure (this is step s336) . If the condition value is a Y or N the consistency check is carried out directly s337. If it is determined at step s338 that the condition value is a - then firstly the consistency check is carried out on that PRN then later on that PRN plus the condition weighting value.

Figure 4 is a Jackson structured diagram illustrating the consistency check process s400. Firstly the relevant rule is found in the control structure (s410) either the element rule found has the rule number = PRN (s411) (this found rule may be either a PR or DR) or if there is no such rule (the element found by hashing has rule number = 0) then the opposite implied/determined rule is found (s412) . To do this (s413) if the current proposed condition is N its weighting value is subtracted s414. Otherwise its weighting is added s415. Whichever is found is the "found" rule. Once the opposite rule is identified at step s413 it is checked at step s415 to see if it is an empty element rule. If this is the case that empty element can be used as the found rule s416.

Next the found rule is processed s420 to see if the found rule is consistent with pre-existing rules and can thus be accepted or rejected. If the found condition value is a ? s421 then the condition can be accepted and the control structure updated accordingly. If the found condition is not a ? then the condition is rejected s423 unless either both proposed and found conditions are equal to a - (s424) or neither proposed nor found conditions are equal to a - (s425) . In both these latter cases the condition can be accepted since the proposed rule is consistent with the found rule and the control structure such as the decision table of figure 2 can be updated.

Perpetual internal logical consistency is maintained otherwise a proposed rule would be able to overwrite an existing rule since the rule numbers would be the same. This would bring about an unintended effect. Embodiments of the present invention prevent this from occurring.

Referring again to figure 3 once the consistency checks s400 have been carried out for conditions which require logical consistency checks the rest of the conditions which require no logical consistency checks are accepted. This involves validation only if conditions have a Y, N or - status at step s341. Entries holding a ?, for example indicating a part rule, will not be accepted. Next the action stub values which indicate the outcome for that rule are added into the control structure s350. This action stub value is then validated at step s351 to check that a Y or N value has been stored. Finally at step s360 the proposed rule is added to the normalised decision table. The question status is updated via step s361 in accordance with table 4. In table 4 the third column refers to the effect on the count of condition stub occurrences .

TABLE 4. 0

In addition the implied part rules which can be implied from the proposed rules addition to the control structure are determined and the decision table updated via step s500. The update of implied parts is illustrated in figure 5. 5 As the first and subsequent rules in an DT are determined, parts of other rules are implied as hereinabove described. The method requires that implied part rules be updated in the table as a means both of navigating incomplete tables and identifying uncovered cases. Such rules are referred to implied part rules (IPR's) . An implied part rule

(IPR) is a combination of any of Y(es), N(o), - (don't care) and ? (don't yet know) values. Examples in the Determined rule numbers (DRN's) of figure 2 are rules 33 and 49. The key is calculated exactly the same way as a DRN key.

The worst case workload for updating implied part rules from a newly determined rule in a DT of m conditions is mn, where n is the number of Y/N condition values in the newly determined rule. This can be seen from the case of rule 53 in figure 2B. This updates implied part rules 33 and 49. If determined rule 1 did not already exist, rule 53 would also update an implied part rule 1 with the condition values "Y?????" . This workload is clearly exponential in the number of conditions, but is therefore bounded in the fan out ratio (as with all other exponential aspects of this method) and in practice the added effort is insignificant.

When updating implied part rules (s500) the process shown in figure 5 is carried out for each condition in the proposed rule s501. This is carried out until each condition has been processed. The implied rule number is set to 1 s502 and then the proposed condition value is checked (s503) if this value is a Y then the weighting value associated with that condition is added to the implied rule number at step s504. If the proposed condition value is an N the weighting value associated with that condition is subtracted from the implied rule number. Once the new implied rule numbers have been established each implied condition is updated at step s506. For this new implied rule the value for the current condition is set opposite to the proposed rule number which has recently been updated. This is step s507. In addition at step s508 any conditions above that being checked are set to have the same value as the proposed condition value. This is illustrated with s509.

Figure 6 illustrates a process for asking questions to a user. This is step s600. For any selection of goals, the algorithm checks or works out the answer to all questions shown to be relevant to that goal and for the case. This is done by applying the rules in the relevant normalised decision tables. To ask and answer all the questions relevant to some subject, and regardless of case, each main goal is asked in turn in whichever sequence is preferred using a recursive algorithm set out below. If only some goals are of interest only these are asked. If sub goals are of interest in isolation they alone may be asked. If the answer is already known that answer is returned otherwise either; if the question is simply the answer for that question it is looked up from its given source; or if the question is a main or sub goal then starting with the first condition in its normalised decision table (i.e. condition 1 rule 1) it is established whether to ask the question (related to that condition number) .

The following is repeated if the rule condition is a ?,- ignore the question, report a missing rule and ask for an assumed answer to the goal, an updated rule or other appropriate action, followed by the option of continuing from this point. If the rule condition value is Y or N this process is repeated recursively to the question. If the condition value is - ignore the question. If the answer to the question is N then the current condition weight is added to the current rule number and 1 is added to the current condition. This is repeated until all conditions stated to be relevant by the current rule have been considered. If the goal value is ? this is reported as a missing rule and an assumed answer is also requested. Also requested is an updated rule or other appropriate action before asking whether to continue from that point. If the goal value is Y or N that answer is returned. After this any further actions for example updating of files can be carried out. It will be noted that only the first action stub entry may be a question. The remainder must be actions.

It will be seen that when using rules once constructed it is necessary to identify which rule number corresponds to a given case for a current goal. One rule may cover many cases. To evaluate the case and find the rule relevant to the case the process shown in figure 6 can be used.

It will be understood that embodiments of the present invention are particularly effective when making repeated changes to rules within advisory applications such as in call centres and e-commerce. Such changes can be made while the system remains in use. The invention ensures that the change only affects the system as explicitly instructed. No unpredictable consequences occur.

One particular class of application to which embodiments of the invention are applicable are commercial classes of applications. This covers all applications that naturally breakdown into sub tasks, suited to being built using Jackson structured design (JSD) and Jackson structured programming (JSP) methodology. In such commercial applications an important aspect of the present invention is in the maintenance and integration with advisory applications. There are several possible approaches to integrating the invention with conventional languages. Other applications are advisory applications. In these, embodiments of the present invention are particularly helpful in maintenance and testing and enable these to be carried out in real-time on the live version while it remains in use. Embodiments of the present invention are also applicable to applications of real-time process controls. In particular in building and testing safety critical or mission critical applications. Embodiments of the present invention can also be applied to parallel applications.

It will also be understood that the term "user answers" is not restricted to answers input by a user or in real time. Rather the answers can come from a user or from a data base, a sensor or from other rules or any other source of condition information.

It will also be understood that further modifications could be made to the above-mentioned examples without departing from the scope of the present invention.

Claims

CLAIMS :

1. A selection control structure for selecting an outcome in response to the status of a plurality of inputs, the selection control structure comprises: plural sets of possible input entries each holding a respective possible input value each said set defining a unique combination of possible input values associated with that set; for each of said plural sets of possible input entries an outcome entry associated therewith, and holding a respective outcome value a one of said outcome entries being selected when the status of the inputs tallies with the possible input values in the set of input entries associated with said one outcome entry; whereby each said set of possible input entries is also associated with a unique index value which is determined in response to the possible input values stored for that set.

2. The selection control structure as claimed in claim 1 further comprising: for each of said plurality of inputs a weighting value associated therewith said index value for each said set being determined in response to a combination of the status and weighting values for each possible input entry in that set.

3. The selection control structure as claimed in claim 2 wherein : the status of each input is dependent upon the answer to a respective question and each input comprises a condition upon which the outcome is dependent.

4. The selection control structure as claimed in claim 3 wherein : the selection control structure has m conditions each of said m conditions being allocated a number i where i = 1,2...m and the ith condition has a weighting value of w = 2 ^(m"l) .

5. The selection control structure as claimed in claim 4 wherein : the index value associated with any of said plural sets is calculated by an equation

index values = 1 + ^ 2 ( -i)

where the sum is over all condition values i.

6. The selection control structure as claimed in any one of claims 1 to 5 wherein said selection control structure comprises a decision table.

7. The selection control structure as claimed in claim 6 wherein: said plurality of inputs comprises the answers to a respective plurality of questions, said status of said inputs indicating a first, second or third status to the answer.

8. The selection control structure as claimed in claim 7 wherein said first, second and third status comprises no, yes and don't care respectively.

9. The selection control structure as claimed in claim 7 or 8 wherein each of said plural sets of possible input entries comprises a rule which is a set of true/false condition values which define an outcome for a particular instance.

10. A method for selecting an outcome comprising the steps of: in response to receiving input values indicating the status of each of a plurality of respective inputs, determining a unique index value and via said unique index value identifying one of a plurality of sets of possible input entries which tally with said input values; and outputting the content of an outcome entry associated with said identified one of said plurality of sets.

11. The method as claimed in claim 10 further comprising the steps of: determining said unique index value in response to a combination of the status of each input value and a weighting value associated with each of said plurality of inputs.

12. A system for real-time decision support comprising: an assessment system arranged to receive input data comprising a users answers to a plurality of questions; and an outcome generating system responsive to receiving the user answers as a plurality of inputs and for selecting an outcome in response thereto; wherein the outcome generating system further comprises: at least one selection control structure which contains a plurality of predetermined outcomes which are each indexed via a unique index value determined in response to said plurality of inputs.

13. The system as claimed in claim 12 wherein said at least one selection control structure comprises a plurality of decision tables each decision table being arranged to provide an outcome to a question being dependent upon a plurality of conditions .

14. The system as claimed in claim 12 or 13 wherein said system is an expert system.

15. The system as claimed in claims 12, 13 or 14 wherein said at least one selection control structure comprises a knowledge base .

16. A method for creating a selection control structure comprising the steps of: providing a skeleton selection control structure ,- adding a set of possible input values along with an outcome value for that set to said structure and allocating that set with a unique index value which is determined in response to the possible input entries stored therein; adding subsequent sets of possible input values and respective outcome value to said selection control structure and allocating each new set with a unique index value; checking that no two sets of possible input values which have unidentical outcome values associated therewith are allocated the same index values.

17. The method as claimed in claim 16 further comprising the steps of, if said checking step identifies a new set of possible input values which equates to a pre-existing set of possible input values but which has dissimilar outcome value associated therewith, updating said control structure by replacing the pre-existing input values and outcome value with the new input values and/or outcome value.

18. A method for creating a selection control structure comprising the steps of: providing a skeleton selection control structure; adding a set of possible input values along with an outcome value for that set to said structure and allocating that set with a unique index value which is determined in response to the possible input entries stored therein; implying at least a portion of a further set of possible input values and allocating that further set with a unique index value; adding a subsequent set of possible input values and respective outcome value to said selection control structure; checking that the values added to said selection control structure are consistent with the at least a portion of a further set; and responsive to entries in said selection control structure not being consistent, indicating an error has occurred.