1 / 44

M odelling Business Rules

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

begaym
Download Presentation

M odelling Business Rules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Decision Tablesand Prologa Modelling Business Rules Jan.Vanthienen@econ.kuleuven.ac.be

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

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

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

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

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

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

  8. Empty decision table

  9. 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;

  10. 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;

  11. 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);

  12. 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);

  13. Expanded decision table

  14. Contracted decision table

  15. Kinds of tables

  16. Holidays (multiple hit, all hits)

  17. Holidays (multiple hit, first hit)

  18. Holidays (single hit contracted)

  19. System of decision tables

  20. Application areas

  21. 3 aspects of a decision situation

  22. Interfaces

  23. Prologa PROcedural LOGic Analyzer • Decision Tables? • Decision Tables and PROLOGA • Features • Experiences    

  24. 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”

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

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

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

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

  29. Building Tables ; Screen Example

  30. 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)

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

  32. Modelling Features (3) • Support for automatic modularization

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

  34. 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)

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

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

  37. V&V ; Example

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

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

  40. Optimization

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

  42. Consultation Session ; Example

  43. AionDS Generation ; Example

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

More Related