v15.2 – Stereotyped relationship doesn’t show stereotype property in Properties

[Paolo F Cantoni]

This is a weird one...  On the SAME diagram, some stereotyped relationships show the stereotype property in the Relationship Properties window and render it on the diagram thus "«stereotyped relationship» (stereotype=<MyProfile>::<MyStereotype>)".  Others show no property in the Properties window yet render it on the diagram.  The stereotyped relationship still works OK in the MDG and generates the correct outcomes.

So weird!  Does anyone have any idea why this might be?
The only consistent things are that if one stereotyped relationship from an element is missing, then all of them are.  Also, it seems to be independent of the diagram - that is, if I copy the two elements to another diagram, the same behaviour applies.

TIA,
Paolo

[Eve]

Without actually seeing your model I can only guess.

But do all of the stereotyped relationships show the same full name in the properties? Is there a tag with the same name on the relationships that are generating ok but aren't showing the option?

[Paolo F Cantoni]

Without actually seeing your model I can only guess.

But do all of the stereotyped relationships show the same full name in the properties? Is there a tag with the same name on the relationships that are generating ok but aren't showing the option?

Thanks, Eve,
I'm only after guesses... 

Yes, they show the same fully qualified name in the t_connectortag table and properties window.  Yes, it's the same tags in the various elements.  It DOES seem to be related to the originating element.

I think I've just found the reason - while replying to the post. It seems as though the anomalous relationships weren't created properly.  I removed the Stereotype (i.e. Profile Constraints::stereotyped relationship) and then re-entered it.  The missing property suddenly rendered.  I suspect a problem with t_xref.  I'll investigate later and report back.

Paolo

[Paolo F Cantoni]

OK, folks, in case this happens to you, here's the solution...

Yes, you DO need to have the t_xref contain the fully qualified stereotype name, BUT you ALSO need to ensure that the ea_guid for the t_connectortag row has the correct prefix (as has been noted a number of times in the forum regarding MDG based tags).

THEN, you'll get the stereotype property to render correctly in the Properties window!

NOTE: in this case, I'm talking about the stereotype property, NOT the Stereotype property!  Why the two properties on the same window have the same name is a defect ¹(at least one of them should have had a qualifier).

Paolo

¹ Noting that the casing is different is a spurious response - so don't even bother!

[Eve]

Since you're so adamant that what you are seeing is a defect, what do you think the defect is?

• That the profile export or load allows tags matching a built-in properties.
• That the profile author chose to implement the language used to describe these relationships in the UAF specification as found.
• That the group notation that separates and qualifies them isn't clear enough. In this case 'General' vs '«stereotyped relationship» ( from Profile Constraints )'

[Paolo F Cantoni]

Since you're so adamant that what you are seeing is a defect, what do you think the defect is?

• That the profile export or load allows tags matching a built-in properties.
• That the profile author chose to implement the language used to describe these relationships in the UAF specification as found.
• That the group notation that separates and qualifies them isn't clear enough. In this case 'General' vs '«stereotyped relationship» ( from Profile Constraints )'

(my emphasis)
Did I ever say it was a defect?  As I read my input, I didn't.  I DID attempt to describe what I thought was weird behaviour, but I hadn't yet determined if it was a defect or not.  I was asking for assistance in trying to track down the cause.

Having located the cause, my last post was to indicate the places to go look if a user had the same weird behaviour (caused by some sort of corruption in the DB - likely user caused, but of unknown origin at this time).

I did say that having two properties with the same name was a defect but "We hold that truth to be self-evident", and was unrelated to the original issue.

Paolo

[Eve]

Did I ever say it was a defect?

Yes.

Why the two properties on the same window have the same name is a defect ¹(at least one of them should have had a qualifier).

(your emphasis)

It's my assertion that they are both qualified by use of grouping.

I didn't reply to your original issue because as you had already found, the properties were incorrectly created and therefore there was nothing to show.