Bug 500683 - Inconsistent metaclass tags in labels of model elements
Summary: Inconsistent metaclass tags in labels of model elements
Status: NEW
Alias: None
Product: Papyrus-rt
Classification: Modeling
Component: tool (show other bugs)
Version: 0.8.0   Edit
Hardware: All All
: P4 normal
Target Milestone: Future   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: ui, usability
Depends on:
Blocks:
 
Reported: 2016-09-01 11:13 EDT by Christian Damus CLA
Modified: 2016-09-09 14:18 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Damus CLA 2016-09-01 11:13:10 EDT
The inclusion of the metaclass tags (within <...> angle brackets) in labels for model elements in the UI is inconsistent.  For example, in the Model Explorer, we can see

* "<Package Import>" on package import relationships
* "<Usage>" on usage dependencies
* "<<RTConnector>> <Connector>" on connectors in capsules
* "<<RTPseudostate>> <Pseudostate>" in state machines
* "<<Capsule>>" only on capsules (no <Class> tag), similarly for ports and parts
* "<<Protocol>>" only on protocols (no <Collaboration>)
* no stereotype keywords nor metaclass tags on protocol messages and parameters
* no stereotype keywords nor metaclass tags on transitions and triggers in state machines
* no metaclass tags on base UML constructs such as packages, enumerations (literals), and classes (properties, operations)

In general, quite a mixed bag.  In many cases, of course, it would seem that the metaclass tags would be redundant because not many (if any) of the UML-RT stereotypes are applicable to multiple different kinds of element, so the icon and/or stereotype keyword is sufficient.

However, in cases of visual impairment, especially for elements that do not have UML-RT stereotypes, the icons can be difficult to distinguish.  For example, the various kinds of dependency tend to look similar, and so the metaclass keywords shown on these are helpful.

Some rational scheme should be codified and implemented for the usage of the metaclass tags in labels, possibly accounting for

* end-user customization of the behaviour in the preferences, especially for accessibility concerns
* correlation with UML-RT stereotypes
* ??
Comment 1 Peter Cigehn CLA 2016-09-02 05:13:14 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).
Comment 2 Simon Redding CLA 2016-09-09 14:18:38 EDT
Does not gate v1.0