Every one of us is born into infancy. We move through our childhood, into adolescence, and then we eventually graduate into adulthood.  This is part of our life-cycle.

Entities also have life-cycles, and the best way to express the business rules for the life-cycle of an entity is by drawing out a state model (a.k.a state machine model).

In the first part of this series,  I made my case for why you should learn business rules. I also introduced the Entity Relation Diagram (ERD) as an effective way of expressing the business rules that will tell the developer how the entities are related. Let’s look at another effective way of expressing business rules.

State Models Illustrate The Business Rules Related To The Life-Cycle Of An Entity

Like I said before, developers love precision, and state modeling is the most precise way of expressing the business rules related to the life-cycle of an entity.

Let’s look at an example.  The state model for our Order entity might look something like this.

This simple but powerful diagram has two basic elements.

1. States – Boxes that represent the stage of a life-cycle (Opened, Payment, Submitted etc.)
2. Transitions – The lines showing the permissible state changes.

How Many Business Rules Do You See?

This “bare bones” version of a state machine is already enough to communicate a wealth of business rules to your developers. For example, the developer can see the following rules when they take a quick glance at this model:

1. An Order can be in one of the following stages of its life-cycle at any given time (Opened, Payment, Submitted, Completed, Abandoned, Cancelled)
2. An Opened Order can move only to the Payment stage, or the Abandoned stage of its lifecycle (nowhere else).
3. An Order at the Payment stage can move only to Submitted, Abandoned, or Cancelled.
4. An Order at the Submitted stage can move only to Completed.
5. An Order has reached its terminal state (i.e. it cannot go anywhere else) once it has reached Completed, Cancelled, or Abandoned.

And this is only the “bare bones” version of the model. We can dress up our state machine even further to start layering on additional business rules.  We can add Triggers, Pre-Conditions, Post-Conditions, to start capturing more details.

Do you see the value of this model yet?

Like I said,  a picture is worth a thousand business rules.

ERDs And State Models Are Based On Internationally Recognized Standards

There’s no doubt that these two entity modeling tools hold a lot of power because of how succinctly they can express business rules. Add to that the fact that both modeling techniques are promoted by OMG’s internationally recognized Unified Modeling Language (UML) standard, and you have an unbeatable combination of tools to get the job done.

I’ll admit that UML models can sometimes be overly cumbersome because they add on a lot of things the BA doesn’t actually need, but the rationale for why they use these two techniques is rock solid.