[OCLInEcore] Templates: Incorrect abstract syntax

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 427560 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 06, 2014 08:32 EDT | | Modified | Feb 07, 2014 11:28 EDT | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

M5.

Repro:

1. Open the templatexEx.oclinecore of the attached project (coming next).
2. Right click on the editor -> OCL -> Save -> AbstractSyntax
3. Open the created .oclas file -> In the synthetised Class T of the TemplateParameter contains a couple of non-sensible properties (or which I don't understand).

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 06, 2014 08:32

Created attachment 239696 project with example

:compression: templatesExample.zip

[eclipse-ocl-bot]

By Ed Willink on Feb 07, 2014 02:39

The properties have opposites with isImplicit true so they represent the reification of an unnavigable opposite; all opposites exist in the pivot.

Since both have the same opposite, there is a bug; only one should be present.

Looking at the XMI:

opposite="#//@nestedPackage.0/@ownedType.0/@ownedTemplateSignature/@ownedParameter.0/@ownedParameteredElement/@ownedAttribute.1"

is a bit long; it would help if the opposite had an xmi:id, which would diagnose the problem when AS2XMIis detects the duplicate.

---

Looks as if MetaModelmanager.installPropertyDeclaration is failing to re-use a pre-existing unnavigable opposite.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 07, 2014 10:14

Those Properties are incrementally appearing after editing.

Problem is in BaseCSPostOrderVisitor::visitReferenceCS (line 284)

The (AS) Property indeed has an opposite

ReferenceCS.getPivot().getOpposite is not null

However

ReferenceCS.getOpposite() is null

I could come up with many questions about why these CS-AS cross-references, but that's another concern.

I'll let you decide how to proper solve the issue. With the fix I might understand what's going on around those CS-AS cross-references.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Feb 07, 2014 10:53

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #3)

However

ReferenceCS.getOpposite() is null

The CS is not a pivot model so it has normal null/non-null Ecore-style opposites.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 07, 2014 11:28

Created attachment 239747 CS-AS cross-reference screenshot

Hi Ed,

I don't understand you... What is a "normal null/non-null Ecore-style opposites." an EOpposite ?...

ReferenceCS clearly has a cross-reference to the opposite (pivot) property. See attachment There is an inconsistency. Perhaps some OCL terminology helps. I understand that the following invariant should be true:

Context ReferenceCS inv: self.opposite = self.pivot.oclAsType(Property).opposite

But it's not. if you debug BaseCSPostOrderVisitor::visitReferenceCS, whereas the RHS expressions returns the expected opposite property, the LHS is returning a null.

Due to the fact that the LHS expression is used (line 284) and it's always returning null, the opposite property is being installed many times (at line 294).

A potential fix could be at line 284: Property pivotOpposite = pivotElement.getOpposite()

However, I don't know what's going on with that ReferenceCS::opposite cross-reference. Why is it there? Should it be populated somewhere else ? Should it be derived ? I've seen other similar CS-AS cross reference, I guess that some name-resolution related activity is the reason, but...

I'll wait for the final fix/correct fix to better understand rather than speculate.

Capture.PNG