Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Harbottle on October 06, 2006, 07:47:43 am
-
Would I be correcting in saying that the concept of "structured activity nodes" is unclear? It seems to me that the whole point is avoid the mess of spaghetti by allowing creation of a structured action where the implication is that there are activities and variables linked in a certain way (i.e. Loopnode)
The spec is very unclear on this.
Also in EA, how do you link parameters on the activity to the sub diagram?
-
Seems clear to me. :)
Have you read Bock on Structured Activities (http://www.jot.fm/issues/issue_2005_05/column4)?
-
Would I be correcting in saying that the concept of "structured activity nodes" is unclear? It seems to me that the whole point is avoid the mess of spaghetti by allowing creation of a structured action where the implication is that there are activities and variables linked in a certain way (i.e. Loopnode)
The spec is very unclear on this.
The main thing that the spec is unclear on is the notation for LoopNodes. The only clue it gives is "No specific notation" which isn't very helpful. However it does mean that I can say without fear of contradiction that the EA LoopNode notation is correct! ;)
Also in EA, how do you link parameters on the activity to the sub diagram?
The only way I can think of is to drop the activity element onto its own child diagram and resize it so it fills the whole diagram. You may want to make it unselectable so it's easier to manipulate the owned elements (right-click | Selectable).
-
Seems clear to me. :)
Have you read Bock on Structured Activities (http://www.jot.fm/issues/issue_2005_05/column4)?
Yes thankyou, I have read that, and many more papers on the subject. That particular paper is rather poorly written (And appears to be missing some diagrams.) It does not - like most UML papers - offer any sort of decent example on how to use the notation. At least it refrains from "Sales Orders" examples.
This paper is a lot better, but also has the same question: exactly how should something like, say, a LoopNode, be notated.
"Semantics of structured Nodes in UML 2.0 Activities." by Harald Storrle, Ludwig-Maxumilians-Universitat Munchen.
-
Seems clear to me. :)
Have you read Bock on Structured Activities (http://www.jot.fm/issues/issue_2005_05/column4)?
A bit off-topic, but what is the advantage of a diagram like Figure 10 over the code in Figure 9? Except maybe it takes 10 times more time to understand Figure 10 than 9 and probably 100 times longer to create the drawing.
-
A bit off-topic, but what is the advantage of a diagram like Figure 10 over the code in Figure 9? Except maybe it takes 10 times more time to understand Figure 10 than 9 and probably 100 times longer to create the drawing.
Thomas,
It's not a question of advantage. The two figures are doing completely different jobs. If anything, Figure 9 is the outcome of the repository traversal in Figure 10. Figure 10 is there to tell Sparx how their internal representation of the concepts in Figure 9 is to be set up (at least on a conceptual or API level).
HTH,
Paolo
-
Hi Paolo,
probably I'm on a totally different boat. To me both represent shadows (in Platon's sense) on the wall stemming from the same "algorithm". But probably I'm completely wrong here. No need for discussion ;)
-
Hi Paolo,
probably I'm on a totally different boat. To me both represent shadows (in Platon's sense) on the wall stemming from the same "algorithm". But probably I'm completely wrong here. No need for discussion ;)
OK Thomas... But I, at least, would appreciate someone confirming I haven't "got hold of the wrong end of the stick"...
Paolo
-
[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?
-
OK Thomas... But I, at least, would appreciate someone confirming I haven't "got hold of the wrong end of the stick"...
I think Bock's use of the Repository Models in his article is more to clarify the syntax of the related UML diagram than to tell Sparks, et.al. how to set up their repositorys. He is using the (admittedly incomplete) repository diagram in the same way my elementary school English teacher used sentence diagramming to analyze the parts of speach used in a given sentence. Am I showing my age (which I happen to be proud of ;D)?
-
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?
Um, I didn't want a lecture on programming (I do have a PhD in a Software Engineering based subject and have been working with UML for 10 years in industry!). I fully understand the structures of these constructs. I was simply wondering if the structured notation could be used to avoid having to replicate the same pattern by being interpreted as a well understood structure with only the relevent activities specified. (In fact, my questions is similar to the question and point of the paper I quoted.)
Trying to communicate "custom" defined UML to colleagues - say in Japan - is a pointless excercise if they don't understand the meaning of the diagram or stereotypes.
-
Harbottle;
My apologies sir. :-[ Your credentials and the paper you referenced were not available to me.
-
I think Bock's use of the Repository Models in his article is more to clarify the syntax of the related UML diagram than to tell Sparks, et.al. how to set up their repositorys. He is using the (admittedly incomplete) repository diagram in the same way my elementary school English teacher used sentence diagramming to analyze the parts of speach used in a given sentence. Am I showing my age (which I happen to be proud of ;D)?
Well, I guess we're all from the same Millenium ;)
However, my point is the same as with all kinds of graphical algorithm descriptions. This UML variant is nothing else than a VARIANT of all the other methods on showing an algorithm in a graphical way. To me it does not bring any more light than writing real or pseudo-code (to readers of "ZEN AND THE ART OF MOTORCYCLE MAINTENANCE").