| Nesting ecore models [message #1840410] |
Wed, 14 April 2021 13:25  |
Eclipse User |
|
|
|
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 #1840432 is a reply to message #1840421] |
Thu, 15 April 2021 03:51  |
| Eclipse User |
|
|
|
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
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)
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
|
|
|
|
|
|
|
|
| Re: Nesting ecore models [message #1840481 is a reply to message #1840457] |
Fri, 16 April 2021 03:29 |
| Eclipse User |
|
|
|
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 11:19 |
| Eclipse User |
|
|
|
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.
|
|
|
Powered by
FUDForum. Page generated in 0.04486 seconds
Home