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 11:08  |
 Kirsten M. Z.
Messages: 132
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 11: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 12:41  |
Ed Willink
Messages: 7655
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 09:16 |
Kirsten M. Z.
Messages: 132
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 
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 09:54 |
Ed Willink
Messages: 7655
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.
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 20:33:59 GMT 2024
Powered by FUDForum. Page generated in 0.03421 seconds |
] 
Search
Help
Register
Login
Home
