One of the most famous epigrams of
programming<http://www.cs.yale.edu/quotes.html>collectd by Alan J.
Perlis is:
*When someone says "I want a programming language in which I need only say
what I wish done," give him a lollipop. *
I'm reminded of this in any discussion where this sales-pitch-black notion
of Business Analysts writing rules by themselves is peddled with the
assumption that some cleverly designed non-trivial DSL will magically
provide a blue sky and smooth sailing. Of course the BAs will still have to
have a clear understanding of the object model, and of course they will
still have to know the basics of rule programming. They'll need good
training, and (although I have never seen this) I think that they'll need a
lot of baby-sitting when they start.
When you write that "DSL ... gets built up over time" I think I know what
you are referring to, but this is more a hint on the way a DSL might be
developed, well before it is released for writing rules for production.
Changing a DSL - even by just adding new phrases - is tricky due to the way
DSL parsing works.
All of this does not mean that it cannot be done or that you cannot do it.
Mostly, it is the result of developing a DSL with the intent of
demonstrating that rules can be written in a language that can be read and
understood by domain experts. (Note what the experts are *not* expected to
do.) According to this, I have the following checklist for a DSL developer:
1. Design a simple object model with clean linkage between related
objects.
2. Know about all rule condition and consequence patterns that will need
to be written.
3. Make sure that you fully understand the way DSL parsing works.
4. Decide about the way the BAs will write the rules (GUI editor or text
editor).
After (2), you still have the option of using spreadsheets or template-based
rule authoring. If 80-90% of your prospective rules can be written by BAs
that way, you may still decide to have the rest written by programmers.
IMHO, none of the aforesaid is specific for Drools.
Cheers
Wolfgang
On 1 February 2011 17:08, cclark01 <chris.clark(a)teranet.ca> wrote:
My company is looking to use Guvnor in a new application we're writing.
Part
of the appeal is the idea that Business Analysts will be able to go and
write rules by themselves. However, in doing a small proof-of-concept, it
appears that you need intimate knowledge of the object model in order to
write any meaningful rules.
I've read up on DSL and it looks like that might help things, but it also
sounds like DSL is the kind of thing that gets built up over time.
So... what's your experience? Do BA's or Developers write the rules in
your
applications? Does the complexity of the object model play a role in who
can write rules, or is it just a matter of training?
If you've created a DSL, how easy/quick was it? If not, any particular
reason why not?
I'm looking for some "real life" experiences so that we can have
appropriate
expectations going into the project.
Thanks,
Chris
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Who-writes-your-rules...
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users