Re-Usability in the Business Rule Approach

by Ronald G. Ross

This column originally appeared in the Sep./Oct. 1996 issue of the Data Base Newsletter.

The object community touts re-usability as a major benefit of object orientation (OO). I believe the business rule approach can produce re-usability on a far greater scale. Let me explain.

Re-usability means various things in OO. For example, an object class can (should) be formed such that the services (methods) it provides can be invoked (i.e., re-used) by many other object classes. This corresponds roughly to the traditional notion of modularity in software engineering.

A more specific interpretation of re-usability in OO is that an operation (method) defined for a supertype automatically is inherited by all subtypes. This enables re-use. Actually, the real focus, however, is on revisability. For example, the operation named 'pay salary' for Employee can be revised to 'work' differently for the subtype Manager. All other object classes (potential 'users' of the operation), however, are shielded from the distinction.

These are good ideas, but fundamentally they are about software re-usability. Can the business rule approach potentially incorporate them? Yes (plus inheritance and revisability for rules). Does the business rule approach potentially offer more? Yes -- far more. Here's how.

In the business rule approach, rules must be segregated from procedures. (This is one aspect of what I call 'rule independence.') Followed rigorously, this produces procedures (I call them 'scripts' -- OO might call them 'use cases') that are nothing more than simple series of requests (a.k.a. 'thin processes'). An implication is that procedures become 'cheap' -- in effect, throw-away. That's exactly what businesses need these days to become more adaptive.

In this environment, rules provide the boundary between procedures for normal business activity and procedures for abnormal business activity (a.k.a. rule violation activity). Here's how that happens. When a procedure (script) for normal business activity fires a rule, a violation may be detected. If so, a procedure (script) to handle it can be invoked automatically. That offers the user the opportunity to correct the violation -- for example, to create, update, or delete the data that caused the violation in the first place.

Re-usability arises as follows. Ideally, the invoked procedure (script) should be the one that in other circumstances would be used for the normal business activity involving that data. In other words, entire procedures -- the ones the users should know already -- can be re-used. As far as I know, OO has no equivalent concept. And without rules, I doubt one can be found.

standard citation for this article:

Ronald G. Ross, "Re-Usability in the Business Rule Approach," Data Base Newsletter, Vol. 24, No. 5 (Sep./Oct. 1996), URL: http://www.BRCommunity.com/a1996/a507.html.