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

Tue Jun 16 20:03:39 EDT 2009

james is having problems, so thought I'd forward for him.

Mark
>> *From: *James Owen <jco2009 at att.net <mailto:jco2009 at att.net>>
>> *Date: *June 16, 2009 6:11:52 PM CDT
>> *To: *Rules Dev List <rules-dev at lists.jboss.org 
>> <mailto:rules-dev at 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 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
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20090617/181f1c65/attachment.html 