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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev