Introduction to the notion
At the heart of the object-oriented approach
This approach, contractual modeling, is an essential tool to push the object logic further, i.e., to design classes as truly autonomous machines, responsible at any given instance for their internal state and accepting responsibility for missions proposed externally.
When should the state diagram be used?
Modelers need to ask themselves the following questions, for each class:
- Do the objects in this class follow a life cycle?
- Do their transformations obey any constraints or a concatenation?
- Is their behavior conditioned by their internal state, or the stage at which they find themselves at a given time?
If the answer to any of these questions is yes, the modeler is justified in representing the phenomenon in the form of a state machine.
A contract, a claim, an operation… have a life cycle with different states marked out. They will behave differently depending on the value of the state. The classes representing them are therefore equipped with state machines.
How to proceed?
The notions of status, milestones, stages… as well as the adjectives or present participles bracketed to the class name, constitute starting points for isolating states. Once the states have been identified, valid transitions are represented (without doubt more than in a nominal object mechanism, all too often reduced to a linear list…).
To consolidate the state machine, it is important to consider how an object is stimulated and how it behaves under stimulation from each state. Backward steps are added to absorb any disruption the object may be subjected to, during its existence (life cycle regression).
Then, inscribed on the transitions are:
- trigger events or conditions,
- operations which carry out the transition,
- emit events.
The state machine is a good way of freeing up the operations of a semantic nature. When the modeling is finished, the transitions carry the operations inscribed on the class that the state diagram is made for.