ST6RI-937 Variants are incorrectly referential

[seidewitz]

This PR corrects the computation of an effective featuringType of a Usage in the postProcess method for UsageAdapter.

Background

Previously, the UsageAdapter::postProcess methods contained the code:

if (target.getDirection() != null || target.isEnd() || 
	// Note: A parsed Usage can only get a featuring type if it is owned via a FeatureMembership.
	!(target.eContainer() instanceof FeatureMembership)) {
	target.setIsComposite(false);
}

The comment note in this code is incorrect. A variant usage is owned by a VariantMembership, which is not a FeatureMembership, but, per semantic constraint checkUsageVariationUsageTypeFeaturing, has the same featuring types as its owning variation, which can be non-empty.

Note that the reason getFeaturingType isn’t just called here is to avoid computing derived values during parse post-processing.

Changes

In project org.omg.sysml.logic:

1. UsageUtil – Added:
   • getExpectedFeaturingType – Gets the expected featuringType for a Usage, assuming limitations in the SysML syntax. This is computed recursively as the owningType of the nearest non-variation container if this exists. Note that the special featuringTypes for variable features are skipped in this computation (not necessary for how this utility is used in postprocessing).
   • hasFeaturingType – Whether getExpectedFeaturingType is non-null, meaning the Usage will have a FeaturingType.
2. UsageAdapter – Revised the method postProcess to use UsageUtil.hasFeaturingType in the condition on whether to set isComposite to false.
3. PortAdapter – Revised the method postProcess to use UsageUtil.getExpectedFeaturingType. This revision was necessary because the change to UsageAdapter resulted in variant PortUsages being considered composite, violating the constraint validatePortUsageIsReference.

Test

• org.omg.sysml.logic.UsagePostProcessTest

[AxelRICHARD]

@seidewitz I don't have any other comments on this pull request. You can merge it.