[rules-dev] refactoring drools

[Wolfgang Laun]

Hi Franz,

just a few thoughts...

"Design" in connection with rule-based systems has several flavours. Some of
the terms I'm going to use here are not well-established, so I'll use quotes
to mark them. All of this is off-the-cuff, and certainly sketchy.

There is the "large-scale design" of a RB application. This is where you
decide about

   - fact types, i.e., the type of ontology you'd like to use (if not Pojos)

   - the kind of session: stateful (truly a production system) or stateless
   (basically just derivative, no fact updates).
   - data flow: how and when to insert facts, how and when to extract
   results
   - architecture of the embedding (Java) application
   - whether to use CEP
   - ...

Then there is "rule design patterns", something that's akin to rule
programming techniques, mostly decisions about

   - when and how to use "auxiliary facts",
   - how to use or not use salience (i.e., rule priority)
   - how to order patterns within a rule,
   - when to use FOP quantifiers or more sophisticated CEs (e.g. accumulate)
   - whether to flatten lists into facts or leave them as a complex
   attribute,
   - whether to go for a DSL
   - whether to use decision tables
   - ...

On a level in between, you have rule grouping:

   - agenda groups
   - activation groups
   - rule flow
   - iterating rule engine activations
   - ...

Sometimes it's possible to delay decisions. For instance, you may not know
whether it's better to have many rules in a few basic patterns with
distinguising data embedded in them, or to have only a few rules,
interpreting the equivalent data contained in static "parameter facts".
Here, you could start out with a data representation, and you might decide
to create rules later on. (See "templates" in Drools "Expert". And the
ongoing discussion in an active thread.)

Rules as in Drools or similar systems are simple program structures; the
essential part (left hand side) is just a boolean expression. A functionally
equivalent engine for the basic CEs would be rather easy to write *if you
use the naive approach* (i.e., not implement a Rete). Whether rule
extension, as implemented in Drools, is a useful feature still remains to be
seen.

Refactoring of rules is difficult, since they tend to interact in a highly
intricate way, especially in production systems. Occasionally you can
refactor by reducing the number of rules, replacing similar rules with a
more general one that incorporates equivalent processing logic as data. For
instance, if you have several rules implementing binary operations (think of
the elementary algebraic or logic operators), you can factor them into a
single BinOp rule where the actual operation is an attribute of the fact
representing the operation, implemented - depending on your RBS - as a
lambda, or a function pointer, or a method of an object of some subclass.
(If this is too hazy, you can ask me for an example.)

-W


On Fri, Apr 9, 2010 at 1:41 PM, Franz Schwab <franz.schwab at gmx.net> wrote:

> Hi,
>
> I forgot to post the links I already found:
> http://community.jboss.org/wiki/RefactoringRules
> http://vimeo.com/5157458
> But this is very Eclipse-specific. The problem is:
> How do you change the design of a big rule based system if the demands
> to it changed? Which common practices do exist?
> What do you do with code smells, e.g. duplicate rules.
> The answers to the rest of your questions:
>
> Am 09.04.2010 07:02, schrieb Wolfgang Laun:
> > On Fri, Apr 9, 2010 at 1:21 AM, Franz Schwab<franz.schwab at gmx.net>
>  wrote:
> >
> >> Hi,
> >> I'm a computer science student and am writing the related-work part for
> >> my diploma thesis and would be interested in (scientific) papers or
> >> information about refactoring or transformation possibilities which can
> >>
> > Could you please be more specific? I have heard the term "refactoring"
> > in connection with certain modifications of a (Java) source program.
> > Is that the idea?
> >
> > And "transformation" can be almost anything that produces a B from an
> A...
> >
> http://en.wikipedia.org/wiki/Code_refactoring
> >
> >> be done with drools / jboss rules in order to improve design of a
> >> knowledge base
> >>
> > How do you define "knowledge base"? Does this mean that you have a
> measure
> > for the quality of KBs?
> >
> Lets say a rule "based system" instead of "knowledge base" in the terms
> of drools.
>
> >   or simply to delete bad smells.
> >
> http://en.wikipedia.org/wiki/Code_smell
> > ?? If I were inclined to be funny, I'd say you start by opening a window;
> but so
> > I just ask you to be more specific.
> >
> No, window is already opened :-)
>
> Thanks, Franz
> > -W
> >
> >   I have to admit that I
> >
> >> never worked with drools, as I said I just need that for the
> >> related-work part.
> >> Could you please give me some hints?
> >> Thanks,
> >> Franz
> >> _______________________________________________
> >> 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100409/7ddb6d7d/attachment.html