A business rule is an operating principle or policy that your software must satisfy. Every organization has its own set of business rules–rules that must be reflected in the software it develops. The object-oriented paradigm is arguably the leading approach to software development; one only has to look at the popularity of object-oriented languages such as Java and C++ or object-based languages such as Visual Basic to see that this is true.
So how do business rules fit into the object-oriented approach to developing software? My experience is that regardless of the development paradigm, business rules are a major aspect of requirements, modeling, programming and testing. Rules often focus on access-control issues. For example, university professors are allowed to input and modify the marks of the students taking their seminars but not the marks of students in other seminars. Business rules may also pertain to business calculations, such as how to convert a percentage mark (say, 76 percent) that a student receives in a seminar into a letter grade (A-). Some business rules focus on the policies of an organization; perhaps a university expels a student when he or she fails more than two courses in the same semester.
The Template
How do you describe a business rule? Figure 1 presents a fully documented version. A business rule should have a unique identifier; my convention is to use the format of BR#, but your organization is free to set its own numbering approach. The unique identifier enables someone to easily refer to business rules in other development artifacts, such as class models and use cases, supporting traceability throughout the development artifacts ("Trace Your Design", Apr. 1999). Notice how the name offers a good idea about the topic of the business rule and how the description exactly defines the rule.
| Figure 1. A Sample Business Rule Template
|
An example of the rule is presented here to help clarify it, and the source of the rule is indicated so that it may be verified (the source of a rule is commonly a person, very often one of your subject-matter experts, or a team of people). A list of related business rules, if any, is provided to support traceability among rules. A revision history of the business rule indicates the date that a change was made, the person who made the change and a description of the change.
Activity Diagrams
You may also decide to use a Unified Modeling Language (UML) Activity Diagram to document the logic of a complex business rule. Activity diagrams are typically used for two main purposes: to describe the high-level logic of a business process in a similar vein to data-flow diagrams (DFDs) of the 1970s and 1980s, or to document the detailed logic of a business rule or operation in a manner reminiscent of flowcharts (also popularized during the 1970s). Both DFDs and flowcharts are described in Chris Ganes and Trish Sarson’s Structured System Analysis: Tools and Techniques (Prentice Hall, 1979). I suspect that BR12, referenced in Figure 1, which describes the logic to determine how a professor qualifies for tenure, is sufficiently complex to require a diagram to fully describe it (I’m not a professor, so I don’t know if this is actually true).
A good business rule is cohesive, describing only one concept. For example, the rule described in Figure 1 only refers to the fact that tenured professors can input marks; it doesn’t discuss what it is to be a tenured professor, when marks need to be entered, or what types of marks should be entered; this is left for other business rules. By ensuring that business rules are cohesive, you make them easier to define and increase the likelihood that they will be reused (every time one of your artifacts refers to a business rule, even other business rules, it is effectively being reused). Unfortunately, because business rules should focus on one issue, you often identify a plethora of rules.
Business rules are identified during the normal course of requirements gathering and object-oriented analysis. For example, when you are use-case and domain modeling, you will often identify business rules. Use-case models document the behavioral (functional) requirements, and domain models document the major business concepts and their relationships pertinent to a system. Figure 2 indicates that both use-case models and class models–which are used in object-oriented development for domain modeling–refer to business rules in their text. It is necessary to separate business rules from other development artifacts, because it is likely they will be referred to by the other artifacts several times.
| Figure 2. How Business Rules Fit In
Both use-case models and class models—which are used in object-oriented development for doamin modeling—refer to business rules in their text. |
For example, BR123 of Figure 1 could be referenced by a "Record Student Marks" use case, one or more classes in your class model that implement this behavior and in the documentation of the source code itself for those classes.
How Rules Fit In
During analysis, your goal is to flesh out the business rules identified during requirements gathering, which often reorganizes high-level rules into collections of cohesive, single-purpose rules. As user interface prototypes are developed, you are likely to identify simple business rules while modeling the system’s screens and reports. For example, a university may have a seminar information screen displaying the number of seats available in the seminar, the number of people enrolled in the seminar and the number of people in the waiting list for the seminar. As you model this screen, you are likely to identify business rules pertaining to the minimum number of students needed for the seminar to be held, the maximum number of students who may be put on a waiting list, and the minimum number of students on the waiting list needed before the seminar should be split into two sections.
During analysis, you are also likely to identify data cleansing and validation rules, particularly if the system needs to integrate with external systems. System integration, already a complex task, is even more difficult if the integration is accomplished via data sharing (as opposed to integration via a well-defined application programming interface). The problem with data sharing strategies–typically file transmission or shared data stores–is that they have often been in use for a long time, and their data designs will have degraded. It is common to see data designs that need to have the values of several columns combined to obtain the required information. For example, consider the following data cleansing rule: "If the value of column A is ‘AD,’ and the value of column G is ‘T,’ then column D represents the date that the student was first admitted to the university." You will also identify data validation rules like "The value of column D must be a date and must be less than or equal to the date stored in column H." Identifying and verifying these types of rules is an important and often difficult part of your analysis efforts.
Business rules are also pertinent to your object-oriented design efforts. As shown in Figure 2, business rules will often define triggers in your UML State Chart diagrams. State chart diagrams are used to model the life cycles of objects, depicting the various states the object may go through in addition to the potential transitions between those states. For example, the life cycle of a seminar object may include states such as proposed, open for enrollment, full, active, canceled, closed to enrollment and completed. There could also be transitions between these states; for example, one transition could be that a seminar becomes scheduled, moving it from the proposed state to the open-for-enrollment state. There would potentially be several business rules pertaining to the scheduling of a seminar; perhaps a seminar needs a location and an instructor assigned to it before it can be added to the official university schedule.
Defining Transactional Logic
Because business rules define some of the fundamental transactional logic that a system must support–logic that is implemented by objects–you will find that business rules drive the identification of collaborations between objects, collaborations that are documented on your UML Collaboration Diagrams and UML Sequence Diagrams.
For example, the business rule described in Figure 1 would require collaborations with the Professor object to determine if it has tenure, with the Seminar object to determine if the Professor object is actually the instructor for it, and again with the Seminar object to determine if it is active (if it is currently being taught). These collaborations could be modeled on either a collaboration diagram or a sequence diagram.
Documenting Your Design
How are business rules indicated within the object-oriented models? The Object Constraint Language (OCL) is a formal language, similar to structured English, to express side effect-free constraints within UML models. OCL can be used for a variety of purposes, including specifying the invariants of classes, pre- and post-conditions on operations and constraints on operations. A graphical model, such as a UML class diagram, is not sufficient for a precise specification. You must describe additional constraints about the objects in the model, constraints that are defined by the business rules. Although business rules are initially described in language that users understand (see Figure 1), experience shows that natural language often results in ambiguities, which in turn lead to defects in software. Hence the need for OCL.
An important aspect of OCL is that it is not a programming language–it is a modeling language. You use it to document your object design and a language such as Java or C++ to implement it. OCL can appear on any UML diagram or in the supporting documentation describing a diagram. I highly suggest reading the book The Object Constraint Language: Precise Modeling With UMLV by Jos Warner and Anneke Kleppe (Addison Wesley Longman, 1999).
As with all requirements and modeling artifacts, business rules will drive some of your test cases. To test the business rule in Figure 1, you would need test cases verifying that the instructor of a seminar could administer marks, that someone who isn’t the instructor couldn’t administer the marks, and that the marks may only be administered with the seminar is active. I suggest reading my book The Object Primer 2nd Edition (SIGS Books/Cambridge University Press, 1995).
There are several strategies for implementing business rules using object-oriented technology. First, simple business rules are often operations in your classes. For example, each of the data-cleansing rules described above could be an operation of the class responsible for processing the pertinent data file. Second, complex business rules are often implemented as a class or component; for example, a class named TenureDeterminer could be developed to implement the business rule of Figure 1. Third, you may decide to implement all of your business rules in a rules engine, such as Platinum’s Aion or Neuron Data’s Blaze, which is then accessed as needed by the object code.
The first two strategies represent standard object-oriented approaches to implementing business rules, and they work well for simple systems. The third one offers the benefit of implementing business rules in one place–the rules engine–making them easier to maintain and enhance. The drawback of rules engines is that they are complex and often require developers to have significant expertise in artificial intelligence.
