Good question!
Because of how EA saves data about States and their sub-states, this is slightly more complicated than we’d like, but we have to work with what EA provides. Or, adopt a different modelling style. (see (2) below)
1 – Using the EA Default Style.
——————————————-
If you want to document the sub-states of a state done EA-style, then the ‘parent’ State isn’t saved in EA as a simple ‘State’ element: EA makes it a ‘StateMachine’ element (looks like a blue oval with some sort of dumbbell shape inside it).
So, the key to getting eaDocX to document it correctly is to define profiles for:
- StateMachine: if you want to make it document its child states, then make the StateMachine document ‘Inline’, and also have document its Children – the ‘Sub-elements’ tab has a drop-down which has ‘Children’. I usually call this ‘Sub-States’ or something like that
- Then the individual States can then be documented e.g. in a table.
IF you want to get all the super-states and sub-states together into one table, then you can create an eaDocX Element Report which will collect up all the states into one flat list, but it will miss-out the StateMachine 🙁 .
2 – Using a simpler Modelling style
————————————————
You can get around this, by using a more straightforward modelling style, which is different from the EA default.
I don’t normally use the ‘StateMachine’ element at all – I don’t see the point.
A State is a State, which may or may not have sub-states, so I generally drag/drop the sub-states under their ‘real’ parent states. The parent state can then have a diagram of it’s sub-states, but the model overall looks simpler. I then give the states which have sub-states a different stereotype (e.g. <>), so that eaDocX can be configured to document <>State elements as Inline, documenting their diagrams and children, but normal States as document as simple Tables.
Then, you CAN have the option of a flat list of all the states, large and small. The StateMachine Element isn’t needed.
About the only problem I can see with the second approach is that whilst the EA model looks more ‘normal’ a UML reader, it isn’t what an EA novice will create, so you’ll have to get your fellow-modelers to adopt the same approach.
..told you it was a good question.
