ST6RI-897 Remove as much non-generated code as possible from EMF Impl classes

[seidewitz]

This PR removes certain non-generated code from the EMF Impl classes that was not removed by the update in PR #570.

Moved to postProcess

Moved non-generated code to the postProcess method of various adapter classes.

1. From the following getters and setters the adapter class corresponding to the Impl class:
   • CommentImpl.setBody
   • ElementImpl.setDeclaredName and setDeclaredShortName
   • FlowUsage.isAbstract
   • LiteralString.setValue
   • Membership.setMemberName and setMemberShortName
   • PortUsageImpl.isComposite
   • RequirementDefinition.setReqId
   • RequirementUsage.setReqId
   • TextualRepresentation.setLanguage and setBody
   • UsageImpl.isComposite
2. From FeatureImpl.isEnd to EndFeatureMembershipAdapter.postProcess.
   • Note. The ownedMemberFeature of an EndFeatureMembership now has its isEnd property set when parsed from the textual notation, but it is no longer set automatically if the relationship is created directly in the abstract syntax.
3. From FeatureImpl.isDirection to ParameterMembershipAdapter.postProcess.
   • Note 1. The ownedMemberParameter of a ParameterMembership (including a ReturnParameterMembership) now has its direction property set when parsed from the textual notation, but it is no longer set automatically if the relationship is created directly in the abstract syntax.
   • Note 2. The code for handling the direction of a FlowEnd moved to FlowEndAdapter.transform rather than postProcess. This cannot be handled in parse post-processing because the computation requires proxy resolution.

Moved to delegates

Moved non-generated code to setting or invocation delegates.

1. Updated CustomUML2EoreConverter so that the SysML EAnnotation is added to the properties Element::elementId, Feature::isNonunique and InvocationExpression::operand (the latter two of which are added to the Ecore metamodel by the converter). Non-generated code has then been moved into new setting delegates for these properties.

   1. Element.getElementId and setElementId – Element_elementId_SettingDelegate calls through to getElementId and setElementId methods on ElementAdapter, which also maintains the elementId state for an Element. If not set explicitly, an elementId is created using the createElementId method, which is overridden in NamspaceAdapter, LibraryPackageAdapter and OwningMembershipAdapter to handle creating stable IDs for library elements.
      • Note. Because Element::elementId has isId = true in the MOF abstract syntax model, the corresponding attribute in the Ecore metamodel was generated with ID = true. This meant that elementId was used internally by Eclipse as the ID for identifying objects within a resource. However, in certain cases, computation of elementId could trigger proxy resolution that searched for an object by ID, causing a circular elementId computation. To avoid this, CustomUML2EoreConverter has been updated to set ID = false for elementId. This does not affect the use of elementId as the XMI ID in serialized XMI files.
   2. Feature.isNonunique and setIsNonunique – Feature_isNonUnique_SettingDelegate gets and sets isNonunique as the logical inverse of isUnique.
   3. InvocationExpression.getOperand – InvocationExpression_operand_SettingDelegate calls through to the getOperand method on InvocationExpressionAdapter, which also maintains the operand state for an InvocationExpression, as an instance of org.omg.sysml.util.OperandEList. An OperandEList is a wrapper that, when an Expression is added to it, actually adds the Expression as an argument of the InvocationExpression.
      • Note. The operand mechanism is a workaround to make the Xtext grammar tractable for parsing operator expressions. For this to work, operand needs to be a containment reference, even though the resulting argument expression is actually contaned as the feature value of an owned parameter of the InvocationExpression. To avoid operand expressions from appearing duplicatively in serialized XMI for an InvocationExpression, it is not possible to read values back from an OperandEList (which is different than it worked before). Instead, Expression.getArgument must be used to get a normal list of the argument expressions of an InvocationExpression.

2. Moved the overriding of RenderingUsage.namingFeature to the new RenderingUsage_namingFeature_InvocationDelegate, which extends Feature_namingFeature_InvocationDelegate.

Enumeration default values

There are a number of cases in the KerML and SysML MOF abstract syntax models in which an enumeration property has no default value. In this case, the implemented EDEFAULT should be null. However, Eclipse always generates a non-null default for a property with an enumeration type. In these cases, the generated EDEFAULT declarations had been hand-modified to change the value to null and marked as @generated NOT. This PR does not change this non-generated code.

Redefined default values

There are a number of cases in the KerML and SysML MOF abstract syntax models in which a property is redefined in order to add a default value or change the default value of the redefined property. For example, the various subclasses of OperatorExpression redefine the operator property to give it a default value appropriate to that kind of expression (e.g., "collect" for a CollectExpression). This was previously implemented by hand-coded overrides of the getters for these properties in the corresponding Impl classes that returned the appropriate value (e.g., the getOperator method was overridden in CollectExpressionImpl to return "collect"). These overriding methods have now been removed and, instead, the appropriate default value is set in the Impl class constructor (e.g., operator = "collect"; in the CollectExpressionImpl constructor). The new approach still requires non-generated code in Impl class constructors. However, it more closely corresponds to the MOF semantics of default initial values.

KerML

1. ImportImpl.isImportAll – Set to true in the following:
   • MembershipExportImpl
   • NamespaceExportImpl
2. OperatorExpressonImpl.operator – Set to the appropriate operator in the following:
   • CollectExpression
   • FeatureChainExpression
   • IndexExpression
   • SelectExpression
3. RequirementConstraintMembershipImpl.kind – Set to RequirementConstraintKind.REQUIREMENT in the following:
   • FramedConcernMembership
   • RequirementVerificationMembership

Note. In addition, the EDEFAULT values for the above properties are also set to the redefined default value (e.g., operator = OPERATOR_EDEFAULT = "collect";). This ensures that the property is not serialized to XMI when it has the new default value. However, it requires that the EDEFAULT field declaration be changed so that it is no longer static final.

SysML

4. FeatureImpl.isComposite
   • Set to true in UsageImpl.
   • Set to false in the following:
     • AttributeUsageImpl
     • BindingConnectorAsUsageImpl
     • EventOccurrenceUsageImpl
     • ExhibitStateUsageImpl
     • IncludeUseCaseUsageImpl
     • PerformActionUsageImpl
     • ReferenceUsageImpl
     • SuccessionAsUsageImpl

Note. For kinds of SysML usages other than those listed above, the usage must be parsed with isComposite = true unless the keyword ref is included in the declaration, even though the default for KerML is isComposite = false. To implement this, isComposite is set to true in the constructor of UsageImpl, even though the default value for isComposite is not actually overridden in Usage in the SysML abstract syntax. However, the value for IS_COMPOSITE_EDEFAULT is not changed, and remains as false. This means that the serialization of isComposite to XMI will now be the same for SysML usages as for KerML features (that is, isComposite=true will always be serialized but isComposite=false will not). This is a change from the previous implementation, in which isComposite=false was incorrectly serialized for usages required to be referential.

Validation

In the above cases of the redefinition of the default value of a property, there are also validation constraints that require that the given default value not change. When previously implemented using overriding methods, these constraints were automatically satisfied and did not need to be checked. With the update in this PR, it is possible to change these properties in the abstract syntax representation to invalid values, so the relevant explicit validation checks have been implemented.

1. KerMLValidator
   • validateEndFeatureMembership
   • validateParameterMembership
   • validateCollectExpressionOperator
   • validateFeatureChainExpressionOperator
   • validateIndexExpressionOperator
   • validateSelectExpressionOperator
   • validateFlowEndIsEnd
2. SysMLValidator
   • validateUsageIsReferential
   • validateReferenceUsageIsReferential
   • validateAttributeUsageIsReferential
   • validateEnumerationDefinitionIsVariation
   • validateEventOccurrenceUsageIsReference
   • validatePortUsageIsReference
   • validateExposeIsImportAll (this was actually already implemented)

[himi]

I confirmed it works. I found we need to be more careful because before post processing, many critical features are not set, which is initiated by postProcessAllCrossReferences().

[seidewitz]

I confirmed it works. I found we need to be more careful because before post processing, many critical features are not set, which is initiated by postProcessAllCrossReferences().

Post-processing happens automatically after a model is parsed by Xtext, so it shouldn't be a problem when using the textual notation. However, you are correct that certain processing will now not be done automatically when a model is constructed in the abstract syntax, such as the un-escaping of names, or the setting of the direction of the owned parameter of a ParameterMembership. But the updated implementation is a more conformant with the abstract syntax per the specifications.