Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338052

Summary:	[evaluator] Support fine-grained constraint evaluation and control
Product:	[Modeling] OCL	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	OCL Inbox <mdt-ocl-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	eclipse
Version:	3.1.0	Flags:	ed: luna+
Target Milestone:	M7
Hardware:	PC
OS:	Windows Vista
Whiteboard:	Usability

Description Ed Willink

2011-02-24 03:06:24 EST

[Axel: after re-reading your description of Impact Analysis and EMF Editor integration, it was much more obvious. Must have been a 'blonde' day.]

A facility that I think TopCased offers is a check box overview of the available constraints so that there is a hierarchical GUI context for failures, rather than the flat problem view, and so that individual constraints can be switched off and retried.

This seems like a natural extension of the Revalidator EMF Editor integration. With the Impact Analyzer offering a much more complex suite of validations, a much stronger GUI is probably useful.

In principle this should not be OCL-specific, so it would be good to make the facility neutral so that it can migrate to EMF, if and when, the Event Manager migrates. Since TopCased is a semi-Eclipse project, it may be possible to acquire their code as a starting point. If so, do minor renaming, get IP approval, then enhance.

Comment 1 Axel Uhl

2011-02-24 03:18:41 EST

Particularly the generalization you're mentioning sounds more like pertaining to the EMF Validation project.

Are you suggesting to not let OCL constraint violations flow into the regular problem view? I would have assumed that the problem view was a natural place to visualize and manage constraint violations, also because it nicely integrates EMF-based editors with non-EMF-based ones.

Comment 2 Ed Willink

2011-02-24 05:34:33 EST

(In reply to comment #1)
> Particularly the generalization you're mentioning sounds more like pertaining
> to the EMF Validation project.

Could be. But someone needs to develop this code and EMFv is short of active developers, so if we want it for our userrs we will have to do it.

> Are you suggesting to not let OCL constraint violations flow into the regular
> problem view?

No. But note that the ProblemView should be populated by the decisions of the designated builder. The EMF editor is a little irregular in leaking an interactive 'Validate' into the Problem View without any mechanism to refresh stale problems during a project rebuild.

> I would have assumed that the problem view was a natural place to
> visualize and manage constraint violations, also because it nicely integrates
> EMF-based editors with non-EMF-based ones.

I'm suggesting a new 'Validation View' that gives a more controllable display than the ProblemView, and a more controllable invocation then select-object-then-validate.

To resolve the EMF builder issue, perhaps the ValidationView has a preferred set of validations that a builder propagates to the Problem View, and alternate interactive selections that are just for experimentation.

Comment 3 Ed Willink

2014-05-27 12:24:46 EDT

Validation View is available for Luna. Maybe promote to EMFv for Mars.

Comment 4 Ed Willink

2015-05-25 17:20:22 EDT

CLOSED after more than a year in the RESOLVED state.