Complex state / composite machine - best practises

[Hamish]

Hi All - long time reader/user, first time caller.

I've recently been reverse engineering out the state model out of an internal system and have managed to document the state transitions, but modelling on a single diagram instance is quite complex.

We have 1 main 'container' object, and 3 related sub-objects, each with their own state models. Loosely based around the following:

container
-- item detail
-- payment detail
-- shipment detail

I have a state machine diagram for each of the above and I have a master model which uses composite state machines for the 3 'detail' state machines.

I'm not clear on the 'proper' UML method of doing this, but at this point my models are readable (although somewhat busy!) but I was hoping to do do this properly in order to get to some simulations to validate the model.

I have whipped a quick example to demonstrate



This a greatly simplified example but I'm trying to determine best practise for linking this composite models. I feel sure I am using the entry/exit Point's into the composite elements incorrectly and I'm not sure how to best represent the path from the entryPoint to the relevant composite state.

If anyone has experience with modeling this type of scenario I would love to hear some opinions as I'm sure there is a number of ways to skin this!

Regards,
Hamish

[qwerty]

Look quite nice. One or two points: consider to make the outer machines appear as composite. You can then easily create overview and detail diagrams. Further you should be careful in using fork/join. You use a join without a fork. Those are meant to picture concurrent states/flows. A fork continues with multiple states concurrently and the join leads them together. In contrast when you use implicit alternate paths (multiple transitions from an activity) or explicit ones with a choice you should join them with a junction.

q.

[Hamish]

Thanks for the response - I might play around with making the outer machines composite as well, and have already gone with your idea of overview detail but having two diagrams and enabling/disabling of the 'show composite in compartment'.

Very good point about the join, I need to include a fork as well to indicate where the concurrency begins. My complex models have some explicit decision nodes but don't incorporate a fork/join to bring them back.

Do you have any comments regarding the entry and exit points to the composites? In some of my more complex models, I have explicit a decisions node and then multiple exit points? I'm not quite sure if my transitions into and out from the composites are correct.

Thanks for your feedback - very useful!

- Hamish.

[qwerty]

Usually the composite parts should have an explicit entry and exit point. Sometimes, when the state machine is quite simple, nobody would shoot you, if they are omitted. However, if they are there, it's clear where the state runs. The best is, to introduce and train modeling rules which pin down this.

q.

[Hamish]

Modelling rules makes sense - but in what form would this take within EA?

I have triggers defined which define the function (or action) required to make  the state transition, but the entry and exit Points for the composite states do not have any defined rules.

Is triggers the EA construct you mean when defining (and training) modelling rules? I understand the concept but not sure how best to implement it within EA.

Ultimately I am going to end up with a large list of define triggers which I can maintain, but this only works state -> state, between entry and exit points to composites.

Thanks again!
 - Hamish.

[qwerty]

I meant something much simpler: a text document. I usually start modeling a meta model but have always to fight for it as people tend to be not willing to understand it. Even people used to UML have problems understanding a meta model. Once they are convinced or got a grip they find it useful. But the effort is usually outstanding.

Regarding the use of triggers: I can not recommend anything as it heavily depends on the usage. So if you feel the way you use them is okay, just do so. If possible discuss the use with the users (modelers). You need to understand their use case (that's where the meta model comes in again).

q.