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.
- States – Boxes that represent the stage of a life-cycle (Opened, Payment, Submitted etc.)
- 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:
- An Order can be in one of the following stages of its life-cycle at any given time (Opened, Payment, Submitted, Completed, Abandoned, Cancelled)
- An Opened Order can move only to the Payment stage, or the Abandoned stage of its lifecycle (nowhere else).
- An Order at the Payment stage can move only to Submitted, Abandoned, or Cancelled.
- An Order at the Submitted stage can move only to Completed.
- 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.
Would anyone else find this useful?
Please share this article with one person who you know is interested.
What a brilliant article and explained in a very interesting way. How about using IBM Rational Rhapsody for creating state machines in an Automotive project?
Thanks Sushruti,
I learned and used Rational Rose many years ago before it was bought by IBM, but I come across very few clients actually use any of those tools. Many of companies who do have it don’t use it well or don’t use it at all.
I find that formal UML is a little too heavy for what most business analysts need to do. I encourage BAs to learn the most important elements of UML and ignore the many of the formal rules to get the best value out of their time and analysis.
This is a great example of how something so simple can bring great clarity ! Thank you so much for sharing!
Thank you Laura. Let me know if there are any other BA related subjects you’d like me to cover.
Thanks for sharing this modeling techniques. Simple and great clarity of modelling any business processes.