Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » How to split up large meta models
| |
| Re: How to split up large meta models [message #516505 is a reply to message #516354] |
Wed, 24 February 2010 04:34   |
 Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
First of all thanks for the quick reply. (I'm still wondering how you
manage to answer so many news messages)
See comments below.
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
>
> Dirk Hoffmann wrote:
>> Hi,
>>
>> over time our meta model became quite large so we would like to split
>> it up.
>>
>> We're using the Ecore Diagram editor from the Ecore Tools Model.
>>
>> The current ecore model consists of a single package.
>>
>> We already released a product based on the large meta model to our
>> customers and would like the new version of our product to be able to
>> load the model files produced by the former version without having to
>> migrate the model files.
>>
>> I guess this means we cannot split up the meta-model into multiple
>> packages as that would change the way model instance are loaded/saved.
>> Am I right?
> It wouldn't change a lot. The nsURI of the package is only used in a
> few places, i.e., on the root element, and as the xsi/xmi:type of
> elements that are serialized with a derived instance.
Ok
>>
>> Alternatively splitting the meta-model diagram into multiple diagrams
>> would help a lot. There is a navigation button labeled "Open the
>> parent diagram" suggesting splitting up a diagram has been envisioned
>> by the creators of the editor. Unfortunately I could not find out how
>> to do so. Any help is very much appreciated.
> For Ecore itself, I just created a bunch of separate diagrams. You'll
> find that all in the models folder of org.eclipse.emf.ecore.
I guess you mean those .mdl files, probably Rational Rose Model files.
We're using the Ecore Tools Diagram Editor (the one creating .ecorediag
files). Do you know of examples using this editor or is there a
conversion facility for .mdl files?
>>
>> We also started a new EMF/GMF based product and want to let the new
>> meta-model be composed of small sub-models right from the beginning.
>> What is the recommended way for this?
> It's definitely possible to create a bunch of interrelated smaller
> packages. Personally I'd avoid any nesting of packages, but that's okay
> too.
Can you point out what you think is bad about nesting them because
that's what we thought to do.
>>
>> Parts of the meta-model of the old and the new product are similar so
>> we thought about sharing those parts. We abandonned that idea for
>> several reasons but still I'm wondering if this were possible.
> You can always specialize how type and element names are looked up to
> remap to a new package structure. A derived instance of
> BasicExtendedMetaData can be quite useful for that.
Could also be a solution for my first point, the migration in case of
splitting up the meta-model, I guess
>>
>> Thanks and Regards,
>> Dirk
|
|
|
| Re: How to split up large meta models [message #516542 is a reply to message #516505] |
Wed, 24 February 2010 11:17 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> First of all thanks for the quick reply. (I'm still wondering how you
> manage to answer so many news messages)
A little bit of OCD helps. Also, itemis funds my work and part of that
includes ensuring that the Eclipse modeling technology is successful and
that its usage is widespread. There's nothing quite like helping others
be successful to help ensure that...
>
> See comments below.
>
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>>
>> Dirk Hoffmann wrote:
>>> Hi,
>>>
>>> over time our meta model became quite large so we would like to
>>> split it up.
>>>
>>> We're using the Ecore Diagram editor from the Ecore Tools Model.
>>>
>>> The current ecore model consists of a single package.
>>>
>>> We already released a product based on the large meta model to our
>>> customers and would like the new version of our product to be able
>>> to load the model files produced by the former version without
>>> having to migrate the model files.
>>>
>>> I guess this means we cannot split up the meta-model into multiple
>>> packages as that would change the way model instance are
>>> loaded/saved. Am I right?
>> It wouldn't change a lot. The nsURI of the package is only used in a
>> few places, i.e., on the root element, and as the xsi/xmi:type of
>> elements that are serialized with a derived instance.
> Ok
>>>
>>> Alternatively splitting the meta-model diagram into multiple
>>> diagrams would help a lot. There is a navigation button labeled
>>> "Open the parent diagram" suggesting splitting up a diagram has been
>>> envisioned by the creators of the editor. Unfortunately I could not
>>> find out how to do so. Any help is very much appreciated.
>> For Ecore itself, I just created a bunch of separate diagrams.
>> You'll find that all in the models folder of org.eclipse.emf.ecore.
> I guess you mean those .mdl files, probably Rational Rose Model files.
> We're using the Ecore Tools Diagram Editor (the one creating
> .ecorediag files). Do you know of examples using this editor or is
> there a conversion facility for .mdl files?
No, I don't mean the mdl files. I'm no longer capable of editing
those. That's why I've switched to creating *.ecorediag equivalents for
the diagram in the *.mdl file. I had to do that manually, which is
pretty painful.
>>>
>>> We also started a new EMF/GMF based product and want to let the new
>>> meta-model be composed of small sub-models right from the beginning.
>>> What is the recommended way for this?
>> It's definitely possible to create a bunch of interrelated smaller
>> packages. Personally I'd avoid any nesting of packages, but that's
>> okay too.
> Can you point out what you think is bad about nesting them because
> that's what we thought to do.
There's nothing bad about it, it's just that all the tools end up
supporting it as an afterthought, so you're much more likely to
encounter tool bugs with nested subpackages than without them. I.e.,
they're basically syntactic sugar that unfortunately often end up being
a little more like syntactic rat poison.
>>>
>>> Parts of the meta-model of the old and the new product are similar
>>> so we thought about sharing those parts. We abandonned that idea for
>>> several reasons but still I'm wondering if this were possible.
>> You can always specialize how type and element names are looked up to
>> remap to a new package structure. A derived instance of
>> BasicExtendedMetaData can be quite useful for that.
> Could also be a solution for my first point, the migration in case of
> splitting up the meta-model, I guess
Yes, such an instance ends up as a clearing house for mapping namespace
and names to their corresponding Ecore metadata so for example a class
moving from one package to another could easily be remapped.
>>>
>>> Thanks and Regards,
>>> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to split up large meta models [message #516586 is a reply to message #516542] |
Wed, 24 February 2010 13:23 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
See below,
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
>
> Dirk Hoffmann wrote:
>> First of all thanks for the quick reply. (I'm still wondering how you
>> manage to answer so many news messages)
> A little bit of OCD helps. Also, itemis funds my work and part of that
Uh, really that serious? ;-)
> includes ensuring that the Eclipse modeling technology is successful and
> that its usage is widespread. There's nothing quite like helping others
> be successful to help ensure that...
>>
>> See comments below.
>>
>> Ed Merks schrieb:
>>> Dirk,
>>>
>>> Comments below.
>>>
>>>
>>> Dirk Hoffmann wrote:
>>>> Hi,
>>>>
>>>> over time our meta model became quite large so we would like to
>>>> split it up.
>>>>
>>>> We're using the Ecore Diagram editor from the Ecore Tools Model.
>>>>
>>>> The current ecore model consists of a single package.
>>>>
>>>> We already released a product based on the large meta model to our
>>>> customers and would like the new version of our product to be able
>>>> to load the model files produced by the former version without
>>>> having to migrate the model files.
>>>>
>>>> I guess this means we cannot split up the meta-model into multiple
>>>> packages as that would change the way model instance are
>>>> loaded/saved. Am I right?
>>> It wouldn't change a lot. The nsURI of the package is only used in a
>>> few places, i.e., on the root element, and as the xsi/xmi:type of
>>> elements that are serialized with a derived instance.
>> Ok
>>>>
>>>> Alternatively splitting the meta-model diagram into multiple
>>>> diagrams would help a lot. There is a navigation button labeled
>>>> "Open the parent diagram" suggesting splitting up a diagram has been
>>>> envisioned by the creators of the editor. Unfortunately I could not
>>>> find out how to do so. Any help is very much appreciated.
>>> For Ecore itself, I just created a bunch of separate diagrams.
>>> You'll find that all in the models folder of org.eclipse.emf.ecore.
>> I guess you mean those .mdl files, probably Rational Rose Model files.
>> We're using the Ecore Tools Diagram Editor (the one creating
>> .ecorediag files). Do you know of examples using this editor or is
>> there a conversion facility for .mdl files?
> No, I don't mean the mdl files. I'm no longer capable of editing
> those. That's why I've switched to creating *.ecorediag equivalents for
> the diagram in the *.mdl file. I had to do that manually, which is
> pretty painful.
Ok, should have looked into the latest sources, not the 2.5.0 source
jar. Eventually found them here:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.ecore/model/?root=Model ing_Project
>>>>
>>>> We also started a new EMF/GMF based product and want to let the new
>>>> meta-model be composed of small sub-models right from the beginning.
>>>> What is the recommended way for this?
>>> It's definitely possible to create a bunch of interrelated smaller
>>> packages. Personally I'd avoid any nesting of packages, but that's
>>> okay too.
>> Can you point out what you think is bad about nesting them because
>> that's what we thought to do.
> There's nothing bad about it, it's just that all the tools end up
> supporting it as an afterthought, so you're much more likely to
> encounter tool bugs with nested subpackages than without them. I.e.,
> they're basically syntactic sugar that unfortunately often end up being
> a little more like syntactic rat poison.
Schluck.
>>>>
>>>> Parts of the meta-model of the old and the new product are similar
>>>> so we thought about sharing those parts. We abandonned that idea for
>>>> several reasons but still I'm wondering if this were possible.
>>> You can always specialize how type and element names are looked up to
>>> remap to a new package structure. A derived instance of
>>> BasicExtendedMetaData can be quite useful for that.
>> Could also be a solution for my first point, the migration in case of
>> splitting up the meta-model, I guess
> Yes, such an instance ends up as a clearing house for mapping namespace
> and names to their corresponding Ecore metadata so for example a class
> moving from one package to another could easily be remapped.
Good to know.
>>>>
>>>> Thanks and Regards,
>>>> Dirk
Thanks and Regards,
Dirk
|
|
| |
| Re: How to split up large meta models [message #516620 is a reply to message #516596] |
Wed, 24 February 2010 10:42 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi Ed,
>
> Found the ecorediag files as mentioned in my previous post.
>
> So all the diagram files refer to the same single ecore model.
Yep.
> Could you explain the workflow needed to arrange the files that way.
> The only way I could imagine is to start with a large diagram
> containing everything, creating multiple copies of that file and then
> specializing each file by performing "Remove from Diagram" operations
> leaving those elements relevant for the specific diagram. I can't
> believe it has to go that way.
Yes, pretty much.
>
> Normally the diagram files are associated to an ecore file and their
> names are equal before the dot.
Yes, that's kind of annoying. I basically created it renamed it and
then created a new one.
> Somehow this association needs to be broken, just I wasn't able to
> find out how, at least without renaming the diagram files. When I
> create a new diagram the editor insists on naming the files equal
> before the dot.
I'm not sure why it was done in this limiting way.
>
> I guess if I managed to create multiple diagrams all refering to the
> same ecore file I could use drag&drop from the outline view to the
> canvas in order to populate the diagram with the model elements I want
> to be visible, am I right? I believe I've come across this techique in
> another post.
Yes.
>
> Thanks again and Regards,
> Dirk Hoffmann
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to split up large meta models [message #516639 is a reply to message #516620] |
Wed, 24 February 2010 16:16 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Hi Ed,
>>
>> Found the ecorediag files as mentioned in my previous post.
>>
>> So all the diagram files refer to the same single ecore model.
> Yep.
>> Could you explain the workflow needed to arrange the files that way.
>> The only way I could imagine is to start with a large diagram
>> containing everything, creating multiple copies of that file and then
>> specializing each file by performing "Remove from Diagram" operations
>> leaving those elements relevant for the specific diagram. I can't
>> believe it has to go that way.
> Yes, pretty much.
>>
>> Normally the diagram files are associated to an ecore file and their
>> names are equal before the dot.
> Yes, that's kind of annoying. I basically created it renamed it and
> then created a new one.
Ok, so I know I didn't miss a feature of the editor. This is my workflow
now:
1 Create a diagram from the ecore file named Empty.ecorediag.
2 Deleted the automatically placed model elements from the diagram only.
3 Create new diagrams through copy & paste from the Empty.ecorediag file.
Thanks
>> Somehow this association needs to be broken, just I wasn't able to
>> find out how, at least without renaming the diagram files. When I
>> create a new diagram the editor insists on naming the files equal
>> before the dot.
> I'm not sure why it was done in this limiting way.
>>
>> I guess if I managed to create multiple diagrams all refering to the
>> same ecore file I could use drag&drop from the outline view to the
>> canvas in order to populate the diagram with the model elements I want
>> to be visible, am I right? I believe I've come across this techique in
>> another post.
> Yes.
>>
>> Thanks again and Regards,
>> Dirk Hoffmann
|
|
|
| Re: How to split up large meta models [message #622200 is a reply to message #516318] |
Tue, 23 February 2010 16:52 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi,
>
> over time our meta model became quite large so we would like to split
> it up.
>
> We're using the Ecore Diagram editor from the Ecore Tools Model.
>
> The current ecore model consists of a single package.
>
> We already released a product based on the large meta model to our
> customers and would like the new version of our product to be able to
> load the model files produced by the former version without having to
> migrate the model files.
>
> I guess this means we cannot split up the meta-model into multiple
> packages as that would change the way model instance are loaded/saved.
> Am I right?
It wouldn't change a lot. The nsURI of the package is only used in a
few places, i.e., on the root element, and as the xsi/xmi:type of
elements that are serialized with a derived instance.
>
> Alternatively splitting the meta-model diagram into multiple diagrams
> would help a lot. There is a navigation button labeled "Open the
> parent diagram" suggesting splitting up a diagram has been envisioned
> by the creators of the editor. Unfortunately I could not find out how
> to do so. Any help is very much appreciated.
For Ecore itself, I just created a bunch of separate diagrams. You'll
find that all in the models folder of org.eclipse.emf.ecore.
>
> We also started a new EMF/GMF based product and want to let the new
> meta-model be composed of small sub-models right from the beginning.
> What is the recommended way for this?
It's definitely possible to create a bunch of interrelated smaller
packages. Personally I'd avoid any nesting of packages, but that's okay
too.
>
> Parts of the meta-model of the old and the new product are similar so
> we thought about sharing those parts. We abandonned that idea for
> several reasons but still I'm wondering if this were possible.
You can always specialize how type and element names are looked up to
remap to a new package structure. A derived instance of
BasicExtendedMetaData can be quite useful for that.
>
> Thanks and Regards,
> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to split up large meta models [message #622205 is a reply to message #516354] |
Wed, 24 February 2010 09:28 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
First of all thanks for the quick reply. (I'm still wondering how you
manage to answer so many news messages)
See comments below.
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
>
> Dirk Hoffmann wrote:
>> Hi,
>>
>> over time our meta model became quite large so we would like to split
>> it up.
>>
>> We're using the Ecore Diagram editor from the Ecore Tools Model.
>>
>> The current ecore model consists of a single package.
>>
>> We already released a product based on the large meta model to our
>> customers and would like the new version of our product to be able to
>> load the model files produced by the former version without having to
>> migrate the model files.
>>
>> I guess this means we cannot split up the meta-model into multiple
>> packages as that would change the way model instance are loaded/saved.
>> Am I right?
> It wouldn't change a lot. The nsURI of the package is only used in a
> few places, i.e., on the root element, and as the xsi/xmi:type of
> elements that are serialized with a derived instance.
Ok
>>
>> Alternatively splitting the meta-model diagram into multiple diagrams
>> would help a lot. There is a navigation button labeled "Open the
>> parent diagram" suggesting splitting up a diagram has been envisioned
>> by the creators of the editor. Unfortunately I could not find out how
>> to do so. Any help is very much appreciated.
> For Ecore itself, I just created a bunch of separate diagrams. You'll
> find that all in the models folder of org.eclipse.emf.ecore.
I guess you mean those .mdl files, probably Rational Rose Model files.
We're using the Ecore Tools Diagram Editor (the one creating .ecorediag
files). Do you know of examples using this editor or is there a
conversion facility for .mdl files?
>>
>> We also started a new EMF/GMF based product and want to let the new
>> meta-model be composed of small sub-models right from the beginning.
>> What is the recommended way for this?
> It's definitely possible to create a bunch of interrelated smaller
> packages. Personally I'd avoid any nesting of packages, but that's okay
> too.
Can you point out what you think is bad about nesting them because
that's what we thought to do.
>>
>> Parts of the meta-model of the old and the new product are similar so
>> we thought about sharing those parts. We abandonned that idea for
>> several reasons but still I'm wondering if this were possible.
> You can always specialize how type and element names are looked up to
> remap to a new package structure. A derived instance of
> BasicExtendedMetaData can be quite useful for that.
Could also be a solution for my first point, the migration in case of
splitting up the meta-model, I guess
>>
>> Thanks and Regards,
>> Dirk
|
|
|
| Re: How to split up large meta models [message #622206 is a reply to message #622205] |
Wed, 24 February 2010 11:17 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> First of all thanks for the quick reply. (I'm still wondering how you
> manage to answer so many news messages)
A little bit of OCD helps. Also, itemis funds my work and part of that
includes ensuring that the Eclipse modeling technology is successful and
that its usage is widespread. There's nothing quite like helping others
be successful to help ensure that...
>
> See comments below.
>
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>>
>> Dirk Hoffmann wrote:
>>> Hi,
>>>
>>> over time our meta model became quite large so we would like to
>>> split it up.
>>>
>>> We're using the Ecore Diagram editor from the Ecore Tools Model.
>>>
>>> The current ecore model consists of a single package.
>>>
>>> We already released a product based on the large meta model to our
>>> customers and would like the new version of our product to be able
>>> to load the model files produced by the former version without
>>> having to migrate the model files.
>>>
>>> I guess this means we cannot split up the meta-model into multiple
>>> packages as that would change the way model instance are
>>> loaded/saved. Am I right?
>> It wouldn't change a lot. The nsURI of the package is only used in a
>> few places, i.e., on the root element, and as the xsi/xmi:type of
>> elements that are serialized with a derived instance.
> Ok
>>>
>>> Alternatively splitting the meta-model diagram into multiple
>>> diagrams would help a lot. There is a navigation button labeled
>>> "Open the parent diagram" suggesting splitting up a diagram has been
>>> envisioned by the creators of the editor. Unfortunately I could not
>>> find out how to do so. Any help is very much appreciated.
>> For Ecore itself, I just created a bunch of separate diagrams.
>> You'll find that all in the models folder of org.eclipse.emf.ecore.
> I guess you mean those .mdl files, probably Rational Rose Model files.
> We're using the Ecore Tools Diagram Editor (the one creating
> .ecorediag files). Do you know of examples using this editor or is
> there a conversion facility for .mdl files?
No, I don't mean the mdl files. I'm no longer capable of editing
those. That's why I've switched to creating *.ecorediag equivalents for
the diagram in the *.mdl file. I had to do that manually, which is
pretty painful.
>>>
>>> We also started a new EMF/GMF based product and want to let the new
>>> meta-model be composed of small sub-models right from the beginning.
>>> What is the recommended way for this?
>> It's definitely possible to create a bunch of interrelated smaller
>> packages. Personally I'd avoid any nesting of packages, but that's
>> okay too.
> Can you point out what you think is bad about nesting them because
> that's what we thought to do.
There's nothing bad about it, it's just that all the tools end up
supporting it as an afterthought, so you're much more likely to
encounter tool bugs with nested subpackages than without them. I.e.,
they're basically syntactic sugar that unfortunately often end up being
a little more like syntactic rat poison.
>>>
>>> Parts of the meta-model of the old and the new product are similar
>>> so we thought about sharing those parts. We abandonned that idea for
>>> several reasons but still I'm wondering if this were possible.
>> You can always specialize how type and element names are looked up to
>> remap to a new package structure. A derived instance of
>> BasicExtendedMetaData can be quite useful for that.
> Could also be a solution for my first point, the migration in case of
> splitting up the meta-model, I guess
Yes, such an instance ends up as a clearing house for mapping namespace
and names to their corresponding Ecore metadata so for example a class
moving from one package to another could easily be remapped.
>>>
>>> Thanks and Regards,
>>> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to split up large meta models [message #622209 is a reply to message #516542] |
Wed, 24 February 2010 13:23 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
See below,
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
>
> Dirk Hoffmann wrote:
>> First of all thanks for the quick reply. (I'm still wondering how you
>> manage to answer so many news messages)
> A little bit of OCD helps. Also, itemis funds my work and part of that
Uh, really that serious? ;-)
> includes ensuring that the Eclipse modeling technology is successful and
> that its usage is widespread. There's nothing quite like helping others
> be successful to help ensure that...
>>
>> See comments below.
>>
>> Ed Merks schrieb:
>>> Dirk,
>>>
>>> Comments below.
>>>
>>>
>>> Dirk Hoffmann wrote:
>>>> Hi,
>>>>
>>>> over time our meta model became quite large so we would like to
>>>> split it up.
>>>>
>>>> We're using the Ecore Diagram editor from the Ecore Tools Model.
>>>>
>>>> The current ecore model consists of a single package.
>>>>
>>>> We already released a product based on the large meta model to our
>>>> customers and would like the new version of our product to be able
>>>> to load the model files produced by the former version without
>>>> having to migrate the model files.
>>>>
>>>> I guess this means we cannot split up the meta-model into multiple
>>>> packages as that would change the way model instance are
>>>> loaded/saved. Am I right?
>>> It wouldn't change a lot. The nsURI of the package is only used in a
>>> few places, i.e., on the root element, and as the xsi/xmi:type of
>>> elements that are serialized with a derived instance.
>> Ok
>>>>
>>>> Alternatively splitting the meta-model diagram into multiple
>>>> diagrams would help a lot. There is a navigation button labeled
>>>> "Open the parent diagram" suggesting splitting up a diagram has been
>>>> envisioned by the creators of the editor. Unfortunately I could not
>>>> find out how to do so. Any help is very much appreciated.
>>> For Ecore itself, I just created a bunch of separate diagrams.
>>> You'll find that all in the models folder of org.eclipse.emf.ecore.
>> I guess you mean those .mdl files, probably Rational Rose Model files.
>> We're using the Ecore Tools Diagram Editor (the one creating
>> .ecorediag files). Do you know of examples using this editor or is
>> there a conversion facility for .mdl files?
> No, I don't mean the mdl files. I'm no longer capable of editing
> those. That's why I've switched to creating *.ecorediag equivalents for
> the diagram in the *.mdl file. I had to do that manually, which is
> pretty painful.
Ok, should have looked into the latest sources, not the 2.5.0 source
jar. Eventually found them here:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.ecore/model/?root=Model ing_Project
>>>>
>>>> We also started a new EMF/GMF based product and want to let the new
>>>> meta-model be composed of small sub-models right from the beginning.
>>>> What is the recommended way for this?
>>> It's definitely possible to create a bunch of interrelated smaller
>>> packages. Personally I'd avoid any nesting of packages, but that's
>>> okay too.
>> Can you point out what you think is bad about nesting them because
>> that's what we thought to do.
> There's nothing bad about it, it's just that all the tools end up
> supporting it as an afterthought, so you're much more likely to
> encounter tool bugs with nested subpackages than without them. I.e.,
> they're basically syntactic sugar that unfortunately often end up being
> a little more like syntactic rat poison.
Schluck.
>>>>
>>>> Parts of the meta-model of the old and the new product are similar
>>>> so we thought about sharing those parts. We abandonned that idea for
>>>> several reasons but still I'm wondering if this were possible.
>>> You can always specialize how type and element names are looked up to
>>> remap to a new package structure. A derived instance of
>>> BasicExtendedMetaData can be quite useful for that.
>> Could also be a solution for my first point, the migration in case of
>> splitting up the meta-model, I guess
> Yes, such an instance ends up as a clearing house for mapping namespace
> and names to their corresponding Ecore metadata so for example a class
> moving from one package to another could easily be remapped.
Good to know.
>>>>
>>>> Thanks and Regards,
>>>> Dirk
Thanks and Regards,
Dirk
|
|
| |
| Re: How to split up large meta models [message #622218 is a reply to message #622212] |
Wed, 24 February 2010 15:37 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi Ed,
>
> Found the ecorediag files as mentioned in my previous post.
>
> So all the diagram files refer to the same single ecore model.
Yep.
> Could you explain the workflow needed to arrange the files that way.
> The only way I could imagine is to start with a large diagram
> containing everything, creating multiple copies of that file and then
> specializing each file by performing "Remove from Diagram" operations
> leaving those elements relevant for the specific diagram. I can't
> believe it has to go that way.
Yes, pretty much.
>
> Normally the diagram files are associated to an ecore file and their
> names are equal before the dot.
Yes, that's kind of annoying. I basically created it renamed it and
then created a new one.
> Somehow this association needs to be broken, just I wasn't able to
> find out how, at least without renaming the diagram files. When I
> create a new diagram the editor insists on naming the files equal
> before the dot.
I'm not sure why it was done in this limiting way.
>
> I guess if I managed to create multiple diagrams all refering to the
> same ecore file I could use drag&drop from the outline view to the
> canvas in order to populate the diagram with the model elements I want
> to be visible, am I right? I believe I've come across this techique in
> another post.
Yes.
>
> Thanks again and Regards,
> Dirk Hoffmann
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to split up large meta models [message #622220 is a reply to message #622218] |
Wed, 24 February 2010 16:16 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Hi Ed,
>>
>> Found the ecorediag files as mentioned in my previous post.
>>
>> So all the diagram files refer to the same single ecore model.
> Yep.
>> Could you explain the workflow needed to arrange the files that way.
>> The only way I could imagine is to start with a large diagram
>> containing everything, creating multiple copies of that file and then
>> specializing each file by performing "Remove from Diagram" operations
>> leaving those elements relevant for the specific diagram. I can't
>> believe it has to go that way.
> Yes, pretty much.
>>
>> Normally the diagram files are associated to an ecore file and their
>> names are equal before the dot.
> Yes, that's kind of annoying. I basically created it renamed it and
> then created a new one.
Ok, so I know I didn't miss a feature of the editor. This is my workflow
now:
1 Create a diagram from the ecore file named Empty.ecorediag.
2 Deleted the automatically placed model elements from the diagram only.
3 Create new diagrams through copy & paste from the Empty.ecorediag file.
Thanks
>> Somehow this association needs to be broken, just I wasn't able to
>> find out how, at least without renaming the diagram files. When I
>> create a new diagram the editor insists on naming the files equal
>> before the dot.
> I'm not sure why it was done in this limiting way.
>>
>> I guess if I managed to create multiple diagrams all refering to the
>> same ecore file I could use drag&drop from the outline view to the
>> canvas in order to populate the diagram with the model elements I want
>> to be visible, am I right? I believe I've come across this techique in
>> another post.
> Yes.
>>
>> Thanks again and Regards,
>> Dirk Hoffmann
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:53:11 GMT 2024
Powered by FUDForum. Page generated in 0.04078 seconds |
] 
Search
Help
Register
Login
Home
