[rules-dev] Rule Dependency Generator
Toni Rikkola
trikkola at redhat.com
Sat Oct 11 05:44:07 EDT 2008
Take a look at VerifierTestStandalone. I used it for testing and it is
an example of how the verifier can be used.
The Misc3.drl file that is in drools-verifier
src/test/resources/org/drools/verifier is the one that tests in
drools-verifier use. The same file exists in drools-ant, but it is used
to test the verifier ant task
Toni
Siddharth Angrish wrote:
> 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
> <mailto: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>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>
> <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>
> <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>
> <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
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
More information about the rules-dev
mailing list