# Decision Tables and Prologa Modelling Business Rules.

## Presentation on theme: "Decision Tables and Prologa Modelling Business Rules."— Presentation transcript:

Decision Tables and Prologa Jan.Vanthienen@econ.kuleuven.ac.be Modelling Business Rules

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 Decision Tables

condition entries (condition states) condition stub (condition subjects) action stub (action subjects ) action entries (action values) Decision Tables

What kinds of knowledge ? Regulations, legislation, … Regulations, legislation, … Business rules, corporate policy,... Business rules, corporate policy,... »accept/refuse orders »discounts »… Expertise Expertise Classification knowledge Classification knowledge »types of customers »risk categories »…

– Powerful visualisation – Preventing errors is easier – Modular knowledge organisation – Performance Compact and structured presentation Avoid incompleteness and inconsistency Group rules into single table Fast decision tree execution 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 Why use decision tables ?

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. Example

Empty decision table

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 2:5 extra days generally if only age = 60 or service >= 30; Rule 1:assign 22 days definitely if always;

Rule 3:3 extra days generally if age >= 60 or service >= 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 4: 2 extra days generally if (45 = 60 or 15 <= 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 = 30);

Rule 1:assign 22 days definitely if always; Rule 2:5 extra days generally if only 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 = 60 or 15 <= service < 30) minus rule 2; Rule 5:impossible definitely if age = 30);

Expanded decision table

Contracted decision table

Kinds of tables

Holidays (multiple hit, all hits)

Holidays (multiple hit, first hit)

Holidays (single hit contracted)

System of decision tables

Application areas

3 aspects of a decision situation

Interfaces

Decision Tables? Decision Tables? Decision Tables and PROLOGA Decision Tables and PROLOGA Features Features Experiences Experiences PRO cedural LOG ic A nalyzer Prologa

Prologa from... from... a rule-based design tool for computer- supported construction and manipulation of decision tables to… to… a tool environment that uses decision tables for knowledge modelling, validation, optimization and implementation

Knowledge Modelling Tool Uses Decision Tables Integrated V&V Features Knowledge Optimization Consultation Engine Import/Export Facilities To/From other knowledge representations What is the PROLOGA system?

Decision tables Rules Conditions Actions Table structures Dependency graph The Prologa system - Preview

– Modelling features – Verification & Validation – Optimization features – Implementation features A ll table manipulations (fill by rules, refined specification language, compose, optimization) Structures of tables, modularization (Intra)tabular and intertabular Minimal columns, minimal rules, interfaces Why use Prologa?

Modelling Features (1) Building & manipulating decision tables Building & manipulating decision tables –specify conditions & actions –reorder by drag & drop –specify input rules : Actions [generally] if condition combinations Not action definitely if condition combinations Action only possible if condition combinations Action definitely if and only if condition combination –fill in entries by mouse

Building Tables ; Screen Example

Modelling Features (2) Structures of tables Structures of tables –Condition subtables : subtables that determine the state of a condition (e.g. when do you consider someone a good customer?) 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) 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 "Execute Order" subtable main table "Customer" subtable subtable further specifies what is understood by the notion of a "good" customer "Execute Order" subtable is only applicable in cases where Credit Limit = Ok and/or Customer = Good

Modelling Features (3) Support for automatic modularization Support for automatic modularization

Our Modularization Approach Rule 1 Rule 2 Rule 4 Rule 6 Rule 3 Rule 5 Rule 8 Rule 7 Rule 11 Rule 10 Rule 9 decomposing knowledge into multiple-table structure Order Execute Order

Working with Projects a project is a collection of related tables a project is a collection of related tables consists of : consists of : »prj-file »MS Access database-file »tab-files file management is handled by Prologa file management is handled by Prologa table linking based on logical table & variable names instead of tab-filenames table linking based on logical table & variable names instead of tab-filenames consultation environment consultation environment other representation formalisms than tables other representation formalisms than tables (future Prologa versions)

(E)E/R Model of Project

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 Prologa and V&V

V&V Features Intra-tabular verification : verify each table 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 Inter-tabular verification : verify different (sub)tables with respect to each other (topic of a current thesis) inter-tabular intra-tabular

V&V ; Example

The cleanroom approach Inconsistency or contradictions Avoided by modelling tables Incompleteness Avoided by automatic generation Redundancy Avoided by table mechanism Prologa and V&V experiences

Optimization Features Table contraction Table contraction –merge columns with identical action parts Row order optimization Row order optimization –less columns by changing order of condition rows Export to minimal rules Export to minimal rules –improved rule notation

Optimization

Implementation Features Prologas consultation environment Prologas consultation environment AionDS generation AionDS generation Export to … Export to … »Pascal »Cobol »Optimal code Whats next ? Whats next ? »use Prologa to build Web-based applications (JAVA) »Prologa as OLE Server or Delphi-component

Consultation Session ; Example

AionDS Generation ; Example

VANTHIENEN J., WETS G., Integration of the Decision Table Formalism with a Relational Database Environment, Information Systems, 20 (7), pp. 595-616, 1995. Storing the DT as a relational table Storing the DT as a relational table – Storing rules as data Storing persistent decision tables

Similar presentations