eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[validation] Complete OCL standalone validation fails for extended meta-models #1371

Closed eclipse-ocl-bot closed 1 week ago

eclipse-ocl-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 441132 | | Status | RESOLVED WORKSFORME | | Importance | P3 normal | | Reported | Aug 05, 2014 03:08 EDT | | Modified | Aug 07, 2014 16:18 EDT | | Version | 5.0.0 | | Reporter | Rolf Theunissen |

Description

Standalone Complete OCL validation fails in the following case.

Take the following Meta-models

meta-model A\ meta-model B extends meta-model A

meta-model A defines an Enumeration 'EnumA'.

Take an ocl file with contents similar to:\ import 'modelA.ecore#/'

package modelA

context ClassA\ inv InvariantA : attrA != EnumA::Item1

Register a this ocl file with a CompleteOCLEObjectValidator for metamodel A:

EValidator.Registry.INSTANCE.put(aPackage, new CompleteOCLEObjectValidator(...))

Now, validation of instances of meta-model B succeed as long as the model is not persisted. When the model is saved to an xmi file, and is validated to following error occurs:

The 'ClassA::InvariantA' constraint result is invalid for 'ClassAImpl@2be0f493{1950A/resource.xmi#_13xhmiir8x4l0}'

Workaround for this bug is, register an EObjectValidator for metamodelA as well:

EValidator eValidator = EValidator.Registry.INSTANCE.getEValidator(aPackage);\ if (eValidator == null) {\ EValidator.Registry.INSTANCE.put(ePackage, new EObjectValidator());\ }

ComposedEValidator cEValidator = ComposedEValidator.install(ePackage); \ CompleteOCLEObjectValidator oclEValidator = new CompleteOCLEObjectValidator(...)\ composedEValidator.addChild(oclEValidator);

Now validation of instances of model B succeed.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Aug 05, 2014 03:17

Please attach your exact repro. I suspect that the problem is a bit different and so your workaround may be unnecessary once the true bug is fixed.

eclipse-ocl-bot commented 1 week ago

By Rolf Theunissen on Aug 05, 2014 08:42

I might have made a mistake in this case. We are trying to track a bug or configuration error in our implementation, turns out, the it is not the described issue here.

The true problem here was an mandatory attribute, that is not set. However the default ecore validation output is not provided, only (cryptic) OCL validation output is provided. When setting the 'Workaround' the default ecore validation is provided (and the extended OCL validation is hidden).

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Aug 05, 2014 08:54

(In reply to Rolf Theunissen from comment #2)

The true problem here was an mandatory attribute, that is not set. However the default ecore validation output is not provided, only (cryptic) OCL validation output is provided. When setting the 'Workaround' the default ecore validation is provided (and the extended OCL validation is hidden).

Still worth a repro; maybe we can do better for the next user.

eclipse-ocl-bot commented 1 week ago

By Rolf Theunissen on Aug 05, 2014 09:23

Created attachment 245725 Example to show the output of validation

Validation output with workaround disabled:

Diagnosis of metamodelA.impl.RootImpl@144d91c5{model/modelA.xmi#/} The 'ClassA2::Invariant1' constraint result is invalid for 'metamodelA.impl.ClassA2Impl@542955e3{model/modelA.xmi#//@classesA2.0}'

Validation output with workaround enabled:

Diagnosis of metamodelA.impl.RootImpl@7c90f004{model/modelA.xmi#/} The required feature 'classA1ref' of 'metamodelA.impl.ClassA2Impl@5464f610{model/modelA.xmi#//@classesA2.0}' must be set The 'ClassA2::Invariant1' constraint is violated for 'metamodelA.impl.ClassA2Impl@72749130{model/modelA.xmi#//@classesA2.1}'

:compression: org.examples.metamodelA.zip

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Aug 07, 2014 16:18

The problem is that your model has no validation of its own. This is an EMF asymmetry that has caught me out in the past. Raise an EMF bug if you want, but why should EMF impose a validation registration for all the models that have no constraints?

Two more workarounds:

a) Add a constraint to your model so that MetamodelAValidator is installed by package registration and so extended by the Complete OCL Validator.

b) add a default validator to the composed validator

composedEValidator.addChild(new EObjectValidator());

The Javadoc for CompleteOCLEObjectValidator is:

/**

No claim to perform EMF validation so I think the behaviour you observe is correct. Any attempt to help would cause trouble to other sensible usages.


You can make the OCL constraint less obscure by installing a SubstitutionLabelProvider

Map<Object, Object> contextEntries = new HashMap<Object, Object>();\
contextEntries.put(EValidator.SubstitutionLabelProvider.class, DomainSubstitutionLabelProvider.INSTANCE);\
Diagnostic diag = Diagnostician.INSTANCE.validate(model, contextEntries);

You then get

The 'ClassA2::Invariant1' constraint result is invalid for 'Root::ClassA2'