Static profile OCL expression fail to resolve correct values at runtime

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 571494 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Feb 25, 2021 00:58 EDT | | Modified | Aug 02, 2021 15:29 EDT | | Depends on | 571005 | | See also | 571407, 573843 | | Reporter | Deniz Eren |

Description

Created attachment 285660\ Example model and profiles

Please see this new uploaded profile and model issue.

Here I've modelled as an example the Roulette numbers 11, 12, 13, 14 and made up some model to show the parity and colour. However the model derived properties fail to identify even Colour.allInstances() in derived properties "colour_fails" and "parity_fails". The more complex derived property also subsequently fail.

:compression: ValidationProblem11.tar.gz

[eclipse-ocl-bot]

By Ed Willink on Feb 26, 2021 04:33

Bug 571407 has been marked as a duplicate of this bug.

[eclipse-ocl-bot]

By Ed Willink on Feb 26, 2021 04:35

From Bug 571407:

Ok. Time for a bit of analysis.

Non-overlapping multiple same-interface inheritance (no redefinitions). Multiple contributions are reified as multiple sub-objects in Ecore or multiple instances in UML. Ecore needs renaming to avoid collisions. OCL just accesses a name and requires a qualifier to disambiguate.

Overlapping/diamond multiple inheritance is achieved by redefinitions that unify the inherited features. Since Ecore has an interface/implementation distinction, the implementation can fold the redefined features, which are all accessed by virtual methods. Whereas I might have expected a redefining feature to redirect to the redefined feature, UML2 rather implements the redefined feature as a redirection to the redefining feature; this policy works for a four way redefinition; 4 redirect to 1 rather than 1 to 4.

Multiple UML instances could work the same way. Probably need to duplicate the new static profile cases as non-static. See Bug 571496.

OCL just uses the feature. The problem is to find the EStructuralFeature for the UML/Pivot Property tolerating UML2Ecore's renaming and then to find the GenFeature for the EStructuralFeature tolerating the selective existence of overriding GenFeatures.

The current solution based on same/new name in the Ecore space seems only partially accurate for the case of abstract classes. Surely there is a more reliable approach based on original names for which an ambiguous reference is illegal OCL?

[eclipse-ocl-bot]

By Ed Willink on Feb 26, 2021 04:49

Use of names is never a good idea and we don't need names or originalNames here.

The Pivot model is initially created as a UML2Pivot conversion. Subsequently the Ecore profile equivalent is overlaid by the Ecore2Pivot with the originalName ensuring accurate overlay.

During CG the UML/Pivot Property to EStructuralFeature conversion is accurately provided by the Ecore ES Object from the Ecore profile complete model overlay.

Subsequently the EStructuralFeature to GenFeature is possible by finding the GenFeature.ecoreFeature that contains the required value; names not needed. Once the GenFeaure is available the spelling required in Java is known.

Real EStructuralFeatures have an EClass container, pseudo-EStructuralFeatures have an EAnnotation container and an EAnnotation.references redirecting one level of redefinition.

The actual EStructuralFeature is therefore available as the transitive closure of the EAnnotation.references, retaining only EClass-contained features. There must be at least one result. There may be many corresponding to the many identical diamond arms, so we can just use the first.

This approach solves the earlier static profile CG cases and fixes the OCL CG for this repro too.

Unfortunately UML2 Bug 571005 problems lead tio numerous errors in the UML2 generated Java.

[eclipse-ocl-bot]

By Deniz Eren on Mar 02, 2021 04:35

Ed, I'm not sure I follow, but if you want me to test any interim fix attempts or version, please let me know.

[eclipse-ocl-bot]

By Ed Willink on Mar 02, 2021 08:47

You should find that the OCL2Java bug is fixed in yesterday's RC1 release.

Unfortunately the bugs in UML2Ecore2Java remain and are outside my purview.

[eclipse-ocl-bot]

By Deniz Eren on Mar 02, 2021 19:08

Hi Ed, do you know if UML2Ecore2Java is actively developed now days? I’m just worried if the needed people are aware of the tickets we’ve raised..

[eclipse-ocl-bot]

By Ed Willink on Mar 03, 2021 02:52

Certainly not actively developed but there are two committers who occasionally contribute.

[eclipse-ocl-bot]

By Deniz Eren on Mar 04, 2021 13:26

Should we move the product field to UMLGen - Java?

[eclipse-ocl-bot]

By Ed Willink on Mar 04, 2021 13:40

No. It depends on Bug 571005 which is a UML2 bug.

[eclipse-ocl-bot]

By Ed Willink on Mar 10, 2021 02:34

OCL issue fixed in 6.14.0

[eclipse-ocl-bot]

By Ed Willink on Jul 20, 2021 07:57

The implementation of this and the the general tidying up of too-many GenModel helpers provided an optimization that AbstractGenModelHelper.getGenFeature searched for an EStructuralFeature rather than name match. This failed for GenerateOCLstdlib so the EStructuralFeature match is followed by a name match accommodating the schizophrenia between installed and generated OCLstdlib.