Actually, you found enough of the correct parts of the specification to put it all together.
So, while you reread what you wrote, here's some things to ponder...
Why not introduce the loop node, even though there is no specific notation? The whole point is that this is a specialization, as you point out, that defines an order of execution. Further, as you point out, the type defines the actual order. In this case, as you point out, the order includes setup, test, and body sections.
As to the notation, there does not have to be any "specific" notation, since the general (parent) types have defined all we need. This specialization simply specifies what is necessary for a valid LoopNode; the notation only has to obey the requirements for the LoopNode parent type, since it specifies all we need.
However, any product (EA or another) that "introduces" LoopNode needs to provide a valid notation for the Node per the specification, and ensure that you can enter the setup, test, and body sections. So, no "syntactical sugar" as far as notation goes, but still some requirements that have to be met.
As far as your "continuing rant" issue goes...
Yes, this is iteration. If you don't want to test a condition - perhaps you're running a game loop or something and will always exit from inside the loop body - then you have all you need.
If you do require a condition, you could model this from the outside "prior" to entering the expansion region, but you might be trapping yourself. In your model you have now separated the logic for your loop exit from the loop itself. What happens if these get out of sync? Perhaps nothing, perhaps something bad. What are the chances of this happening in your organization, modeling paradigm, or any particular model? Who knows, perhaps acceptably small, perhaps not.
Now enter constructs like LoopNode. Using this paradigm you've resolved the above questions.
And the "hassle" is minimal: you are doing the same work as you would need to do to "model the conditional part prior to entering" the expansion region. Where's the extra work?
Of course, you might use a LoopNode on one diagram and an expansion region on another. Each is good at explaining specific things, and each best works at its own level of abstraction. This kind of thing shows up a lot in UML.
Make any sense yet?
David
