Summary: | Inconsistent metaclass tags in labels of model elements | ||
---|---|---|---|
Product: | [Modeling] Papyrus-rt | Reporter: | Christian Damus <give.a.damus> |
Component: | tool | Assignee: | Project Inbox <papyrusrt-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P4 | CC: | charles, papyrus-bugs, sredding |
Version: | 0.8.0 | Keywords: | ui, usability |
Target Milestone: | Future | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=475905 https://bugs.eclipse.org/bugs/show_bug.cgi?id=500679 |
||
Whiteboard: |
Description
Christian Damus
2016-09-01 11:13:10 EDT
The inconsistent use in the model explorer is only one aspect to consider. Currently the title of the properties view have the same inconsistency. Depending on how we want to solve this, the display of the meta-class label could be different between the model explorer and the title of the properties. I could very well see a solution where the meta-class label is not necessarily shown in the model explorer, but it should at least be consistently shown in the properties view title. This is something that I personally use a lot in the legacy tooling, e.g. in the situation where you cannot see/remember what the icon meant in the model explorer, one can always inspect the element in the properties view and be reminded about it's meta-class just by looking at the title. So what I would like to see is at least that we always shows the meta-class name in the title of the properties view. One more thing to consider is that the meta-class label should be DSML aware, and not just pick the meta-class name from the UML meta-model. Take the classic example with the protocol message in a UML-RT protocol. One protocol message is represented by both one Operation and one CallEvent. Selecting a protocol message should neither show the meta-class name of Operation, nor CallEvent, but should instead should the DSML specific meta-class name of ProtocolMessage (or possibly OutProtocolMessage, InProtocolMessage or InOutProtocolMessage depending on its direction). Related to this is that not all DSML concepts are explicitly stereotyped, e.g. the protocol message, which is implicitly stereotyped based on the stereotype on the Interface owning the Operation of the protocol message. So we cannot rely on the stereotype label either (see Bug 500679 for more of the discussion around the suppression of redundant stereotypes). In these situations it might be even more important to have the support for DSML aware meta-class labels in the title in the properties view (and possibly optionally in the model explorer). Does not gate v1.0 |