UMLR — UML2.5: Clarification about UML profiles

12.3.1 Summary

The only mentions that the profile mechanism is applicable to arbitrary metamodel are:

> The Profiles clause describes capabilities that allow metaclasses to be extended to adapt them for different purposes. (1st paragraph)

The paragraph continues with "the UML metamodel". So the generality is very subtle.

> In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF.

The next sentence reverts to the special case of a UML profile extending the UML metamodel:

> Thus when defining a UML profile, the profile’s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel whose XMI serialization is referenced in Annex E.

The next paragraph is the same:

> Profiles are not a first-class extension capability (i.e., it does not allow for creating new metamodels).

> Rather, the intention of Profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method.

Again, the generality is lost in the next sentence:

> Each such adaptation is grouped in a Profile. It is not possible to remove any of the Constraints that apply to UML using a Profile, but it is possible to add new Constraints that are specific to the Profile.

The reasons for defining a profile are only explained in terms of extending the UML metamodel.

If anything, these reasons are equally applicable for extending UMLDI!

12.3.3 Semantics

The sub-clause "Restricting Availability of UML Elements" is specific to UML profiles extending the UML metamodel.

This is misleading. These restrictions are equally valid for UML profiles extending other metamodels (defined in UML of course)

ProfileApplication.

This is written again from the perspective of a UML profile extending the UML metamodel:

> One or more Profiles that extend UML may be applied at will to a model Package.

Again, the generality is lost.

Stereotypes

The "Restricting Availability of UML Elements" section in Profiles has the following constraint:

> Stereotypes can participate only in binary Associations. The opposite class can be another Stereotype, a non-Stereotype Class that is a packagedElement of a Profile (directly or indirectly), or a UML metaclass.

Because this constraint is in 12.3.1 only and not in 12.3.3, it is unclear whether this constraint is only applicable to UML profiles extending the UML metamodel or not.

These problems are a consequence of the organization of the Profile clause which has an uneven split where the UML-based explanation is in one place (12.3.1) and the generic explanation elsewhere (12.3.3)

For readers, it is difficult to tell whether there are differences between the two capabilities.

It is difficult to tell what is specific to UML profiles extending the UML metamodel (I.e., does not apply to UML profiles extending other metamodels)

It is difficult to tell whether users have to figure out how to "merge" 12.3.1 and 12.3.3 for UML profiles that extend both the UML metamodel and some other metamodel.

This difficulty comes from the duplication of the content, once for UML a second time for other cases.

It would be better if the material were not duplicated at all and if there care special cases for UML profiles extending the UML metamodel that do not apply to other cases, then have these clearly described in a sub-clause.