Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » Distinguishing "logical" Ecore elements from additional "technical" ones

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Distinguishing "logical" Ecore elements from additional "technical" ones

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

Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766675]

Sun, 25 June 2017 10:45

Daniel Strueber

Messages: 8
Registered: April 2014

Junior Member

In my use-case, I need to I compute a complete list of all elements in a given model, where this model can potentially be a meta-model.

As an example, consider a simple Ecore meta-model with 1 EPackage, 3 EClasses and 2 EReferences. Clearly, I would expect this list to have 1+3+2=6 elements.

However, it turns out the actual number is 8: Upon loading, for each of the two EReferences, an elements of the type "EGenericTypeImpl" is created (and the property "eClassifier" of each EReference is set to to one these elements).

I assume these additional elements serve some meaningful technical purpose. Still, they are not only irrelevant for my use-case, but actually detrimental: in the list that I want to compute, it is important to have a list of the "logical" elements, i.e., those shown to the user in the graphical and tree-based Ecore editors.

So, it need a way of distinguishing

* "logical" elements from "technical" ones,
* "logical" properties of elements from "technical" ones.

Is there a natural way of doing this?

[Updated on: Sun, 25 June 2017 10:48]

Report message to a moderator

Re: Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766676 is a reply to message #1766675]

Sun, 25 June 2017 10:58

Ed Willink

Messages: 5395
Registered: July 2009

Senior Member

Hi

If you guarantee that you will never need to use templated elements you can ignore the EGenericType and use just 'legacy' Ecore.

Alternatively if you may need templates you should understand how EGenericType extends the original Ecore metamodel to add support without trashing 'legacy' Ecore applications.

Regards

Ed Willink

Report message to a moderator

Re: Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766677 is a reply to message #1766676]

Sun, 25 June 2017 11:02

Daniel Strueber

Messages: 8
Registered: April 2014

Junior Member

Hi Ed,

so is it safe to say that "EGenericType" is actually a unique case, and there are no additional instances where the in-memory representation of an Ecore model has additional elements apart from those which are visible in the tree-based editor?

Best regards,
Daniel

[Updated on: Sun, 25 June 2017 11:03]

Report message to a moderator

Re: Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766678 is a reply to message #1766677]

Sun, 25 June 2017 11:23

Ed Willink

Messages: 5395
Registered: July 2009

Senior Member

Hi

I'm not quite sure what you mean by a "unique case". The layout in the Tree Editor is a little pragmatic and configurable via the "Show Generic" toolbar menu option, so I wouldn't want to comment on any exact 1:1 correspondences between Tree editor artifacts and EObjects.

EGenericType and ETemplateParameter have some similarities to UML's TemplateSignature and TemplateParameter, but also aggregate the TemplateParameterSubstitution and TemplateBinding, so depending on your point of view you can regard EGenericType as an elegant compact legacy preserving compromise or an unmodeled anarchic dustbin of at least four distinct capabilities.

EAnnotation but no EDetail is of course another area where the Tree editor gets complicated/inadequate.

Regards

Ed Willink

Report message to a moderator

Re: Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766686 is a reply to message #1766678]

Sun, 25 June 2017 19:22

Daniel Strueber

Messages: 8
Registered: April 2014

Junior Member

I see. This extension is a bit hard to get used to, especially since the XMI representation of the Ecore model seems to be oblivious to it as well. But I now have an idea of how to work with it - thanks for your help!

Report message to a moderator

Re: Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766703 is a reply to message #1766686]

Mon, 26 June 2017 10:08

Ed Willink

Messages: 5395
Registered: July 2009

Senior Member

Hi

I found examples essential to understand EGenericType. The Classic OCL is unpleasantly generic and so has a bit of everything:

GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
GIT\org.eclipse.ocl\plugins\org.eclipse.ocl.uml\model\OCLUML.ecore

The Pivot OCL has an Ecore 2 Pivot transformation that might help. You can find an if-tree for the various EGenericType behaviours in:

GIT\org.eclipse.ocl\plugins\org.eclipse.ocl.pivot\src\org\eclipse\ocl\pivot\internal\ecore\es2as\Ecore2AS.java resolveType

Regards

Ed Willink

Report message to a moderator

Previous Topic:	distinguish between EClasses
Next Topic:	[Edapt] DiagnosticException while migrating

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Sep 24 06:58:47 GMT 2017

.:: Contact :: Home ::.