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.