Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Nesting ecore models
Nesting ecore models [message #1840410] Wed, 14 April 2021 17:25 Go to next message
Thomas Chiang is currently offline Thomas ChiangFriend
Messages: 78
Registered: March 2020
Member
Hi,

I am hoping to modularize my metamodel by splitting the responsibilities. I want to use one metamodel to represent abstractions and another for refinements. The idea is that when I go to implement them the instance of the abstract metamodel is composed of 1 or more of instances of the refinement metamodel.

My question now is how do I go about doing that? It seems that I can't connect packages within an ecore model so I want to know how I can put one ecore metamodel into another ecore metamodel and have it be reachable by classes within the parent metamodel as there will need to be information shared between the 2 levels.
Re: Nesting ecore models [message #1840412 is a reply to message #1840410] Wed, 14 April 2021 18:12 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1253
Registered: July 2009
Location: Canada
Senior Member

Hi, Thomas,

If you want to reference classes in one Ecore model (call it a) from another Ecore model (call it b), then what you need to do is in an editor open on b.ecore, use the "Load Resource" action (available in the Ecore Editor menu or in the context menu) to load a.ecore and then all of its elements will be available to select as superclasses, types, opposites, etc. of elements in b.ecore.

HTH,
Christian
Re: Nesting ecore models [message #1840420 is a reply to message #1840412] Wed, 14 April 2021 23:02 Go to previous messageGo to next message
Thomas Chiang is currently offline Thomas ChiangFriend
Messages: 78
Registered: March 2020
Member
Hi Christian,

How do I get the loaded resource to show up in the class diagram representation so I can edit my metamodels there rather than having to use the tree editor?
Re: Nesting ecore models [message #1840421 is a reply to message #1840420] Wed, 14 April 2021 23:23 Go to previous messageGo to next message
Thomas Chiang is currently offline Thomas ChiangFriend
Messages: 78
Registered: March 2020
Member
In a nutshell I want to be able to create this:
index.php/fa/40336/0/

Except the package that is inside here needs to be its own ecore project so that I can generate the files for it so that I can create a separate editor for it. I still want the ability to nest it like this though.
Re: Nesting ecore models [message #1840432 is a reply to message #1840421] Thu, 15 April 2021 07:51 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 91
Registered: December 2015
Location: Grenoble, France
Member
Hello,

You have to carefully distinguish your ecore package (metamodel) structure and your diagrams.

You can have as many ecore packages as you want and they can reference each other. You can have also nested ecore packages in the same ecore file (although this doesn't have any particular semantics: no visibility rules, no nested name spaces, you have to be sure package names, nsURI and prefixes are unique)

You also have to think about your genmodels, do you want to have all the java code of the different ecore packages generated in the same project? or you want separate code in different projects or directories? a single genmodel can generate code for different packages and reference other genmodels.

Now concerning the diagrams (aird files) , you can create as many class diagrams as you want, but each diagram is associated with a ecore package, so that any classifier that you create using the palette are created in the associated package. You can see this relation in the Model Explorer view

index.php/fa/40341/0/

To be able to reference in your diagram classes in other ecore files , go to the Model Explorer and in the context menu of the aird file select add model, and choose the existing resource (this is the equivalent of the Load Resource in the tree editor)

index.php/fa/40339/0/

After that you can add a reference to an existing class in your diagram (use the palette entry for adding existing elements), they will be marked by a small arrow in the corner. After that you can create references or inheritance relationships to this classes from the classes in your package

index.php/fa/40340/0/
Re: Nesting ecore models [message #1840441 is a reply to message #1840432] Thu, 15 April 2021 09:33 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 32073
Registered: July 2009
Senior Member
Note that one limitation I should mention is that co-dependent packages cannot be in separate projects. I mention this because I see a bidirectional reference between Input and In_Port so the packages of these two classes will need to be in a single project. It's also generally a good idea to have a single *.genmodel per project.

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Nesting ecore models [message #1840444 is a reply to message #1840441] Thu, 15 April 2021 12:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7292
Registered: July 2009
Senior Member
Hi

Indeed but that is a Java limitation, which may not apply for purely modeling purposes. For instance you could make the bidirectional unidirectional, and rely on the ability to navigate anything in any direction in OCL. The unnecessary complexity of UML Associations exists pretty much to enable the 'second' end of an Association to add a 'first' end without needing to edit the first metamodel. That the complexity is unnecessary is demonstrated by Ecore's much simpler EReferences for which opposite EAnnotations can provide the missing inverses.

However if there is a real co-dependence it suggests that there is no actual separation and so they should be folded, or else an abstraction should be introduced to allow proper layering to apply.

Regards

Ed Willink
Re: Nesting ecore models [message #1840445 is a reply to message #1840444] Thu, 15 April 2021 14:28 Go to previous messageGo to next message
Thomas Chiang is currently offline Thomas ChiangFriend
Messages: 78
Registered: March 2020
Member
These are all extremely helpful thank you so much!

And like you said I have it as a bidirectional reference purely for navigation purposes. Navigating through OCL may be the better option down the line but I'm not sure yet.

The main reason I want to have two separate projects for the two metamodels is because I want to define the editor for each of the metamodels in Sirius separately. The idea being that when I create a new instance of the child metamodel I want it to have an editor with different feature than that of the instance of the parent metamodel. This is because there are actions that may be possible for the child that the parent shouldn't be able to do and vice versa.

For the port classes, in theory they should be unidirectional, however I put the Ereference as bidirectional purely for navigation purposes like I said before because it makes it easier to navigate in AQL which is the equivalent of EOL but for Sirius, although much more difficult to work with.
Re: Nesting ecore models [message #1840447 is a reply to message #1840432] Thu, 15 April 2021 14:34 Go to previous messageGo to next message
Thomas Chiang is currently offline Thomas ChiangFriend
Messages: 78
Registered: March 2020
Member
Also I have tried to create another .aird file and I get this error:

Description Resource Pa/th Location Type
Found 2 main representations files (that means not referenced by another) in "wfp": wfp.airdand wfpmm.aird. A modeling project must contain only one. wfp Unknown Modeling Marker

Should I not be doing this within an ecore modeling project and instead in just a standard modeling project? Or does this mean that they need to be in two separate folders? In the pictures that you sent it looks like it's all within 1 ecore modeling project so this error has be confused now.

In fact it appears that I don't even have the option to add model from a right click on the .aird file. What kind of project is this or what packages do I need to download in order to be able to do this?
index.php/fa/40342/0/

[Updated on: Thu, 15 April 2021 14:48]

Report message to a moderator

Re: Nesting ecore models [message #1840457 is a reply to message #1840447] Thu, 15 April 2021 17:40 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 1
Registered: April 2021
Junior Member
Hello,

You are right, I do not use Modeling (or Ecore Modeling) projects in my day to day work, so I was testing in a plain PDE plugin project. Sorry if that confused you.

If you prefer to use a (Ecore) Modeling Project, you can only have a single aird file per project (named either as the project or "representations" ), but you can create as many diagrams as you want inside this representation file.

In the case of Modeling Projects, all types defined in model files in your project will be available for referencing from your diagrams.

If you want to reference a type defined in a model file in another project, go to the Model Explorer and right click on the project entry called Project dependencies and there you will find the menu to add a model.

index.php/fa/40343/0/

Hope it's clearer

G. Vega
Re: Nesting ecore models [message #1840481 is a reply to message #1840457] Fri, 16 April 2021 07:29 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 91
Registered: December 2015
Location: Grenoble, France
Member
Hello again,

Just to complement my previous answers. Modeling projects and representations files (aird) are not necessary to work with ecore metamodels.

The concepts of Modeling Project and representation files (aird) come from Sirius. You need to use them only if you use the editors generated by Sirius. They are documented here :

Modeling project : https://www.eclipse.org/sirius/doc/user/general/Modeling%20Project.html

aird editor : https://www.eclipse.org/sirius/doc/user/general/Aird_Editor.html

In your case, you need to be aware of them because you are using the Ecore Diagram Modeler for designing your ecore class diagrams, and this modeler happens to be a Sirius based editor.

An Ecore Modeling project is an specialized Sirius Modeling Project. I personally do not use it, because I most of the time use the tree editor to create my ecore
packages (or xcore lately). That's why in my first post I used a plain plugin project. I usually create the class diagrams afterwards, mostly for documentation.

That's why I insisted in my first post that you need to separate the logical structure of your ecore packages from its representation in diagrams.

Your metamodel can be defined in a single, huge, monolithic ecore package and you can create as many class diagrams as you want, to show different aspects of it.
Conversely, your metamodel can be defined in many modular (possibly nested) ecore packages (maybe in different projects) and you can create a single class diagram that display it in an
unified diagram.

The same is true if you are planning to define Sirius editors for your metamodel. You can define your metamodel in a single ecore package and yet define several Sirius editors to visualize/edit
different viewpoints of your models. Conversely, you can define your metamodel in several ecore packages modeling different aspects of your domain and then define a single Sirius editor to
visualize/edit your model in an integrated way.

However, if you plan to have a textual syntax for your metamodel (using xtext) the situation is not that flexible. It is very hard (without extensive customization of the code generated by xtext)
to have separate text files to represent different aspects of the same modeled entity. The relation between ecore packages and xtext grammars is tighter. In this case you have to think very carefully
in advance. You may even need to define two different metamodels: one for the concrete syntax and one for the abstract syntax.

In my opinion, the main drivers to modularize a metamodel in several ecore packages have to be resue, maintainability and extensibility.

Hope this helps

G. Vega

Re: Nesting ecore models [message #1840499 is a reply to message #1840481] Fri, 16 April 2021 15:19 Go to previous message
Thomas Chiang is currently offline Thomas ChiangFriend
Messages: 78
Registered: March 2020
Member
Hi German,

These answers have all been very helpful I really appreciate it.

From what I have discovered so far by playing around one can only make a Sirius editor if there is a .ecore metamodel. It doesn't seem to be enough to have just an Epackage.

As for the scope of the editor for these metamodels that I am creating I'm not sure yet which method would be better for satisfying a usability requirement for the editor that I am creating which is part of why I have been asking this question; I would like to develop both solutions so that we can test both out and see which one we like more. We know that we need two things though; a method for managing the instances, and a method to modularize the instances as well. This is what led to me separating the project into 2 metamodel. 1 for management and one for the actual model creation.

Your answers have been very insightful in helping me to figure out how to implement this. Thanks! I will likely post here again if I have any more question with regards to this topic.
Previous Topic:UML profile and EMF ecore
Next Topic:Automatic generation of random ecore model instances
Goto Forum:
  


Current Time: Thu Oct 21 06:30:36 GMT 2021

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

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

Back to the top