State machines or state machine diagrams are the base modelling techniques of behavioral class characteristics. There are many ways how to define and model class behaviour and state machines.
The main goals to achieve are:
- readability of the state chart
- robustness (meaning that you don’t model just one point of view)
- as simple as possible
The art of state modelling is based on more decisions of the modeller (designer) which influence the final result and design of the state machine. One of the open points is to decide whether it is better to define any property through the state representation or simply with just a class attribute.
Firstly, try to collect:
- assumed most important states of the class
- all operations that trigger state changes
Even if you start with state machine modelling one should ask a simple questions “What are the main states of my Class?” …and … “What are the main operations of my Class that trigger any state changes?” then try to sketch it and after some analytical iterations your model can be done.
There are some questions that can be very helpful for design decisions in order to model an attribute, composite element or part of your state machine:
- is the “property” critical for the Object’s life cycle? (if yes …then model the state)
- does the “property” represent really the state of the Object? (if yes …then model the state)
- does the “property” define some complex behavioral aspects of the Object? (if yes …then model the state, or composite part of it)
- does the class have different transitions “with” the property compared to “without”? (if yes …then model the state)
- are there any parallelisms or similarities of the state machine part? (if yes …then model a composite part)
- are there any state combinations? (then you’d better use attributes)
- is there still any “similar” state in the class? (you are absolutely on a wrong way)
- can be the state machine part modelled as standalone class and used as a composite part? (do it!)
- does the class have any specific complex behaviour for the property? (if yes …then model the composite part)
If after a few hours your state machine is too complex (too many transitions, too many nested state machines, too many similar states or redundant transitions) you are on a wrong way – just like by OOP: too many attributes and methods are not recommended, the same has to be borne in mind in case of state machines.
Many state machines that I saw have nothing to do with OOD – UML gives you a chance to encapsulate parts of your state machines and to define them as composites of your main class (modelled with composite structure diagrams) and combine your state machine smartly with attributes. It makes your design more modular and robust for the future extensions.