Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » EMF reflection in completeOCL (Pivot)(Cannot iterate over an object's references )
EMF reflection in completeOCL (Pivot) [message #1780016] Tue, 16 January 2018 14:57 Go to next message
Steve Pearson is currently offline Steve PearsonFriend
Messages: 10
Registered: May 2014
Junior Member
I am using CompleteOCL scripts to add constraints to an EMF data model and I need to iterate over the set of features/references.
This is provided in the EMF API by EObject::eCrossReferences() but I cannot cast to EObject in the OCL

context MyDataClass
def: crossRefs() : Integer = self.oclAsType(ecore::EObject).eCrossReferences()->size()
inv HasCrossRefs : self.crossRefs() > 0


For each item of MyDataClass I get the error
'Incompatible source type: 'MyDataClass' for oclAsType(ecore::EObject)

From the OCL FAQ https://wiki.eclipse.org/OCL/FAQ I understand that for the Classic OCL the Parsing option implicitRootClass can be set to EObject to solve this, but in the Pivot OCL this is deprecated and only oclContainer() and oclContents() EMF functions are available (which work fine).

How can I discover an object's references (from a supertype context) using CompleteOCL and the Pivot OCL?
Re: EMF reflection in completeOCL (Pivot) [message #1780028 is a reply to message #1780016] Tue, 16 January 2018 15:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5625
Registered: July 2009
Senior Member
Hi

The Pivot OCL supports reflection, so once you have climbed to the meta-level using oclType(), you have a Pivot::Class from where you may navigate to pivot::Class::ownedProperties and/or pivot::Class::ownedOperations. self.oclType().ownedProperties->size().

NB it is a pivot::Class which has many similarities to a uml::Class but a number of UML irregularities are normalized away justifying adjustments to make names consistent. See GIT\org.eclipse.ocl\plugins\org.eclipse.ocl.pivot\model\Pivot.ecore if the content assist lets you down.

(Don't worry about duplicates; I'm afraid that FUDforum is not the best Forum management tool in the world.)

Regards

Ed Willink
Re: EMF reflection in completeOCL (Pivot) [message #1780082 is a reply to message #1780028] Wed, 17 January 2018 08:58 Go to previous messageGo to next message
Steve Pearson is currently offline Steve PearsonFriend
Messages: 10
Registered: May 2014
Junior Member
Thanks, I see that pivot::Class::ownedProperties returns the direct properties of the class. Is there a method for returning all its inherited properties as well?

For a given context (a model class possibly with many subclasses) I need to check that its referenced objects of are not in a forbidden container. EObject::eCrossReferences() would have helped. Is there no way I can access the EObject methods of the EMF API?

You have oclContainer() and oclContents() which seem to cover the EObject methods eContainer() and eAllContents().
Re: EMF reflection in completeOCL (Pivot) [message #1780090 is a reply to message #1780082] Wed, 17 January 2018 10:28 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5625
Registered: July 2009
Senior Member
Hi

.oclType()->closure(superClasses).ownedProperties will get you the inherited Property's too.

You should be able to use the EMF API if your object are modelled rather than just implemented as EObjects, i.e. you must specify EObject as a superClass.

If you can provide a full repro, I would like to understand what you are trying to achieve. You comment on oclContainer() and oclContents(). oclGet() has been under consideration, but it presents some template/signature challenges to provide good deterministic type safety, perhaps by offering Property::oclGet(e:OclElement) : typeof(type) rather than OclElement::oclGet<T>(p:Property(T)) : T. eGet() is very unsatisfactory in variously returning an Object, EObject or EList. OCL 2.2 dug a bit of a hole by suggesting that Collection conforms to OclAny; I don't want to dig this hole any deeper; oclGet() must be clean.

(If you are using CompleteOCL you should really use the CompleteClass where all the inherited and 'additional' features are aggregated in a uniform cache. Unfortunately providing the OCL-level API to this is still work in progress.)

Regards

Ed Willink
Re: EMF reflection in completeOCL (Pivot) [message #1780108 is a reply to message #1780090] Wed, 17 January 2018 13:10 Go to previous messageGo to next message
Steve Pearson is currently offline Steve PearsonFriend
Messages: 10
Registered: May 2014
Junior Member
Thanks for the tip to include the inherited properties.

I have an Ecore model (which I cannot change so OCLinEcore is not an option) for which I want to add OCL constraints to the structural checks provided by standard EMF validation.
The EMF genmodel is configured so that "Root Extends Interface : org.eclipse.emf.ecore.EObject". EObject is then a superclass in the generated EMF code at least. But the Ecore model itself is independent of EMF and EObject.

As an example: I have a class that contains a list of items that are sub-classed in many ways. I want to discover all the objects referenced by these items that are of a certain class (oclIsKindOf(class)) and apply a constraint to them. In EMF I could iterate over the contents' references using eCrossReferences() to discover all the referenced objects.
In completeOCL I could write specific constraints for each concrete subclass using known property names, but I wanted something more generic. Something that does not need to be updated when another subclass is added to the model.

In the attached class diagram, I want to ensure that for any genItem in MyContainer that references an itemB, its attribute isOK=True. I could do this by testing refx and refy targets explicitly, but I want to be able to check this for any subclass of GenItem.
Re: EMF reflection in completeOCL (Pivot) [message #1780113 is a reply to message #1780108] Wed, 17 January 2018 14:07 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5625
Registered: July 2009
Senior Member
Hi

Helios M4 is deeply ingrained in my memory. It was when EMF made the bold (and correct) design change that EModelElement does not extend EObject, consequently model elements only extend EObject when explicitly declared to do so. If your Ecore model does not do this then the cast to EObject is a statically determinstic illegal modeling operation giving you an invalid value. You cannot cast to a CorbaObject either since you do not have a CorbaObject . You might fudge it with a helper operation that uses dynamic typing.

If CompleteOCL supported additional inheritance as well as additional Operations and Properties you could remedy the deficiency with a new static inheritance. See http://issues.omg.org/browse/OCL25-165 and now https://bugs.eclipse.org/bugs/show_bug.cgi?id=529938

Thanks. Your eCrossReferences() use case seems to identify that the various EcoreUtil cross referencing facilities cannot be implemented in OCL. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=529937

Regards

Ed Willink
Previous Topic:EMF reflection in completeOCL (Pivot)
Goto Forum:
  


Current Time: Mon Feb 19 20:44:14 GMT 2018

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

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