Home » Modeling » EMF » Why does ECORE exists, when UML was there already?(ECORE vs. UML)
| Why does ECORE exists, when UML was there already? [message #1008442] |
Tue, 12 February 2013 13:58  |
 Luis Fernando Robledano-Esteban
Messages: 32
Registered: February 2013 |
Member |
|
|
After a couple of days new to this world of EMF I really don't get it yet.
ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset of UML (as a metamodel and not as a graphical representation).
I really think it is a new layer which introduces more complexity an makes even flater learning curve.
And it is difficult to see advantages. Why in first step didn't Eclipse take UML/XMI for graphical and persistent representation?
What am I missing?
Thanks pals
ArkosX
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1008473 is a reply to message #1008442] |
Tue, 12 February 2013 16:00  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Luis,
Comments below.
On 12/02/2013 3:13 PM, Luis Fernando Robledano-Esteban wrote:
> After a couple of days new to this world of EMF I really don't get it
> yet.
> ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset of
> UML (as a metamodel and not as a graphical representation).
That's one way to look at it.
> I really think it is a new layer which introduces more complexity an
> makes even flater learning curve.
Then I think you've missed the point. You certainly can't argue that
Ecore is more complex than UML, right? So I'm not sure the basis for
your statement that it's a new layer that introduces more complexity.
> And it is difficult to see advantages.
The most glaring example is as follows: suppose you have a UML class
"Company" that you've designed to represent company instances. With UML
itself, you cannot create an instance of such a class. On the other
hand, with Ecore, you can use EcoreUtil.create(eClassForCompany) to
create an instance. UML2 is a metamodel, but it what it's a meta model
for is not defined, it's up to the user/developer to map the semantics.
Ecore is also a metamodel, and it's a meta model for EObjects, i.e.,
what it's a meta model for is very precisely defined.
> Why in first step didn't Eclipse take UML/XMI for graphical and
> persistent representation?
I'm not sure what you mean. Keep in mind that the OMG defines XMI
serialization in terms of EMOF, and it defines UML using EMOF. Ecore is
an implementation of EMOF and hence the basis for implementation all the
OMG specifications at Eclipse, and the mechanism by which XMI
serialization is supported.
>
> What am I missing?
If all you want to do is draw nice UML diagrams and work with nice UML
instances, you don't need to learn Ecore. If you want to design models
that you can actually instantiate, you'll need Ecore's help for that.
Of course you can combine the two and map UML onto Ecore and then create
instances based on that interpretation of UML.
>
> Thanks pals
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Why does ECORE exists, when UML was there already? [message #1008604 is a reply to message #1008473] |
Wed, 13 February 2013 09:23 |
Luis Fernando Robledano-Esteban
Messages: 32
Registered: February 2013 |
Member |
|
|
Thanks for your answer. This discussions help me a lot. My comments also within the text.
Ed Merks wrote on Tue, 12 February 2013 11:00Luis,
Comments below.
On 12/02/2013 3:13 PM, Luis Fernando Robledano-Esteban wrote:
> After a couple of days new to this world of EMF I really don't get it
> yet.
> ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset of
> UML (as a metamodel and not as a graphical representation).
That's one way to look at it.
> I really think it is a new layer which introduces more complexity an
> makes even flater learning curve.
Then I think you've missed the point. You certainly can't argue that
Ecore is more complex than UML, right? So I'm not sure the basis for
your statement that it's a new layer that introduces more complexity.
Yes it is, why?
- I already know UML, after all it is a standard -broader that ECore- and therefore there are more chances that someone already knows UML. If someone has to learn modeling, will he-she choose a cross-fields standar or an SoftwareDev-Eclipse-Java standard?
- UML Class diagrams are not more difficult. In fact less, because for diagramming and understanding concepts nothing more is needed. For ECore it seems from the beginning mapping to UML, Java-code (Gen), is needed (in order to understand his benefits).
> And it is difficult to see advantages.
The most glaring example is as follows: suppose you have a UML class
"Company" that you've designed to represent company instances. With UML
itself, you cannot create an instance of such a class. On the other
hand, with Ecore, you can use EcoreUtil.create(eClassForCompany) to
create an instance.
CASE/UML tools allowed the generation of instances in diagrams (and in code generation if you wish). You could use whatever UML tool you wanted.
UML2 is a metamodel, but it what it's a meta model
for is not defined, it's up to the user/developer to map the semantics.
Ecore is also a metamodel, and it's a meta model for EObjects, i.e.,
what it's a meta model for is very precisely defined.
Exactly, that is what I see, that it is adding semantics. And that is OK, I understand: it is the same each UML tool does -well there are some semantics specification in UML-.
That means that in order to add semantics, EMF creates the whole world of conceptualization and syntax. It could have just created code generation layer and reuse whatever is given by UML. I agree that to make public this and make it a standar for all Eclipse tools makes sense.
> Why in first step didn't Eclipse take UML/XMI for graphical and
> persistent representation?
I'm not sure what you mean. Keep in mind that the OMG defines XMI
serialization in terms of EMOF, and it defines UML using EMOF. Ecore is
an implementation of EMOF and hence the basis for implementation all the
OMG specifications at Eclipse, and the mechanism by which XMI
serialization is supported.
>
Is what I say above: Eclipse could have reused UML and add over it.
> What am I missing?
If all you want to do is draw nice UML diagrams and work with nice UML
instances, you don't need to learn Ecore. If you want to design models
that you can actually instantiate, you'll need Ecore's help for that.
Of course you can combine the two and map UML onto Ecore and then create
instances based on that interpretation of UML.
>
Even when I started to work with Eclipse some months ago when I tried to work with UML there were references to UML2Tools, EMF...
I do want to generate code and make use of libraries-plugins which have been developed for EMF.
IMO it was not necessary a new whole system to do that, UML and XMI and the Eclipse-"Code Generation libraries" would have sufficed. (Notice that ECore still needs UML transformation and that is a big piece).
Now that it exists, there is no alternative but to learn it.
> Thanks pals
ArkosX
[Updated on: Wed, 13 February 2013 09:37] Report message to a moderator |
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1008610 is a reply to message #1008499] |
Wed, 13 February 2013 09:37 |
Luis Fernando Robledano-Esteban
Messages: 32
Registered: February 2013 |
Member |
|
|
Hallvard Traetteberg wrote on Tue, 12 February 2013 13:11On 12.02.13 06.13, Luis Fernando Robledano-Esteban wrote:
> After a couple of days new to this world of EMF I really don't get it yet.
> ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset of
> UML (as a metamodel and not as a graphical representation).
> I really think it is a new layer which introduces more complexity an
> makes even flater learning curve.
> And it is difficult to see advantages. Why in first step didn't Eclipse
> take UML/XMI for graphical and persistent representation?
>
> What am I missing?
One thing is the history (MOF as UMLs metamodel, MOF split into CMOF and
EMOF, Ecore as an implementation of EMOF) another is how it's useful to
perceive it today. I tend to think of Ecore as a practical (and rather
minimalistic) modeling language designed for implementing a system,
rather "just" talking about it. It deliberately avoids a lot of UML's
complexity, which is a relief for both system developers and tool
developers, since this gives less semantics to understand and argue
about and less implementation work. These choices has created a very
innovative Eclipse-based modeling ecosystem that I believe wouldn't be
there if UML had been chosen.
Hallvard
Thanks Hallvard,
It seems it is quite extended the idea that UML is complex, IDK why. A class diagram is easy, well in fact it is used in the EMF to start explaining EMF -surprising ah?-. Can you tell me what do you mean by "lot of UML's complexity", an example maybe?.
IT is exactly the fact that there is that ecosystem which concerns me, not about the advantages, of course, but the problem that it seems to be a niche -Eclipse-Java- , a lot of information and code, etc., to in the end provide code generation -and auxiliary and very useful libraries it seems too  , so don't take me wrong there-.
I want to insist that my ignorance may make me sound stubborn. 
ArkosX
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1008614 is a reply to message #1008610] |
Wed, 13 February 2013 09:57 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I thinks Ed Merks' response could have been much more brutal.
If you ask the question "can I use XXX for real development?"
For Ecore, the answer is unequivocably "yes". And you just have to
choose which of ten solid and twenty experimental enhanced modeling
project capabilities you like as well.
For UML, the answer is at best "sort of". There is so much complexity
that many of the more basic functionalities are swamped. Some of us are
trying hard to improve matters but you really need to be enthusiastic
about the extra abstractions that UML specifications give you over
Ecore's heavily modeled implementations.
Even at OMG, there has been discussion about whether Ecore should be
adopted in favour of MOF. Many OMG specifications leverage Eclipse EMF
for their tooling and have to go through a final de-Eclipse'ing stage to
make the published models neutral.
Regards
Ed Willink
On 13/02/2013 09:37, Luis Fernando Robledano-Esteban wrote:
> Hallvard Traetteberg wrote on Tue, 12 February 2013 13:11
>> On 12.02.13 06.13, Luis Fernando Robledano-Esteban wrote:
>> > After a couple of days new to this world of EMF I really don't get
>> it yet.
>> > ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset of
>> > UML (as a metamodel and not as a graphical representation).
>> > I really think it is a new layer which introduces more complexity an
>> > makes even flater learning curve.
>> > And it is difficult to see advantages. Why in first step didn't
>> Eclipse
>> > take UML/XMI for graphical and persistent representation?
>> >
>> > What am I missing?
>>
>> One thing is the history (MOF as UMLs metamodel, MOF split into CMOF
>> and EMOF, Ecore as an implementation of EMOF) another is how it's
>> useful to perceive it today. I tend to think of Ecore as a practical
>> (and rather minimalistic) modeling language designed for implementing
>> a system, rather "just" talking about it. It deliberately avoids a
>> lot of UML's complexity, which is a relief for both system developers
>> and tool developers, since this gives less semantics to understand
>> and argue about and less implementation work. These choices has
>> created a very innovative Eclipse-based modeling ecosystem that I
>> believe wouldn't be there if UML had been chosen.
>>
>> Hallvard
>
>
> Thanks Hallvard,
> It seems it is quite extended the idea that UML is complex, IDK why. A
> class diagram is easy, well in fact it is used in the EMF to start
> explaining EMF -surprising ah?-. Can you tell me what do you mean by
> "lot of UML's complexity", an example maybe?.
> IT is exactly the fact that there is that ecosystem which concerns me,
> not about the advantages, of course, but the problem that it seems to
> be a niche -Eclipse-Java- , a lot of information and code, etc., to in
> the end provide code generation -and auxiliary and very useful
> libraries it seems too :), so don't take me wrong there-.
>
>
> I want to insist that my ignorance may make me sound stubborn. :p
>
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1008617 is a reply to message #1008614] |
Wed, 13 February 2013 10:27 |
Luis Fernando Robledano-Esteban
Messages: 32
Registered: February 2013 |
Member |
|
|
I must have missed something last 10 years.
I did use UML is SW Development, starting with Classes Diagrams -ClD-, Collaboration Dgms to transmit information are useful, state diagrams and sequence diagrams ...
I soon started to use code generation from ClDs, for classes in C++ and Java, or DTDs for example, some dinamic functionallity from activity diagrams, and state diagrams as well. I'm speaking of the years about 1998-2003, actually software I used was WithClass2000.
There was a point where I didn't even open the IDE (Borland C++, gcc) I just run the compiler from the UML tool.
Nowadays first thing I do to understand some code is rev-engineer with some UML tool.
I start to suspect that some -many?- people really see it clearer going from the code of line to the big picture, but I do it the other way around: I need to see the main goal and how it is distributed in the packages, classes, ending up with sequence diagrams -which summary what is important- and code.
So the answer is yes, UML can be used. But more, the goal of UML is not code generation but schematization. For me, it is difficult to have a discussion about the architecture or even about functionally with code; I do need some graphical representation and UML provides that.
I don't allege that UML is perfect; if it were there wouldn't be other representation paradigms such as BPMN.
MAybe is because I started with Software Engineering topics and UML and then it seemed easy for me, but really it would help me if I see an example where UML is complex -and Ecore or the Concept itself is not-.
ArkosX
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1008624 is a reply to message #1008604] |
Wed, 13 February 2013 10:52 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Luis,
Comments below.
On 13/02/2013 10:23 AM, Luis Fernando Robledano-Esteban wrote:
> Thanks for your answer. This discussions help me a lot.
>
> Ed Merks wrote on Tue, 12 February 2013 11:00
>> Luis,
>>
>> Comments below.
>>
>> On 12/02/2013 3:13 PM, Luis Fernando Robledano-Esteban wrote:
>> > After a couple of days new to this world of EMF I really don't get
>> it > yet.
>> > ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset
>> of > UML (as a metamodel and not as a graphical representation).
>> That's one way to look at it.
>> > I really think it is a new layer which introduces more complexity
>> an > makes even flater learning curve.
>> Then I think you've missed the point. You certainly can't argue
>> that Ecore is more complex than UML, right? So I'm not sure the
>> basis for your statement that it's a new layer that introduces more
>> complexity.
>>
>> Yes it is, why?
>> - I already know UML, after all it is a standard -broader that ECore-
>> and therefore there are more chances that someone already knows UML.
>> If someone has to learn modeling, will he-she choose a cross-fields
>> standar or an SoftwareDev-Eclipse-Java standard?
EMOF is a standard too. A much simpler one.
>> - UML Class diagrams are not more difficult. In fact less, because
>> for diagramming and understanding concepts nothing more is needed.
>> For ECore it seems from the beginning mapping to UML, Java-code
>> (Gen), is needed (in order to understand his benefits).
No, EMF supports dynamic models for which no code is generated.
>>
>>
>> > And it is difficult to see advantages. The most glaring example is
>> as follows: suppose you have a UML class "Company" that you've
>> designed to represent company instances. With UML itself, you cannot
>> create an instance of such a class. On the other hand, with Ecore,
>> you can use EcoreUtil.create(eClassForCompany) to create an instance.
>> CASE/UML tools allowed the generation of instances in diagrams (and
>> in code generation if you wish). You could use whatever UML tool you
>> wanted.
Yes, but with Ecore you don't need to generate code at all. You can
simply create a model and create instances of that model.
>>
>> UML2 is a metamodel, but it what it's a meta model for is not
>> defined, it's up to the user/developer to map the semantics. Ecore is
>> also a metamodel, and it's a meta model for EObjects, i.e., what it's
>> a meta model for is very precisely defined.
>>
>> Exactly, that is what I see, that it is adding semantics.
No, UML doesn't add the semantics. What you produce from UML is what
produces the semantics. I.e., the "whatever UML tool" you mention above
is what assigns semantics however it decides is useful.
>> And that is OK, I understand: it is the same each UML tool does -well
>> there are some semantics specification in UML-.
No, not really.
>> That means that in order to add semantics, EMF creates the whole
>> world of conceptualization and syntax.
Not sure what you mean by that.
>> It could have just created code generation layer and reuse whatever
>> is given by UML.
But as we've established, UML doesn't specify what's to be generated.
EMOF on the other hand, specifies exactly how instances should behave.
I.e., it defines a reflective model for instances and that's what EMF
has implemented with Ecore and EObject. And that's how we were able to
implement UML in the first place. There would be no UML implementation
without Ecore to generate it and there was no UML specification with
EMOF to define it.
>> I agree that to make public this and make it a standar for all
>> Eclipse tools makes sense.
I'm not sure what you're agreeing with...
>>
>> > Why in first step didn't Eclipse take UML/XMI for graphical and >
>> persistent representation?
>> I'm not sure what you mean. Keep in mind that the OMG defines XMI
>> serialization in terms of EMOF, and it defines UML using EMOF. Ecore
>> is an implementation of EMOF and hence the basis for implementation
>> all the OMG specifications at Eclipse, and the mechanism by which XMI
>> serialization is supported.
>> >
>> Is what I say above: Eclipse could have reused UML and add over it.
No, that's misguided thinking. We needed Ecore to even build UML in
the first place. And we need Ecore to implement XMI serialization. Of
course you can use UML and nice UML tools to do all manner of cool
things, all without using Ecore at all, but you've taken that point of
view and turned it around to argue that Ecore isn't needed at all by
anyone for anything because they could all just use UML. That's just
misguided and wrong.
>>
>> > What am I missing?
>> If all you want to do is draw nice UML diagrams and work with nice
>> UML instances, you don't need to learn Ecore. If you want to design
>> models that you can actually instantiate, you'll need Ecore's help
>> for that. Of course you can combine the two and map UML onto Ecore
>> and then create instances based on that interpretation of UML.
>> >
>> Even when I started to work with Eclipse some months ago when I tried
>> to work with UML there were references to UML2Tools, EMF...
Next you'll argue we don't need Java, only UML, and you don't want to
learn Java?
>> I do want to generate code and make use of libraries-plugins which
>> have been developed for EMF.
So you'll need to understand Java and the frameworks on top of it.
>> IMO it was not necessary a new whole system to do that, UML and XMI
>> and the Eclipse-"Code Generation libraries" would have sufficed.
No, it wouldn't have.
>> (Notice that ECore still needs UML transformation and that is a big
>> piece).
No, Ecore does not need UML at all, it's the other way around.
>> Now that it exists, there is no alternative but to learn it.
Yes, just as there's no alternative to using Java, unless you can find
some other nice implementation of the OMG's stack of specifications.
Maybe something from Microsoft for C#.
>>
>> > Thanks pals
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1008630 is a reply to message #1008617] |
Wed, 13 February 2013 11:03 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Luis,
Comments below.
On 13/02/2013 11:27 AM, Luis Fernando Robledano-Esteban wrote:
> I must have missed something last 10 years. :p
Everything we did at Eclipse. :-P
> I did use UML is SW Development, starting with Classes Diagrams -ClD-,
> Collaboration Dgms to transmit information are useful, state diagrams
> and sequence diagrams ...
> I soon started to use code generation from ClDs, for classes in C++
> and Java, or DTDs for example, some dinamic functionallity from
> activity diagrams, and state diagrams as well. I'm speaking of the
> years about 1998-2003, actually software I used was WithClass2000.
> There was a point where I didn't even open the IDE (Borland C++, gcc)
> I just run the compiler from the UML tool.
> Nowadays first thing I do to understand some code is rev-engineer with
> some UML tool.
So you're clearly a diehard UML fan. :-)
> I start to suspect that some -many?- people really see it clearer
> going from the code of line to the big picture, but I do it the other
> way around: I need to see the main goal and how it is distributed in
> the packages, classes, ending up with sequence diagrams -which summary
> what is important- and code.
A great many people design their model first. These days you can to that
in Xcore if you like a textual representation or with Ecore Tools, if
you like class diagrams; the later is just a simplified UML diagramming...
> So the answer is yes, UML can be used. But more, the goal of UML is
> not code generation but schematization.
UML's goals are much much broader than Ecore's.
> For me, it is difficult to have a discussion about the architecture or
> even about functionally with code; I do need some graphical
> representation and UML provides that.
Keep in mind that most of the UML specification is about the abstract
representation of UML, i.e., the abstract syntax trees that underlie the
diagrams. Visualization of that structure is a separate concern. Ecore
Tools visualizes Ecore instances much like Papyrus visualizes UML2
instances...
> I don't allege that UML is perfect; if it were there wouldn't be other
> representation paradigms such as BPMN.
> MAybe is because I started with Software Engineering topics and UML
> and then it seemed easy for me, but really it would help me if I see
> an example where UML is complex -and Ecore or the Concept itself is not-.
Have you ever seen a diagram of the whole UML model that fits in a
single page?
http://download.eclipse.org/modeling/emf/emf/javadoc/2.8.0/org/eclipse/emf/ecore/doc-files/EcoreRelations.gif
Okay, adding generics complicated the picture a bit
http://download.eclipse.org/modeling/emf/emf/javadoc/2.8.0/org/eclipse/emf/ecore/doc-files/Generics.gif
But good luck finding a diagram that explains all of UML on something
that doesn't cover an entire wall!
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Why does ECORE exists, when UML was there already? [message #1009269 is a reply to message #1008610] |
Thu, 14 February 2013 19:48 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 13.02.13 01.37, Luis Fernando Robledano-Esteban wrote:
> It seems it is quite extended the idea that UML is complex, IDK why. A
> class diagram is easy, well in fact it is used in the EMF to start
> explaining EMF -surprising ah?-. Can you tell me what do you mean by
> "lot of UML's complexity", an example maybe?.
UML's diagrams (class, collaboration, sequence) aren't that complex I
agree, if your focus is creating diagrams for your design (or
re-engineering some other's). Once you want to do model-driven
development, you must understand UML's meta-model and that's when it
becomes very complex, and Ecore and EMF's simplicity a relief.
> IT is exactly the fact that there is that ecosystem which concerns me,
> not about the advantages, of course, but the problem that it seems to be
> a niche -Eclipse-Java-
Luckily, a lot of people and companies fit in this niche.
Hallvard
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1009491 is a reply to message #1009269] |
Fri, 15 February 2013 08:22 |
|
Le 14/02/2013 20:48, Hallvard Trætteberg a écrit :
> On 13.02.13 01.37, Luis Fernando Robledano-Esteban wrote:
>> It seems it is quite extended the idea that UML is complex, IDK why. A
>> class diagram is easy, well in fact it is used in the EMF to start
>> explaining EMF -surprising ah?-. Can you tell me what do you mean by
>> "lot of UML's complexity", an example maybe?.
>
> UML's diagrams (class, collaboration, sequence) aren't that complex I
> agree, if your focus is creating diagrams for your design (or
> re-engineering some other's). Once you want to do model-driven
> development, you must understand UML's meta-model and that's when it
> becomes very complex, and Ecore and EMF's simplicity a relief.
For the curious, here are class diagrams showing all the concepts
defined in both metamodels:
- Ecore (using Ecore.ecore from http://www.eclipse.org/emf/2002/Ecore)
https://dl.dropbox.com/u/17313550/ecore.svg
- UML (using uml.ecore from http://www.eclipse.org/uml2/3.0.0/UML)
https://dl.dropbox.com/u/17313550/uml.svg
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1009496 is a reply to message #1009491] |
Fri, 15 February 2013 08:27 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Cool! Thanks for sharing that!!
On 15/02/2013 9:22 AM, Pierre-Charles David wrote:
> Le 14/02/2013 20:48, Hallvard Trætteberg a écrit :
>> On 13.02.13 01.37, Luis Fernando Robledano-Esteban wrote:
>>> It seems it is quite extended the idea that UML is complex, IDK why. A
>>> class diagram is easy, well in fact it is used in the EMF to start
>>> explaining EMF -surprising ah?-. Can you tell me what do you mean by
>>> "lot of UML's complexity", an example maybe?.
>>
>> UML's diagrams (class, collaboration, sequence) aren't that complex I
>> agree, if your focus is creating diagrams for your design (or
>> re-engineering some other's). Once you want to do model-driven
>> development, you must understand UML's meta-model and that's when it
>> becomes very complex, and Ecore and EMF's simplicity a relief.
>
> For the curious, here are class diagrams showing all the concepts
> defined in both metamodels:
>
> - Ecore (using Ecore.ecore from http://www.eclipse.org/emf/2002/Ecore)
>
> https://dl.dropbox.com/u/17313550/ecore.svg
>
> - UML (using uml.ecore from http://www.eclipse.org/uml2/3.0.0/UML)
>
> https://dl.dropbox.com/u/17313550/uml.svg
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Why does ECORE exists, when UML was there already? [message #1010976 is a reply to message #1008442] |
Mon, 18 February 2013 15:42 |
Roland Tepp
Messages: 36
Registered: July 2009 |
Member |
|
|
Ed Merks and others have provided pretty nice and high level response to
this question, but let me please try to alleviate your confusion a bit
from my own perspective.
12.02.2013 16:13, Luis Fernando Robledano-Esteban kirjutas:
> After a couple of days new to this world of EMF I really don't get it yet.
> ECORE seems to be (bibliography such as EMF 2Ed. says so) a subset of
> UML (as a metamodel and not as a graphical representation).
> I really think it is a new layer which introduces more complexity an
> makes even flater learning curve.
First of all, EMF and UML do not necessarily work at cross purposes.
In fact, Eclipse tooling for UML uses EMF as an underlying metamodel for
all UML models.
In fact, whenever you take any UML diagramming tool (regardless, wether
it can spit out code, reverse engineer it, or just print pretty
pictures), it has some underlying model that allows it to display such
models. Chances are they all use EMOF in one form or another under the
covers. EMF being an implementation of EMOF is no different.
As being an "extra layer", you are partially correct. Namely, since UML
is defined in terms of an EMOF model -> EMF implements EMOF -> UML is
(can be) defined in terms of EMF -> there's your extra layer.
On the other hand - this extra layer is already there in UML
specification, so where's the problem?
Also, while UML works conceptually on a very high level of abstraction,
EMF is necessarily much more "closer to the metal". You can interact
with EObject instances from Java code, but you really can't do the same
for UML model elements (without a library such as EMF).
(now, I should probably shut up about UML, since I don't really know all
that much about it)
To answer your last question:
> And it is difficult to see advantages. Why in first step didn't Eclipse
> take UML/XMI for graphical and persistent representation?
>
Seriously? And what should they have used for implementation detail?
Pretty printed graphics? in SVG format perhaps?
> What am I missing?
>
Plenty of things probably.
From my perspective, EMF is the assembly language of UML.
This means that everything you can express in UML, you can probably
express in EMF, but not necessarily or easily the other way around.
Is it a good thing? It depends on your point of view, I guess.
You can write up your own domain specific modeling DSL's and tooling for
manipulating such models. In fact there are tons of existing frameworks
and libraries and tooling support available.
You can keep it as light-weight as necessary. You can include it in your
processes without needing to cough up prohibitively expensive license
fees for some of the UML tools I've seen on the market.
You can use EMF tooling for one-off projects such as log file analyzers
or gathering static analysis information of your projects. You can model
static structure of your domain with it and run complex rule engines on
top of that information.
It is malleable and lightweight enough that you can start introducing it
gradually into the whole software development cycle instead of dropping
it like a big bomb wholesale.
|
|
|
Goto Forum:
Current Time: Thu Apr 18 07:34:04 GMT 2024
Powered by FUDForum. Page generated in 0.04162 seconds |
] 
Search
Help
Register
Login
Home
