Lately I developed more state machines than ever before. In the past I had respect for that type of diagrams but now I think it’s just cool

Why to use state-machines at all?

UML supports state charts for really long time, but only a small part of UML community uses state-machines on a regular basis.
My experience confirms that – it isn’t easy to start using them. The question is – why?

In my opinion, the reason is – the way how the people do thinking – in functions and activities (actually straight forward ). Therefore most of us likes sequence and activity charts better.
Everybody begins programming by writing functions – first, you have an idea of desired result in your mind and next, to get that result – you program a… function. Other way around – nobody will start thinking about classes, instances, states, interaction between objects, etc. if you just want e.g. to parse some strings.

But one day you want to (or you have to ) develop code in a more structured way. At that point machines can help
- Why? Because they get the object oriented methodology to the heart of the matter – it’s all about objects and their states. But as already mentioned above, at the beginning, state-machines seem to be non-trivial
– So what to do?

How to get the state-machine right?

Wouldn’t be great if an UML tool could interact with you and give you feedback while modeling to show if you are still on the right track?
– It’s exactly what AMUSE does. It extends Enterprise Architect to an interactive UML tool.

My first lesson learned with AMUSE

1. First, install the tool – very easy
2. Cause I developed state machines before AMUSE, the next step was also easy going – created a model, a view, a package, added an state diagram and drew a trivial state chart
3. Next, I wanted of course to know if it’s executable – the first thing I had to learn was to add every state-machine into simulation window manually. Actually it’s annoying, hope we change that in the next version
4. But already at the fourth step I learned a really important thing – every state machine belongs to a class. First, I thought it is also nonsense, but then I’ve got it

Basically it is easy and exactly the right way to think:

- So, you want a state chart? First question you have to answer – state of what? And the answer is – state of class you have to design.

Answering that question is the first step in the right direction of good design!

Bottom line

To cut a long story short:

• State machines are cool, because they guide you to a good design
• AMUSE is cool, because it guides you to a good state machine
  - e.g. it creates automatically a class and a state machine that belongs to a state diagram if you forgot

meanwhile i came to the conclusion:
- Usage of state machines is probably most suitable way to enter into object oriented design, but they are also excellent helpers for experts.

Next time more …