If the classes of your model define the statics we are now left with dealing with the dynamics of the domain. With the dynamics, I mean all the “state” and “rules” that any instance object defined by a class in your model might have.
This is where UML introduce the State Machine. A state machine helps us to describe the different allowed states an object can be in and how it is transitioned between these states.
For the Car class in the model, I choose to model the state machine above.
Each box is a State. A state has a name. A state can have transitions moving into it or out of it. To follow a transition out of a state and land in another state we must use a trigger. A trigger is a method of the class that performs all actions associated with moving from one state to another. In order to be allowed to execute a trigger, we must first be in an action where this trigger can be used.
State machines can make the dynamics of the information in your model much more accessible. Having the rules that the state machine implies also remove the need for a lot of other means to make sure that the information does not end up in illegal states.
The current state is stored in the attribute named the state in this case. But a class can have multiple state attributes (named differently) – just as objects in real world follow different state machines depending on perspective. The perspective I have chosen above might be called LifeTimeState. And maybe there is another state attribute called CleanlinessState.
You can implement many business rules in state machines like these. Consider that your domain has a rule “Do not start production until deposit is paid”. I would go about it like this:
and a Guard on the state machine:
The language used to declare the guard is called OCL – Object Constraint Language. It is a languages that allows you to navigate your model. So you can easily make more complex rules. Consider that the Brand must be set before we start production:
“self.DepositPaid and self.TheBrandOfTheCar->notEmpty”
OCL makes heavy use your model and the rule is just as clear as your model is – using the language of the domain.
You can also define Entry and Exit actions when you enter one state and leave another.
Like this:
