ted.neward@newardassociates.com | Blog: http://blogs.newardassociates.com | Github: tedneward | LinkedIn: tedneward
a bit about Rule Engines and Expert Systems
a bit about when to apply them
how to use the CLIPS rules engine
"... an intelligent computer program that uses knowledge and inference procedures to solve problems that are difficult enough to require significant human expertise for their solution."
a generalized expert system in which the expertise (the domain knowledge) is missing, to be entered via some form of programming language at a later date
JESS (Java Expert System Shell)
Drools
ILOG Rules
inference engine
pattern matcher
agenda
execution engine
rule base
working memory
RETE (ree-tee) algorithm
Latin for "net"
form a graph of nodes, connecting rules to facts and vice versa
very powerful, sometimes confusing
Forward-chaining
"if-else" style condition-execution
"drawing conclusions from the available evidence"
Backward-chaining
rules engine actively looks to make rules fire
"looking for evidence to back a hypothesis"
Is your algorithm primarily compute-intensive or is there significant decision-making capability involved?
If your basic algorithm is compute-intensive or a table-lookup, without much conditional branching or decision-making involved, then don't use a rules engine.
If however, the algorithm involves significant conditional branching or decision-making, then consider using a rules engine.
Are the decisions that need to be made relatively simple, or potentially complex?
If you find that you can't write the decision rules, for whatever reason, then stop here until you can, or use some other tool instead that will help you discover the rules you need. Put another way, if you can't state some rules, don't use a rules engine.
If you have 2, or fewer, conditions in your rules (or, for example, a block with 2 nested if-statements or less), don't use a rules engine-it's probably overkill.
If you have 3 or more conditions in your rules (or, for example, a block with 3 or more nested if-statements in pseudo-code), then consider using a rules engine.
Is your algorithm basically static, or are the rules likely to change reasonably often over time?
If the rules/logic are well-defined and static, then don't use a rules engine-you probably don't need the overhead or flexibility.
If the rules are likely to change over time due to the nature of the application, then consider using a rules engine-the flexibility is worth the overhead.
Are you going to maintain the code or finished product over time, or is this effort a one-shot effort?
If the code is not going to be maintained over time, then don't use a rules engine-you probably won't gain any significant advantage from it.
If the code is going to be maintained over time, consider using a rules engine--the ROI will be worth it (see question #6).
Does your customer require a custom solution or do you need to hard-wire the algorithm for absolute high-end performance, or can the solution accommodate a rules engine?
If you need to optimize for speed and memory, or your customer requires a custom solution, then don't use a rules engine.
If the performance requirements will accommodate a rules engine solution, then consider using one.
Can the project/product line afford the overall cost of using a rules engine over the project/product lifecycle?
There are a number of costs typically associated with using rules engine tools:
Licensing fees for development and deployment of the engine
Training developers and (if necessary) end-users
ROI-financial analysts have shown that you don't begin to break even monetarily on the typical investment in rules engine technology until at least 1 year after deployment to your customer. However, at that point, the flexibility and ease-of-maintenance begin to show significant returns.
For simulation and prototyping
In cases where you find you may not really know or understand the rules you are trying to encode in your algorithm, a rules engine can provide a flexible way to encode and modify the rules over time as they are discovered
A rules engine architecture also provides a convenient structure for separating "business logic" from the rest of the system, aiding in the effort to clearly "separate concerns"
rules engines are powerful ways to design a system
rules engines can give end-users substantial power
ensure the problem is right before using a rules engine
CLIPS is a which means it's a Lisp, essentially
Architect, Engineering Manager/Leader, "force multiplier"
http://www.newardassociates.com
http://blogs.newardassociates.com
Sr Distinguished Engineer, Capital One
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Books
Developer Relations Activity Patterns (w/Woodruff, et al; APress, forthcoming)
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)