Tuesday, 27 March 2007
Friday, 2 March 2007
Wednesday, 7 February 2007
Tuesday, 30 January 2007
Thursday, 18 January 2007
Agile Software Development and Rules Engines
In the wonderful book ‘User Stories Applied’ of Mike Cohn he defines these characteristics of a user story:
- Independent
- Negotiable
- Valuable to users or customers
- Estimable
- Small
- Testable
To demonstrate a way of improving quality vs. quantity in communicating what needs to be done, agile methodologies (re)invented acceptance tests. Instead of making the customer describe what he wants you ask him: “how will I know that what I did is according to what you want?” And he will start saying what needs to be done to be able to know if what was requested was build and finished or not. Instead of heavy descriptions, two purposes are achieved: you know how you can test and what needs to be done at the same time. Also, ambiguity tends to be dissolved by acceptance tests, because a man in order to know how to test something he must have a very intimate knowledge and understanding of that thing.
http://www.infoq.com/articles/Rule-Engines
Relinquish Flow Control
Allowing the rule engine to determine which rules to run and when is an important step in making use of the full power of a rule engine. Developers who are used to having control over the execution of their business logic may find this transition troublesome, but once you've grown accustomed to this way of working, you're likely to find that it offers a fair amount of power.
Many rule engines allow the process of selecting and ordering rules to be influenced. Drools offers an array of conflict resolution strategies and rule attributes such as salience and agenda groups to control them. These kinds of options allow you to leave overall flow control to the rules but exert whatever control is necessary to fulfil your business logic or to tune approach the rule engine adopts.
Rules as Procedural Code
If you've done a fair amount of procedural programming, switching over to a rule-oriented model of development can be a little disorienting. You're likely to slip into familiar development patterns for procedural development and ask questions like:
How do I run only one rule?
Can I list the rules I want to run, in order?
It's important to realize that it's possible to do these things, but it's not always advisable. For instance, in Drools, you can control which rules are run by using activation filters, and you can control the order using conflict resolution. Resist these options: sometimes they are necessary, but it's easy to reach for these controls too soon as a knee-jerk reaction to old procedural paradigms.