Business Rules & UML

[Kiwilee]

We are attempting to create a list of all our business rules.  At a latter date the aim is to drop these into a business rules engine.

Does anyone have any suggestions on how UML could be used to capture and document these business rules, and what part EA could play in this.

[CJ]

G'day,

I'm still learning UML, and EA, and haven't gotten around to modeling business rules.  I'll throw some ideas out there anyway.

You could model your business rules as constraints (and create an new type of constraint called BR or Business Rule).  In your domain model, your BR's would be internal to the classes.  If you have a constraint that is common amongst many classes, then put the contraint in a class that is inherited by all that share the constraint.

Although I've read that business rules should not be modelled as software requirements, I'd still consider using the requirement element (and create a new type of requirement called BR or Business Rule).  This would allow you to externalize a business rule, link it to whatever other element you want however you want, and take advantage of the relationship matrix and anything else that applies to elements.

Hope that generates some ideas.

[thomaskilian]

Hi Kiwilee,
like Jason I'm still learning UML and EA. However, Jasons approach appears to me to have a very technical odor. When starting with business modelling you do not have classes in the beginning. They are a result of the business modeling process. So I would start taking requirements, arranging them according to functional and non functional requirements. Requirements should be traced to stakeholders so you know how placed a requirement. Now you start modelling use cases and have to make <<realize>> associations from all requirements to the related use cases. Having done that you are ready to start modeling classes. At that point you can go on and attach requirements to your classes, but at this stage the requirements have more technical than business aspects. I can recommend to read Use Case Modeling by Bittner/Spence which helped me understanding Business Modeling with UML very much.

The above process is some kind of engine. So I wonder what kind of engine you would like to use and for what purpose?

[Bruno.Cossi]

Hi,

Problem is in what you consider to be a business rule. Jason's approach would work if a rule were but a validation, then it certainly could be modelled as a constraint. Generally though, business rules is defined as any piece of knowledge a business has about itself. (see Business Rules Group, www.brgroup.com) By that definition, your whole UML model represents your business rules.
Now, if you are looking at using a rules engine, the business rules you are looking at are likely validations, calculations etc. You are probably using a rules engine to keep the business rules in one place, where you can easily manage them, switch them on/off or make them conditional. (Am I wrong?). Rules engine is really nothing else but a technical environment, a way to implement the business rules you have modelled in your UML model. The fact that you will implement your rules using a rules engine should not impact the way you build the model itself.

What I would do (and what we actually do) is to use Thomas' approach and externalize business rules into external requirements of the type "Business Rule" or potentially create a new stereotype <<business rule>>. Then I would use these to capture the business rules that you are likely to end up putting into a rules engine. Thus, you would visibly separate the rules (which in a typical business change fairly frequently) from the system related requirements (which, after implementation, remain relatively stable).

Reading this after myself, I am not sure if I am making any sense. Hope this helps, anyway :-)

Bruno

[CJ]

G'day,

Can't comment on the process of business modeling, but can throw a couple of extra ideas on how to document business rules in EA.  Maybe blasphemous ideas, but what the heck.

Use "class" elements, stereotyped as "Business Rule".  If you have such a need,  you can then have attributes, operations, requirements, and constraints that apply to the business rules.  You can build a hierarchy of business rules, and link those business rules to any other artifact in your project.

Look into the "Import/Export CSV" feature in EA.  (Under the "Project", "Import/Export" menus.)  It might be useful when dropping your rules "into a business rules engine".

[sargasso]

I am going to go out on a limb here!  

The question I have for Kiwilee is : Do you have a metamodel for your business rules?

As you want to "later" drop these into an engine, do you have an idea of what structure the engine is to support?

There are several different (read competing)"ways" of specifying BR's.  Without having looked in detail at any BR engines I would expect that they all have different requirements in terms of how the rules are specified.

try {
   http://www.brcommunity.com/

   http://members.ozemail.com.au/~ieinfo/index.htm
}

catch {
   Well and truly confused yet?;  
}

While, your organization may be eager to commence capturing the rules, I would suggest you get the metamodel defined first to aviod some severe dissappointment later when "drop these into an engine" becomes a larger issue than expected.

hth
Bruce

[thomaskilian]

Bruno,

(see Business Rules Group www.brgroup.com)

is actually for sale   Can you put the right link here please?

[Bruno.Cossi]

Hi Thomas,

ouch! And I would have sworn the link worked couple weeks ago! Maybe not... :-)
Here is one that works:

http://www.businessrulesgroup.org/brghome.htm

Bruno

[thomaskilian]

Hi Bruno,
thanks a lot for the reference . I was not aware of that aspect.