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.
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.
validateFeatureChainingFeatureConformance – Each chainingFeature (other than the last) must conform to all the featuringTypes of the next Feature in the chain.
validateRedefinitionDirectionConformance – If the redefinedFeature of a Redefinition has a non-null direction, then the redefiningFeature must have the same direction.
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.
validateBindingConnectorTypeConformance – Either the first end of a BindingConnector should conform to the second, or vice versa.
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 22.214.171.124 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.]
validateExpressionResultExpressionMembership – An Expression must own at most one ResultExpressionMembership.
validateFunctionResultExpressionMembership – A Function must own at most one ResultExpressionMembership.
validateFeatureChainExpressionConformance – The featuringTypes of the targetFeature of a FeatureChainExpression must conform to the result parameter of the argument Expression of the FeatureChainExpression.
validateFeatureReferenceExpressionReferentIsFeature – The first Membership of a FeatureReferenceExpression that is not a ParameterMembership must have a Feature as its memberElement.
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.
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.
validateSelectExpressionOperator – The operator of a SelectExpression must be “select”.
validateFeatureValueOverriding – All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues.
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.