Home » Modeling » EMF » History of EMF
| | |
| Re: History of EMF [message #1818427 is a reply to message #1818426] |
Mon, 16 December 2019 07:10   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
The common general reason people do things from scratch is that they believe that their hand written code will be simpler, easier to understand, and more efficient than using some other framework. It's just human nature to believe this. Using a framework will require learning that framework and initially one will question why that framework seems so much more complex than is completely necessary. Of course over time, the hand written code will need to solve all the same problems and all the same complexity will be reinvented. But, it will well understood by the author, because the author wrote it. But to everyone else, it will be yet another complex framework.
The referenced document it states:
Quote:This document describes the Basic Meta-Model (BMM), a model of object models. It may be considered as an approximate replacement for the UML XMI. It is human-readable and writable, and supports generic types (open and closed), container types, and multiple inheritance.
Clearly these folks know of UML, and describe in detail its shortcomings and complexities, so they decided to create something just like it, but simpler and better. But there are certainly no technical reasons (e.g., immaturity of the frameworks at Eclipse) why they wouldn't do this using EMF and other downstream frameworks. After all, UML's defacto standard implementation is the Eclipse UML2 implementation, based on EMF and described with Ecore. Moreover, these frameworks are what IBM uses to build its commercial tools as far back so 2000. It brings back memories of IBM where they "pushed" their customers to use profiled UML as the way to design a DSL, rather than to use EMF to design a lightweight DSL. Not only that, the technical leaders were of the opinion that a model is "just a model" not a language. Why? Because a model has no concrete syntax, arguing that an XML serialization is not a concrete syntax. The underlying reason (in my opinion) was that UML sold tools while EMF was free and although EMF is used to build said commercial tools, EMF had its own free tools that anyone could use for free.
I expect that there were purely political reasons for the BMM design/implementation approach, but you should ask them for the reasons. It will definitely not be technically justified by the immaturity or lack of functionality in the available Eclipse frameworks at the time those decisions were made.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: History of EMF [message #1818437 is a reply to message #1818436] |
Mon, 16 December 2019 10:06 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
As usual, UML remains the focus as well as the point of comparison. But Ecore actually provides the pragmatic solutions, has a huge stack of frameworks to do everything one might imagine doing with models, can be used to build UML, SysML, and anything else (DSL) imaginable, and, along with Eclipse's many non-modeling frameworks, can be leveraged to build rich tools around these things. The lack of clear vision (model snow-blindness) is the unfortunate domain of big organizations with grandiose visions working with other big organizations with alternative grandiose visions. Meanwhile the anti-modeling bigots long with the Luddites are sure they can do everything better by hand. Alas, such is how the really world works.
I would not characterize the dysfunctional funding model for modeling technologies as a failure of modeling but rather a reflection of the simple fact that Eclipse modeling is a victim of its own success. Why invest in technologies that are perceived to be stable, robust, and mostly complete? Investment goes into new cool things because executives (who hold the purse) are like children: they are enamored by new toys and the old toys are pushed to the side. Even developers generally much prefer to develop new cool things rather than support old things. So the investment and interest is focused on all the cool things you can do with the wide variety of frameworks that already exist with the underlying (baseless) assumption that the free goodness will always just keep flowing forever because someone else will do that. That part is definitely dysfunctional and could ultimately lead to failure of the whole...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: History of EMF [message #1818444 is a reply to message #1818437] |
Mon, 16 December 2019 11:51 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
Indeed. If UML had separated its distinct analysis and synthesis/implementation requirements, the synthesis/implementation sub-UML might be remarkably similar to Ecore. It even had a name (EMOF) but was discarded as UML 2 bloated out.
Determined UML users are forced to struggle with the bloat and while Eclipse's UML2Ecore rescues something useful from a UML model, it is had to answer the question why bother with conversion from a perverse UML abstraction when Ecore does the job much more directly and is consequently so much better?
Perhaps the answer comes from diagrams that on a good day can be very helpful and where this thread started.
Ecore had no diagrams for ages, and just as the old Ecore Tools got useful, it died. I find the new Sirius based Ecore Tools very unsatisfactory because it has a Sirius world *.aird lock-in that fights the standard edit-a-file Eclipse ergonomics. It seems you share this view since the Ecore diagram files have never been updated from the old Ecore Tools.
When editing Ecore files, I probably use the Ecore Tree editor 90% of the time, the OCLinEcore text rendering 6% of the time, an XML text editor 3% of the time and Ecore Tools 1%. I only use UML in so far as I need test cases for UML tooling support.
Ecore is great, but the tools around it don't provide an integrated UI. Ecore Tools is painful to use. Ecore supports reflective XML editing, but no tool supported reflective diagram drawing until I developed one to draw diagrams for a conference paper. (It's part of QVTd and on offer to Sirius where it belongs.)
When Ecore's implementation utility is stretched to a no-Java model specification role, sadly some cracks start to appear in particular in regard to inconsistent treatment of dynamic model inheritance of EObject.
If we had time/commitment to address the above comparatively minor issues we could Make Eclipse Great Again.
Regards
Ed
|
|
|
Goto Forum:
Current Time: Thu Apr 25 09:16:51 GMT 2024
Powered by FUDForum. Page generated in 0.03435 seconds |
] 
Search
Help
Register
Login
Home
