Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Distinguishing "logical" Ecore elements from additional "technical" ones
Distinguishing "logical" Ecore elements from additional "technical" ones [message #1766675] Sun, 25 June 2017 10:45 Go to next message
Daniel Strueber is currently offline Daniel StrueberFriend
Messages: 11
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7127
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 Go to previous messageGo to next message
Daniel Strueber is currently offline Daniel StrueberFriend
Messages: 11
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7127
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 Go to previous messageGo to next message
Daniel Strueber is currently offline Daniel StrueberFriend
Messages: 11
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 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7127
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:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue May 11 11:43:17 GMT 2021

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly