Papyrus/Mars Work Description/Improvments/Stereotype support/Solutions

Steeotype Display: Solutions

Different solutions have been studied to find the best soution. First suggestion is to translate all the Eannotation properties into NamedStyle properties. Second soltution would be to define one label by stereotype. This chapter will describe the different solutions.

Named Styles

Based on the previous analysis, the Named Styles seems to be a good approach. This chapter explains how Named Styles work and how it can be integrated into the code to display stereotypes. Named Style is a GMF concept based on the Notation file. Named Styles define typed properties as a Style into the notation file. Types for Named Styles are the primitive ones: int, boolean, string, list, double… Notation file can be overridden by the CSS that is also accessible by the Named Style.

Architecture

Here is the general overview of the new solution for the Stereotypes to be displayed with Named Styles.
Note: method’s name is informative and not definitive. The direct edition of the stereotypes from the appearance property view is now done through the Edit Part which centralizes the different actions to be executed to display, hide, and update the stereotypes to be displayed.

CSS and Named Styles

In order to keep as many liberty degrees to the user as for the present solution, the same set of parameters is required. To allow the user to define the list of Stereotypes to hide from CSS and from the user interface, different list should be used for the CSS and the notation file. Then the lists can be merged instead of being overriden.

Those means that a lot of lists should be implemented as a parameter:

• stereotypesToHide
• stereotypesToDisplayAsQN
• stereotypePropertiesToHide
• stereotypesToDisplay
• CSSStereotypesToHide
• CSSStereotypesToDisplayAsQN
• CSSStereotypePropertiesToHide

Pro & Cons

The advantage of this solution is that the mechanism is quite close from the initial one. The CSS can be used as a user preference. It is based on GMF as required. And the intelligent part is done by a controller instead of via the interface directly.

In a other hand, this solution won't work if there are several CSS files used at the same level ( for example for each stereotype) . By default, the CSS mechanism will choose the CSS file with higest priority and ignore the other ones. On top of this, the list management between CSS and Notation file would be difficult to maintain and is a source of troubles.

Label for Each Stereotype

Another solution would be to change the architecture and specify one label for each stereotype. The difficulty here would be that the list of stereotypes that can be applied is not exhaustive. So it is not possible to create an UML object for each type of stereotype. The solution would be then, to create the label directly when the stereotype is applied. This solution avoid the use of lists and with the parameter "isVisible" can be shown or hidden from the CSS file without duplicating properties.

Architecture

The Architecture is quite similar to the NamedStyle solution, except the new Label element with the following properties:

• Type
• Stereotype
• isVisible
• QNDepth
• Properties

CSS and NamedStyles

NamedStyles will also be used in this solution for the properties that are not designed by default (like the QNDepth) and required into the CSS. The stereotypes would be shown or hidden through the CSS thanks to the following command:

Label[type=StereotypeLabel][name="SysML::Blocks::Block"]{
   isVisible : false;
   depth: "full";
}

Pros & Cons

• Pros : Using one label for each stereotype allows several CSS at the same level. The solution avoids lists of String management. Simple to maintain.
• Cons: The stereotype label is added dynamically into the notation file, and not into the UML model. It could generate refresh issues.

Property View Interface

to be edited

Conclusion

The retain solution will be the Single Label for each stereotype applied. An will be put in place as explained in a further chapter.