![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In some business rules application contexts, such as risk analysis, the knowledge of factors leading to some assessment is often qualitative, not quantitative
I happened to be asked if it would make sense to use ILOG JRules to express this type of fuzzy reasoning. At first, I was surprised by the idea, but then I started digging into it. I decided to write this article to share my ideas and approach with the business rules community, and to gather feedback, opinions, suggestions.
Some background on WebSphere ILOG JRules
In this section, I'll give some background information about JRules; if you're already knowledgeable about JRules concepts, you can safely skip this section.
WebSphere ILOG JRules (hereafter JRules) provides functionality to build and deploy rule-based applications. A rule-based application is an application in which business logic is expressed using business rules, which are externalized from the application code and are managed and executed in a business rules management system (BRMS) infrastructure.
A business rule is any statement in the form “IF criteria THEN action” that is of interest to the business. In order to empower business users to directly express and manage the business rules relevant to an application domain, JRules implements a high-level business-oriented rule language called Business Action Language, or BAL. BAL allows the expression of sentences in a user-provided vocabulary, as shown in Figure 1.
Figure 1. Business rules, vocabulary and object model
The user vocabulary is defined by building a Business Object Model (BOM) artifact that defines the entities involved in a problem domain, how these should be shown (verbalized) to the user and how they are mapped to implementation artifacts (XML Object Model, either Java™ or XML).
Executing business rules (Rete algorithm)
JRules can execute business rules in sequential mode or using a high-performance version of the Rete algorithm, which follows these steps:
- The rule engine matches the conditions of the rules in the rule set against the objects in working memory.
- For each match, a rule instance is created and put into an execution queue called the agenda. Then the agenda, based on some ordering principles, selects the rule instance that should be fired.
- Firing the rule instance executes the rule action. Actions can modify the working memory.
The process continues cyclically until there are no more rule instances left in the agenda.
Figure 2. Rule engine - Rete plus mode
Some background on fuzzy logic
In this section, I'll give a very basic introduction to the concepts of fuzzy logic that are pertinent to the purpose of this article, which is to calculate the degree of confidence we can have in an assertion from imprecisely asserted knowledge.
Fuzzy sets and fuzzy assertions
A set is a collection of elements with a well-defined notion of membership. For example, the collection of people older than 70 is a set. Membership is "crisp," that is, an element either is member or not member of the set.
A fuzzy set is a collection which has a defined "degree of membership."
For example the collection of "old people" is not a well-defined set, but can be defined as a fuzzy set as long as we define what percentage "old" we consider a person's age. For example, 10 years is 10% old, 50 years is 40% old, 70 years is 90% old, and so on.
Mathematically, the degree of membership is captured by defining a membership function, which maps each member to a number from 0 to 1.
A fuzzy assertion is a statement about the membership of something in some fuzzy set, and as such has a "degree of truth."
For example, the customer is old is a statement that has a degree of truth corresponding to the degree of membership of the customer to the old people fuzzy set.
As is the case with vanilla sets, fuzzy sets can be defined by enumerating the members of the set with the corresponding degree of membership.
Set operators (union, intersection and complement) can be promptly extended to fuzzy sets, where:
- The membership function of the union of two fuzzy sets is taken to be the maximum of the two membership functions. For example, if I can say with 80% confidence that the customer is old, and 30% confidence that the customer is middle-aged, then I can say with 80% confidence that the customer is old OR the customer is middle-aged.
- The intersection takes the minimum of the two membership functions. For example, if a driver is 100% middle aged and is a 10% safe driver, I can say with 10% confidence that the driver is both middle aged AND safe driver. >
- The complement takes the "1’s complement." For example, if I’m 100% confident that the customer is old, I can say with 0% confidence that the customer is not old.
A single fuzzy statement assumes the form:
If x is A then y is B.
In a fuzzy inference system, the semantic of this statement differs from the classical inference rule in that:
-
x is Acalculates the degree of membership ofxin the fuzzy setA. -
y is Basserts thatyis member of a fuzzy setB. -
if x is A then y is Basserts that the truth level (the degree of membership) ofy is Bis equal to the truth level ofx is A.
Typically, a fuzzy inference involves three main phases: fuzzyfication, rule evaluation and defuzzyfication.
Fuzzyfication
During this phase fuzzy sets are built to represent the "universe of discourse" of the application, and input data is evaluated to calculate the degree of membership in the appropriate fuzzy sets. For example, if I want to express rules on how the age of a driver affects the risk of accident, I will build an "old" fuzzy set (input) and a "high_risk" fuzzy set. From the age of the driver, I'll be able to calculate the degree of membership of the driver in the old fuzzy set.
Rule evaluation
During this phase the engine will evaluate the rules and infer the degree of membership in the output fuzzy sets. For example, I could gather from one rule that the driver is high-risk with 90% confidence and from another rule that the driver is low-risk with 20% confidence.
Defuzzyfication
During this phase a crisp numeric output is calculated from the fuzzy sets. This is an algorithmic calculation. For example, a numeric risk score can be calculated from high-risk and low-risk membership.
Using JRules for fuzzy inference
In order to use JRules as a fuzzy inference engine, you need to:
- Write a BOM that allows you to express fuzzy assertions
- Engage the JRules inference engine to work on fuzzy assertions
Writing a BOM for fuzzy assertions
The BOM has two main classes: FuzzySet and FuzzyFact. Figure 2 shows the basic reusable vocabulary for writing fuzzy assertions. Figure 3 shows a simple if-then rule built on top of that.
FuzzyFact
A FuzzyFact is the main BOM class. It implements fuzzy assertions.
FuzzyFact has a truth level, and exposes the
somehow operator, which returns
true if the truth level is more than 0.
For example the following rule:
definitions
set age to a number in { 30 , 40 , 50, 60 , 70};
if
somehow age is old
then
print "age: " + age + " is old with confidence: " + truth value ;
else
print "age: " + age + " is not old at all" ;
gives:
age: 30 is not old at all
age: 40 is not old at all
age: 50 is old with confidence: 0.4
age: 60 is old with confidence: 0.8
age: 70 is old with confidence: 1.0
|
results in:
age: 30 is not old at all age: 40 is not old at all age: 50 is old with confidence: 0.4 age: 60 is old with confidence: 0.8 age: 70 is old with confidence: 1.0 |
FuzzyFacts can be combined using fuzzy Boolean operators. For example:
if somehow 'the driver' is MIDDLE_AGED and 'the driver' is LOW_RISK_DRIVER then print "MIDDLE_AGED with evidence: " + the truth level of 'the driver' is MIDDLE_AGED ; print "LOW_RISK_DRIVER with evidence: " + the truth level of 'the driver' is LOW_RISK_DRIVER ; print "combined (and) evidence: " + truth value; |
results in:
MIDDLE_AGED with evidence: 0.2 LOW_RISK_DRIVER with evidence: 0.5 combined (and) evidence: 0.2 |
FuzzySet
A FuzzySet provides a method to obtain or assert a FuzzyFact, namely:
-
getMembership(Object), verbalized as{an object} is {a fuzzy set}, creates a FuzzyFact out of the FuzzySet. -
assertFact(Object), verbalized asset {a fuzzy set} as {0}creates a FuzzyFact in the FuzzySet than can be retrieved later using thegetMembership()function.
A FuzzySet can be defined explicitly, by calling the empty constructor and
adding (asserting) all member facts. For example, the following rule
asserts that HIGH_RISK is a member of the
risk fuzzy set. The truth value of the asserted
fact is implicitly derived from the rule context.
if somehow the age of person is old then set risk as HIGH_RISK ; print "risk is HIGH_RISK with confidence: " + truth value ; |
A FuzzySet can be also be defined implicitly, by associating the fuzzy set to a membership function that will calculate the membership degree when needed. A simple and typical example of a membership function is the “trapezoidal” function, Figure 3 shows the membership function for the young, middle-aged and old fuzzy sets.
Figure 3. Trapezoidal membership function
Figure 4 represents the (trapezoidal) membership functions of our sample domain.
Figure 4. The fuzzy vocabulary
Figure 5 shows the fuzzy vocabulary defined in JRules Rules Studio. >
Figure 5. BOM elements
The basic idea is to let the JRules engine work as if it were doing a "sharp" inference and leverage the JRules IlrTool APIs to track the truth level of the assertions.
Table 1. IlrTool API subset
notifyAddInstance(IlrRuleInstance instance, IlrRuleInstance previous)
Provides notification that a rule instance has been inserted into the agenda. |
notifyBeginInstance(IlrRuleInstance instance)
Provides notification that a rule instance has been selected to fire and that the first action is about to be executed. |
notifyEndInstance(IlrRuleInstance instance)
Provides notification that a rule instance has finished executing the action part. |
As described in Executing business rules (Rete algorithm), JRules will first evaluate the antecedent of each business rule against the objects in working memory; if the antecedent evaluates to true, the rule is put in the agenda.
In our case, the antecedent of each business rule can be a combination of
fuzzy facts. The somehow operator will evaluate
to true if the fuzzy facts can be true for a rule instance, that is for
the application of the business rule to specific business objects in
working memory. In this case, the rule instance is added in the agenda and
the notifyAddInstance callback is called. The
truth value of the instance can be captured and tracked until the instance
is removed from the agenda (by
notifyEndInstance).
The critical assumption here is that JRules is evaluating the antecedent
of a business rule and calling
notifyAddInstance in the same Java thread.
Note that a limitation of this approach is that the
somehow operator can be called only once in
a rule antecedent.
Figure 6 shows the EngineTracker Java implementation. The engine tracker is registered with the JRules rules engine and will receive notifications of rule evaluation events.
Figure 6. The engine tracker
During the inference phase, the inference engine will assert the membership of workspace objects to some fuzzy set we use to classify our problem space. For example, we can define a HIGH_RISK fuzzy set and a LOW_RISK fuzzy set. The business rules will assert when we consider a driver a member of each category, and the engine will calculate the degree of membership.
During the defuzzyfication phase, a numeric "risk score" is calculated. A common procedure is to calculate the barycenter of the trapezoids of the resulting fuzzy sets. This involves simple geometrical calculations and is easily implemented in Java.
Figure 7 shows the resulting scoring calculated by the following rules:
Old Rule:
if somehow 'the driver' is OLD then set risk as HIGH_RISK ; |
Young Rule:
if somehow 'the driver' is YOUNG then set risk as HIGH_RISK ; |
Safe Driver Rule:
if somehow 'the driver' is MIDDLE_AGED or 'the driver' is LOW_RISK_DRIVER then set risk as LOW_RISK ; |
Unsafe Driver Rule:
if somehow 'the driver' is HIGH_RISK_DRIVER then set risk as HIGH_RISK ; |
Figure 7. Scoring
In summary, fuzzy techniques enjoy a widespread reputation for providing very useful tools for coping with imprecise knowledge. IBM ILOG JRules is a flexible and powerful tool for building a functional (albeit simple) implementation of a fuzzy inference system. In this article, I showed you how such a system can be implemented. I'd be glad to hear from you with about ideas and experiences!
- Mathworks Fuzzy
Logic Toolbox documentation
-
WebSphere ILOG JRules BRMS Information Center
-
developerWorks BPM zone
-
IBM BPM
Journal
Alessandro Mottadelli is an ILOG technical sales specialist in IBM Softare Group in Italy. He has nearly 30 years experience in the software industry. Before his current position, Alessandro was an application architect for more than a decade in the IBM Services group, and prior to that he worked on object-oriented programming as a Smalltalk technical sales specialist.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
