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@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@redhat.com
   <mailto:trikkola@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@codehaus.org <mailto:mproctor@codehaus.org>
               <mailto:mproctor@codehaus.org

               <mailto:mproctor@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@lists.jboss.org
               <mailto:rules-dev@lists.jboss.org>
               <mailto:rules-dev@lists.jboss.org
               <mailto:rules-dev@lists.jboss.org>>

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


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

               _______________________________________________
               rules-dev mailing list
               rules-dev@lists.jboss.org
               <mailto:rules-dev@lists.jboss.org>
               https://lists.jboss.org/mailman/listinfo/rules-dev
               

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



           _______________________________________________
           rules-dev mailing list
           rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
           https://lists.jboss.org/mailman/listinfo/rules-dev
           

       _______________________________________________
       rules-dev mailing list
       rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
       https://lists.jboss.org/mailman/listinfo/rules-dev



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

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
 

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev