Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances
[EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances [message #1035128] Sat, 06 April 2013 07:08 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Hi @all,

I found an interesting "issue" with OCL embedded in Ecore (OCLInEcore). I investigated the problems and also found the reason. It is related to many technologies, but I have chosen this subforum.

Please consider the following OCL invariant embedded in my ecore:

invariant mustBeSameType: someObject1.eClass() = someObject2.eClass();


and I also tried (which tricks the editor)

invariant mustBeSameType: someObject1.oclAsType(ecore::EObject).eClass() = someObject2.oclAsType(ecore::EObject).eClass();


My idea only works (for both OCLInEcore Editor and runtime) if I set the base class of the objetcts' classes explicitly to EObject, i.e.

class ClassOfSomeObject1 extends ecore::EObject


I checked the difference, because in Java someObject1/2 are EObjects regardless of whether I use 'extends ecore::EObject' or not. However, if I use 'extends ecore::EObject', there is additional runtime type information within the model, which is required for the OCL Expression.

So far, that's ok! And I was happy that this worked.

However, there is a problem if using other 'frameworks' like CDO. In the GenModel there is the setting 'use CDOObject as base class for root classes'. If I set 'ecore::EObject' explicitly, CDOObject is not used as base class any more. This is why I cannot use the 'extends ecore::EObject' trick if I want to use CDO. As far as I know, CDOObject itself cannot be used as base class explicitly, e.g. 'extends cdo::CDOObject'.

Didn't know in which subforum I put this report [EMF/OCL/CDO/GenModel...]. Basically, this is not a bug of any product. Maybe a little design flaw? Anybody has some comments or workarounds?

[Updated on: Sat, 06 April 2013 07:12]

Report message to a moderator

Re: [EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances [message #1035175 is a reply to message #1035128] Sat, 06 April 2013 08:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4009
Registered: July 2009
Senior Member
Hi

It was at Helios M4 that EMF made the change to remove visibility of
EObject inheritance. It was a pain for comaptibility, but correct
UML-wise. EModelElement is the counterpart of UML/MOF Element and that
is all that modellers should see. You should indeed need to do
oclAsType(ecore::EObject) to make EObject visible.

Performing eClass() equality is as foolish as String equality.

In OCL, you should use oclType() but again equality is not great. Much
better to use conformsTo.

The new Pivot support for oclTYpe() gives you consistent UML-like
reflection; oclType() gives you a Class rather than eClass()' EClass.

Do you have an OCL use case that oclType() cannot answer?

Modeling encapsulation shouldn't really allow you to see EObject at all.
Why do you need to?

Regards

Ed Willink

On 06/04/2013 12:08, Kirsten M. Z. wrote:
> Hi @all,
>
> I found an interesting "issue" with OCL embedded in Ecore
> (OCLInEcore). I investigated the problems and also found the reason.
> It is related to meny Technologies, so I have chosen this subforum.
>
> Please consider the following OCL invariant embedded in my ecore:
>
> [code]invariant mustBeSameType: someObject1.eClass() =
> someObject2.eClass();[/ocl]
>
> and I also tried (which tricks the editor)
>
> invariant mustBeSameType:
> someObject1.oclAsType(ecore::EObject).eClass() =
> someObject2.oclAsType(ecore::EObject).eClass();
>
> My idea only works (for both OCLInEcore Editor and runtime) if I set
> the base class of the objetcts' classes explicitly to EObject, i.e.
>
> class ClassOfSomeObject1 extends ecore::EObject
>
> I checked the difference, because in Java someObject1/2 are EObjects
> regardless of whether I use 'extends ecore::EObject' or not. However,
> if I use 'extends ecore::EObject', there is additional runtime type
> information within the model, which is required for the OCL Expression.
>
> So far, that's ok! And I was happy that this worked.
>
> However, there is a problem if using other 'frameworks' like CDO. In
> the GenModel there is the setting 'use CDOObject as base class for
> root classes'. If I set 'ecore::EObject' explicitly, CDOObject is not
> used as base class any more. As far as I know, CDOObject itself cannot
> be used as base class explicitly, e.g. 'extends cdo::CDOObject'.
>
> Didn't know in which subforum I put this report
> [EMF/OCL/CDO/GenModel...]. Basically, this is not a bug of any
> product. Maybe a little design flaw? Anybody has some comments or
> workarounds?
>
>
Re: [EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances [message #1036357 is a reply to message #1035175] Mon, 08 April 2013 05:16 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
> Performing eClass() equality is as foolish as String equality.
>
> In OCL, you should use oclType() but again equality is not great. Much
> better to use conformsTo.

I did not know anything about the oclType() method, but sounds that it is perfectly suitable for the problem I posted (in association with conformsTo).

To be honest, I wanted to post a very simple example which 'needs' EClass. In fact, I would need the method 'isSuperTypeOf', and I also store an EClass (a given type) within my model as one part of the two arguments in 'isSuperTypeOf'. I know that this is a strange mixing of meta levels, but let's assume that this is a good idea Smile

Maybe 'oclType()' is the solution I need. The thing is: I don't know! Currently, the context help in the OclInEcore editor does not provide meaningful information. I don't know why and when it broke, but it does not show meaningful methods, attributes etc. right now. I should check other versions. I also use the interactive OCL console. It shows available features very reliable. However, it seems to use another OCL subset, so the method oclType() is not available. I cannot find information about oclType() in the OCL standard as well. To conclude, I can only presume what oclType() does and provides.

I tried using 'xxxx.oclType().isSuperTypeOf(yyyyy.oclType())', but I get an error (unresolved operation).

I guess oclType() returns an OclType structure, right? But what does OclType provide? I found some exemplary implementations. According to http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.ocl.doc%2Fhelp%2FOclType.html OclType supports 'conformsTo', for example, but nothing more.
Re: [EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances [message #1036380 is a reply to message #1036357] Mon, 08 April 2013 05:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4009
Registered: July 2009
Senior Member
HI

It is certainly difficult to know what oclType() returns. Every version
of the OCL specification changes it since it is such a mess.

The Pivot-based binding of Eclipse OCL prototypes a UML-aligned solution
and so oclType() returns a Metaclass(T) which conforms to Class, in a
similar fashion to Java's getClass(), except that in OCL the T is the
statically determinate type rather than Object.

Once you have a Metaclass, you can use UML navigation. e.g.
closure(superclass)->includes(X).

Regards

Ed Willink


On 08/04/2013 10:16, Kirsten M. Z. wrote:
>> Performing eClass() equality is as foolish as String equality.
>>
>> In OCL, you should use oclType() but again equality is not great.
>> Much better to use conformsTo.
>
> I did not know anything about the oclType() method, but sounds that it
> is perfectly suitable for the problem I posted (in association with
> conformsTo).
>
> To be honest, I wanted to post a very simple example which 'needs'
> EClass. In fact, I would need the method 'isSuperTypeOf', and I also
> store an EClass (a given type) within my model as one part of the two
> arguments in 'isSuperTypeOf'. I know that this is a strange mixing of
> meta levels, but let's assume that this is a good idea :)
>
> Maybe 'oclType()' is the solution I need. The thing is: I don't know!
> Currently, the context help in the OclInEcore editor does not provide
> meaningful information. I don't know why and when it broke, but it
> does not show meaningful methods, attributes etc. right now. I should
> check other versions. I also use the interactive OCL console. It shows
> available features very reliable. However, it seems to use another OCL
> subset, so the method oclType() is not available. I cannot find
> information about oclType() in the OCL standard as well. To conclude,
> I can only presume what oclType() does and provides.
>
> I tried using 'xxxx.oclType().isSuperTypeOf(yyyyy.oclType())', but I
> get an error (unresolved operation).
>
> I guess oclType() returns an OclType structure, right? But what does
> OclType provide? I found some exemplary implementations. According to
> http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.ocl.doc%2Fhelp%2FOclType.html
> OclType supports 'conformsTo', for example, but nothing more.
Re: [EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances [message #1036401 is a reply to message #1036380] Mon, 08 April 2013 06:33 Go to previous message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Ah, ok, I found 'Metaclass(T)', Class, Type etc.

I guess that these types can be used instead of EClass, and they are sufficient to do anything 'type related'. 'closure(superclass)->includes(X)' is also very neat. Solution found, thanks!
Previous Topic:Content assist behavior in embedded xtext ocl editor
Next Topic:[OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL
Goto Forum:
  


Current Time: Tue Jul 29 09:03:06 EDT 2014

Powered by FUDForum. Page generated in 0.02177 seconds