Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCLinEcore issues with derived attributes/operations
OCLinEcore issues with derived attributes/operations [message #555335] Thu, 26 August 2010 11:26 Go to next message
Joern is currently offline JoernFriend
Messages: 22
Registered: March 2010
Junior Member
I am trying to enhance an Ecore model with several constraints. What is the technical difference in the implementation using OCL operations and derived, volatile attributes? In fact the same OCL expression given in a operation does work but not for a derived, volatile attribute (it results in one NPE per element using the reflective ecore editor).
An example to derive the opposite reference to self:
attribute derivedOpposite: OtherType { derived,volatile }
		{
			derivation: OtherType.allInstances()->select(reference=self)->asSequence()->first();
		}

Or does this difference roots in other invariants using this attributes/operations?
Thanks in advance,
Joern
Re: OCLinEcore issues with derived attributes/operations [message #555458 is a reply to message #555335] Thu, 26 August 2010 16:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Joern

For OMG OCL, there is no obvious difference between an individual
attribute or parameter-less operation; it's just a matter of style.
However once OCL defines the semantics of overloading and dynamic
resolution it is likely that an overloaded attribute will be an error
and an overloaded operation a dynamic dispatch (just like Java).

For EMF and MDT/OCL features use setting-delegate registrations while
operations use invocation-delegates; these could be very different, but
only if you like to make things deliberately confusing; all three
delegates should be registered in unison. The setting delegates use
reflection through the longstanding eGet(). The invocation delegates use
eInvoke() introduced in 3.6M4. If you neglect to set Operation
Reflection true in genmodel, eInvoke() is not generated; MDT/OCL 3.0.1
will give a warning and workaround this misconfiguration.

Please submit a Bugzilla for the NPE with a hopefully very small
demonstration project (unless its the Operation Reflection feature),

Regards

Ed Willink

On 26/08/2010 12:26, Joern wrote:
> I am trying to enhance an Ecore model with several constraints. What is
> the technical difference in the implementation using OCL operations and
> derived, volatile attributes? In fact the same OCL expression given in a
> operation does work but not for a derived, volatile attribute (it
> results in one NPE per element using the reflective ecore editor). An
> example to derive the opposite reference to self:
> attribute derivedOpposite: OtherType { derived,volatile }
> {
> derivation:
> OtherType.allInstances()->select(reference=self)->asSequence()- >first();
> }
> Or does this difference roots in other invariants using this
> attributes/operations?
> Thanks in advance,
> Joern
Re: OCLinEcore issues with derived attributes/operations [message #555494 is a reply to message #555458] Thu, 26 August 2010 18:33 Go to previous messageGo to next message
Joern is currently offline JoernFriend
Messages: 22
Registered: March 2010
Junior Member
Hi Ed,

Thanks for the explanation.

I have posted https://bugs.eclipse.org/bugs/show_bug.cgi?id=323741. There seem to be more than one NPE-generating bug using derived attributes and the ecore editor - but they seem to be harder to reproduce.

Best regards,

Joern
Re: OCLinEcore issues with derived attributes/operations [message #555504 is a reply to message #555494] Thu, 26 August 2010 20:43 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Joern

It's a user bug. In:

attribute derivedOpposite: OtherType { derived,volatile }
{
derivation:
OtherType.allInstances()->select(reference=self)->asSequence()- >first();
}

this is not an EAttribute but an EReference; use the 'property' keyword.

However Bug 323741 remains open to remind me that the editors should
have semantic validation to detect this mistake. Hopefully in 3.1.0 in
late October.

Regards

Ed Willink


On 26/08/2010 19:33, Joern wrote:
> Hi Ed,
>
> Thanks for the explanation.
>
> I have posted https://bugs.eclipse.org/bugs/show_bug.cgi?id=323741
> There seem to be more than one NPE-generating bug using derived
> attributes and the ecore editor - but they seem to be harder to reproduce.
>
> Best regards,
>
> Joern
Previous Topic:OCL Enumeration ordered?
Next Topic:[Announce] MDT/OCL 3.0.1 SR RC2 is now available
Goto Forum:
  


Current Time: Fri Apr 26 07:32:34 GMT 2024

Powered by FUDForum. Page generated in 0.03515 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top