440 likes | 461 Views
Decision Tables and Prologa. M odelling Business Rules. Jan.Vanthienen@econ.kuleuven.ac.be. Decision Tables. What is a decision table ? Completeness criterion Exclusivity criterion. Table Representing complete set of conditional expressions where expressions are mutually exclusive
E N D
Decision Tablesand Prologa Modelling Business Rules Jan.Vanthienen@econ.kuleuven.ac.be
Decision Tables • What is a decision table ? • Completeness criterion • Exclusivity criterion • Table • Representing complete set of conditional expressions • where expressions are mutually exclusive • In a predefined area
condition stub (condition subjects) condition entries (condition states) action entries (action values) action stub (action subjects) Decision Tables
What kinds of knowledge ? • Regulations, legislation, … • Business rules, corporate policy, ... • accept/refuse orders • discounts • … • Expertise • Classification knowledge • types of customers • risk categories • …
Why use decision tables ? • Compact and structured presentation • Avoid incompleteness and inconsistency • Group rules into single table • Fast decision tree execution • Powerful visualisation • Preventing errors is easier • Modular knowledge organisation • Performance
Why use decision tables ? if (credit limit = 'Ok') and (customer = 'Good') and (Stock Sufficient)then Execute Order if (customer = 'Not Good') and (credit limit = 'Not Ok') then Refuse Order if (credit limit = 'Not Ok')and (customer = 'Good') and not(Stock Sufficient) then Put On Waiting List if (Customer = 'Good') and (Stock Sufficient) then Execute Order if (Customer = 'Good') and not(Stock Sufficient) and (credit limit = 'Ok') then Put On Waiting List if (credit limit = 'Ok') and (Customer = 'Not Good') and not(Stock Sufficient) then Put On Waiting List if (credit limit = 'Ok') and (Stock Sufficient) and (Customer = 'Not Good') then Execute Order
Example • The number of holidays depends on age and years of service. Every employee receives at least 22 days. Additional days are provided according to the following criteria: • Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days. • Employees with at least 30 years of service and also employees of age 60 or more, receive 3 extra days, on top of possible additional days already supplied. • If the employee has at least 15 but less than 30 years of service, 2 extra days are given. These 2 days are also provided for employees of age 45 or more. The 2 extra days can not be combined with the 5 extra days.
Decision rules • Every employee receives at least 22 days. • Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days. Rule 1: assign 22 days definitely if always; Rule 2: 5 extra days generally if onlyage < 18 or age >= 60 orservice >= 30;
Employees with at least 30 years of service and also employees of age 60 or more, receive 3 extra days, on top of possible additional days already supplied. • If the employee has at least 15 but less than 30 years of service, 2 extra days are given. These 2 days are also provided for employees of age 45 or more. The 2 extra days can not be combined with the 5 extra days. Rule 3: 3 extra days generally if age >= 60 or service >= 30; Rule 4: 2 extra days generally if(45 <= age < 60 or age >= 60 or15 <= service < 30) minus rule 2;
From common sense knowledge, it is clear that an employee younger than 18 years can not have 15 or more years of service. The impossible condition combinations should be discarded from the table by adding the rule: Rule 5: impossible definitely if age < 18 and (15 <= service < 30 orservice >= 30);
Rule 1: assign 22 days definitely if always; Rule 2: 5 extra days generally if only age < 18 or age >= 60 or service >= 30; Rule 3: 3 extra days generally if age >= 60 or service >= 30; Rule 4: 2 extra days generally if(45 <= age < 60 or age >= 60 or15 <= service < 30) minus rule 2; Rule 5: impossible definitely if age < 18 and (15 <= service < 30 orservice >= 30);
Prologa PROcedural LOGic Analyzer • Decision Tables? • Decision Tables and PROLOGA • Features • Experiences
Prologa from... “a rule-based design tool for computer-supported construction and manipulation of decision tables” to… “a tool environment that uses decision tables for knowledge modelling, validation, optimization and implementation”
What is the PROLOGA system? • Knowledge Modelling Tool • Uses Decision Tables • Integrated V&V Features • Knowledge Optimization • Consultation Engine • Import/Export Facilities • To/From other knowledge representations
The Prologa system - Preview Decision tables Rules Conditions Actions Table structures Dependency graph
Why use Prologa? • All table manipulations (fill by rules, refined specification language, compose, optimization) • Structures of tables, modularization • (Intra)tabular and intertabular • Modelling features • Verification & Validation • Optimization features • Implementation features • Minimal columns, minimal rules, interfaces
Modelling Features (1) • Building & manipulating decision tables • specify conditions & actions • reorder by drag & drop • specify input rules : Actions [generally] if condition combinationsNot action definitely if condition combinationsAction only possible if condition combinationsAction definitely if and only if condition combination • fill in entries by mouse
Modelling Features (2) • Structures of tables • Condition subtables : subtables that determine the state of a condition (e.g. when do you consider someone a good customer?) • Action subtables : subtables that further elaborate on what additional knowledge holds for certain cases (e.g. what discount to give if an order is accepted)
Table Structures ; Example "Customer" subtable subtable further specifies what is understood by the notion of a "good" customer main table "Execute Order" subtable is only applicable in cases where Credit Limit = Ok and/or Customer = Good "Execute Order" subtable
Modelling Features (3) • Support for automatic modularization
Our Modularization Approach decomposing knowledge into multiple-table structure “Order” Rule 2 Rule 1 Rule 3 Rule 4 Rule 5 Rule 6 “Execute Order” Rule 7 Rule 10 Rule 9 Rule 11 Rule 8
Working with Projects • a “project” is a collection of related tables • consists of : • prj-file • MS Access database-file • tab-files • file management is handled by Prologa • table linking based on logical table & variable names instead of tab-filenames • consultation environment • other representation formalisms than tables (future Prologa versions)
Prologa and V&V • Although the use of decision tables has been proposed before in V&V literature (Cragun, Puuronen), our viewpoint differs from these other approaches • decision tables as a modelling technique on its own, and not merely as a means towards verification of rule-based systems • As pointed out in (Preece 94), tools that verify rule-bases after operationalizing them into decision table format, generally fail to find anomalies that stretch beyond simple pairs of rules • full V&V between tables
V&V Features • Intra-tabular verification : verify each table • single-hit decision tables • contradiction messages • verification report • Inter-tabular verification : verify different (sub)tables with respect to each other (topic of a current thesis) intra-tabular inter-tabular
Prologa and V&V experiences The cleanroom approach • Inconsistency or contradictions • Avoided by modelling tables • Incompleteness • Avoided by automatic generation • Redundancy • Avoided by table mechanism
Optimization Features • Table contraction • merge columns with identical action parts • Row order optimization • less columns by changing order of condition rows • Export to minimal rules • improved rule notation
Implementation Features • Prologa’s consultation environment • AionDS generation • Export to … • Pascal • Cobol • Optimal code • What’s next ? • use Prologa to build Web-based applications (JAVA) • Prologa as OLE Server or Delphi-component
Storing persistent decision tables • Storing the DT as a relational table • Storing rules as data VANTHIENEN J., WETS G., Integration of the Decision Table Formalism with a Relational Database Environment, Information Systems, 20 (7), pp. 595-616, 1995.