KERML_ — Association ends can have more than one type

In general, Feature::type can have more than one value, and there is no restriction on this for end Features. The Association::relatedType property is derived as all the types of all the associationEnds of the Association. However, Association::sourceType is derived to be just the first relatedType. But consider the following Association:

assoc A {
    end feature x : X1, X2;
    end feature y : Y1, Y2;
}

Even though this is a binary Association (it has exactly two ends), it has four relatedTypes: X1, X2, Y1 and Y2. As a binary Association, though, it (implicitly) specializes the library Association BinaryAssociation, with the first end redefining the source and the second end redefining the target. However, with the current derivation, the sourceType of A will be only X1, and the targetTypes will be X2, Y1 and Y2 – even though X2 is a type of the source end.

Restrict ends to have only a single type

One possible resolution to this issue would be to allow a Relationship to have multiple sourceTypes as well as multiple targetTypes. The sourceTypes property for a binary Association would then be derived as all the types of the first associationEnd, while the targetTypes would be all the types of the second associationEnd.

However, it seems more natural for a binary Association with two associationEnds to also be a binary Relationship between two relatedTypes (allowing that these may be the same Type). More generally, one would expect that an N-ary Association with N associationEnds to also be an N-ary Relationship between exactly N relatedTypes (allowing duplicates).

So, the proposed resolution is to add a validation constraint requiring that every associationEnd owned by an Association have exactly one type. Note allows, e.g., a redefining associationEnd to have a type that is more specialized than its redefined associationEnd, because the derivation of type results in the redefining associationEnd having only the more specialized type. However, it would not allow the redefining associationEnd to be declared with a type unrelated to the redefined associationEnd, because that would result in the redefining associationEnd having two types, its declared type as well as the type inherited from the redefined associationEnd.

The proposed constraint is currently violated by the Performs Association in the Performances library model. This is because Performs attempts to re-order the associationEnds redefined from the Involves Association it specializes. But this does not work because the checkFeatureEndRedefinition constraint still requires that the ends of Perform redefine the ends of Involves in order. The resulting implied Redefinitions to meet this constraint then result in the ends of Performs having two types (both Object and Performance_), violating the new validation constraint proposed in this resolution.

So, the proposed resolution also revises the declarations of Involves and Performs so that Performs does not violate the new validation constraint. (The proposed changes to the Performances library model are consistent with changes proposed in resolution KERML_-87 to issue KERML_-18, but can also be enacted separately if KERML_-87 is not approved.)