Proper state machine implementation?

[Frank Horn]

I'm really happy with class, activity, and sequence diagrams in EA, but I think the state machine implementation is a mess. EA keeps twisting my layout on saving and reloading, automatically adds transitions without my consent, hides triggers from upper levels in subdiagrams, ignores regions in state machines a.s.o.

I keep reporting the obvious bugs, but what I would really like to have is a proper view of the state machine structure in the project browser. I mean one which reflects the UML structure. Currently EA hides too much for my taste (maybe they think it's easier for beginners this way, but it makes setting up a complex state machine very tedious).

Here's an example: In a package, create a state machine diagram, add two states, and in the second state, define two regions with two substates each. The project browser will show:

package
----diagram
----state1
----state2
--------state3
--------state4
--------state5
--------state6

were I would like it to show:

package
----statemachine
--------diagram
--------default_region
------------state1
------------state2
----------------region1
--------------------state3
--------------------state4
----------------region2
--------------------state5
--------------------state6

Not only are the regions not shown as nodes in the browser: the information which states belong to which region is not even saved within the model, but only in the diagram, and you need a diagram to change it. I think this is not only against the grain from an XMI point of view, but also inconsistent with the way EA handles other objects like classes, activities, lifelines a.s.o

[Paolo F Cantoni]

I'm really happy with class, activity, and sequence diagrams in EA,

Then, Frank, you haven't (ab)used it enough...  

Your point above, though, is very well made.  We were just discussing this kind of thing among ourselves at work recently.

In a number of places, the diagram IS the thing - but it is also a rendering of the thing.  You can't just store the diagram, you have to store the thing the diagram represents, because EA has a number of internal dichotomies.

As usual, we came to the conclusion it was yet another fundamental problem with EA...

Paolo

[Frank Horn]

I have taken a closer look at the XMI that EA produces from state machines, and it is a complete mess. Regions of states are in the model part, but regions of state machines are hidden in some obscure tags within the extension part.

We had been hoping we could define a state machine in EA, export it to XMI and use this to trigger a generic state machine implementation we would then have written. But I don't want to do this with the weird stuff EA produces.

I've taken a look at some other tools too, but ArgoUML and StarUML only support XMI 1. Visual Paradigm at least shows regions in the tree view, and states can easily be be dragged from one region to another, but I don't know about their XMI, because the community edition doesn't support exports.

Anyway, I'm bitterly disappointed. When we switched to C# after many frustrating years with Visual Basic and Rose, we rejeceted XDE because of the missing XMI import, and Visio was out of the question anyway. And now I have to learn that EA too suffers from the Visio disease of saving model elements within diagrams.

[«Midnight»]

Frank,

Given the time you are investing in the search, why not develop some XSLT routines to transform the XMI into something you can use?

Since you are working in the .Net world anyway, you can use the .Net transform engine, which should be up to the job. If you create some stock NameTable implementations in .Net this should optimize well, and you're on your way.

It's work, but being frustrated doesn't seem to be getting you where you want to be.

Just my 0.02 CAD, for what it's worth.

David

[Frank Horn]

why not develop some XSLT routines to transform the XMI into something you can use?

David,

that's just what I had been planning, but it will be much more work than it would have been with a decent XMI, cause my XSLT would have to parse the xmi:Extension stuff and not just the packagedElement-region-subvertex hierarchy. So I've had no choice but to skip it for the time being.

Frank

[«Midnight»]

I agree Frank,

It is a pile of work.

And it will be a real pain when you try to move to XQuery sometime in the future (when you need fast response from a database of this stuff).

Still, if you put the same - not inconsiderable, I agree - amount of effort into being frustrated about this, you'll likely see less progress at the end.

David