General - pja - UpperCamelCase for Stereotype name

[PalmJanssen]

Names of stereotypes in UML are preferred to start with an upper-case letter. This was not done in former ISO 19103 and 19109, so there is some legacy there. Anyway the stereotype name is not case sensitive. What should we do now?

[cportele]

We should probably be consistent with UML and use UpperCamelCase for stereotypes (FeatureType, ApplicationSchema, Union, etc.) and lowerCamelCase for keywords (interface, dataType, enumeration). Or at least add a note somewhere why the UML guidance is not used (UML 1 legacy).

As you say, string comparisons are always case-insensitive, so this has no impact on existing models and implementations.

[jechterhoff]

It is a question whether we want to be compliant with UML 1, 2, or something in between.

ISO 19505-1:2012 (same as OMG UML v2.4.1, part 1) states in section 12.2.9 (Stereotypes):

• Stereotype names should not clash with keyword names for the extended model element.
• Normally a stereotype's name and the name of its applications start with upper-case letters, to follow the convention for naming classes. Domain-specific profiles may use different conventions.
• Matching between the names of stereotype definitions and uses is case-insensitive, so naming stereotype applications with lower-case letters where the stereotypes are defined using upper-case letters is valid, although stylistically obsolete.
• In UML 1.3, tagged values could extend a model element without requiring the presence of a stereotype. In UML 1.4, this capability, although still supported, was deprecated, to be used only for backward compatibility reasons. In UML 2, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values. However, the “required” extension mechanism can, in effect, provide the 1.3 capability, since a tool can in those circumstances automatically define a stereotype to which “unattached” attributes (tagged values) would be attached.

If we intend to be compliant to UML 2, we need to define stereotypes for all model elements to which we want to attach tagged values. In the specification, we define tags for (application) schema packages, enumerations, code lists, and properties. For the packages, we can use stereotypes «ApplicationSchema» and «Schema». Stereotype «CodeList» would also be fine. We have a "clash" with keyword names enumeration and property (at least if we compare names ignoring case; it is unclear if that is meant with "clash" - UML 2.5.1 also just says "clash").

In Geospatial Data Modelling and Model-driven Transformation of Geospatial Data based on UML Profiles, section 5.3.2.2, an interesting decision was made regarding stereotypes whose names are equal to UML keywords:

«Enumeration» and «DataType» are not stereotypes, but keywords denoting the UML metamodel elements Enumeration and DataType, respectively. Thus, they have to be treated differently regarding their formal definition in combination with tag definitions as part of a UML profile compliant with the UML profile definition of the OMG. Appropriate stereotypes need to be defined which extend the metaclasses Enumeration and DataType, respectively. The question arises, which stereotype names to choose, since naming a stereotype identically to an existing UML keyword can lead to confusion and, therefore, is discouraged from by the UML specification (ISO 2012b). However, the UML specification also recommends to start keyword names with a small letter and stereotype names with a capital letter which makes the difference visible at first view, provided this rule is followed strictly. Based on this argument, the decision was made to name the stereotypes in the proposed formal ISO 19136 UML profile identically to the already existing keywords and to strictly adhere to the upper and lower case rule. This means, a stereotype «Enumeration» is defined which extends the UML metaclass Enumeration and a stereotype «DataType» which extends the UML metaclass DataType. Both stereotypes are, in addition, provided with the required tag definitions.

I made a test with a UML profile in Sparx Systems Enterprise Architect, where all stereotype names are in UpperCamelCase, and some of the stereotypes have names that are equal to UML keywords. However, they are not exactly equal to the keyword name, since keyword names start with a lower-case character (see ISO 19505-2:2012, Annex B: Keywords). Here is the resulting diagram:

Note that the model elements do have the tags that are defined for them in the UML profile - which is what we want.

It is interesting that the boxes for Interface1, MyDT, and Enumeration just show the stereotype name (in UpperCamelCase), whereas CodeList shows both keyword enumeration and stereotype «CodeList». Also note that MyUnion only shows stereotype «Union», but not the keyword dataType. If I uncheck the "Show Element Stereotypes" option in the Elements Appearance part of the UML diagram options in EA, only the UML keywords (enumeration, interface, and dataType) are shown:

Looks like an explanation for the observed behavior can be found at https://www.sparxsystems.com/forums/smf/index.php?topic=10638.0

While the last observations are tool specific, that tool is, as far as we know, in wide use within the geospatial community.

So there are reasons for defining stereotypes whose names are equal to UML keywords, but in UpperCamelCase. While we would ignore the recommendation (not obligation) from the UML standard to avoid such naming, we would not have to come up with new stereotype names.

If we do not define stereotypes for properties and enumerations, then by adding tags to such model elements, we would no longer be compliant to UML 2, strictly speaking. Then again, reality is that we (frequently) have to deal with a mix of UML 1 and UML 2 based models and profiles anyway. In addition, I would not want to miss Enterprise Architects forgiveness that allows me to add tagged values to model elements in an ad-hoc fashion (avoiding the need to adjust the UML profile for just small model modifications).

I would certainly want to keep using some stereotype when modeling data types, enumerations, properties, etc., since then the UML tool generates the tag definitions for me. Manually adding tags all the time would be a no-go.

[PalmJanssen]

Interesting. I must say that I did not know of the 'keyword' concept. I always thought that the UML <<dataType>> was also a stereotype. I understand the difference now.

There are several points:

• ISO 19103 must be guiding in stereotypes
• It will become quite confusing if every extension on iso 19103 implies newly named stereotypes like gml encoding profile, json encoding profile etc. I would somehow like the TV's for encoding profiles not to be refelected in newly added stereotypes, but as extensions on existing stereotypes. I think the EA mdg technology facillitates this.

I agree with this text line:

In addition, I would not want to miss Enterprise Architects forgiveness that allows me to add tagged values to model elements in an ad-hoc fashion (avoiding the need to adjust the UML profile for just small model modifications).

[jechterhoff]

There is no need to come up with new/different stereotypes for each encoding.

The package merge mechanism for UML profiles in theory provides the necessary means to merge stereotype definitions with same stereotype name, more specifically the tag definitions of such stereotypes, so that the resulting stereotype has the tags needed for all the relevant encodings or other implementation purposes.

From a practical point of view, and especially with regards, to modeling in Enterprise Architect, a community can then also define their own UML profile with all relevant stereotypes and tags, for the necessary encodings. No merging required. Definition of conceptual and encoding UML profiles would be a cleaner approach, but is not essential in practice.

[jechterhoff]

Decision: see #7