Re: Fwd: [rules-dev] Debugging, Tracing and Visualization of rule execution

> *From: *James Owen <jco2009(a)att.net <mailto:jco2009@att.net>> > *Date: *June 16, 2009 6:11:52 PM CDT > *To: *Rules Dev List <rules-dev(a)lists.jboss.org > <mailto:rules-dev@lists.jboss.org>> > *Subject: **Re: [rules-dev] Debugging, Tracing and Visualization of > rule execution* > > > Greetings: > > Just a word and I'm not sure how to implement this: In OPSJ Dr. > Forgy implemented "flagged" IF conditional statements such as (pseudo > code) > > Rule_1 > IF > [f1] something1 happens > [f2] something2 happens > [f3] something3 happens > THEN > do something > ELSE [f1] fails > report why or do something > ELSE [f2] fails > report why or do something > ELSE [f3] fails > report why or do something > ELSE > do the EHS of the rule > > This is pretty much what he calls "syntatic sugar" that you can > program in the code each time. BUT, he made it so the programmer > could easily check a rule (or all of them of so desired) to see why > it failed. I used it with great success on a couple of projects and > really, really miss it when programming in any other rulebased system. > > Also, this is part of the very thing that Edson was complaining about > and I call a programmer's Beta-1 Error problem. It didn't fire when > it should have fired - so why didn't it? This would help immensely. > Surely, if one old man working in his 3rd floor attic in Pittsburgh, > PA, can implement this in his rulebase in just a couple of days (I > was there when he did it back in 1998), a whole cadre of experienced > Java programmers can implement it a world-class rulebase, right? > > SDG > jco > "This above all: to thine own self be true, > And it must follow, as the night the day, > Thou canst not then be false to any man." > Hamlet, Act 1, Scene III > http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html > > > > > On Jun 16, 2009, at 5:29 PM, Mark Proctor wrote: > >> Daniel Gebler wrote: >>> For our integration of Drools 5.0 we want to provide end users with >>> limited technical skills the possibility to debug, trace and >>> visualize the rule execution as well as the fact base. >>> >>> Questions that are frequently asked by users as well as by the >>> development/qa team: >>> - Did my rule r1 fire for this query? >>> - Why did rule r1 not fire (i.e. which constraint doesn’t >>> match)? >>> - Which kind of rule dependencies (chaining) do I have in >>> my rule base? Rule r1 and r2 are dependent iff action of r1 (e.g. >>> publish a fact) makes constraint of r2 true. >>> - Which rules need to fire in order to generate the >>> additional fact f1 in the fact base? >>> - What is the smallest change in the fact base (additional >>> facts etc.) in order to make rule r1 to fire (abduction)? >>> >>> Problems: >>> - Eclipse plugin doesn’t provide information of what >>> didn’t happen and why it didn’t happen ( ‘Audit’ view allows just >>> tracking of positive cases, i.e. what happened). Furthermore the >>> stability of the eclipse plugin seems to be limited. >>> - Integrating over SPI doesn’t allow to show the Rete >>> network because Rete view works only with drl files >>> - How to provide feedback to a normal end user of the >>> search server (limited tech skills) about rule-related information? >>> >>> Solution ideas/approaches + our assessment: >>> 1. Use a run time monitor providing on-demand log trace >>> information when facts are being published. The log trace provides >>> the information about which and why a particular constraint is or >>> is not satisfied. Our initial implementation uses an aspect >>> oriented approach (JBoss AOP) to gather relevant information. In >>> detail: Our initial implementation uses an aspect oriented approach >>> (JBoss AOP) to gather the information by intercepting >>> EntryPointNode.assertObject(), and traversing the rete network to >>> collect the constraint information for every unique alpha/join >>> node. This will allow to visualize the log trace (GUI) and >>> interpret the trace in the context of our product. We discussed >>> this approached in #drools with Edson Tirelli and he was very >>> interested. >>> 2. Use drools AgendaEventListener. Listener does not gets >>> enough debug info exposed, esp. we cannot extract the cause to >>> reject a rule. Not enough information available therefore this one >>> is not an option. >>> >>> Additionally, it would be nice for our development to also >>> visualize the Rete-OO network, but that seems to be impossible when >>> integrating drools directly via the SPI classes. Is there a way to >>> connect the viewer to a network inside a running VM? >> Constructing against the SPI instead of using DRL, you are scaring >> me now? >> >> Mark >>> >>> We would like to hear whether you know any other opinions, or have >>> points how to implement those features. Please share your >>> experience how to bridge the gap between end-users with limited >>> technical backgrounds expressing and investigating the rule inference. >>> >>> Thanks, >>> Daniel >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev > > >