I'd recommend starting with an UML class diagram of your domain objects,
before thinking about the rules that apply on them.
In my use cases I've found that it's a lot easier to write rules on a
good, normalized domain model.
Michael Neale wrote, On 2006-11-17 10:07 AM:
There isn't a common methodology yet.
It often comes down to syle/preferences. Just like with code, I prefer
Test Driven approaches and iterations, others prefer a bottom up
modelling approach.
The common theme is that the model that the rules use needs to be pretty
sound, both in terms of the problem domain but also not to
complicated/nested that it makes the rules hard to write and read.
On 11/16/06, *Anea* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Is there a common methodology for the development of rules?
In the "classic" programmimg, you don´t start directly with coding, you
start with the design of your project.
You build your class diagramms, use case model, workflow diagrams
and so on.
If I plan to include a rules engine into my project, I will surely
start the
same way, but how exactly do rules (discovery, vocabulary
definition, ...)
fit into this development step?
--
View this message in context:
http://www.nabble.com/Rules-Development-tf2642794.html#a7377142
Sent from the drools - user mailing list archive at Nabble.com
<http://Nabble.com>.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
<http://xircles.codehaus.org/manage_email>
--
With kind regards,
Geoffrey De Smet
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
