Hmmm.... Define "appropriate." Opinions are like certain body parts; we all have
them and they all smell the same. :-)
IMHO, one of my "rules" is that if it's easier to code in Java (or C++ or COBOL or
whatever) then do it that way. The first two lines are data validation which
should have been in the input screen, not in the Jess rulebase. The third line is
also data validation of a sort but employs a basic algorithm which normally belongs
in procedural code. The last line is a rule but it is easily implemented in any
procedural language. Here are some "Rules of Thumb" that I usually employ when
considering whether or not to use an ES or plain Java (or even C++.)
Rule of Thumb 1: If the decision tree takes less than one page of notebook paper,
use Java. If the tree takes more than one page, you might need an ES. If the
decision tree is very complicated and takes lots of thinking, use an ES.
Rule of Thumb 2: Never do in an ES what is far easier in procedural Languages.
Rule of Thumb 3: Try, really try, not to do math functions within an ES.
Rule of Thumb 4: Use an ES whenever you have nonmonotonic reasoning.
Rule of Thumb 5: Use an ES whenever you have a lot of rules that, while simple in
themselves, are complex taken together.
So, how does one measure complexity? You could say that if you have 20 complex
rules (possibly defined as more than 3 condition elements on the LHS) and more than
20 complex objects (possibly defined as more than 5 attributes and more than 10
methods) that you have a sufficiently complex problem. But what if you only have
19 rules and 21 complex objects? Or 18 rules and 25 complex objects? Or 25 rules
and 3 complex objects?
Well, that is where "experience" comes in. Once you've built 10 or 20 of these you
should be able to look at the situation and see where and how a rulebase fits the
equation. So, jump in and build some simple rulebase applications (even were the
guidelines say you don't need one - such as your example) and get some of that
"experience." Above all, have fun. :-)
One other problem that you will encounter, eventually, is that someone will want to
use SQL to extract certain data rather than pattern matching rules. That's OK.
Sometimes it's simpler for a small problem to do it this way. But, when the
problems become complex (there's that word again) then you'll have to patiently
explain how an ES can solve the problem and the ES will offer much better
scalability when properly designed.
BTW, rulebase is one word, just like database. So is rulebased and databased.
Although, in times past, we have used the terms Rule-Based and Knowledge-Based with
a hyphen in the middle, as in the name of my company. :-)
Robert Quillen wrote:
> First I'd like to say that I'm completely new to Jess and rule based programming.
>
> I need to write some software that will check a collection of data for
> completeness and/or correctness. If any of the data are incomplete or otherwise
> incorrect, the system must give feedback as to which data are at fault.
>
> Some example constraints:
>
> "First Name" must not be empty
> "Last Name" must not be empty
> X must be greater than Y
> if A equals B then C must equal D
>
> Would Jess be appropriate for this?
>
> -Robert Quillen
--
ttfn
IHN
Jim
---------------------------------
James C. Owen
Knowledge-Based Systems Corporation
6314 Kelly Circle
Garland, TX 75044
972.530.2895
mailto:[EMAIL PROTECTED]
http://www.kbsc.com
"Have You Read My #1 Best Seller? There Will Be A Test. -God"
(Seen on a billboard in DFW MetroPlex.)
"NT's lack of reliability is only surpassed by its lack of scalability." -- John
Kirch
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
