Eclipse Community Forums: OCL » EMF reflection in completeOCL (Pivot)

Help

Home

Home » Modeling » OCL » EMF reflection in completeOCL (Pivot)(Cannot iterate over an object's references )

Show: Today's Messages :: Show Polls :: Message Navigator

EMF reflection in completeOCL (Pivot) [message #1780016]

Tue, 16 January 2018 14:57

Steve Pearson

Messages: 12
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?

Report message to a moderator

Re: EMF reflection in completeOCL (Pivot) [message #1780028 is a reply to message #1780016]

Tue, 16 January 2018 15:30

Ed Willink

Messages: 7655
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

Report message to a moderator

Re: EMF reflection in completeOCL (Pivot) [message #1780082 is a reply to message #1780028]

Wed, 17 January 2018 08:58

Steve Pearson

Messages: 12
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().

Report message to a moderator

Re: EMF reflection in completeOCL (Pivot) [message #1780090 is a reply to message #1780082]

Wed, 17 January 2018 10:28

Ed Willink

Messages: 7655
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

Report message to a moderator

Re: EMF reflection in completeOCL (Pivot) [message #1780108 is a reply to message #1780090]

Wed, 17 January 2018 13:10

Steve Pearson

Messages: 12
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.

Attachment: genericReferences.JPG
(Size: 18.96KB, Downloaded 211 times)

Report message to a moderator

Re: EMF reflection in completeOCL (Pivot) [message #1780113 is a reply to message #1780108]

Wed, 17 January 2018 14:07

Ed Willink

Messages: 7655
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

Report message to a moderator

Previous Topic:	EMF reflection in completeOCL (Pivot)
Next Topic:	Bug in generated code?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 15:01:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter