Fstachecki: /* Rule Engine ⌘ */

2018-09-11T10:15:56Z

Rule Engine ⌘

New page

[[Category:Drools Filip|00]]

<div class="noprint">
<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="false" font="Trebuchet MS" headingmark2="。" lang="中文版" >
;title: Drools introduction
;author: <br/>安博 Bernard Szlachta (bs@nobleprog.com), Filip Stachecki (filip@nobleprog.pl)
</slideshow>

{{Can I use your material}}

</div>

=Drools=
== Approaches to Business Analysis and Design⌘ ==
* Data First (RDMS)
** first approach to analysis focused on data
* Object Orientation (OOP)
** business logic was mixed up with data
* Processes First (BPMS)
** process management tools allowed analysts to create executable process models
* Rules First (BRMS)
** having rules and processes, a person can derive everything else

==Business Rule Approach⌘==
===Terms and Business Rules vocabulary⌘===
* A '''term''' is a noun or noun phrase that workers recognize and use in business communications of all kinds (in agreements, deals, licenses, certifications, warranties, manuals, ...)
* A term carries a particular meaning for the business, which should be unambiguous given a particular context of usage (e.g. customer, order, invoice, employee)
* A term is a word or expression that has a precisely limited meaning in some uses or is peculiar to a science, art, profession, trade, or special subject
* Every term requires a careful definition:
** Customer: one that purchases some commodity or service; especially, one that purchases systematically or frequently

===Terms⌘===
Term should be:
* '''Basic''' (should represent something fundamental to business, cannot be derived)
* '''Countable''' (a thing whose instances can be counted - employee instead of staff)
* '''Non-procedural''' (term is about knowledge, not about the actions)

The collection of all terms and definitions are the core part of a business vocabulary.

Such terms are crucial for expressing business rules effectively.

===Fact Types⌘===
* Connections between terms are expressed using verbs and verb phrases - '''fact types'''.
* Fact type "customer places order" can be used in BR "A customer has always placed at least one order."
* Fact types extend business vocabulary:
** add standard verbs and verb phrases
** by connecting terms they bring structure to the vocabulary
* At least one term can be involved in connections:
** person smokes (one term)
** customer places order (two terms - a majority of connections)
** person visits city on date (three terms)

===Graphical Concept Models⌘===
[[File:ClipCapIt-140905-142125.PNG|500px]]

<small>Ronald Ross, Business Rule Concepts: Getting to the Point of Knowledge, Figure 1-1, simple concept model in graphical form</small>

===Business Rules⌘===
[[File:ClipCapIt-140905-143445.PNG]]
* Rules are familiar to us all in real life.
* We play games by rules, we live under a legal system based on rules, we set rules for our children, and so on.
* Thinking about the control aspect of any organized activity in terms of rules is actually very natural (try explaining any game without explaining the rules the game is based).

====What is a Business Rule?⌘====
The SBVR follows a common-sense definition of ‘business rule’:
Business Rule: rule that is under business jurisdiction
*‘Under business jurisdiction’ means that the business can enact, revise, and discontinue their business rules as they see fit.
* If a rule is not under business jurisdiction in that sense, then it is not a business rule.
* For example, the ‘law’ of gravity is obviously not a business rule. Neither are the ‘rules’ of mathematics.



====Business Rule “Mantra”⌘====
“Rules are based on facts, and facts are based on terms.”
<table border="0" cellpadding="10" cellspacing="0">
<tr>
<td>[[File:RuleFactTerm.png]]</td>
<td>
'''Terms'''<br/>
*Employee
*Employee number
*Car
*Car registration number

'''Facts'''<br/>
*Car has car registration number
*Employee drives car

'''Rules'''<br/>
*Each employee must be uniquely identifiable.
* Each car always has exactly one car registration number.</td>
</tr>
</table>

==== Exercise ⌘====
# For a Pizza Company, create a fact model
# Write a couple of rules a Pizza Company can have based on the fact model
[[Pizza Rules Sample Answer]]

===Business Rules Approach architecture⌘===
[[File:ClipCapIt-150708-132606.PNG]]

== Artificial Intelligence ⌘==
[[File:Drools-ai.jpg]]

* Expert Systems are also known as Knowledge-based Systems and Knowledge-based Expert Systems
* Drools is a Rule Engine that uses the rule-based approach to implement an Expert System and is more correctly classified as a Production Rule System.

== Rule Engine ⌘==
:[[File:Drools-ruleengine.PNG]]
<p style="font-size:10px">Drools documentation, Figure 1.1. High-level View of a Rule Engine</p>
* The '''Rules''' are stored in the Production Memory
* '''Facts''' that the '''Inference Engine''' matches against are kept in the '''Working Memory'''.
* Facts are asserted into the Working Memory where they may then be '''modified''' or '''retracted'''.
* A system with a large number of rules and facts may result in many rules being true for the same fact assertion; these rules are said '''to be in conflict'''.
* The '''Agenda''' manages the execution order of these conflicting rules using a '''Conflict Resolution''' strategy.

=== Advantages of a Rule Engine ⌘===
* Declarative Programming ("What", not "How")
* Explanation Facility - we can see "how" engine solved the problem
* Logic and Data Separation (breaking OO coupling of data and logic)
* Speed and Scalability (Rete, Leaps, PHREAK)
* Centralization of Knowledge (Documentation)
* Tool Integration
* Understandable Rules (DSL)

=== When should you use RE? ⌘===
* The problem may not be complex but there is no non-fragile way of building a solution for it
* The problem is beyond any obvious algorithmic solution
* The logic changes often
* Domain experts (or business analysts) are readily available, but are nontechnical
* There are too many rules to manage them in the code
* We need rules to be explicit and documented

=== When shouldn't you use RE? ⌘===
* Maintaining the infrastructure is more expensive than the gains
* With system which hardly ever change
* There is no person understanding RE

=== Alternatives to Rule Engine ⌘===
* Scripting
* Decision Tables (Lookup tables, DMN)
* Other data-driven solutions


== What are Rules ⌘==
Rules are the guidelines which instruct people '''what''' to do '''when''' certain conditions happen

=== Rules Examples ⌘===
* When the booking form arrives, then we send the confirmation letter
* When there are no bookings 14 days before the course commences, then we cancel the course

=== Rules Syntax ⌘===
When (if) Then
Condition Action
Left side Right side
LHS RHS

Example
if it rains take an umbrella

=== Rules Syntax ⌘===
:[[File:ClipCapIt-150708-182520.PNG]]

Rule "Next delegate discount"
When
$NumberOfDelegates > 1
Then
$Price = $Price - $Price*($numberOfDelegates-1)*10%
End
===Domain Specific Language Rules⌘===
:[[File:ClipCapIt-171026-120855.PNG]]
* DSL is a way non-technical people can write '''executable''' rules in Drools environment
* DSL is ultimately transformed to rules (mvel or java)
* .dsl file contain the transformations (mapping)

== The Business Rules Manifesto ⌘==
http://www.businessrulesgroup.org/brmanifesto.htm
Rules are not process and not procedure. They should not be contained in either of these.

Rules build on facts, and facts build on concepts as expressed by terms.

If something cannot be expressed, then it is not a rule.

Business rules should be expressed in such a way that they can be validated for correctness by business people.

Exceptions to rules are expressed by other rules.

Drools introduction - Revision history

Fstachecki: /* Rule Engine ⌘ */