Object rules are the primary type of rule with which we have to concern ourselves. They include everything we can say about the “stuff” in our system. Database people would call these entities; OO people would call them classes. “Stuff” is the best generalization that I can come up with.
Object rules are inherent in the nature of the object, but do not include those that are UI-specific. The structure of these objects is more or less an ERD or class model, but not exactly.
Going back to my post of a few days ago, the most important thing to keep in mind is that this is NOT a simple data model. It describes the business rules of the structure of the objects of interest. The objects themselves with their associations and their attributes look very ERD-like. But I also think that generalization should be included as part of our grammar as well as display functions for the objects and other derived attributes (that do not fit nicely into an ERD type of grammar).
For our grammar, we use UML class diagrams. The project that got us started on this road was a large computer retailer that needed to support generalization in their business. “We sell computers. These computers have a structure, but laptops and desktops have a slightly different structure. We want to be able to think about our business in an OO kind of way.” So, we started inventing a grammar that would allow us to describe these kinds of relationships. I had recently published Oracle8 Design Using UML Object Modeling for Oracle Press, so I was familiar with UML class diagrams as a data modeling tool. Even though we were not data modeling, we were creating a business rules model so I started to see the similarities between our grammar and UML class diagrams. I thought that we could adapt UML class diagrams for our purpose. It turned out that they worked pretty well.
In our first implementation, we did not even generate each class to a table. We generated to several generic structures: people, locations, organizations, products, etc. When we had trouble getting good performance out of the generated systems, we changed to a “one table for each class” generation algorithm. This is an important point since we completely changed what we did with the structural rules without changing the rules grammar. When you look at the current BRIM® object generation algorithm, it would be easy to think that we started with an ERD way of thinking and evolved it a bit. Instead, we started out miles from ERD thinking and only evolved into a “ERD-ish” kind of tool after a long road and many iterations.
Process rules were actually the first part of the BRIM® architecture to be invented. The project was a tax collection agency. They had lots of documents, each with its own process flow. We needed a generic way to define the documents (structure) as well as this workflow (process). The workflow was actually the more interesting part since the document structure was pretty simple. This was where we came up with a process engine.
The big idea related to process rules was that they were not an independent thing. The process was tied to a document. Most OO process tools implement processes as independent things (mostly with a UI flavor) which then interact with objects. In my way of thinking, process is tied to objects so objects go though states. An object is always in exactly in one state. This allows you to intelligently divorce object process from the UI.
Data validation rules were created to support the US military security clearance form (the SF86) web service. There are thousands of rules associated with this service. There are hundreds of rules that are quite complex, many of them spanning multiple objects. For example: “If your marital status is divorced, then you must have one or more former spouse records.”
It is easy to think that the three flavors of object rules (structure, process, data validation) compose a partitioning of the rules themselves. That is not true. These three types require three different articulation mechanisms. An individual rule can frequently be articulated using more than one mechanism. A trivial example might be the following: “Last name must only include letters.” This could be articulated in the structure as a field mask; it could be articulated in the process as a validation rule when the object is being validated; or it could be a data validation rule. You could even implement this in the UI layer as a UI rule (but that would not be very smart). In this case, the rule should most logically be represented as a structural rule, but there are other examples that are far less obvious. I will write a separate blog post about one of these more complex examples.
Leave a Reply