[SNIP]
This paper is a lot better, but also has the same question: exactly how should something like, say, a LoopNode, be notated. [/SNIP]
I'm not sure I understand the problem here. Whenever the UML Specification is silent, we are free to do what we wish; there is no "should be" to worry about--other than to be clear enough in our communications that our readers understand our intent. Here is how I approach the issue:
In traditional Structured Programming there are three logic patterns:
Simple Sequence,
Selection, and
Repetition (aka;
Loopnode, having two forms:
doUntil and
doWhile). The traditional flowchart notation for these patterns are well known, but I can provide examples if you like. All of these can be modeled by an activity diagram that emphasizes control flow. The mantra is
One way in, one way out of these logic patterns.
In traditional structured programming, the three basic logic patterns may be nested in any combination to build up complex logic flows. The UML allows an equivalent nesting of structured activities.
EA provides a structured activity element with a stereotype and composite icon for your use. In a diagram, clicking on this element opens a subordinate diagram page where the structured logic may be denoted as the above mentioned activity control flow. The added power provided by the UML is that Action Pins and Object Nodes may be used to enrich the value of the diagram by denoting information flows as well as control flows. (It goes without saying that the control flow logic of the subordinate diagram should be consistent with the stereotype of the parent.)
IMO: Bock makes the point that one may use this approach to activity diagramming, or, if it makes communication more effective, a textual form of notation may be used instead. This is similar to the use of a textual form for Use Cases as that may more effectivly communicate some concepts than a Use Case Diagram's notation.
Does this help?
