[rules-dev] Rule Dependency Generator
Mark Proctor
mproctor at codehaus.org
Tue Oct 7 07:51:48 EDT 2008
Siddharth Angrish wrote:
>
> Hi Toni,
>
> I checked out the drools-verifier code. For a little
> acclimatization I went through a few files. Looks like
> Verifier.java is the main
> class for verifier tool. I went on to check how the Consequences
> are being handled but could only find the interface
> Consequence.java and
> TextConsequence.java which doesn't do too much.
> It would be helpful to have some higher level description of the
> relevant class relationships. (who's who).
> Also, it may be helpful to know how to build this code and how to
> run it. I checked out the code from the url:
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/
> but could not get any build script or instructions.
>
Toni will answer on how the code works, but I'll answer on how to build.
You first need to checkout the whole of trunk and do a full build and
install, atleast once.:
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk
<http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/>
As a minimum this is "mvn install". This should build a number of
modules, including drools-verifier. then do "mvn eclipse:eclipse" (or
IDEA equivalent) to make sure all the eclipse .proejct .classpath files
are up to date. Then in eclipse import droosl-core, drools-compiler and
drools-verifier and you should be good to go. Also once you've built
once from root with maven, you should be able to go int drools-verifier
itself and type "mvn install".
>
>
> I hope I am going in the right direction.
>
> Siddharth
>
>
>
>
>
>
>
> On Mon, Oct 6, 2008 at 6:56 PM, Toni Rikkola <trikkola at redhat.com
> <mailto:trikkola at redhat.com>> wrote:
>
> Hi Siddharth
>
> Your work sounds interesting and I would like to hear more
> about it. Looks like your version is smarter with dependencies.
>
> The report data is used in Guvnor and in the HTML-report, but
> it can also be retrieved as XML or java objects.
>
> The HTML-report lists all the fields, rules and object types.
> So you can see what rules use certain object type and the
> field view shows what values are compared against the field.
> This dependency data is also used in the verification rules
> when searching for issues from the rule base.
>
> Like Mark said, the verifier is still quite blind for the RHS.
> Right now it just handles it as a string. So it can't really
> tell what objects were modified and how. This information is
> important to solve what rule creates or modifies facts to
> satisfy another rule. This dependency data can then again be
> used to find subsumption, loops ect.
>
> I hope that we can discuss about this soon.
>
> Toni
>
> Mark Proctor wrote:
>
> Siddharth Angrish wrote:
>
> Hi Mark
>
> I went through the RuleAnalytics Module document.
> It looks like there is a good compatibility between
> your visions of Rule Analysis and our rule dependency
> generation work. I'll be excited to further develop
> and integrate my work with drools-verifier module code.
>
> Just a short summary of how I had approached the problem:
>
> We have long ruleflow which consists of other
> ruleflows, ruleflow groups, split conditions. Using
> drools API I was
> able to traverse through the main ruleflow including
> (recursively) constituent nodes. So at any node I knew
> which rules
> are relevant. Now, to find out dependency between
> rules I required very intricate information about any
> given rule. I could not
> find sufficient drools APIs to get this information.
> There are methods to get LHS and RHS of a rule but
> they do not give information about individual
> attributes. For RHS its more worse. No textual
> information was availabe about it. (I am using 4.0.7
> and I had even posted my questions on Drools user
> mailing list)
>
> As a result, I wrote my own .drl file parser using
> javacc (which was very interesting to do) and got
> whatever information I required.
> Now I knew which rule modifies which attribute (and of
> which class) and which rule uses what atrributes in
> its conditional part. Its much easier to get dependecy
> sequence now. I know a few cases where this approach
> might produce a false dependency sequence but using
> other rule-flow(salience, agenda) information can help
> us avoid that.
>
> Now, how shall we go about it? I have installed irc
> on my system and I think I require some url to be able
> to connect to you guys.
>
> The details of connecting with irc are here:
> http://www.jboss.org/drools/irc.html
>
> you want to speak to Rikkola online if you see him.
>
> We don't want to add another DRL parser, as we already
> build up an internal tree - including consequence. So in
> the drools-verifier you already see how we build the descr
> tree, although that doesn't yet have an AST for the
> consequence, however we have java analysier that currently
> does (using antlr) and this and pulls out used identifiers:
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/main/java/org/drools/rule/builder/dialect/java/JavaExprAnalyzer.java
>
> We also extended our antlr grammar to understand the
> modify(...) {......} keyword. So you should be able to
> re-use the code inside of java expr analyzer to rewrite
> your existing stuff and also reusing our existing descr
> tree. Hopefully Toni Rikolla can help you with this online.
>
> Mark
>
>
> Siddharth
>
>
> On Sun, Oct 5, 2008 at 7:40 PM, Mark Proctor
> <mproctor at codehaus.org <mailto:mproctor at codehaus.org>
> <mailto:mproctor at codehaus.org
> <mailto:mproctor at codehaus.org>>> wrote:
>
> Drools 5.0 has the drools-verifier. This does a
> variety of
> verifications and analysis, like where class fields
> are used, gap
> analysis etc. The Guvnor BRMS can produce HTML
> reports for this
> information. Subsumption isn't done yet, we needed
> to analys the
> consequences for update/modify to try and detect
> potential
> impacted rules - this is also needed to detect
> which rules depend
> on other rules.
>
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-verifier/
> http://wiki.jboss.org/wiki/RuleAnalyticsModule
>
> So we would love to have your work as additions to
> this, but it
> will need to be integrated with the existing
> drools-verifier
> module code and the HTML reporting - can you make
> that happen? It
> would be ideal, as it then means your code is part
> of the main
> project and will be maintained and improved by the
> community.
>
> Maybe you could pop onto irc, and chat to us about
> it more?
> http://www.jboss.org/drools/irc.html
>
> Do you have any visualisation plans? If on the web
> GWT-Diagram is
> turning out to be a great tool
> http://code.google.com/p/gwt-diagrams/
>
> Mark
>
>
>
> Sangrish wrote:
>
> Hi
>
> I have been using Drools Rules Engine in
> our application
> for past
> couple of weeks.
> One of the requirements in our project was to
> let a user
> (anyone who is
> writing/analysing the rules) find out
> what other rules a given rule depends upon.
> There were a few
> kinds of
> dependencies:
> 1) Object Attribute dependency: The attributes
> of an object
> being used in
> the conditional part of a rule
> might be getting modified in the consequence
> part of
> another rule. We
> wanted all such rules with each rule having its own
> dependency list.
> 2) Rule Salience based dependency. A rule
> having lower
> salience should be
> executed only after a higher (if any) salience
> rule has
> already been
> executed.
> 3) Dependency caused by a specific Rule flow.
> Rules in a
> ruleflow group
> should be executed only if (if any) Split
> condition gets
> satisfied.
> 4) Agenda flow dependency (i.e., one agenda
> following another)
> We could not find much support for this in
> the Drools API.
> Hence we
> decided to write our own dependency generator.
> The tool we
> are writing
> caters to first 3 dependencies. We might even
> handle the 4th
> one. Since Drools is open source, we thought of
> contributing our bit towards
> its development. If the drools team wants I can
> happily work
> with them on
> getting this functionality plugged in the
> Drools system.
>
>
> Thanks
> Siddharth
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> <mailto:rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>>
>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081007/ba3ffa5e/attachment.html
More information about the rules-dev
mailing list