Home » Modeling » EMF » Extending the Ecore meta-metamodel (M3)
|
| Re: Extending the Ecore meta-metamodel (M3) [message #645334 is a reply to message #645322] |
Thu, 16 December 2010 16:09   |
|
Hi e.c.l.i.p.s.e.n.e.w.s.g.r.o.u.p,
Extending Ecore is not recommended because you would inherit internal implementation that can change at any time and break you. Forking and and *changing* Ecore sounds even worse. Both seems possible though.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 16.12.2010 17:04, schrieb e.c.l.i.p.s.e.n.e.w.s.g.r.o.u.p@gmail.com:
> Hi,
>
> I wonder whether someone could shed light on how the Ecore meta-metamodel can be extended with one or more additional concepts? As an example, let's say that we would like to add a concept EEntity to Ecore as a subtype of EClassifier. Clearly, this concept should be supported by the EMF framework and made available when creating Ecore models (.ecore). Is this possible in an intuitive manner?
>
> I've search after information on this, but I've not been able to localise such.
>
> Also, I'm aware that such an extension may compromise the compatibility with existing tools and technologies based on the Ecore meta-metamodel. However, this is intended as a prototype.
>
> Any help, tips or links are appreciated!
>
> Have a good day!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Extending the Ecore meta-metamodel (M3) [message #645341 is a reply to message #645322] |
Thu, 16 December 2010 16:56 |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
As Eike suggests, extending Ecore is not recommended. Try to get by
annotating Ecore instead. I imagine that entity could be supported by
having EClasses that have some special EClasses in its super types and
that at runtime these would be instances that implement those special
interfaces. Perhaps you want to generate some other stuff too, but I
expect you could drive that with annotations...
e.c.l.i.p.s.e.n.e.w.s.g.r.o.u.p@gmail.com wrote:
> Hi,
>
> I wonder whether someone could shed light on how the Ecore
> meta-metamodel can be extended with one or more additional concepts?
> As an example, let's say that we would like to add a concept EEntity
> to Ecore as a subtype of EClassifier. Clearly, this concept should be
> supported by the EMF framework and made available when creating Ecore
> models (.ecore). Is this possible in an intuitive manner?
>
> I've search after information on this, but I've not been able to
> localise such.
>
> Also, I'm aware that such an extension may compromise the
> compatibility with existing tools and technologies based on the Ecore
> meta-metamodel. However, this is intended as a prototype.
>
> Any help, tips or links are appreciated!
>
> Have a good day!
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | | | | | | | | | |
| Re: Extending the Ecore meta-metamodel (M3) [message #646828 is a reply to message #646774] |
Fri, 31 December 2010 17:10 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Comments below.
e.c.l.i.p.s.e.n.e.w.s.g.r.o.u.p@gmail.com wrote:
> It seems to me that you apparently don't want to give specific details
> on how to revise the framework in the manner I've described.
You'll find that I have a years long track record of giving specific
details.
> You state that my question is mysterious and not concrete, but I do
> believe it's both concrete and straightforward.
I'm sure you do, but I'm not sure anyone can argue that EClass2 is a
concrete concept.
>
> Of course, you are perfectly entitled not to give specific information.
You'll find that specific questions typically yield specific answers
while open ended general questions often get questions as answers.
> If this is the case, may I ask why?
I'm a very busy person and I'm not getting the impression you're doing
all that much to find answers on your own. You might, for example, look
at all the places that EClass is used in the framework. You might
explore how EClass and EDataType are used in the rest of the model, and
so on.
>
> Anyway, I was merely looking for some guidelines to get going.
Extending Ecore is something I always recommend against, so you're
asking for guidelines to navigating a path I consider best avoided...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Extending the Ecore meta-metamodel (M3) [message #1064679 is a reply to message #645322] |
Thu, 20 June 2013 14:07 |
Darren Hurt
Messages: 32
Registered: July 2009 |
Member |
|
|
Hi Ed.
I am a newcomer to the 'mainstream' MDA community, but quite an old hat when it comes to devising MDA architecture and practising MDA principles (about 15 years in the private MDA 'backstreet' ).
I think the lack of ability to extend the root M3 model in mainstream modelling tools etc. is somewhat holding back the full potential of MDA.
Let me elaborate why I believe this seemingly absurd statement.
In my previous job I had a large hand in devising and implementing a modelling structure whereby we had our own M3 model (according to OMG terminology) that was it's own meta-model etc., then an M2 model to define the meta-model of our model and the model itself where actual business models were created for end products. This was the central piece in a platform for creating solutions in the capital markets arena, but the platform was in fact completely generic. We devised our own user language that could be used at all levels (M3, M2, M1 and M0). It is used to define the logic of extra derived properties, validation constraints and queries of the model, meta-models and running system. I guess the user language was performing a role similar to what I see with OCL in the 'mainstream' stuff at the moment (e.g. with OCLInEcore invariants, derived ops, queries etc.), but with the added ability to provide extra behaviour in the final running (M0) system. However, these things were invented by us entirely in isolation, so it's interesting to see many of these similar ideas in the mainstream and OMG standards. I guess it was and is an insular organisation that I worked for, and that we were an insular group within it  .
Anyway, my point is, that the modelling environment we had was enormously richer than that offered by the mainstream 'ecore'/MOF specifications, as we could extend our own root model however we liked. This recursion was tremendously powerful and enabled us to do some amazing things, from defining our own kinds of model inheritances (single, multiple, none etc.) to defining the forms for editing the models in the models themselves, with crazy recursive stuff like be able to create the forms to edit the types that make up the forms model in forms defined by instances of the very types that made up the forms model itself etc., or writing validation functions for the validation function types that themselves were instances of the validation function types etc. etc. In fact a big point about it is that the tooling of the entire model (editors, manipulation actions etc. etc.) was largely defined in this M3 model itself, enabling it to kind of tool itself if you see what I mean. The whole look of the editors and the actions available, the validation rules etc. could be utterly changed without writing (OR GENERATING!) any Java code (some user language code and meta-model changes only). When combined with subjectivity and functional read-only-ness rules in the meta-models (which we also modeled) it even enabled me to devise ways of giving entirely different views and editing permissions for models to different kinds of users.
For these reasons I can see exactly why someone would want (very much) to be able to override the M3 model itself, and it is a shame that this is not yet a mainstream possibility without inventing your own structures that do not comply with the standards.
Personally I feel that the importance of the somewhat restricting OMG standards are over-stated, and that overly zealous conformance to these standards and associated process can serve to greatly slow down the rate of technological progress.
I see enormous potential in a modelling framework that allows extension of the root model, and if only I could persuade my former company to donate what we have to the open source community, or to develop a product based only on the modelling framework we devised, then it would be very interesting to see how it was received as a standalone product in its own right .
regards,
Darren
|
|
|
| Re: Extending the Ecore meta-metamodel (M3) [message #1064729 is a reply to message #1064679] |
Thu, 20 June 2013 16:40 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Darren,
Comments below.
On 20/06/2013 4:07 PM, Darren Hurt wrote:
> Hi Ed.
>
> I am a newcomer to the 'mainstream' MDA community, but quite an old
> hat when it comes to devising MDA architecture and practising MDA
> principles (about 15 years in the private MDA 'backstreet' ).
> I think the lack of ability to extend the root M3 model in mainstream
> modelling tools etc. is somewhat holding back the full potential of MDA.
I doubt that. What makes M3 so special?
> Let me elaborate why I believe this seemingly absurd statement.
> In my previous job I had a large hand in devising and implementing a
> modelling structure whereby we had our own M3 model (according to OMG
> terminology) that was it's own meta-model etc., then an M2 model to
> define the meta-model of our model and the model itself where actual
> business models were created for end products. This was the central
> piece in a platform for creating solutions in the capital markets
> arena, but the platform was in fact completely generic. We devised our
> own user language that could be used at all levels (M3, M2, M1 and
> M0). It is used to define the logic of extra derived properties,
> validation constraints and queries of the model, meta-models and
> running system. I guess the user language was performing a role
> similar to what I see with OCL in the 'mainstream' stuff at the moment
> (e.g. with OCLInEcore invariants, derived ops, queries etc.), but with
> the added ability to provide extra behaviour in the final running (M0)
> system. However, these things were invented by us entirely in
> isolation, so it's interesting to see many of these similar ideas in
> the mainstream and OMG standards. I guess it was and is an insular
> organisation that I worked for, and that we were an insular group
> within it :).
>
> Anyway, my point is, that the modelling environment we had was
> enormously richer than that offered by the mainstream 'ecore'/MOF
> specifications, as we could extend our own root model however we liked.
I'm doubtful of the final self defining meta model needing to be
extensible and I'm doubtful how the representation for instance could
deal with such extensibility.
> This recursion was tremendously powerful and enabled us to do some
> amazing things, from defining our own kinds of model inheritances
> (single, multiple, none etc.) to defining the forms for editing the
> models in the models themselves, with crazy recursive stuff like be
> able to create the forms to edit the types that make up the forms
> model in forms defined by instances of the very types that made up the
> forms model itself etc., or writing validation functions for the
> validation function types that themselves were instances of the
> validation function types etc. etc. In fact a big point about it is
> that the tooling of the entire model (editors, manipulation actions
> etc. etc.) was largely defined in this M3 model itself, enabling it to
> kind of tool itself if you see what I mean.
It's impossible to know concretely what this all implies.
> The whole look of the editors and the actions available, the
> validation rules etc. could be utterly changed without writing (OR
> GENERATING!) any Java code (some user language code and meta-model
> changes only). When combined with subjectivity and functional
> read-only-ness rules in the meta-models (which we also modeled) it
> even enabled me to devise ways of giving entirely different views and
> editing permissions for models to different kinds of users.
It's not even clear here which of all the M3 though M0 this might apply,
or only to the M0 things.
> For these reasons I can see exactly why someone would want (very much)
> to be able to override the M3 model itself, and it is a shame that
> this is not yet a mainstream possibility without inventing your own
> structures that do not comply with the standards. Personally I feel
> that the importance of the somewhat restricting OMG standards are
> over-stated, and that overly zealous conformance to these standards
> and associated process can serve to greatly slow down the rate of
> technological progress.
I doubt anyone (at the OMG) will accuse EMF of being overzealous about
conforming to OMG standards.
> I see enormous potential in a modelling framework that allows
> extension of the root model, and if only I could persuade my former
> company to donate what we have to the open source community, or to
> develop a product based only on the modelling framework we devised,
> then it would be very interesting to see how it was received as a
> standalone product in its own right :).
I'm certainly curious, but also dubious. In any case, nothing prevents
someone from extending Ecore but all the downstream frameworks that know
only about Ecore won't understand anything about such extension so the
value is limited.
>
> regards,
>
> Darren
>
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Extending the Ecore meta-metamodel (M3) [message #1064772 is a reply to message #1064729] |
Thu, 20 June 2013 23:58 |
Darren Hurt
Messages: 32
Registered: July 2009 |
Member |
|
|
Ed,
Thanks for your replies. It is of course impossible for you to get much of a feel for what I describe without really seeing it However, this is difficult to accomplish for a number of reasons.
Extending the self referential model is tricky, and needs a little care (in the mysterious framework i refer to) but it does work and is very powerful, requiring a few choice bits of data in the bootstrapping methods occasionally to prevent recursion issues etc.
I get your point about downstream tools, but in the framework I describe that was not an issue as any extra tooling could be invented in the context of the model itself, and in an extremely modular way that largely avoided polluting inappropriate parts of the model.
Anyway, I understand the difficulties in opening up the Ecore M3 model, but at the same time I wanted to point out that doing so can - as I found - be extremely worthwhile.
Anyway, just wondering how I might start getting involved and contributing some of my modelling ideas to Eclipse etc? Its tricky when one works for a very small firm with 0 clout, and that does not have the resources to sponsor such activity...
It feels like I'd have to go it alone, but I am completely unsure of the business model surrounding open source software contribution (I.e. how will I make a living from it if I'm giving it away - I guess that's why I'm working for someone else ).
|
|
|
| Re: Extending the Ecore meta-metamodel (M3) [message #1064800 is a reply to message #1064772] |
Fri, 21 June 2013 07:44 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Darren,
Comments below.
On 21/06/2013 1:58 AM, Darren Hurt wrote:
> Ed,
> Thanks for your replies. It is of course impossible for you to get
> much of a feel for what I describe without really seeing it However,
> this is difficult to accomplish for a number of reasons.
> Extending the self referential model is tricky, and needs a little
> care (in the mysterious framework i refer to) but it does work and is
> very powerful, requiring a few choice bits of data in the
> bootstrapping methods occasionally to prevent recursion issues etc.
> I get your point about downstream tools, but in the framework I
> describe that was not an issue as any extra tooling could be invented
> in the context of the model itself, and in an extremely modular way
> that largely avoided polluting inappropriate parts of the model.
> Anyway, I understand the difficulties in opening up the Ecore M3
> model, but at the same time I wanted to point out that doing so can -
> as I found - be extremely worthwhile.
I'm always open to concrete new ideas...
>
> Anyway, just wondering how I might start getting involved and
> contributing some of my modelling ideas to Eclipse etc?
Just do it. :-P
Generally, to make contributions, you'll need to be in a position to be
able to make your contributions available under the EPL license.
http://www.eclipse.org/legal/CLA.php
Most projects are more than willing to work closely with contributors,
and essentially all projects are using git, so it's easy to create a
fork for managing your own playground. So find something that interests
you, look at the bugzillas open for the project, and see if any of those
look interesting to try to address in order to learn about the project...
> Its tricky when one works for a very small firm with 0 clout, and that
> does not have the resources to sponsor such activity...
In general clout is proportional to involvement and contribution. He/she
who writes the code has the clout. The company I worked for didn't feel
that EMF was something they could convince other companies to use (so
they invented impressive technologies like SDO instead), and this was a
company with very impressive clout. Popularizing EMF turned out to be
much easier than they imagined, but who's heard of SDO?
> It feels like I'd have to go it alone, but I am completely unsure of
> the business model surrounding open source software contribution (I.e.
> how will I make a living from it if I'm giving it away :) - I guess
> that's why I'm working for someone else :)).
Yes, that's indeed an open problem solved in a number of different ways,
none of which are perfect. Being the leading expert of a software base
that's widely adopted is certainly an opportunity for associated service
work. Alternatively, providing commercial products on top of an open
base is another approach. Government sponsorship is also occasionally
possible.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 02:17:20 GMT 2024
Powered by FUDForum. Page generated in 0.02859 seconds |
] 
Search
Help
Register
Login
Home
