[rules-dev] Rule Dependency Generator
Siddharth Angrish
sidangrish at gmail.com
Fri Oct 10 02:53:34 EDT 2008
Hi Toni
I ran the JUnit test case : VerifierTest.java. It ran
successfully but I was expecting it to generate some html (or something)
report of what verification it could generate or any analysis. It just says
yes/no. Which test case shall I run to see what output(and where) is being
generated by the current "verification" code.
Also, the input file "Misc3.drl" is present in more than 1 place and I am
not sure where does the test case pick it from.
Thanks
Siddharth
On Tue, Oct 7, 2008 at 2:46 PM, Toni Rikkola <trikkola at redhat.com> wrote:
> Hi
>
> Yes, the Verifier.java is the main class. At the moment
> TextConsequence.java and Consequence.java are the only classes that handle
> the RHS. Verifier uses these in the drl-files, but it just does a simple
> string comparison.
>
> Verify objects (classes that extend VerifierComponent) contain data about
> the relations that they have. Each object is given an id and this id is used
> to indicate the relations. Each object also knows the rule name and rule id
> that it belongs to. Patterns have object type id's and Restrictions have
> field id's, with this information you can find out where object types or
> fields are used. All this information is stored in VerifierDataMaps and to
> get for example all the restrictions that use certain field you need to know
> the field id and call getRestrictionsByFieldId(int fieldId) or do this
> search in verifier rules where the same objects are as facts.
>
> The verifier executes in three phases.
>
> First phase finds the dependencies. Which field belongs to which object
> type and what rules contain what object types and flattens the AST so that
> it can be more easily used in the verifying rules. This phase also finds out
> the different possibilities that can satisfy patterns and rules. Main class
> for this phase is PackageDescrFlattener, it stores the data to VerifierData.
>
> The second phase is done with drools rules. It uses flattened AST and
> dependency facts to solve object relationships and find issues.
> Relationships that are found here are overlaps/partial redundancies,
> redundancies, incompatibilities and opposites. These can happen between
> rules, patterns or restrictions. Issues are stored using VerifierResult
> class.
>
> Third phase just takes the conclusions from working memory and reports them
> in the format that you want.
>
> Toni
>
> 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.
>>
>> 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
>>
>>
>
> _______________________________________________
> 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/20081010/4e2a7f87/attachment.html
More information about the rules-dev
mailing list