2011-03-29 London - Decision tables in depth (Michael Anstis)
-
Upload
geoffrey-de-smet -
Category
Technology
-
view
6.066 -
download
0
Transcript of 2011-03-29 London - Decision tables in depth (Michael Anstis)
drools
Michael Anstis
Decision Tables in depth
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Overview
Tabular representation of decisions.
Compact way to model large sets of related rules.
The state of a number of conditions determines the execution of a set of actions.
Many variations of the decision table concept exist which look similar at first sight.
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Types
Types
Layout Horizontal
Vertical
Limited entry
Extended entry
Categorisation Expanded form, contracted form
Multi-hit, all hits
Multi-hit, first hit
Single hit
Layouts
Horizontal
Layouts
Vertical
Layouts
Limited entry
Layouts
Extended entry
Categorisation
Expanded form
Single column for every condition combination
The number of columns should equal the product of the number of states for every condition.e.g. 3 conditions each with 2 states gives:
2 * 2 * 2 = 8 combinationse.g. 2 conditions each with 3 states and 1 condition with 4 states gives:
3 * 3 * 4 = 36 combinations
Categorisation
Expanded form (continued)
Condition states should be digitised e.g. age: 60 not a free-form integer field
Condition states should be continuouse.g. GOOD: age=18; BAD: age=30
Not essential for expansion but ensures completeness
This guarantee of completeness of condition combinations is one of the main advantages of decision tables.
Categorisation
Expanded form (continued)
Categorisation
Contracted form
Contraction is the first optimisation.
Reduces the number of condition columns.
If the same actions exist for rules covering all condition states for a given condition they can be combined and the condition state becomes irrelevant.
Categorisation
Contracted form stage 1Rules 2 and 3 are impossible conditions
Categorisation
Contracted form stage 2Merge adjacent column groups with identical action parts
Categorisation
Multi-hit, all hits
To get complete result all rules matching need to have their actions executed.
Condition columns are not mutually exclusive
If the Condition columns are not exclusive, some combination of conditions are present in more than one column, which may lead to ambiguity or inconsistency.
Categorisation
Multi-hit, all hits
Given a 35 year old with 15 years service1. Rule 1 matches, giving 22 days2. Rule 5 matches, giving an additional 3 days3. A total of 25 days is assigned
Categorisation
Multi-hit, first hit
To get complete result the first rule (from left-to-right) matching needs to have its action executed.
Condition columns are not mutually exclusive.
If the Condition columns are not exclusive, some combination of conditions are present in more than one column, which may lead to ambiguity or inconsistency.
Categorisation
Multi-hit, first hit
Given a 35 year old with 15 years service1. Rule 4 matches, giving 25 days2. Rule 6 would match but Rule 4 was the first hit
Categorisation
Single hit
Each possible combination of conditions matches exactly one, and only one, rule.
Condition columns are mutually exclusive
As the Condition columns are exclusive; combinations of conditions cannot be present in more than one column which eliminates ambiguity and inconsistency.
Classic form if Single-hit is "expanded decision table"; but this can be optimised or contracted.
Categorisation
Single hit
Given a 35 year old with 15 years service1. Rule 3 matches, giving 25 days2. No other rules match
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Validation & Verification
Redundancy
Ambivalence (conflicting)
Deficiency
Mitigation
Validation & Verification
Redundancy
Duplication
Subsumption
Two rules have the same actions, but one contains additional conditions in which it will succeed. Whenever the more restrictive rule succeeds, the less restrictive rule also succeeds, resulting in redundancy.
Impossible conditionsConditions that do not make sense (e.g. age < 0)
Validation & Verification
Redundancy - Subsumption
Validation & Verification
Ambivalence
Contradictory rules
Two (or more) rules have the same conditions but with different actions.
Conflicting rulesAn action for one rule is the opposite of the same action for the other rule.
Ambiguous rulesThe actions are different but not opposite.
Validation & Verification
Ambivalence
Premium is 500 if applicant age is less than 30
Premium is 300 if Years Without Claim is greater than or equal to 10 years.
Applicant is 29, premium is 500
Applicant has 12 years without claim, premium is 300
Applicant is 29 with 12 years without claim, premium is ?!?
Validation & Verification
Deficiency
Missing rulesA situation exists in which a particular action is required, but there is no rule that succeeds in that situation and produces the desired conclusion.
Unused input state or domain attribute
Missing knowledgeThe absence of some essential elements from the problem situation.
Validation & Verification
Mitigation redundancy
Duplication
Cannot occur in the Single-hit decision table, because columns do not overlap.
Subsumption
Cannot occur in the Single-hit decision table, because columns do not overlap.
Impossible conditions
Impossible combinations may still exist.
Validation & Verification
Mitigation - ambivalence
The single-hit table format avoids such conflicts.
Premium is 500 if applicant age is less than 30
Premium is 300 if Years Without Claim is greater than or equal to 10 years.
Applicant is 29 with 12 years without claim, premium is 300
Validation & Verification
Mitigation - deficiency
Missing rules
Expanded decision table is exhaustive
All combinations of condition states are included
Unused input state or domain attribute
Expanded decision table is exhaustiveAll combinations of condition states are included
Missing knowledgeValidation of domain model by domain expert
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Transformation
Decision Trees
RequirementsDigitised condition states
Each Condition in a column becomes a branch
Multi-hitWalk every path through tree
Single-hitWalk single path through tree
Transformation
Example - Decision Table
Transformation
Example - Decision Tree
Transformation
Paying attention?
Rules 1, 2 and 3, 4 have the same action no matter what the state of Hunger. Therefore they can be contracted...
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Decision Tables in Guvnor
What do we currently provide?
Vertical layout
Generalised categorisationMulti-hit, all hit; Multi-hit first hit; Single hit
Extended entry
Digitised condition states (enumerated fields)
New decision table editor
Foundation for future work
Condition and rule negation
Cell merging
Cell grouping
Decision Tables in Guvnor
What do we currently provide?
Cell merging
Decision Tables in Guvnor
What do we currently provide?
Cell grouping
Decision Tables in Guvnor
What do we currently provide?
Video demonstration
Demonstration available online at http://vimeo.com/21438537
Decision Tables in Guvnor
Generation of DRL
Each row compiles into a separate DRL rule
Decision Tables in Guvnor
Generation of DRL
Each row compiles into a separate DRL rule
rule "Row 1 dtable"
dialect "mvel"
when
$person : Person( age < "18" )
then
$person.setHolidayEntitlement( 27 );
end
rule "Row 2 dtable"
dialect "mvel"
when
$person : Person( age >= "18" , age < "45" , lengthOfService < "15" )
then
$person.setHolidayEntitlement( 22 );
end
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Roadmap
What does the future hold?
Provision of other layoutsHorizontal
Limited entry
Automated optimisation
Improved support for digitised condition states
Integration of V&V providing visual feedback
Pluggable editors for Model Fact Types
Usability enhancements
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Summary
Decision TablesAre an important tool for modelling decisions
Provide a simple, yet powerful, visualisation of decision components
Allow large sets of related rules to be easily worked upon simultaneously
Provide the means to easily validate and verify rules
GuvnorExisting capabilities suitable for most
A solid foundation for the future
A roadmap to become the market leader
Agenda
Overview
Types
Validation & Verification
Transformation
Decision Tables in Guvnor
Roadmap
Summary
Q&A
Useful links
Projecthttp://www.jboss.org/drools
Reference Manualhttp://www.jboss.org/drools/documentation.html
Bloghttp://blog.athico.com/
Mailing Listshttp://www.jboss.org/drools/lists.html
Michael Anstis
Decision Tables in depth
This is the title
Second line of the title
Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline LevelNinth Outline Level
This is the chapter title
This is the subtitle