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 <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> 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
                <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
                <mailto:[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]>
                <mailto:[email protected]
                <mailto:[email protected]>>

                   https://lists.jboss.org/mailman/listinfo/rules-dev


                
------------------------------------------------------------------------

                _______________________________________________
                rules-dev mailing list
                [email protected]
                <mailto:[email protected]>
                https://lists.jboss.org/mailman/listinfo/rules-dev

            
------------------------------------------------------------------------



            _______________________________________________
            rules-dev mailing list
            [email protected] <mailto:[email protected]>
            https://lists.jboss.org/mailman/listinfo/rules-dev

        _______________________________________________
        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

Reply via email to