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: http://en.wikipedia.org/wiki/Code_refactoring Lets say a rule "based system" instead of "knowledge base" in the terms of drools. http://en.wikipedia.org/wiki/Code_smell No, window is already opened :-) Thanks, Franz

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(a)gmx.net&gt; wrote: