KERML — Context-dependent meanings for feature multiplicity, ordering, and uniqueness

The specification gives Feature::multiplicity, ordering, and uniqueness very different meanings for what it calls "end" features (see KERML-34 for definition of terms) than other features. This requires modelers and tool builders to create special cases in their minds and implementations to accommodate it. It also prevents

• connector ends from giving smaller lower multiplicity than their association ends (see KERML-55)
• participant features from specifying how many values they have (see KERML-35)
• multiplicities from being uniquely specified (see KERML-36).

Normally feature multiplicity restricts the number of values of a feature, but for association "end" features it restricts the number of values of the corresponding features of associated classifiers (association ends in SysML1.x/UML sense,(see KERML-34 for definition of terms) about terms), see excepts below. For example, in the Product Selection example, the info feature of association Selection has the usual semantics for multiplicity, but the "end" features linkedCart an linkedProduct do not. The same comments apply to end ordering and uniqueness.

Clause 7.4.5 (Associations) says

The semantics of multiplicity is different for end features from that for non-end features (as described in 7.3.4.2). The end features of an association determine the participants in the links that are instances of the association and, as such, effectively have multiplicity of "1" relative to the association. But, if an association end has a multiplicity specified other than 1..1, then this is interpreted as follows: For each association end, the multiplicity, ordering and uniqueness constraints specified for that end apply to each set of instance of the association that have the same (single) values for each of the other ends. For a binary association, this corresponds to the multiplicity resulting from "navigating" across the association given a value at one end of the association to the other end of the association.

Clause 8.4.4.5.1 (Associations) says

As endFeatures, the associationEnds of an Association are given a special semantics compared to other Features. Even if an associationEnd has a declared multiplicity other than 1..1, the associationEnd is required to effectively have multiplicity 1..1 as a participant in the Link. Note that the Feature Link::participant is declared readonly, meaning that the participants in a link cannot change once the link is created.

If an associationEnd has a declared multiplicity other than 1..1, then this shall be interpreted as follows: For an Association with N associationEnds, consider the i-th associationEnd ei. The multiplicity, ordering and uniqueness constraints specified for ei apply to each set of instances of the Association that have the same (singleton) values for each of the N-1 associationEnds other than ei.

Clause 8.3.3.3.3 (Feature) says

isEnd : Boolean
Whether or not the this Feature is an end Feature, requiring a different interpretation of the multiplicity of the Feature. An end Feature is always considered to map each domain instance to a single co-domain instance, whether or not a Multiplicity is given for it. If a Multiplicity is given for an end Feature, rather than giving the co-domain cardinality for the Feature as usual, it specifies a cardinality constraint for navigating across the endFeatures of the featuringType of the end Feature.

That is, if a Type has n endFeatures, then the Multiplicity of any one of those end Features constrains the cardinality of the set of values of that Feature when the values of the other n-1 end Features are held fixed.