Apply metatype over type-stereotype consistently

[Paolo F Cantoni]

Over the years, Sparx appears to have been moving (quite rightly in my opinion) toward the use of the metatype rather than the stereotype as the property to be exposed to the user - where a metatype exists for the type-stereotype combination.

From a consistency point of view, this should be made universal.

In this feature request, I'm specifically asking for this to be applied to the RefGUID return string.

However, in the equivalent forum post, I'm asking the users to add any instances that they find where that consistency hasn't been applied yet.

Reported,
Paolo

NOTE: In our case, our stereotype names are abbreviated/encoded versions of the metatype name and so are of dubious values to our users.  But that's only a special use case.  The general principle still applies, regardless.

[Paolo F Cantoni]

I received the following reply from Sparx Support:
Thank you for your enquiry. Our developers have provided the following feedback, please see:

This is the duplicate of your own reported issue (Ref: 20013999)

A metatype is not an alternative rendering of a stereotype. It is an alternative rendering of UML type+stereotype.
It would seem the "developers" are not aware that it is NOT possible to have a stereotype associated with an item without the item ALSO having an associated type!

Consequently, if the item in question HAS a valid Type+Stereotype combination, then the metatype CAN be displayed.  My request was to allow the user to decide.  If it is not valid to display the metatype if the stereotype is there, why did Sparx suddenly several years ago start exposing the metatype?  It's just inconsistent!

What do others think?

Paolo

[Eve]

A metatype is not an alternative rendering of a stereotype. It is an alternative rendering of UML type+stereotype.

But not all places render the UML Type and Stereotype. What support is stating is that it's not a valid assumption to assume that everywhere a stereotype is used the metatype should be used in its place. The only places I know of that display the metatype are the ones where it treated equivalent to a UML type. Which is exactly why it shouldn't be in the RefGUID return string. Only the stereotype is displayed there.

[Paolo F Cantoni]

A metatype is not an alternative rendering of a stereotype. It is an alternative rendering of UML type+stereotype.

But not all places render the UML Type and Stereotype. What support is stating is that it's not a valid assumption to assume that everywhere a stereotype is used the metatype should be used in its place. The only places I know of that display the metatype are the ones where it treated equivalent to a UML type. Which is exactly why it shouldn't be in the RefGUID return string. Only the stereotype is displayed there.

From the user perspective, especially the end-user (as opposed to custodians/power users who have got used to EA's self inconsistencies); once we've introduced the notion of metatype as the "intersection" of Type and Stereotype and they "get it", they see it as confusing as to why they need to separate the two.

My assertion (not an assumption) is that wherever a stereotype is used, and there is a valid intersection with the Type - yielding the metatype, the metatype can be displayed with no loss of generality!  Notwithstanding that you correctly identified the subset of such places where it is currently used, what is conceptually wrong with my assertion that it can be used universally?

I'm not asking that it MUST be displayed for everyone at all times, but that we have the ability to require it (analogously to [  ] Use Alias if Available).

Paolo

[Paolo F Cantoni]

My assertion (not an assumption) is that wherever a stereotype is used, and there is a valid intersection with the Type - yielding the metatype, the metatype can be displayed with no loss of generality!  Notwithstanding that you correctly identified the subset of such places where it is currently used, what is conceptually wrong with my assertion that it can be used universally?

(my emphasis)  Nobody has countered my assertion in over a week.  Am I, therefore, allowed to say it's valid?

If so, then there is no reason not to allow metatype for type+stereotype.

Paolo

[Eve]

You're allowed to say anything you want.

But it doesn't follow that EA should substitute stereotype for metatype.

EA currently displays metatype:

• In the title of properties dialog. If the element stereotype does not define a metatype the stereotype is not displayed
• In the docked properties window. The original type is also another entry in the list of groups
• Toolbox (for a view specification or technology where an explicit toolbox isn't defined). Original UML types are also available here.

EA displays the stereotype when the original type is not represented texually including:

• Browser window
• RefGuid tagged values
• Selecting a stereotype/stereotype property

From my perspective EA is consistent in how this is behaves already. All you're doing is pushing for a change in behavior where you have defined a practice using EA that doesn't match EA.

[Paolo F Cantoni]

[SNIP]

From my perspective, EA is consistent in how this behaves already. All you're doing is pushing for a change in behavior where you have defined a practice using EA that doesn't match EA.

Yes, that's exactly what I'm pushing for!   

Isn't that exactly what a feature request is?  Since the request has been denied, I'm undertaking an appeal (to the non-existent "Administrative Appeals Tribunal"  ) to see if I can sway the internal opinion with (I hope) remorseless logic!  Remember, I'm not asking for it to be universal, but selectable.

Paolo