v16.1 Can't set Parent_ID where parent is a Note item

[Paolo F Cantoni]

We create "Neighborhood" Diagrams for our items.  Since Diagrams can't have tagged Values, we use the DiagramNote item (effectively the "Title Block" for the diagram) as a surrogate.  We make the Parent of the Diagram and the Parent of the DiagramNote the item for whom the Diagram is being generated.  This works fine for most items, but recently our Diagrammer Add-In has been crashing on Note Items with the message indicating that the Parent_ID relationship is contrary to UML specifications.  That is, when we set the Parent_ID of the DiagramNote to be that of the Note Item (for which we are creating the Neighborhood Diagram), the exception is thrown.


Before I report a defect, can anyone point to the section of the UML specification that indicates this rule (which we appear to be breaking)?  A quick check of 7.8.2 Comment [Class] (of the UML 2.5.1 Standard) indicates no such issue.


We have been processing such Note items with our Diagrammer for over a decade, so when did this change?


TIA,
Paolo

[qwerty]

I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. Seems to make sense, though inconvenient for coder relying on it otherwise.

q.

[Paolo F Cantoni]

I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.

q.

Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything.

Paolo

[Geert Bellekens]

I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.

q.

Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything.

Paolo

I just check the UML specs, and a Comment is in fact a specialization of Element, and an element can be the owner of other elements.
So there is no (UML) reason notes shouldn't be able to own other elements.

Geert

[Modesto Vega]

Hi Paulo,

Are you setting the Parent_ID of an element, as per Geert comment, or of a diagram? Both, have a Parent_ID.

[Paolo F Cantoni]

Hi Paulo,

Are you setting the Parent_ID of an element, as per Geert's comment, or of a diagram? Both have a Parent_ID.

Hi Modesto,
The problematic Parent _ID is the Element.  The Diagram Parent_ID is set as it used to be.  What's confusing is that I'm sure that this didn't happen with v15.2, so I suspect that the new DLL has the bug, and so, since I'm linking to it in the Add-In, even v15.2 activation of the Add-In crashes.

Paolo

[Paolo F Cantoni]

I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.

q.

Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything.

Paolo

I just check the UML specs, and a Comment is in fact a specialization of Element, and an element can be the owner of other elements.
So there is no (UML) reason notes shouldn't be able to own other elements.

Geert

Thanks, Geert;
that was my reading of the Standard, but they can be pretty dense, so I wanted another "set of eyes" to confirm or deny.

Let's see what the Sparxians have to say tomorrow.

Paolo

[qwerty]

Got it into the wrong throat (as we say here). It's probably the special treatment of EA that notes (aren't they call annotation in UML?) never were "real" elements. You did not see them in the browser. Likely that's why they still can not be parent of anything. Will it change for good? Maybe.

q.

[Geert Bellekens]

Got it into the wrong throat (as we say here). It's probably the special treatment of EA that notes (aren't they call annotation in UML?)

Comment in UML, see § 7.8.2 Comment [Class] page 40

Geert

[qwerty]

Yes, thanks :-) So Sparx has an "excuse" since it's not an UML element (btw. Object isn't UML either). But don't they claim to be UML 2 compliant?

q.

P.S. I can't find a UML compliance statement right now but pretty sure in the past they had some advert in this direction.

[Paolo F Cantoni]

Yes, thanks :-) So Sparx has an "excuse" since it's not a UML element (btw. Object isn't UML either). But don't they claim to be UML 2 compliant?

q.

P.S. I can't find a UML compliance statement right now, but pretty sure in the past, they had some adverts in this direction.

(my emphasis) If it's NOT UML, then how can it break UML Rules...

The exception message is explicit: The Relationship is NOT allowed by UML Rules" (IIRC).

Paolo

[qwerty]

It's "The requested connection is not UML compliant". But I meant an explicit statement like "UML 2.0 compliant modeling tool". I seem to remember that ad but there is none anymore. Maybe in one of the heave PDF document files?

q.

P.S. Indeed after searching the Help theres a lot about NIEM, BPMN, etc. compliance but not so much about UML. I found "it is not a strictly UML compliant construct)" in the help about SDs.

[Mauricio Moya (Arquesoft)]

Are you using Parent_ID instead of Package_ID?

[Geert Bellekens]

Well, "if it looks like a duck...."

and a EA Note element pretty much looks like a UML Comment to me, so for all intends an purposes, I guess we can treat a Note like it's a UML Comment.

Geert

[qwerty]

Well, "if it looks like a duck...."

But this one barks ;-)

Honestly, this is a Sparx element, not an UML element. Like Object, which is kind of heritage. Eve already told that the latter will not change for compatibilty reasons. Looks like UML InstanceSpecification but...

q.