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@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@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev