Home » Modeling » EMF » Why didn't EMF use the UML meta-model and the MOF?
| Why didn't EMF use the UML meta-model and the MOF? [message #376134] |
Mon, 14 October 2002 05:09  |
Eclipse User |
|
|
|
Hi,
(I am new to this newsgroup, so if this has been answered many times, please
just fwd me to the reference. I read the faq, but it didn't really answer
the question.)
I am confused as to why EMF didn't use the MOF / JMI and UML meta-model
specs from the OMG? These are well accepted, established, and provide full
UML and XMI coverage. From my perspective as a case vendor, EMF looks like
an undercooked re-invention.
Was the reason for simplicity? Do the EMF architects know something about
the MOF2.0 spec, and are moving forward to this? Don't they agree with the
MOF spec?
Cheers,
Andrew McVeigh
London, UK
http://www.hopstepjump.com
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376135 is a reply to message #376134] |
Mon, 14 October 2002 06:54  |
| Eclipse User |
|
|
|
Andrew,
Being overcooked verses undercooked depends on your preference but once
something is overcooked, no amount of uncooking will fix it. There's certainly
a lesson in that...
EMF began as a full MOF implementation some years ago and has been pruned down
to a set of essential requirements based on practical experience with the
technology. EMF represents the core subset that's left when the non-essentials
are eliminated. It represents a rock solid foundation upon which the more
ambitious extensions of UML and MDA can be built. A number of the MDA vendors
certainly view EMF in this light...
Members of our group are involved in a number of standards efforts, including
the MOF 2.0 work. We are also a very pragmatic bunch, and we strive to deliver
simple solutions to complex problems.
Andrew McVeigh wrote:
> Hi,
>
> (I am new to this newsgroup, so if this has been answered many times, please
> just fwd me to the reference. I read the faq, but it didn't really answer
> the question.)
>
> I am confused as to why EMF didn't use the MOF / JMI and UML meta-model
> specs from the OMG? These are well accepted, established, and provide full
> UML and XMI coverage. From my perspective as a case vendor, EMF looks like
> an undercooked re-invention.
>
> Was the reason for simplicity? Do the EMF architects know something about
> the MOF2.0 spec, and are moving forward to this? Don't they agree with the
> MOF spec?
>
> Cheers,
> Andrew McVeigh
> London, UK
> http://www.hopstepjump.com
--
Ed Merks
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376137 is a reply to message #376135] |
Mon, 14 October 2002 12:18 |
| Eclipse User |
|
|
|
Hi Ed,
Thanks for the response.
> Being overcooked verses undercooked depends on your preference but once
> something is overcooked, no amount of uncooking will fix it. There's
certainly
> a lesson in that...
I have no problems with the MOF being referred to as overcooked, but the
same is true of things like EJB, CORBA, UML etc. My preference for them
lies in the fact that they are standards and they are fairly comprehensive.
As such, they facilitate vertical tool chains between vendors.
> EMF began as a full MOF implementation some years ago and has been pruned
down
> to a set of essential requirements based on practical experience with the
> technology. EMF represents the core subset that's left when the
non-essentials
> are eliminated. It represents a rock solid foundation upon which the more
> ambitious extensions of UML and MDA can be built. A number of the MDA
vendors
> certainly view EMF in this light...
How would / should one represent a state machine using the EMF? Do you
envisage EMG being able to be the repository for a fully-fledged UML case
tool, or is that not its intention? I also use a number of tools from
vendors which rely on XMI, and only a very small subset of the UML
meta-model is supported via the EMF XMI, as far as I can see. I could be
wrong, however, as I have only had a brief investigation of EMF.
I was getting very excited about EMF after the announcement, and fully
expected it to be a full MOF implementation in the spirit of Netbeans MDR.
I currently use NSUML and NSMDF and find them to be quite acceptable.
> Members of our group are involved in a number of standards efforts,
including
> the MOF 2.0 work. We are also a very pragmatic bunch, and we strive to
deliver
> simple solutions to complex problems.
I agree, and the goal of simplicity is laudable. I guess that I find
immense value in the OMG specified UML meta-model. I work with it all the
time, and have found it to be comprehensive and beneficial. Wouldn't it be
possible to support both the EMF core model and a full UML meta-model via
mappings to the same MOF repository?
Cheers,
Andrew
> Andrew McVeigh wrote:
>
> > Hi,
> >
> > (I am new to this newsgroup, so if this has been answered many times,
please
> > just fwd me to the reference. I read the faq, but it didn't really
answer
> > the question.)
> >
> > I am confused as to why EMF didn't use the MOF / JMI and UML meta-model
> > specs from the OMG? These are well accepted, established, and provide
full
> > UML and XMI coverage. From my perspective as a case vendor, EMF looks
like
> > an undercooked re-invention.
> >
> > Was the reason for simplicity? Do the EMF architects know something
about
> > the MOF2.0 spec, and are moving forward to this? Don't they agree with
the
> > MOF spec?
> >
> > Cheers,
> > Andrew McVeigh
> > London, UK
> > http://www.hopstepjump.com
>
> --
> Ed Merks
>
>
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376139 is a reply to message #376137] |
Mon, 14 October 2002 13:14 |
| Eclipse User |
|
|
|
Andrew,
You are exactly right about having both EMF and a full UML model. The XSD model
is described and implemented using EMF so the same could most certainly be done
for a full UML model; unlike XSD, it could perhaps extend Ecore directly. There
are interesting discussions to be had about this, and about how UML and XSD are
related...
By restricting Ecore to core concepts that have a simple and direct Java
interpretation, one with hand-written quality and runtime performance, we hope
to bring the powerful advantages of modeling to those not (yet) convinced by a
full MDA vision. Ecore is a simple and powerful common denominator; perhaps that
makes it only as exciting as pavement, but that is the stuff of roads...
Andrew McVeigh wrote:
> Hi Ed,
>
> Thanks for the response.
>
> > Being overcooked verses undercooked depends on your preference but once
> > something is overcooked, no amount of uncooking will fix it. There's
> certainly
> > a lesson in that...
>
> I have no problems with the MOF being referred to as overcooked, but the
> same is true of things like EJB, CORBA, UML etc. My preference for them
> lies in the fact that they are standards and they are fairly comprehensive.
> As such, they facilitate vertical tool chains between vendors.
>
> > EMF began as a full MOF implementation some years ago and has been pruned
> down
> > to a set of essential requirements based on practical experience with the
> > technology. EMF represents the core subset that's left when the
> non-essentials
> > are eliminated. It represents a rock solid foundation upon which the more
> > ambitious extensions of UML and MDA can be built. A number of the MDA
> vendors
> > certainly view EMF in this light...
>
> How would / should one represent a state machine using the EMF? Do you
> envisage EMG being able to be the repository for a fully-fledged UML case
> tool, or is that not its intention? I also use a number of tools from
> vendors which rely on XMI, and only a very small subset of the UML
> meta-model is supported via the EMF XMI, as far as I can see. I could be
> wrong, however, as I have only had a brief investigation of EMF.
>
> I was getting very excited about EMF after the announcement, and fully
> expected it to be a full MOF implementation in the spirit of Netbeans MDR.
> I currently use NSUML and NSMDF and find them to be quite acceptable.
>
> > Members of our group are involved in a number of standards efforts,
> including
> > the MOF 2.0 work. We are also a very pragmatic bunch, and we strive to
> deliver
> > simple solutions to complex problems.
>
> I agree, and the goal of simplicity is laudable. I guess that I find
> immense value in the OMG specified UML meta-model. I work with it all the
> time, and have found it to be comprehensive and beneficial. Wouldn't it be
> possible to support both the EMF core model and a full UML meta-model via
> mappings to the same MOF repository?
>
> Cheers,
> Andrew
>
> > Andrew McVeigh wrote:
> >
> > > Hi,
> > >
> > > (I am new to this newsgroup, so if this has been answered many times,
> please
> > > just fwd me to the reference. I read the faq, but it didn't really
> answer
> > > the question.)
> > >
> > > I am confused as to why EMF didn't use the MOF / JMI and UML meta-model
> > > specs from the OMG? These are well accepted, established, and provide
> full
> > > UML and XMI coverage. From my perspective as a case vendor, EMF looks
> like
> > > an undercooked re-invention.
> > >
> > > Was the reason for simplicity? Do the EMF architects know something
> about
> > > the MOF2.0 spec, and are moving forward to this? Don't they agree with
> the
> > > MOF spec?
> > >
> > > Cheers,
> > > Andrew McVeigh
> > > London, UK
> > > http://www.hopstepjump.com
> >
> > --
> > Ed Merks
> >
> >
--
Ed Merks
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376145 is a reply to message #376137] |
Mon, 14 October 2002 15:29 |
| Eclipse User |
|
|
|
Andrew,
We're very interested in working with others on a full UML model using EMF.
We're hoping to see a proposal soon. EMF's Ecore model would be the meta-meta
model and ideally also the base model for this full UML model.
There has been some discussion of this topic already - see the "Marco's UML
plugin" thread (9/14/2002).
Frank.
Andrew McVeigh wrote:
> Hi Ed,
>
> Thanks for the response.
>
> > Being overcooked verses undercooked depends on your preference but once
> > something is overcooked, no amount of uncooking will fix it. There's
> certainly
> > a lesson in that...
>
> I have no problems with the MOF being referred to as overcooked, but the
> same is true of things like EJB, CORBA, UML etc. My preference for them
> lies in the fact that they are standards and they are fairly comprehensive.
> As such, they facilitate vertical tool chains between vendors.
>
> > EMF began as a full MOF implementation some years ago and has been pruned
> down
> > to a set of essential requirements based on practical experience with the
> > technology. EMF represents the core subset that's left when the
> non-essentials
> > are eliminated. It represents a rock solid foundation upon which the more
> > ambitious extensions of UML and MDA can be built. A number of the MDA
> vendors
> > certainly view EMF in this light...
>
> How would / should one represent a state machine using the EMF? Do you
> envisage EMG being able to be the repository for a fully-fledged UML case
> tool, or is that not its intention? I also use a number of tools from
> vendors which rely on XMI, and only a very small subset of the UML
> meta-model is supported via the EMF XMI, as far as I can see. I could be
> wrong, however, as I have only had a brief investigation of EMF.
>
> I was getting very excited about EMF after the announcement, and fully
> expected it to be a full MOF implementation in the spirit of Netbeans MDR.
> I currently use NSUML and NSMDF and find them to be quite acceptable.
>
> > Members of our group are involved in a number of standards efforts,
> including
> > the MOF 2.0 work. We are also a very pragmatic bunch, and we strive to
> deliver
> > simple solutions to complex problems.
>
> I agree, and the goal of simplicity is laudable. I guess that I find
> immense value in the OMG specified UML meta-model. I work with it all the
> time, and have found it to be comprehensive and beneficial. Wouldn't it be
> possible to support both the EMF core model and a full UML meta-model via
> mappings to the same MOF repository?
>
> Cheers,
> Andrew
>
> > Andrew McVeigh wrote:
> >
> > > Hi,
> > >
> > > (I am new to this newsgroup, so if this has been answered many times,
> please
> > > just fwd me to the reference. I read the faq, but it didn't really
> answer
> > > the question.)
> > >
> > > I am confused as to why EMF didn't use the MOF / JMI and UML meta-model
> > > specs from the OMG? These are well accepted, established, and provide
> full
> > > UML and XMI coverage. From my perspective as a case vendor, EMF looks
> like
> > > an undercooked re-invention.
> > >
> > > Was the reason for simplicity? Do the EMF architects know something
> about
> > > the MOF2.0 spec, and are moving forward to this? Don't they agree with
> the
> > > MOF spec?
> > >
> > > Cheers,
> > > Andrew McVeigh
> > > London, UK
> > > http://www.hopstepjump.com
> >
> > --
> > Ed Merks
> >
> >
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376147 is a reply to message #376145] |
Tue, 15 October 2002 04:42 |
| Eclipse User |
|
|
|
> We're very interested in working with others on a full UML model using
EMF.
> We're hoping to see a proposal soon. EMF's Ecore model would be the
meta-meta
> model and ideally also the base model for this full UML model.
That was what I suspected. In fact, Ecore looks a bit more like the OMGs
"metameta-model" (!) than a meta-model. I expect that to fully implement a
description of UML using Ecore, the result would end up looking like the
current OMG meta-model but a bit simpler.
(Contrast this with netbeans, which has a very well accomplished MOF
already. I think it is due for inclusion in the 4.0 release, sometime in
the medium-term future. It can take different backing stores, including a
small database).
One exciting possibility perhaps would be to steer this stuff in the
direction of Colin Atkinson's work on potency (UML2001). His basic line
seems to be that the OMG metameta-model is too complex, because of its
inability to express relationships that cross more than 1 layer of
instantiation. i.e. in the UML meta-model it would be nice to be able to
say that a component instance must reside in a node instance. Adding the
idea of potency allows this and means that the metameta-model shrinks down
to something very small -- something like Ecore, I would guess. Just a
thought.
My fear is that a heavy-duty re-invention of the wheel is needed to get to
the same point of utility as the MOF. Not that I care too much as I have
access to a reasonable MOF, but if I integrate with eclipse, I will have to
heavily rework my CASE tool. I also feel that the notion of a model in MDA
is not the same thing as the model of a java program. By only representing
java concepts, the abstraction level of all models is effectively pulled
right down to the implementation level. The idea of MDA seems to be to have
a very high level representation (with the detail intact, just a high level
of abstraction) and move it down to a platform-specific implementation
ideally via automation. This relies heavily on the notion of a UML
domain-specific profile.
>
> There has been some discussion of this topic already - see the "Marco's
UML
> plugin" thread (9/14/2002).
>
I'll have a look.
Cheers,
Andrew
> Frank.
>
>
> Andrew McVeigh wrote:
>
> > Hi Ed,
> >
> > Thanks for the response.
> >
> > > Being overcooked verses undercooked depends on your preference but
once
> > > something is overcooked, no amount of uncooking will fix it. There's
> > certainly
> > > a lesson in that...
> >
> > I have no problems with the MOF being referred to as overcooked, but the
> > same is true of things like EJB, CORBA, UML etc. My preference for them
> > lies in the fact that they are standards and they are fairly
comprehensive.
> > As such, they facilitate vertical tool chains between vendors.
> >
> > > EMF began as a full MOF implementation some years ago and has been
pruned
> > down
> > > to a set of essential requirements based on practical experience with
the
> > > technology. EMF represents the core subset that's left when the
> > non-essentials
> > > are eliminated. It represents a rock solid foundation upon which the
more
> > > ambitious extensions of UML and MDA can be built. A number of the
MDA
> > vendors
> > > certainly view EMF in this light...
> >
> > How would / should one represent a state machine using the EMF? Do you
> > envisage EMG being able to be the repository for a fully-fledged UML
case
> > tool, or is that not its intention? I also use a number of tools from
> > vendors which rely on XMI, and only a very small subset of the UML
> > meta-model is supported via the EMF XMI, as far as I can see. I could
be
> > wrong, however, as I have only had a brief investigation of EMF.
> >
> > I was getting very excited about EMF after the announcement, and fully
> > expected it to be a full MOF implementation in the spirit of Netbeans
MDR.
> > I currently use NSUML and NSMDF and find them to be quite acceptable.
> >
> > > Members of our group are involved in a number of standards efforts,
> > including
> > > the MOF 2.0 work. We are also a very pragmatic bunch, and we strive
to
> > deliver
> > > simple solutions to complex problems.
> >
> > I agree, and the goal of simplicity is laudable. I guess that I find
> > immense value in the OMG specified UML meta-model. I work with it all
the
> > time, and have found it to be comprehensive and beneficial. Wouldn't it
be
> > possible to support both the EMF core model and a full UML meta-model
via
> > mappings to the same MOF repository?
> >
> > Cheers,
> > Andrew
> >
> > > Andrew McVeigh wrote:
> > >
> > > > Hi,
> > > >
> > > > (I am new to this newsgroup, so if this has been answered many
times,
> > please
> > > > just fwd me to the reference. I read the faq, but it didn't really
> > answer
> > > > the question.)
> > > >
> > > > I am confused as to why EMF didn't use the MOF / JMI and UML
meta-model
> > > > specs from the OMG? These are well accepted, established, and
provide
> > full
> > > > UML and XMI coverage. From my perspective as a case vendor, EMF
looks
> > like
> > > > an undercooked re-invention.
> > > >
> > > > Was the reason for simplicity? Do the EMF architects know something
> > about
> > > > the MOF2.0 spec, and are moving forward to this? Don't they agree
with
> > the
> > > > MOF spec?
> > > >
> > > > Cheers,
> > > > Andrew McVeigh
> > > > London, UK
> > > > http://www.hopstepjump.com
> > >
> > > --
> > > Ed Merks
> > >
> > >
>
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376212 is a reply to message #376139] |
Thu, 24 October 2002 10:18 |
| Eclipse User |
|
|
|
I was very interested to see that the EUM project (Eclipse Universal
Modeler) at http://www.research.ibm.com/AEM/eum.html is using the MOF and
XMI! What are your thoughts on that?
From the EUM page:
"By using accepted standards from end to end, we create an easy path to
adoption and maximum interoperability
with existing tools, and encourage others to build on top of our work to
add value to our offering. "
Cheers,
Andrew
London, UK
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3DAAFB5C.73D9939F@ca.ibm.com...
> Andrew,
>
> You are exactly right about having both EMF and a full UML model. The XSD
model
> is described and implemented using EMF so the same could most certainly be
done
> for a full UML model; unlike XSD, it could perhaps extend Ecore directly.
There
> are interesting discussions to be had about this, and about how UML and
XSD are
> related...
>
> By restricting Ecore to core concepts that have a simple and direct Java
> interpretation, one with hand-written quality and runtime performance, we
hope
> to bring the powerful advantages of modeling to those not (yet) convinced
by a
> full MDA vision. Ecore is a simple and powerful common denominator;
perhaps that
> makes it only as exciting as pavement, but that is the stuff of roads...
>
> Andrew McVeigh wrote:
>
> > Hi Ed,
> >
> > Thanks for the response.
> >
> > > Being overcooked verses undercooked depends on your preference but
once
> > > something is overcooked, no amount of uncooking will fix it. There's
> > certainly
> > > a lesson in that...
> >
> > I have no problems with the MOF being referred to as overcooked, but the
> > same is true of things like EJB, CORBA, UML etc. My preference for them
> > lies in the fact that they are standards and they are fairly
comprehensive.
> > As such, they facilitate vertical tool chains between vendors.
> >
> > > EMF began as a full MOF implementation some years ago and has been
pruned
> > down
> > > to a set of essential requirements based on practical experience with
the
> > > technology. EMF represents the core subset that's left when the
> > non-essentials
> > > are eliminated. It represents a rock solid foundation upon which the
more
> > > ambitious extensions of UML and MDA can be built. A number of the
MDA
> > vendors
> > > certainly view EMF in this light...
> >
> > How would / should one represent a state machine using the EMF? Do you
> > envisage EMG being able to be the repository for a fully-fledged UML
case
> > tool, or is that not its intention? I also use a number of tools from
> > vendors which rely on XMI, and only a very small subset of the UML
> > meta-model is supported via the EMF XMI, as far as I can see. I could
be
> > wrong, however, as I have only had a brief investigation of EMF.
> >
> > I was getting very excited about EMF after the announcement, and fully
> > expected it to be a full MOF implementation in the spirit of Netbeans
MDR.
> > I currently use NSUML and NSMDF and find them to be quite acceptable.
> >
> > > Members of our group are involved in a number of standards efforts,
> > including
> > > the MOF 2.0 work. We are also a very pragmatic bunch, and we strive
to
> > deliver
> > > simple solutions to complex problems.
> >
> > I agree, and the goal of simplicity is laudable. I guess that I find
> > immense value in the OMG specified UML meta-model. I work with it all
the
> > time, and have found it to be comprehensive and beneficial. Wouldn't it
be
> > possible to support both the EMF core model and a full UML meta-model
via
> > mappings to the same MOF repository?
> >
> > Cheers,
> > Andrew
> >
> > > Andrew McVeigh wrote:
> > >
> > > > Hi,
> > > >
> > > > (I am new to this newsgroup, so if this has been answered many
times,
> > please
> > > > just fwd me to the reference. I read the faq, but it didn't really
> > answer
> > > > the question.)
> > > >
> > > > I am confused as to why EMF didn't use the MOF / JMI and UML
meta-model
> > > > specs from the OMG? These are well accepted, established, and
provide
> > full
> > > > UML and XMI coverage. From my perspective as a case vendor, EMF
looks
> > like
> > > > an undercooked re-invention.
> > > >
> > > > Was the reason for simplicity? Do the EMF architects know something
> > about
> > > > the MOF2.0 spec, and are moving forward to this? Don't they agree
with
> > the
> > > > MOF spec?
> > > >
> > > > Cheers,
> > > > Andrew McVeigh
> > > > London, UK
> > > > http://www.hopstepjump.com
> > >
> > > --
> > > Ed Merks
> > >
> > >
>
> --
> Ed Merks
>
>
|
|
| |
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376216 is a reply to message #376215] |
Tue, 29 October 2002 05:06 |
| Eclipse User |
|
|
|
Martin,
My biggest concern over the past few years has been the shockingly rapid
multiplication of complex, overlapping technologies and standards that are
becoming increasing less fathomable to the masses of programmers intended to use
them. My work on the Ecore-based XSD model for XML Schema has really driven this
point home for me. I believe that the human mind needs a conceptual framework
that can be grasped as a whole and that much of today's technology is rapidly
moving beyond our individual ability to grasp significant portions of it.
Stacked layers of such complexity will crush the productivity out of our
community.
Take Java as a case in point. Did it become more popular than C++ because it was
more complete in its support for object oriented programming. I don't think so.
Did folks worry about splitting the object oriented programming community? Of
course. Was it a good thing? Who's to judge?
As I see it, the complete MDA story is a very large mouthful for people to
swallow. Starting with a small and tasteful serving is just what's needed to
help promote the rest of the banquet. The variety of choice beans on the table
just doesn't seem to be doing the trick, so we will strive for simple, and if
it's complex that people really want, they already know where to find that...
Martin Matula wrote:
> Hi Andrew,
>
> Andrew McVeigh wrote:
> > My fear is that a heavy-duty re-invention of the wheel is needed to get to
> > the same point of utility as the MOF.
>
> My biggest concern besides the things you mentioned is, that Ecore forks
> MOF community and this is at the time when MOF begins to get more
> acceptance (with more people becoming enthusiastic about MDA). I think
> it is a pity...
>
> > Not that I care too much as I have
> > access to a reasonable MOF, but if I integrate with eclipse, I will have to
> > heavily rework my CASE tool.
>
> You are welcome to use NetBeans MDR in eclipse (I am aware of companies
> that are already doing that) as it is independent from the rest of NetBeans.
> Regards,
> Martin
--
Ed Merks
|
|
| |
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376220 is a reply to message #376217] |
Tue, 29 October 2002 15:51 |
| Eclipse User |
|
|
|
Hi Ed and Frank,
thanks for your replies. As you probably would expect, I disagree with
you :).
I think that the Java/C++ example is different. I believe the main
reason for creation and broad adoption of Java was not that C++
programming was too complex and Java simple.
In addition, I do not agree that MOF is too complex (in terms of its
constructs). I believe the main problem for people who are new to MOF is
the "meta-meta" they have to deal with when they are reading the
documentation. But Ecore is no different in this aspect - it is also a
meta-meta model. Just the documentation, tutorial and EMF makes it
easier for the people to understand and see what it can be good for.
My experience is that once the people understand "meta-meta", they often
want even more complex features than what the current version of MOF offers.
> To use Ed's C++/Java analogy again, we believe that Ecore is to MOF
what Java is
> to C++. It's true that Java split the OO community, but I would argue
that Java
> furthered the cause of mainstream OO acceptance by much more than any
language
> before it.
I completely disagree with this analogy - I don't see anything similar
in C++/Java relationship. Java did split the OO community, but added a
lot of useful stuff to justify that split - platform independence,
safety, better programming style, etc.
What does Ecore add to justify the split of the MOF community?
Simplicity? So what makes Ecore much easier to grasp than MOF? Don't you
think it is "only" the EMF (which can equaly be built on top of MOF),
tutorials and docs?
In fact, to be honest, a completely different analogy comes to my mind -
I believe that Ecore is to MOF what C# is to Java - if you take a while
to think about it, it makes a lot of sense.
Anyway, I do not want to start a new flame war. I just feel it would be
much more valuable for the community, if the EMF (and any other Ecore
based tools) was based on MOF rather than Ecore, preserving all the
interoperability with existing MOF, UML and XMI tools. The same way as
it would be much more valuable for community if Microsoft had invested
in buidling tools for Java rather than reinventing the wheel with C# and
whole .NET and building tools for that. But I understand that it would
not be the best solution for Microsoft...
Martin
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376228 is a reply to message #376220] |
Wed, 30 October 2002 12:34 |
| Eclipse User |
|
|
|
Martin,
Believe it or not, I don't "completely disagree" with everything you say :).
The fact of the matter, though, is that Ecore is simpler than MOF in some very
important ways. For one, it is a single inheritance model guaranteeing a
maximally efficient mapping to Java.
The fact that we can show the entire Ecore model in a single class diagram (see
the relations, attributes, and operations diagram) that can be displayed on my
laptop screen is also pretty convincing.
We think Ecore is a core subset of MOF. Take away the "E"s in the names and
there's no dramatic departure - just pruning.
Frank.
Martin Matula wrote:
> Hi Ed and Frank,
> thanks for your replies. As you probably would expect, I disagree with
> you :).
> I think that the Java/C++ example is different. I believe the main
> reason for creation and broad adoption of Java was not that C++
> programming was too complex and Java simple.
> In addition, I do not agree that MOF is too complex (in terms of its
> constructs). I believe the main problem for people who are new to MOF is
> the "meta-meta" they have to deal with when they are reading the
> documentation. But Ecore is no different in this aspect - it is also a
> meta-meta model. Just the documentation, tutorial and EMF makes it
> easier for the people to understand and see what it can be good for.
> My experience is that once the people understand "meta-meta", they often
> want even more complex features than what the current version of MOF offers.
>
> > To use Ed's C++/Java analogy again, we believe that Ecore is to MOF
> what Java is
> > to C++. It's true that Java split the OO community, but I would argue
> that Java
> > furthered the cause of mainstream OO acceptance by much more than any
> language
> > before it.
>
> I completely disagree with this analogy - I don't see anything similar
> in C++/Java relationship. Java did split the OO community, but added a
> lot of useful stuff to justify that split - platform independence,
> safety, better programming style, etc.
> What does Ecore add to justify the split of the MOF community?
> Simplicity? So what makes Ecore much easier to grasp than MOF? Don't you
> think it is "only" the EMF (which can equaly be built on top of MOF),
> tutorials and docs?
> In fact, to be honest, a completely different analogy comes to my mind -
> I believe that Ecore is to MOF what C# is to Java - if you take a while
> to think about it, it makes a lot of sense.
> Anyway, I do not want to start a new flame war. I just feel it would be
> much more valuable for the community, if the EMF (and any other Ecore
> based tools) was based on MOF rather than Ecore, preserving all the
> interoperability with existing MOF, UML and XMI tools. The same way as
> it would be much more valuable for community if Microsoft had invested
> in buidling tools for Java rather than reinventing the wheel with C# and
> whole .NET and building tools for that. But I understand that it would
> not be the best solution for Microsoft...
> Martin
|
|
| |
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376247 is a reply to message #376216] |
Tue, 05 November 2002 10:15 |
| Eclipse User |
|
|
|
Originally posted by: joerg.von.frantzius.artnology.nospam.com
--------------090404040902030209060100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Ed Merks wrote:
>Martin,
>
>My biggest concern over the past few years has been the shockingly rapid
>multiplication of complex, overlapping technologies and standards that are
>becoming increasing less fathomable to the masses of programmers intended to use
>them. My work on the Ecore-based XSD model for XML Schema has really driven this
>point home for me. I believe that the human mind needs a conceptual framework
>that can be grasped as a whole and that much of today's technology is rapidly
>moving beyond our individual ability to grasp significant portions of it.
>Stacked layers of such complexity will crush the productivity out of our
>community.
>
>Take Java as a case in point. Did it become more popular than C++ because it was
>more complete in its support for object oriented programming. I don't think so.
>Did folks worry about splitting the object oriented programming community? Of
>course. Was it a good thing? Who's to judge?
>
>As I see it, the complete MDA story is a very large mouthful for people to
>swallow. Starting with a small and tasteful serving is just what's needed to
>help promote the rest of the banquet. The variety of choice beans on the table
>just doesn't seem to be doing the trick, so we will strive for simple, and if
>it's complex that people really want, they already know where to find that...
>
The one with the banquet and the serving is really nice :)
As I see it, there's some kind of general idea, which once has been
dubbed as "Meta-meta is better-better!
< http://www.dstc.edu.au/Research/Projects/MOF/Publications/Pa pers/dais97.pdf>"
The question is, what does the concrete formalism look like that I end
up working with? In that respect and taking the nature of my projects
into account, I personally trust EMF to be much more handy and practical
than a full blown MOF implementation. Even more so if code generation
feasts, as (to me) they seem to be implied with MOF+MDA, come into the
picture.
If I got it right (e.g. from this article
< http://www.infoworld.com/articles/hn/xml/02/09/09/020909hnec lipseemf.xml>),
then at least one of the driving persons behind the MOF, Sridhar
Iyengar, has worked on the EMF (and there seem to be more in this
group). This is nice because it transports the idea into a tool that is
in widespread use for lower-scale or less academic projects.
>
>
>Martin Matula wrote:
>
>
>
>>Hi Andrew,
>>
>>Andrew McVeigh wrote:
>>
>>
>>>My fear is that a heavy-duty re-invention of the wheel is needed to get to
>>>the same point of utility as the MOF.
>>>
>>>
>>My biggest concern besides the things you mentioned is, that Ecore forks
>> MOF community and this is at the time when MOF begins to get more
>>acceptance (with more people becoming enthusiastic about MDA). I think
>>it is a pity...
>>
>>
>>
>>> Not that I care too much as I have
>>>access to a reasonable MOF, but if I integrate with eclipse, I will have to
>>>heavily rework my CASE tool.
>>>
>>>
>>You are welcome to use NetBeans MDR in eclipse (I am aware of companies
>>that are already doing that) as it is independent from the rest of NetBeans.
>>Regards,
>>Martin
>>
>>
>
>--
>Ed Merks
>
>
>
>
--------------090404040902030209060100
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Ed Merks wrote:<br>
<blockquote type="cite" cite="mid3DBE5D9B.C538B91E@ca.ibm.com">
<pre wrap="">Martin,
My biggest concern over the past few years has been the shockingly rapid
multiplication of complex, overlapping technologies and standards that are
becoming increasing less fathomable to the masses of programmers intended to use
them. My work on the Ecore-based XSD model for XML Schema has really driven this
point home for me. I believe that the human mind needs a conceptual framework
that can be grasped as a whole and that much of today's technology is rapidly
moving beyond our individual ability to grasp significant portions of it.
Stacked layers of such complexity will crush the productivity out of our
community.
Take Java as a case in point. Did it become more popular than C++ because it was
more complete in its support for object oriented programming. I don't think so.
Did folks worry about splitting the object oriented programming community? Of
course. Was it a good thing? Who's to judge?
As I see it, the complete MDA story is a very large mouthful for people to
swallow. Starting with a small and tasteful serving is just what's needed to
help promote the rest of the banquet. The variety of choice beans on the table
just doesn't seem to be doing the trick, so we will strive for simple, and if
it's complex that people really want, they already know where to find that...</pre>
</blockquote>
The one with the banquet and the serving is really nice :)<br>
<br>
As I see it, there's some kind of general idea, which once has been
dubbed as "<a
href=" http://www.dstc.edu.au/Research/Projects/MOF/Publications/Pa pers/dais97.pdf">Meta-meta
is better-better!</a>" The question is, what does the concrete
formalism look like that I end up working with? In that respect and
taking the nature of my projects into account, I personally trust EMF
to be much more handy and practical than a full blown MOF
implementation. Even more so if code generation feasts, as (to me) they
seem to be implied with MOF+MDA, come into the picture.<br>
<br>
If I got it right (e.g. from this <a
href=" http://www.infoworld.com/articles/hn/xml/02/09/09/020909hnec lipseemf.xml">article</a>),
then at least one of the driving persons behind the MOF, Sridhar
Iyengar, has worked on the EMF (and there seem to be more in this
group). This is nice because it transports the idea into a tool that is
in widespread use for lower-scale or less academic projects.<br>
<br>
<blockquote type="cite" cite="mid3DBE5D9B.C538B91E@ca.ibm.com">
<pre wrap="">
Martin Matula wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Andrew,
Andrew McVeigh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">My fear is that a heavy-duty re-invention of the wheel is needed to get to
the same point of utility as the MOF.
</pre>
</blockquote>
<pre wrap="">My biggest concern besides the things you mentioned is, that Ecore forks
MOF community and this is at the time when MOF begins to get more
acceptance (with more people becoming enthusiastic about MDA). I think
it is a pity...
</pre>
<blockquote type="cite">
<pre wrap=""> Not that I care too much as I have
access to a reasonable MOF, but if I integrate with eclipse, I will have to
heavily rework my CASE tool.
</pre>
</blockquote>
<pre wrap="">You are welcome to use NetBeans MDR in eclipse (I am aware of companies
that are already doing that) as it is independent from the rest of NetBeans.
Regards,
Martin
</pre>
</blockquote>
<pre wrap=""><!---->
--
Ed Merks
</pre>
</blockquote>
<br>
</body>
</html>
--------------090404040902030209060100--
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376701 is a reply to message #376228] |
Sat, 25 January 2003 23:06 |
| Eclipse User |
|
|
|
Originally posted by: luke.rebus.co.za
Hi,
I have been following, albeit silently, many similar conversations on this
newsgroup... it seems that there are many people who really care about the
fact the Ecore is not based on MOF. I believe successful software has a
two-fold attribute ;)
It must be a) useful and, b) beautiful...
Most folk would probably not deem the latter so important (I'm just saying)
;)
I think they care for one or more of a few potential reasons:
They (like I) already trust, and _really_ use UML... As a programmer, the
most valuable thing about it is to be able to communicate about software
with people who are _not_ programmers, never mind non-Java folk... (Java
programmers have never really had communication issues like others, right?).
Secondly, UML is about OO... It is even more OO than Java... (or is it only
I who could imagine a purer OO programming language... until UML came
along?)
Another reason, I think, is that even though MOF is not the only route for
standardising on a UML data structure, it is (for now) effectively been
chosen by the industry of both commercial, and free, open and closed,
systems; organisations across many development creeds, even industries
outside software development markets. Who is any one group to decide on the
meta-meta model? CORBA technology specs are linked to MOF for a reason too -
interoperability beyond the scope of itself. I believe Java culture should
never find itself as the lesser entity when it comes to industry compliance;
surely this is a bad indication?
Many people are eager about EMF, it is certainly serious stuff; and worried
that Ecore is not going to end up UML compatible at all (with the using of
XMI, this is confusing to say the least). Modeling tools that only let one
model Java code are not 'real' modeling tools, to me, they are fancy code
generators (which is what a lot of MDA seems to be too). Not to downplay the
power these tools give engineers ;)
UML is a far richer thing, allowing many 'perspectives' etc. each
perspective being a transform from the concept, closer to the code (and back
again). Note: this is pure convention, and not UML spec, per se... This is
the first publicly accessible system, via which, requirements can be traced
to the code that implements them. The height of one's analysis level is open
to the real world, meaning the idea can come straight from the brain, into
the machine, without conceptual info getting lost in the translation... each
transform making it more and more concrete a model... Eventually, when the
transform is at a low enough level, one can commit to a language. Why do
this? Why not? Why not capture the functionality of a system in a model that
represents itself and nothing else... free from technological bounds.
MDA is actually an automation of this transformation from one (more
analytical perspective), to another (more concrete perspective). It needs
UML to be comprehendible by humans and machines.
People invest in UML, they commit a lot of knowledge to UML models. My take
is, represent it's data as you like, but don't mess with parts of a unified
language that one does not use - remove them, and it won't be very unified
at all, rather customised actually... this might even be referred to, by
some, as undoing the wheel, never mind re-inventing it... if we must have
different XMLs for UML, fine, we can transform them too, harnessing one of
the true powers of XML data representation... it is inevitable to need to
perform an endless chain of transformations (to keep your knowledge in the
loop) because market fragmentation, at the data representation level, is
inevitable until UML grows to fill even more of its potential. It should be
no problemo if an industry supports many such meta-structures of the UML,
right?
'Real' modeling tools use languages (like UML) that have _no coupling_ to
technologies, methodologies, languages etc. These modeling tools are useful
to generate code from (via technologically decoupled modules), but only
worth the effort if their data structure is going to be maintainable for
years to come... or at least migratable. To me, it seems that the EMF is
not really about modeling in a greater sense, and therefore deems all that
is not Java, not worth including.
It's link to MDA actually supports this, despite it containing the word
'Model' in its name. i.e. Describe a <insert data structure here> shaped
hole, and code will be generated to fill it, macro-oo-style...
This 'pruning' of the MOF seems to be about getting rid of 'the stuff that
is of no use to Java folk'. I thought the whole point of these meta-meta
models were to allow platform/technology/language independent ways of
capturing, expressing, and, in most programmer's cases, editing/generating
code/data. A meta-meta model that promises the notion of:
"Describe one meta model, and use it everywhere..."
(in fact, much like th 'ol Java promise of writing code once... etc. and
it's kinda working, right? Assets building up, right?). This applies to so
much more than programming languages... key point being a potential way to
automate information extraction (knowledge capture) from the domain,
straight into the requirements analysis, design, and implementation of
software systems intended for use in the domain. What I am talking about is
the linguistic aspect of UML that far too under-played by software
engineers.
This meta-model is UML, and what it promises is:
"Describe your domain once, and use it everywhere..."
Ecore's domain seems to be efficient, simple, easy, OO-macro-based Java
coding technology.
Ecore is as abstract, and difficult to grasp initially, as MOF, or any other
set of meta-meta concepts, are; and we are, after all, only human. ;)
It is sad, to me, that there is not a single open source,
no-monkey-business, UML modeling tool out there (with as many
code-generating frameworks as imaginable if you wish...), and was hoping EMF
was not trying to re-invent the conceptual wheel, but rather, make stuff
like this, opensource...
I suppose I might have raised many hackles here, and expect due flaming (and
potentially access-blocking) gauntlets, but I gotta say this stuff for my
own conscience ;) The world needs opensource UML, badly. Why can't it happen
on the 'happening' IDE-for-anything-but-nothing in-particular?
(Or is it just me?)
sincerely,
Luke Vorster
P.S. It should be noted that I probably have so much to say because of the
wonderful accessibility of EMF (docs, tuts, code, etc.)
P.P.S. I have a project, a UML compiler of a nature that is similar, but not
quite the same, as one for software code generation. It is extremely
frustrating trying to look for a 'bandwagon' that will get me closer to
it... and UML in general.
"Frank Budinsky" <frankb@ca.ibm.com> wrote in message
news:3DC01816.D6CCF815@ca.ibm.com...
> Martin,
>
> Believe it or not, I don't "completely disagree" with everything you say
:).
>
> The fact of the matter, though, is that Ecore is simpler than MOF in some
very
> important ways. For one, it is a single inheritance model guaranteeing a
> maximally efficient mapping to Java.
>
> The fact that we can show the entire Ecore model in a single class diagram
(see
> the relations, attributes, and operations diagram) that can be displayed
on my
> laptop screen is also pretty convincing.
>
> We think Ecore is a core subset of MOF. Take away the "E"s in the names
and
> there's no dramatic departure - just pruning.
>
> Frank.
>
>
> Martin Matula wrote:
>
> > Hi Ed and Frank,
> > thanks for your replies. As you probably would expect, I disagree with
> > you :).
> > I think that the Java/C++ example is different. I believe the main
> > reason for creation and broad adoption of Java was not that C++
> > programming was too complex and Java simple.
> > In addition, I do not agree that MOF is too complex (in terms of its
> > constructs). I believe the main problem for people who are new to MOF is
> > the "meta-meta" they have to deal with when they are reading the
> > documentation. But Ecore is no different in this aspect - it is also a
> > meta-meta model. Just the documentation, tutorial and EMF makes it
> > easier for the people to understand and see what it can be good for.
> > My experience is that once the people understand "meta-meta", they often
> > want even more complex features than what the current version of MOF
offers.
> >
> > > To use Ed's C++/Java analogy again, we believe that Ecore is to MOF
> > what Java is
> > > to C++. It's true that Java split the OO community, but I would argue
> > that Java
> > > furthered the cause of mainstream OO acceptance by much more than any
> > language
> > > before it.
> >
> > I completely disagree with this analogy - I don't see anything similar
> > in C++/Java relationship. Java did split the OO community, but added a
> > lot of useful stuff to justify that split - platform independence,
> > safety, better programming style, etc.
> > What does Ecore add to justify the split of the MOF community?
> > Simplicity? So what makes Ecore much easier to grasp than MOF? Don't you
> > think it is "only" the EMF (which can equaly be built on top of MOF),
> > tutorials and docs?
> > In fact, to be honest, a completely different analogy comes to my mind -
> > I believe that Ecore is to MOF what C# is to Java - if you take a while
> > to think about it, it makes a lot of sense.
> > Anyway, I do not want to start a new flame war. I just feel it would be
> > much more valuable for the community, if the EMF (and any other Ecore
> > based tools) was based on MOF rather than Ecore, preserving all the
> > interoperability with existing MOF, UML and XMI tools. The same way as
> > it would be much more valuable for community if Microsoft had invested
> > in buidling tools for Java rather than reinventing the wheel with C# and
> > whole .NET and building tools for that. But I understand that it would
> > not be the best solution for Microsoft...
> > Martin
>
|
|
|
| Re: Why didn't EMF use the UML meta-model and the MOF? [message #376711 is a reply to message #376701] |
Tue, 28 January 2003 09:06 |
| Eclipse User |
|
|
|
Luke,
I hope your vision of open source UML tooling is realized eventually. In the
meantime, EMF is a Java Programmer's tool that, given the current state of
software development technology, we believe mixes just the right amount of
modeling with programming to maximize the effectiveness of both. By introducing
some of the benefits of modeling to a much wider audience, EMF can only help the
cause of UML.
Frank.
Luke Vorster wrote:
> Hi,
>
> I have been following, albeit silently, many similar conversations on this
> newsgroup... it seems that there are many people who really care about the
> fact the Ecore is not based on MOF. I believe successful software has a
> two-fold attribute ;)
>
> It must be a) useful and, b) beautiful...
>
> Most folk would probably not deem the latter so important (I'm just saying)
> ;)
>
> I think they care for one or more of a few potential reasons:
>
> They (like I) already trust, and _really_ use UML... As a programmer, the
> most valuable thing about it is to be able to communicate about software
> with people who are _not_ programmers, never mind non-Java folk... (Java
> programmers have never really had communication issues like others, right?).
> Secondly, UML is about OO... It is even more OO than Java... (or is it only
> I who could imagine a purer OO programming language... until UML came
> along?)
>
> Another reason, I think, is that even though MOF is not the only route for
> standardising on a UML data structure, it is (for now) effectively been
> chosen by the industry of both commercial, and free, open and closed,
> systems; organisations across many development creeds, even industries
> outside software development markets. Who is any one group to decide on the
> meta-meta model? CORBA technology specs are linked to MOF for a reason too -
> interoperability beyond the scope of itself. I believe Java culture should
> never find itself as the lesser entity when it comes to industry compliance;
> surely this is a bad indication?
>
> Many people are eager about EMF, it is certainly serious stuff; and worried
> that Ecore is not going to end up UML compatible at all (with the using of
> XMI, this is confusing to say the least). Modeling tools that only let one
> model Java code are not 'real' modeling tools, to me, they are fancy code
> generators (which is what a lot of MDA seems to be too). Not to downplay the
> power these tools give engineers ;)
>
> UML is a far richer thing, allowing many 'perspectives' etc. each
> perspective being a transform from the concept, closer to the code (and back
> again). Note: this is pure convention, and not UML spec, per se... This is
> the first publicly accessible system, via which, requirements can be traced
> to the code that implements them. The height of one's analysis level is open
> to the real world, meaning the idea can come straight from the brain, into
> the machine, without conceptual info getting lost in the translation... each
> transform making it more and more concrete a model... Eventually, when the
> transform is at a low enough level, one can commit to a language. Why do
> this? Why not? Why not capture the functionality of a system in a model that
> represents itself and nothing else... free from technological bounds.
>
> MDA is actually an automation of this transformation from one (more
> analytical perspective), to another (more concrete perspective). It needs
> UML to be comprehendible by humans and machines.
>
> People invest in UML, they commit a lot of knowledge to UML models. My take
> is, represent it's data as you like, but don't mess with parts of a unified
> language that one does not use - remove them, and it won't be very unified
> at all, rather customised actually... this might even be referred to, by
> some, as undoing the wheel, never mind re-inventing it... if we must have
> different XMLs for UML, fine, we can transform them too, harnessing one of
> the true powers of XML data representation... it is inevitable to need to
> perform an endless chain of transformations (to keep your knowledge in the
> loop) because market fragmentation, at the data representation level, is
> inevitable until UML grows to fill even more of its potential. It should be
> no problemo if an industry supports many such meta-structures of the UML,
> right?
>
> 'Real' modeling tools use languages (like UML) that have _no coupling_ to
> technologies, methodologies, languages etc. These modeling tools are useful
> to generate code from (via technologically decoupled modules), but only
> worth the effort if their data structure is going to be maintainable for
> years to come... or at least migratable. To me, it seems that the EMF is
> not really about modeling in a greater sense, and therefore deems all that
> is not Java, not worth including.
>
> It's link to MDA actually supports this, despite it containing the word
> 'Model' in its name. i.e. Describe a <insert data structure here> shaped
> hole, and code will be generated to fill it, macro-oo-style...
>
> This 'pruning' of the MOF seems to be about getting rid of 'the stuff that
> is of no use to Java folk'. I thought the whole point of these meta-meta
> models were to allow platform/technology/language independent ways of
> capturing, expressing, and, in most programmer's cases, editing/generating
> code/data. A meta-meta model that promises the notion of:
>
> "Describe one meta model, and use it everywhere..."
>
> (in fact, much like th 'ol Java promise of writing code once... etc. and
> it's kinda working, right? Assets building up, right?). This applies to so
> much more than programming languages... key point being a potential way to
> automate information extraction (knowledge capture) from the domain,
> straight into the requirements analysis, design, and implementation of
> software systems intended for use in the domain. What I am talking about is
> the linguistic aspect of UML that far too under-played by software
> engineers.
>
> This meta-model is UML, and what it promises is:
>
> "Describe your domain once, and use it everywhere..."
>
> Ecore's domain seems to be efficient, simple, easy, OO-macro-based Java
> coding technology.
>
> Ecore is as abstract, and difficult to grasp initially, as MOF, or any other
> set of meta-meta concepts, are; and we are, after all, only human. ;)
>
> It is sad, to me, that there is not a single open source,
> no-monkey-business, UML modeling tool out there (with as many
> code-generating frameworks as imaginable if you wish...), and was hoping EMF
> was not trying to re-invent the conceptual wheel, but rather, make stuff
> like this, opensource...
>
> I suppose I might have raised many hackles here, and expect due flaming (and
> potentially access-blocking) gauntlets, but I gotta say this stuff for my
> own conscience ;) The world needs opensource UML, badly. Why can't it happen
> on the 'happening' IDE-for-anything-but-nothing in-particular?
>
> (Or is it just me?)
>
> sincerely,
>
> Luke Vorster
>
> P.S. It should be noted that I probably have so much to say because of the
> wonderful accessibility of EMF (docs, tuts, code, etc.)
>
> P.P.S. I have a project, a UML compiler of a nature that is similar, but not
> quite the same, as one for software code generation. It is extremely
> frustrating trying to look for a 'bandwagon' that will get me closer to
> it... and UML in general.
>
> "Frank Budinsky" <frankb@ca.ibm.com> wrote in message
> news:3DC01816.D6CCF815@ca.ibm.com...
> > Martin,
> >
> > Believe it or not, I don't "completely disagree" with everything you say
> :).
> >
> > The fact of the matter, though, is that Ecore is simpler than MOF in some
> very
> > important ways. For one, it is a single inheritance model guaranteeing a
> > maximally efficient mapping to Java.
> >
> > The fact that we can show the entire Ecore model in a single class diagram
> (see
> > the relations, attributes, and operations diagram) that can be displayed
> on my
> > laptop screen is also pretty convincing.
> >
> > We think Ecore is a core subset of MOF. Take away the "E"s in the names
> and
> > there's no dramatic departure - just pruning.
> >
> > Frank.
> >
> >
> > Martin Matula wrote:
> >
> > > Hi Ed and Frank,
> > > thanks for your replies. As you probably would expect, I disagree with
> > > you :).
> > > I think that the Java/C++ example is different. I believe the main
> > > reason for creation and broad adoption of Java was not that C++
> > > programming was too complex and Java simple.
> > > In addition, I do not agree that MOF is too complex (in terms of its
> > > constructs). I believe the main problem for people who are new to MOF is
> > > the "meta-meta" they have to deal with when they are reading the
> > > documentation. But Ecore is no different in this aspect - it is also a
> > > meta-meta model. Just the documentation, tutorial and EMF makes it
> > > easier for the people to understand and see what it can be good for.
> > > My experience is that once the people understand "meta-meta", they often
> > > want even more complex features than what the current version of MOF
> offers.
> > >
> > > > To use Ed's C++/Java analogy again, we believe that Ecore is to MOF
> > > what Java is
> > > > to C++. It's true that Java split the OO community, but I would argue
> > > that Java
> > > > furthered the cause of mainstream OO acceptance by much more than any
> > > language
> > > > before it.
> > >
> > > I completely disagree with this analogy - I don't see anything similar
> > > in C++/Java relationship. Java did split the OO community, but added a
> > > lot of useful stuff to justify that split - platform independence,
> > > safety, better programming style, etc.
> > > What does Ecore add to justify the split of the MOF community?
> > > Simplicity? So what makes Ecore much easier to grasp than MOF? Don't you
> > > think it is "only" the EMF (which can equaly be built on top of MOF),
> > > tutorials and docs?
> > > In fact, to be honest, a completely different analogy comes to my mind -
> > > I believe that Ecore is to MOF what C# is to Java - if you take a while
> > > to think about it, it makes a lot of sense.
> > > Anyway, I do not want to start a new flame war. I just feel it would be
> > > much more valuable for the community, if the EMF (and any other Ecore
> > > based tools) was based on MOF rather than Ecore, preserving all the
> > > interoperability with existing MOF, UML and XMI tools. The same way as
> > > it would be much more valuable for community if Microsoft had invested
> > > in buidling tools for Java rather than reinventing the wheel with C# and
> > > whole .NET and building tools for that. But I understand that it would
> > > not be the best solution for Microsoft...
> > > Martin
> >
|
|
|
Goto Forum:
Current Time: Wed Nov 05 12:43:41 EST 2025
Powered by FUDForum. Page generated in 0.36377 seconds |
Home