I agree with you that Ecore is a language which is used to define UML
This is why EclipseUML is directly working at Ecore level and not at just
at EMF level. Don't forget that even if ecore is a language you can only
design class diagram. It means that only static graphical presentation is
possible to cover structural modeling. This is a serious limitation in
the use of Ecore diagrams as modeling solution.
What I also don't like with Ecore diagrams is the use of multiple views in
which the diagram is the model. Diagrams should a viewer of the model and
all modeling job should be done in the model using synchronization rules
as a back office job.
Doing that allow to:
- use the same element inside different views
- keep the model logic for the entire project and not just a diagram level
(classifier ID remains the same after transformation)
- keep traceability of classifiers
- allow to add documentation and keep it synchronized
- allow live code and model synchronization
- allow java annotation integration
- allow database modeling with JPA, Hibernate etc...this is the pojo
concept going in a top down and bottom up cycles.
and a lot more.....
My vision how modeling tools should work in an agile project is therefore
correct :-)
Ecore is agile with the use of UML Superstructure (e.g. Omondo) and only
MDD with the use of GMF or ecore diagrams.