Menu
▾
▴
[Jboss-svn-commits] JBL Code SVN: r4221 - in labs/jbossrules/trunk/documentation/manual/en: Chapter-Deployment Chapter-Rule_Engine
|
From: <jbo...@li...> - 2006-05-15 07:35:24
|
Author: mic...@jb... Date: 2006-05-15 03:35:06 -0400 (Mon, 15 May 2006) New Revision: 4221 Added: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Section-Testing.xml labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Testing1.png labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Testing2.png Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Working_Memory.xml Log: stuff on logical assertions Added: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Section-Testing.xml =================================================================== --- labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Section-Testing.xml 2006-05-15 06:50:07 UTC (rev 4220) +++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Section-Testing.xml 2006-05-15 07:35:06 UTC (rev 4221) @@ -0,0 +1,98 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE section PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN" +"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd"> +<section> + <title>Testing</title> + + <para>In recent years, practices such as Test Driven Development have become + increasingly mainstream, as the value and quality that these techniques + bring to software development has been realised. In a sense, rules are code + (although at a highlevel), and a lot of the same principles apply.</para> + + <para>You can provide tests as a means to specify rule behaviour before + rules are even written. Further to this, tests are even more important in + environments where rules change frequently. Tests can provide a baseline of + confidence that the rule changes are consistent with what is specified in + the tests. Of course, the rules may change in such a way as the tests are + now wrong (or perhaps new tests need to be written to cover the new rule + behaviour). As in TDD practices, tests should be run often, and in a rule + driven environment, this means that they should be run everytime the rules + change (even though the software may be static).</para> + + <section> + <title>Testing frameworks</title> + + <para>For developers, clearly JUnit (or TestNG) are popular tools for + testing code, and these can also apply to rules. Keep in mind that rule + changes may happen out of sync with code changes, so you should be + prepared to keep these unit tests up to date with rules (may not be + possible in all environments). Also, the best idea is to target testing + some core features of the rule sets that are not as likely to change over + time.</para> + + <para>Obviously, for rule tests, other non source code driven frameworks + would be preferable to test rules in some environments. The following + section outlines a rule testing component add on.</para> + </section> + + <section> + <title>FIT for Rules - a rule testing framework</title> + + <para>As a seperate add-on, there is a testing framework available that is + built on FIT (Framework for Integrated Testing). This allows rule test + suites (functional) to be capture in Word documents, or Excel spreadsheets + (in fact any tool that can save as HTML). It utilises a tabular layout to + capture input data, and make assertions over the rules of a rulesets + execution for the given facts. As the tests are stored in documents, the + scenarious and requirements can be (optionally) kept in the same + documents, providing a single point of truth for rule behaviour.</para> + + <para>Also, as the test documents are not code, they can be updated + frequently, and kept with the rules, used to validate rule changes etc. As + the input format is fairly simple to people familiar with the domain of + the rules, it also facilitates "scenario testing" where different + scenarious can be tried out with the rules - all external to the + application that the rules are used in. These scenarios can then be kept + as tests to increase confidence that a rule change is consistent with the + users understanding.</para> + + <para>This testing framework is built on FIT and JSR-94, and is kept as a + seperate project to JBoss Rules. Due to it being built on FIT, it requires + a different licence (but is still open source). You can download and read + more about this tool from this web page: <ulink + url="http://fit-for-rules.sourceforge.net/"> + <citetitle>Fit for rules</citetitle> + </ulink> http://fit-for-rules.sourceforge.net/</para> + + <para>The following screen captures show the fit for rules framework in + action.</para> + + <screenshot> + <mediaobject> + <imageobject> + <imagedata fileref="Testing1.png" /> + </imageobject> + </mediaobject> + </screenshot> + + <para>Using Fit for rules, you capture test data, pass it to the rule + engine and then verify the results (with documentation woven in with the + test). It is expected that in future, the Drools Server tools will provide + a similar integrated framework for testing (green means good ! red means a + failure - with the expected values placed in the cell). Refer to + http://fit.c2.com for more information on the FIT framework itself.</para> + + <screenshot> + <mediaobject> + <imageobject> + <imagedata fileref="Testing2.png" /> + </imageobject> + </mediaobject> + </screenshot> + + <para>More information and downloads from <ulink + url="http://fit-for-rules.sourceforge.net/"> + <citetitle>Here</citetitle> + </ulink></para> + </section> +</section> \ No newline at end of file Property changes on: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Section-Testing.xml ___________________________________________________________________ Name: svn:eol-style + native Added: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Testing1.png =================================================================== (Binary files differ) Property changes on: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Testing1.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Testing2.png =================================================================== (Binary files differ) Property changes on: labs/jbossrules/trunk/documentation/manual/en/Chapter-Deployment/Testing2.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Working_Memory.xml =================================================================== --- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Working_Memory.xml 2006-05-15 06:50:07 UTC (rev 4220) +++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Working_Memory.xml 2006-05-15 07:35:06 UTC (rev 4221) @@ -39,8 +39,9 @@ <para>Basically the reverse of Asserting. When you retract a fact, the working memory will no longer track that fact, and any rules that were dependent on that fact will not be activated. Note that it is possible to - have rules that depend on the "non existence" of fact, in which case - retracting a fact may cause a rule to activate.</para> + have rules that depend on the "non existence" of a fact, in which case + retracting a fact may cause a rule to activate (see the "not" and "exist" + keywords).</para> </section> <section> @@ -52,6 +53,40 @@ </section> <section> + <title><indexterm> + <primary>Logical Assertion</primary></indexterm> + </title> + + <para> + In a regular assertion, you need to explicitly retract a fact. In logical assertions, the fact that was asserted will be automatically retracted when + the conditions that asserted it in the first place are no longer true (its actually cleverer then this, if there are no possible conditions that could support the logical assertion, only then will it be retracted). + </para> + + <para> + This sounds confusing but its not really. Logical assertions are a powerful form of truth maintenance. A logically asserted fact can be thought of as a proxy for all the conditions that cause the rule it belongs to to be true. This means that you can use a logically asserted fact in a condition in other rules, without including all the conditions that triggered the logical assertion (meaning that all those conditions are not repeated everywhere). Logically asserted facts are like other facts, nothing special, you can even use "not" to check for the non existance of a logically asserted fact. + </para> + + <section> + <title>Example scenario</title> + <para> + An example may make things clearer. + Imagine a credit card processing application, processing transactions for a given account (and we have a working memory accumulating knowledge about a single accounts transaction). The rule engine is doing its best to decide if transactions are possibly fraudulent or not. Imagine this rule base basically has rules that kick in when there is "reason to be suspicious" and when "everything is normal". </para> + <para> + Of course there are many rules that operate no matter what (performing standard calculations etc). + Now there are possibly many reasons as to what could trigger a "reason to be suspicious": someone notifying the bank, a sequence of large transactions, transactions for geographically disparate transactions, or even reports of credit card theft. Rather then smattering all the little conditions in lots of rules, imagine there is a fact class called "SuspiciousAccount". </para> + <para> + Then there can be a series of rules whose job is to look for things that may raise suspicion, and if they fire, they simply assert a new SuspiciousAccount() instance. All the other rules just have conditions like "not SuspiciousAccount()" or "SuspiciousAccount()" depending on their needs. Note that this has the advantage of allowing there to be many rules around raising suspicion, without touching the other rules. When the facts causing the SuspiciousAccount() assertion are removed, the rule engine reverts back to the normal "mode" of operation (and for instance, a rule with "not SuspiciousAccount()" may kick in which flushes through any interrupted transactions). + </para> + <para> + If you have followed this far, you will note that truth maintenance like logical assertions allows rules to behave a little like a human would, and can certainly make the rules more managable. + </para> + + </section> + </section> + + + + <section> <title>Globals</title> <para>Globals are a named objects that can be passed in to the rule @@ -107,14 +142,14 @@ <para>Rule engines that are based around algorithms like RETE are technically statefull rule engines. That is, they work best when the RETE network is longer lived, being notified of changes, and accumulating facts - - that is where they shine. </para> + - that is where they shine.</para> <para>However, many scenarious simply require a stateless mode where all the facts (data) are supplied fresh to the rule engine and then the rules are invoked. Drools is fine in these scenarious as well - in fact, the RETE algorithm is still of benefit as often there will be scenarios in a stateless session where rules actions cause other rules to fire, or where - there are large numbers of facts to match with rules. </para> + there are large numbers of facts to match with rules.</para> <para>The JSR-94 api specifies statefull and stateless modes, but the equivalent in the native API is to simply create a new working memory |
