Author Topic: CombinedFragment - naming anomaly (Read 7998 times)

Paolo F Cantoni · « **on:** September 27, 2006, 04:38:23 am »

The rendering of CombinedFragments (see Help under Interaction Operators) seems t be defective. As I understand the [size=13]UML 2.1 Superstructure (interim)[/size] Specification 14.3.3 CombinedFragment (from Fragments), where a fragment is not anonymous, the name precedes the operator:
sd <name> (ignore | consider) { <message-name> [, <message-name>]* }

however, if the fragment is anonymous, then the operator suffices:
loop

If I add a name to the above anonymous loop, I should see:
sd <name> loop

or at least:
<name> loop

EA places the name after the operator, leading to incongruous syntax and confusing semantics.

Have I go t this the the wrong way round? Or does it need fixing?

TIA,
Paolo

Jan ´Bary´ Glas · « **Reply #1 on:** September 27, 2006, 05:17:35 am »

I would call that a semantic incorrectness - that means a bug.

jeshaw2 · « **Reply #2 on:** September 27, 2006, 07:26:40 am »

Quote

...As I understand the [size=13]UML 2.1 Superstructure (interim)[/size] Specification 14.3.3 CombinedFragment (from Fragments), where a fragment is not anonymous, the name precedes the operator:
sd <name> (ignore | consider) { <message-name> [, <message-name>]* }...

I noticed this in the last Interaction Diagram I did. Intuitively, it seemed reversed to me too. However, when studying the quoted UML spec., I could not find support for the relative positioning of the <fragment name> as you suggest. Can you point me to a page # where you find wording on this?

Your inclusion of "SD" in your syntax makes me wonder if you are confusing the <name> of the Sequence Diagram with the <name> of the embedded CombinedFragment. Could the full syntax be:

[size=13]sd [<diagram name>] (ignore | consider) [<fragment name>] { <message-name> [, <message-name>]* }[/size]
(Where the square brackets "[]" denote optionality)?

I should think that a syntax with two optional names located side-by-side would be ambiguous when only one name was specified.

Still perplexed...
Jim

Paolo F Cantoni · « **Reply #3 on:** September 27, 2006, 07:32:19 am »

Jim,

some examples are to be found in Figure 14.24 - Ignore, Consider, assert with State Invariants on page 532.

HTH,
Paolo

jeshaw2 · « **Reply #4 on:** September 27, 2006, 07:06:28 pm »

Paolo;
Looking at Fig 14.24, I see your point. However, I'm having trouble explaining the presence of "SD" in the diagram. "SD" normally appears in the diagram frame title, not in a fragement frame title (to my way of thinking). :-/

I now believe that both the UML 2.1, Figure 14.24 and EA have issues that need resolution.

Paolo F Cantoni · « **Reply #5 on:** September 27, 2006, 07:23:46 pm »

Quote

Paolo;
Looking at Fig 14.24, I see your point. However, I'm having trouble explaining the presence of "SD" in the diagram. "SD" normally appears in the diagram frame title, not in a fragement frame title (to my way of thinking). :-/

I now believe that both the UML 2.1, Figure 14.24 and EA have issues that need resolution.

Yes, I agree...

My vote for fragments would be:

<fragment name> <operator>
[constraint]
-------------------------
[constraint]

Paolo

jeshaw2 · « **Reply #6 on:** September 27, 2006, 07:58:42 pm »

You got my vote!

«Midnight» · « **Reply #7 on:** September 28, 2006, 04:17:33 am »

And mine.

However, there should be an option to display as per the UML 2.1 specification if that is different. Thus we preserve the ability to be compatible. Meanwhile, who of us have an ear at the OMG UML table, and can raise this as an issue to be solved later? [My "ear" is on another committee; a direct path would be better.]

Paolo F Cantoni · « **Reply #8 on:** September 29, 2006, 12:34:45 am »

Quote

And mine.

However, there should be an option to display as per the UML 2.1 specification if that is different. Thus we preserve the ability to be compatible. Meanwhile, who of us have an ear at the OMG UML table, and can raise this as an issue to be solved later? [My "ear" is on another committee; a direct path would be better.]

Dave,

As Jim points out, the UML specification is a bit self contradictory in this area.

My suggestions are designed to be more consistent than the specification, but still compatible with as much of it as possible.

Paolo

Paolo F Cantoni · « **Reply #9 on:** September 29, 2006, 01:03:17 am »

We've been looking at ways to reduce the complexity of some of our sequence diagrams and we've come to the following conclusion:

if there is only one allowable operand for the interactionOperator (such as opt, loop, break or neg); then the operand (EA's Condition) should be rendered within the name and operator panel:

---------------------------------------------------
|<fragment name> <operator> <operand> |
|--------------------------------------------/
|

where there are more than one possible operand, then:

---------------------------------------------------
|<fragment name> <operator> | [size=16][<operand>][/size]
|-------------------------------/
|
|
|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| [size=16][<operand>][/size]

The operand is more prominent in the second case because it needs to be distinguished from the surrounding text.

(Figure 14.11 in the Superstructure Specification is one of the better examples of this...)

I hope this will be a reasonable suggestion...

Thoughts?

Paolo

«Midnight» · « **Reply #10 on:** September 29, 2006, 03:41:09 am »

I think I'm getting you here, and it seems to make sense. I'll have to muse on it though. When I get a moment I'll look through 2.1 again.

However, assuming nothing in 2.1 contradicts this representation - and I don't think it does - I agree it can improve readability, particularly where both fragment forms coexist in the model.

Sparx Systems Forum

News: