Community
Participate
Working Groups
In the Ecore Editor the superclass of "Derived" is shown by rendering as "Derived -> Base" with a child element in which "Base" may be edited. The UML Editor provides a similarly helpful rendering of a stereotype for "Derived " by rendering as "<<Stereotype>> Derived " (- but superclasses are not shown, so a child element is available for the generalization) - but the stereotype application has no child element necessitating a more complex Properties Page for "Base". The lack of a child element is a particular problem for Bug 529767 where a Problem Marker needs to navigate to a feature of the stereotype application. Introduction of a stereotype application child element can unwind one of the 'helpful' design considerations underpinning the UML Model Editor that actually turns out to be unhelpful, confusing and restricting. (Now that Papyrus provides the helpful UML user interface, the UML Model Editor needs to be targeted at clear accurate diagnostic functionality.)
(In reply to comment #0) > The lack of a child element is a particular problem for Bug 529767 where a > Problem Marker needs to navigate to a feature of the stereotype application. The correct behavior, given the way stereotype applications are rendered in the UML editor, would be to navigate to the base element. I thought there was logic in place to do that already, but in case there isn't it should be added. > Introduction of a stereotype application child element can unwind one of the > 'helpful' design considerations underpinning the UML Model Editor that actually > turns out to be unhelpful, confusing and restricting. This would be incorrect, as stereotype applications are not children of their base elements; rather, they extend the set of properties that are available for the base element.
(In reply to Kenn Hussey from comment #1) > This would be incorrect, as stereotype applications are not children of > their base elements; rather, they extend the set of properties that are > available for the base element. Strictly speaking they are containers of the root, but displaying all stereotype applications at the root would be very unhelpful. In practice they are all related to a stereotyped class so they can be displayed as a child element of that class. This does not mean that they are children. The Ecore Editor has a variety of non-contained child elements such as super-classes.
(In reply to comment #2) > In practice they are all related to a stereotyped class so they can be displayed > as a child element of that class. This does not mean that they are children. The > Ecore Editor has a variety of non-contained child elements such as > super-classes. Hmm, that's a fair point. I suppose a "Show Stereotype Applications" option could be added to the editor, similar to the "Show Generics" option for the Ecore editor, which would display the stereotypes for a given element as child elements in the tree instead of (or perhaps in addition to?) "bolting them on" to the element itself. Contributions welcome.
