KERML — Validation constraints are missing in the KerML abstract syntax

The following validation constraints are implied by textual descriptions in the specification, but are missing in the abstract syntax. They should be added, along with appropriate OCL.

8.3.3.1.10 Type

validateTypeOwnedUnioningNotOne – A Type must not have exactly one ownedUnioning.

validateTypeOwnedIntersectingNotOne – A Type must not have exactly one ownedIntersecting.

validateTypeOwnedDifferencingNotOne – A Type must not have exactly one ownedDifferencing.

8.3.3.3.3 Feature

validateFeatureChainingFeatureConformance – Each chainingFeature (other than the last) must conform to all the featuringTypes of the next Feature in the chain.

8.3.3.3.8 Redefinition

validateRedefinitionDirectionConformance – If the redefinedFeature of a Redefinition has a non-null direction, then the redefiningFeature must have the same direction.

8.3.3.3.10 Subsetting

validateSubsettingMultiplicityConformance – If the subsettingFeature of a Subsetting has a multiplicity that is a MultiplicityRange, then this must be consistent with the MultiplicityRange (if any) of the subsettedFeature (if the multiplicity bounds are model-level evaluable).

validateSubsettingUniquenessConformance – The subsettingFeature of a Subsetting must not have isUnique = false if the subsettedFeature has isUnique = true.

8.3.4.5.2 BindingConnector

validateBindingConnectorTypeConformance – Either the first end of a BindingConnector should conform to the second, or vice versa.

8.3.4.5.3 Connector

validateConnectorAssociationEnds – All associations typing a Connector must have the same number of associationEnds, which are the same as the number of relatedFatures of the Connector.
[Note: See the statement in 7.4.6.2 Connector Declaration on this.]

validateConnectorTypeFeaturing – If a Connector has an owningType or (non-implied) ownedTypeFeaturings, then each of its relatedFeatures must have some featuringType of the Connector as a direct or indirect featuringType.
[Note: This validation constraint corresponds to the semantic constraint checkConnectorTypeFeaturing, in the case that the semantic constraint is not able to be satisfied by adding implied TypeFeaturings.]

8.3.4.7.3 Expression
validateExpressionResultExpressionMembership – An Expression must own at most one ResultExpressionMembership.

8.3.4.7.4 Function
validateFunctionResultExpressionMembership – A Function must own at most one ResultExpressionMembership.

8.3.4.8.3 FeatureChainExpression

validateFeatureChainExpressionConformance – The featuringTypes of the targetFeature of a FeatureChainExpression must conform to the result parameter of the argument Expression of the FeatureChainExpression.

8.3.4.8.4 FeatureReferenceExpression

validateFeatureReferenceExpressionReferentIsFeature – The first Membership of a FeatureReferenceExpression that is not a ParameterMembership must have a Feature as its memberElement.

8.3.4.8.5 InvocationExpression

validateInvocationExpressionParameterRedefinition – Each input parameter of an InvocationExpression must redefine a feature of a type of the InvocationExpression.

validateInvocationExpressionNoDuplicateParameterRedefinition – Two different parameters of an InvocationExpression must not redefine the same feature of a type of the Invocationexpression.

8.3.4.8.14 OperatorExpression

validateOperatorExpressionCastConformance – If an OperatorExpression is for the cast operator (as), then the types of the result of the argument of an OperatorExpression must conform to the target types of the cast.

8.3.4.8.15 SelectExpression

validateSelectExpressionOperator – The operator of a SelectExpression must be “select”.

8.3.4.10.2 FeatureValue

validateFeatureValueOverriding – All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues.

8.3.4.12.3 MetadataFeature

validateMetadataFeatureMetaclassNotAbstract – The metaclass of a MetadataFeature must not be abstract.

validateMetadataFeatureAnnotatedElement – The annotatedElement of a MetadataFeature must have an abstract syntax metaclass consistent with the annotatedElement declarations for the MetadataFeature.

validateMetadataFeatureBody – Each ownedFeature of a MetadataFeature must have no declared name, redefine a Feature owned by a supertype of the MetadataFeature, either have no featureValue or a featureValue with a value Expression that is model-level evaluable, and only have ownedFeatures that also meet these restrictions.

Add missing constraints

Most of the new constraints proposed in the issue description are added to the abstract syntax. However, the following are not included, or are different from what was suggested, for the reasons given below.

1. validateRedefinitionFeatureConformance – Allows an inout direction to be redefined as in or out as well as inout.
2. validateSubsettingMultiplicityConformance – Not included. This will be considered separately with other issues related to multiplicity semantics.
3. validateBindingConnectorTypeConformance – Not included. For semantic reasons, this and other type-checking constraints will be considered separately (see also the discussion on KERML-127).
4. validateConnectorAssociationEnds – Not included. This constraint was intended to formalize a statement made in subclause 7.4.6.2 of the Language Description. However, enforcing this would prevent an n-ary connector from declaring ends, since the base connector Links::Link has no ends. Instead, the relevant paragraph in 7.4.6.2 is rewritten.
5. validateConnectorTypeFeaturing – Not included. This constraint was intended to provide a validation check of checkConnectorTypeFeaturing in case it is not possible to add an implied relationship to satisfy that constraint. However, it is sufficient for a tool to just report that checkConnectorTypeFeaturing cannot be satisfied in this case.
6. validateExpressionResultExpressionMembership and validateFunctionResultExpressionMembership – Check all memberships (owned or inherited), not just ownedMemberships. Checking for just owned ResultExpressionMemberships would still allow a Function or Expression to inherit multiple result expressions from multiple supertypes, which would not have any clear meaning.
7. validateOperatorExpressionCastConformance – Not included. This is essentially another type-checking constraint, which will be handled separately.