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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[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]>>
<mailto:[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]>>
<mailto:[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]>
<mailto:[email protected]
<mailto:[email protected]>>
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
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]>
<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]
https://lists.jboss.org/mailman/listinfo/rules-dev
