search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[validation] Quadratic diagnostics for multiple Complete OCL validators #1663

Open eclipse-ocl-bot opened 1 day ago

eclipse-ocl-bot commented 1 day ago

| --- | --- | | Bugzilla Link | 486872 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 29, 2016 16:43 EDT | | Modified | Feb 01, 2016 05:48 EDT | | Reporter | Ed Willink |

Description

Created attachment 259457\ demo project

The attached project from the "EMF validation with several OCL documents" OCL newsgroup thread use two CompleteOCLEObjectValidator for two Complete OCL documents. This results in duplicate diagnostics.

Problem is that each Complete OCL validator validates all Complete OCL constraints.

:compression: CompleteOCLTest.zip

eclipse-ocl-bot commented 1 day ago

By Ed Willink on Jan 29, 2016 17:34

This is similar to the over-validation of Bug 468843, for which a PivotEObjectValidator.complementingModels enables validation to be model-filtered.

Exploiting this in CompleteOCLEObjectValidator can solve the problem, but gives a regression on testValidate_Validate_completeocl where there is a Complete OCL / OCLinEcore hybrid. Correct an OCLinEcore cpnstraint is diagnosed by the CompleteOCLEObjectValidator.

However this is a rather silly way to go. With three validators each attempts all constraints and rejects two thirds. Much better to support a MultiCompleteOCLEObjectValidator so that one validation pass does everything.

Need both approaches:

If Complete OCL is added/removed by independent clients they must be isolated.

If multiple Complete OCL documents are added by a simple client a multi-document constructor will be better.

eclipse-ocl-bot commented 1 day ago

By Ed Willink on Feb 01, 2016 05:48

(In reply to Ed Willink from comment #1)

If multiple Complete OCL documents are added by a simple client a multi-document constructor will be better.

This is pretty easy: branch ewillink/486872

But elaboration of the testValidate_Validate_completeocl JUnit test seems to detect a new bug; two separate *.oclinecore imports conflict. Needs more work. Not high enough priority now. There is a workaround.