[validation] Add EStructuralFeature to validation diagnostic

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 465397 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 24, 2015 05:51 EDT | | Modified | May 19, 2015 09:54 EDT | | See also | 467577 | | Reporter | Ed Willink |

Description

The "EMFForms Validation using Complete OCL" thread on eclipse.technology.emft identified that Complete OCL could be used with EMF FOrms but that validation warnings do not appear in the EMF Form.

It would appear that an OCL diagnostic comprises Diagnostic.data[] comprising the EObject, whereas EMF Forms requires [EObject, EStructuralFeature].

Add the additional information.

Repro in: news://news.eclipse.org:119/mgnkku$uvj$1@news.eclipse.org

[eclipse-ocl-bot]

By Ed Willink on Apr 24, 2015 06:23

Add the additional information.

Not so simple. (Classic OCL and Pivot OCL are the same here.)

When embedded in Ecore, an OCL constraint such as:

self.ucName = self.name.toUpperCase()

is defined for the EClass, therefore it is the EClass that is entered in Diagnostic.data[] as the offender. How do we know whether "ucName" or "name" could/should be an additional Diagnostic.data[] element?

(In UML, there is a poorly specified Constraint::constrainedElement that could be interpreted as providing extra context.)

The best we can do in Ecore is a heuristic.

Perhaps each "self.X" in the OCL constraint identifies "X" as a co-offender.\ Perhaps transient/derived/volatile are excluded to reduce multiples.\ Do we have to follow operation calls to discover indirect "self.X" references?

What is the custom and practice? Would reporting a three-valued data[] comprising object, EStructuralFeature, another EStructuralFeature cause different trouble?

Simpler just to add "X" from the lexically first "self.X" since with constraints written as "expected = computed" we should find the first "self.X" in "expected". Users can easily recode, perhaps using a let-variable, to get a desired effect.

NB "self.X" is for clarity, the above discussion apples to implicit self, i.e. "X" too.

[eclipse-ocl-bot]

By Ed Willink on May 06, 2015 07:12

(In reply to Ed Willink from comment #1)

The best we can do in Ecore is a heuristic.

Consider:

context Operation\ inv UniquePreconditionName: ownedPreconditions->isUnique(name)

Currently this causes the Operation to be highlighted with a warning giving a multi-line squiggle on all pre-conditions, post-conditions, body, ... unhelpful.

A "first self.x term" heuristic would trim the squiggle to all the pre-conditions.

(A narrower squiggle on only the offending pre-conditions requires a semantic or perturbation analysis of isUnique.)

[eclipse-ocl-bot]

By Ed Willink on May 19, 2015 09:54

(In reply to Ed Willink from comment #1)

When embedded in Ecore, an OCL constraint such as:

self.ucName = self.name.toUpperCase()

is defined for the EClass

But it could also be defined as derived property, leaving no doubt.

The Pivot representation is a clarification of mush, so we could choose to represent derived properties as Property constraints, with a bloated "self.x = " prefix when in AS form. Again no doubt as to the localization of the diagnostic.

In UML, we could use the Constraint.constrainedElement to choose whether to convert UML Class invariants to Pivot Class/Property invariants.

Too big a change for post-RC1. See also Bug 467577.