[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