Bug 322715

Comment 1 Ed Willink 2011-05-08 05:59:01 EDT

There is a much simpler way.

UML2Ecore currently provides http://www.eclipse.org/uml2/1.1.0/GenModel annotations containing the OCL as strings.

If UML2Ecore provided the missing validationDelegate, invocationDelegate, and settingDelegate registrations for the http://www.eclipse.org/uml2/1.1.0/GenModel URI, rather than the http://www.eclipse.org/emf/2002/Ecore/OCL URI as suggested in comment #1, UML2 need do no more.

OCL can install a duplicate delegate registration handler for http://www.eclipse.org/uml2/1.1.0/GenModel and it can work.

Existing users just see three additional EPackage annotations.

Comment 2 Kenn Hussey 2011-05-08 21:54:24 EDT

It's too late in the release cycle to consider this change. We'll have to look at it in the next release (Juno).

Comment 3 Ed Willink 2013-01-28 12:37:44 EST

Bug 399253 involves joining the dots on:
- edit OCL in a Papyrus UML diagram
- convert *.uml to *.ecore
- use the OCL in a validation of an *.xmi dynamic instantiation/genmodeled instance

It's very nearly there. Problem is that UML2Ecore generates non-delegate OCL bodies.

Is the Comment #1 suggestion acceptable?

Comment 4 Kenn Hussey 2013-01-28 12:56:01 EST

(In reply to comment #3)
> Bug 399253 involves joining the dots on:
> - edit OCL in a Papyrus UML diagram
> - convert *.uml to *.ecore
> - use the OCL in a validation of an *.xmi dynamic instantiation/genmodeled
> instance
> 
> It's very nearly there. Problem is that UML2Ecore generates non-delegate OCL
> bodies.

I'll be looking at this enhancement as soon as M5 is released next week.

> Is the Comment #1 suggestion acceptable?

Perhaps, although it would seem preferable to do it the "standard" way. I'll be in a better position to decide once I've taken a closer look at the problem after M5.

Comment 5 Kenn Hussey 2013-02-01 10:32:14 EST

FYI, I've started looking at this and am optimistic that I'll have support for OCL validation and invocation delegates done soon, hopefully even in time for M5. I'll be supporting these via new "Validation Delegates" and "Invocation Delegates" options in the converter which specify whether invariant constraints and operation bodies (respectively) should be handled with delegates.

Is there a standard way for property derivations to be defined in OCL yet, or are there still only conventions? Does UML 2.5 specify them in an organized way? OCL setting delegates can effectively already be supported via the annotation tag in the Ecore profile, but if we want "first class" support I'll need some more input (and probably a separate bug since it's new territory for the converter)...

Comment 6 Ed Willink 2013-02-01 12:08:40 EST

The OCL spec is very confusing, but if you read very carefully you find the underlying intent. My current interpretation is that:

An <initial> Value Property expression is a default value initializer. i.e an OCL representation of the Property's defaultValue ValueSpecification.

A <derived> Value Property 'expression' is actually a constraint, whose context is the Property's owner and whose OCL is a constraint expressed in terms of that self context. There is no real semantic difference between this and a class invariant. There is a minor practical difference in that a <derived> Property constraint has a constrainedElement identifying the Property.

Historically Eclipse OCL has not always appreciated this and so has tended to treat a derived value expression as an override of an initial value; this is wrong.

I think you'll find that the existing UML2Ecore EAnnotations are remarkably close; just needs some namespace tweaking and the delegates EPackage header.

You might take the same view as EMF GenModel for Xcore. Newly created EMF GenModels have new coherent functionality (Operation Reflection). Old GenModels default to traditional functionality.

GIT\org.eclipse.ocl\tests\org.eclipse.ocl.examples.xtext.tests\model\Company.ecore should have examples of everything.

http://wiki.eclipse.org/MDT/OCLinEcore might be the delegates spec.

Comment 7 Kenn Hussey 2013-02-01 14:00:12 EST

(In reply to comment #6)
> The OCL spec is very confusing, but if you read very carefully you find the
> underlying intent. My current interpretation is that:
> 
> An <initial> Value Property expression is a default value initializer. i.e an
> OCL representation of the Property's defaultValue ValueSpecification.
> 
> A <derived> Value Property 'expression' is actually a constraint, whose context
> is the Property's owner and whose OCL is a constraint expressed in terms of that
> self context. There is no real semantic difference between this and a class
> invariant. There is a minor practical difference in that a <derived> Property
> constraint has a constrainedElement identifying the Property.

Yeah, that confirms my suspicion that things aren't yet defined well enough around property derivations for me to arrive at the "right" solution at this time. Best to focus on validation and invocation delegates for now, methinks (especially since the UML metamodel uses operations to define derivations for derived properties currently anyway).

> Historically Eclipse OCL has not always appreciated this and so has tended to
> treat a derived value expression as an override of an initial value; this is
> wrong.

Doh.

> I think you'll find that the existing UML2Ecore EAnnotations are remarkably
> close; just needs some namespace tweaking and the delegates EPackage header.

Yes, and I've already done that for validation and invocation delegates...

> You might take the same view as EMF GenModel for Xcore. Newly created EMF
> GenModels have new coherent functionality (Operation Reflection). Old GenModels
> default to traditional functionality.

I don't want to assume just how folks want to handle their invariant constraints and operation bodies; the new options will be there should they want to turn them on.

> GIT\org.eclipse.ocl\tests\org.eclipse.ocl.examples.xtext.tests\model\Company.ecore
> should have examples of everything.

I was already aware of how things need to look from an Ecore perspective (since I added support for delegates to EMF); I was looking for guidance on the "right" way to represent these things in UML/OCL.

> http://wiki.eclipse.org/MDT/OCLinEcore might be the delegates spec.

Yeah, I've seen this before too. Thanks.

Comment 8 Ed Willink 2013-02-01 14:16:27 EST

Class Invariants and Operations will be good.

But I see no problem in mapping an OCL-languaged (or default-languaged) OpaqueExpression) Property default value to an OCL <initial> EStructuralFeature EAnnotation.

UML doesn't really distinguish <derived> property constraints so just ignore them; class EAnnotations will do fine.

Comment 9 Kenn Hussey 2013-02-01 14:35:57 EST

Converter options have been added to support validation and invocation delegates, and the UML2 code generator has been fixed to work properly with them. Support for setting delegates, if/when needed, should be done in response to a separate bug/enhancement.

The changes have been committed and pushed to the 'master' branch in git.

Comment 10 Kenn Hussey 2013-02-01 14:57:38 EST

A UML2 4.1 integration build containing the changes is now available.