Open eclipse-ocl-bot opened 2 months ago
By Ed Willink on Dec 08, 2018 04:45
(In reply to Ed Willink from comment #0)
An initial synthesis problem from a duplicate Class.Class implicit opposite requires a safe-name generation in the PivotTables synthesis.
Perhaps, but UML2EcoreAnalyzer.qvto already has a duplicateUnnavigableOpposites diagnosis that fails to identify the hazrad. Of course there is so much debug output that the diagnosis would be swamped anyway. Time for a tidy up.
By Ed Willink on Dec 10, 2018 13:44
(In reply to Ed Willink from comment #0)
An initial synthesis problem from a duplicate Class.Class implicit opposite requires a safe-name generation in the PivotTables synthesis.
No. PivotMetamodelManager.getPrimaryProperty is broken if the argument is an ambiguous implicit opposite.
Fixed. Ambuiguites are now faithfully modeled in *Tables.java (so that an attempt to use them reports the anomally).
By Ed Willink on Dec 11, 2018 12:55
(In reply to Ed Willink from comment #1)
Perhaps, but UML2EcoreAnalyzer.qvto already has a duplicateUnnavigableOpposites diagnosis that fails to identify the hazrad.
No. The unnavigable opposite detection rlies on the full UML modeling so that a naivable property is an Association.memberEnd (not onwnedEnd) whereas an unnavigable property (opposite) is an Association.ownedEnd.
Pragmatic Association-less properties do not 'work'.
The PivotMetamodelManager.getPrimaryProperty fix is therefore all that is required.
Pushed to master for 2019-03M1.
By Ed Willink on Dec 19, 2018 01:48
(In reply to Ed Willink from comment #3)
The PivotMetamodelManager.getPrimaryProperty fix is therefore all that is required.
It certainly helps. But ...
Pragmatic Association-less properties do not 'work'.
The synthesis supports the following use cases.
unidirectional: Class-owned-Property => EStructuralFeature
fully navigable bidirectional: Class-owned-Property + Association + Class-owned-Property => EReference + EReference
Not supported:\ partially navigable bidirectional: Class-owned-Property + Association + Association-owned-Property => EReference + EAnnotation
The not-supported use-case is not used by OCL.uml. It is widely used by UML.xmi, but few if any go through the synthesis without deletion/renaming. The lack of support is therefore perhaps fudged by renaming pragmatisms.
Immediate problem worked around by not naming the opposite of Class.resolvedClass; after the duplicate *Tables Java symbol is fixed.
| --- | --- | | Bugzilla Link | 542544 | | Status | REOPENED | | Importance | P3 normal | | Reported | Dec 08, 2018 04:21 EDT | | Modified | Dec 19, 2018 01:48 EDT | | Blocks | 542534 | | Reporter | Ed Willink |
Description
Bug 542534 reports some problems when introducing Class.resolvedBy/resolutionFor.
An initial synthesis problem from a duplicate Class.Class implicit opposite requires a safe-name generation in the PivotTables synthesis.
The workaround problem whereby an attempt to declare Class.resolutionFor as in unnavigable opposite is ignored. The QVTo transformation is reifiying all pivot properties. (All properties exist in a Pivot metamodel; one end optionally annotated as isImplicit. Instances of the pivot metamodel do not have to have reified opposites; isImplicit controls reification.)