By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Translating requirements into design
How to describe business rules
Every business operates on the basis of business rules. If we tried to analyze how many business rules we found in one particular company, our count would go into the thousands. Yet, in analysis and design we still pay too little attention to business rules.
From a global viewpoint, business rules are the fundamental policies and constraints in the business. They are statements that are intended to control or influence the behavior of the business. By the OMG definition, a business rule is "declarations of policy or conditions that must be satisfied".
We are quick to accept that business rules need to be identified and captured early during business process modeling. When we are doing business process modeling or business process reengineering we talk about business rules in quite a natural way. We "only" need to write them down which, however, is not so easy.
If we assumed for a moment that we did it, we were able to use the gained knowledge for use case modeling. We could reference business rules in our requirements package for the use case. Business rules are never "owned" by a use case, since a business rule might be implemented by more than one use case.
On the other hand, a business rule might well be incorporated in a use case. If we take a particular point of view and think of a business rule as a link between a certain object state, a condition and an action, the action statement might well translate into a use case. For example, the business rule "if a product is classified as export-restricted, then the explicit approval of government authorities must be obtained in every single case" would result in a use case "obtain government approval" which in turn might even need to be broken down further into more use cases.
Business rules can also have a more static nature. Integrity rules are good examples for this. For example, the integrity rule "every order must contain at least one order item" reflects a static business rule. Integrity rules do not normally translate into a use case but are interpreted later when classes and class diagrams are modeled.
At this time, we have not made any statement about the implementation of business rules. This, however, is a major concern. Shall we hardwire business rules into our application code?
Separation from the application
The separation of business rules from presentation, application and data access logic may well be considered a major trend. Business rules keep changing continuously at the policy level, i.e. managers act and react to internal and external conditions. At the software level, however, we always face the problem of falling behind with changing business rules in the software. Also, we are hard pressed to ensure consistency of the implementation of business rules across the enterprise. The same business rule may be implemented in multiple applications.
Consequently, failing to separate business rules from the application must be considered a major an unforgivable design error. We must never deprive a business of the capability to change business rules at any time while maintaining consistency across applications.
The question is: how can we express business rules in some formal way? At that point, we run into various problems. Business people use natural language, such as "if the customer reported more than 2 accidents in the past 3 years and the damage exceeds $5,000 then further investigation needs to be done as to whether the claim might be fraudulent" or "if a customer is in default with payments for more than 10 days then a statement is sent with $5 added as overdue fine". For example, if we tried to use Object Constraint Language (OCL) we would face difficulties as this language is based on first-order predicate logic. This kind of language is alien to business people.
An XML-based approach
Also, in this case XML can help us to express business rules as knowledge representation. As a meta-language, XML allows us to create new languages (i.e. vocabularies). IBM Corp. developed a markup-language for expressing business rules, called "Business rules markup language" (BRML). Although BRML is also based on first-order logic the language is much better understandable to business people. Also, we are on a higher level. However, this does not mean that OCL is of no use any more. Of course, we still need OCL, but that comes later in the design process.
BRML is still at an early stage in development. So far, to our knowledge BRML has not been submitted to W3C. However, things look quite promising and there are many advantages to using an XML based approach.
To summing up, we benefit a lot from capturing business rules early and expressing them in some formal language. We can use business rules to validate our use case model. Also, we can embed "calls" to the business rule interpreter into our application logic (and data access logic, presentation access logic, if applicable). Can we use business rules to generate test case scenarios for system test and for unit test? Yes, we can! To do this, we need a tool that interprets our XML file and generates test scripts. Although we were to develop such a tool in-house it definitely would save a lot of money in the end.
Not all questions are answered, though. One of these remaining questions is: how can we validate syntactic restrictions? XML parsers can only validate with respect to a DTD or a schema but cannot check syntactic restrictions that go beyond what can be checked by an XML parser. However, that should not keep us from going into this direction.
Copyright 2002 Jenz & Partner GmbH. Jenz & Partner is a technically-oriented analyst and consulting firm. We help our customers understand market and technology trends, particularly in the Business Process Integration space, by providing in-depth research and analysis on strategies and technologies.
For More Information:
- For insightful opinion and commentary, read our Guest Commentary columns.
- Tired of technospeak? The Web Services Advisor column provides a clear understanding of Web services.
- Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
- Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
- Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.