[news.eclipse.modeling] Re: Should UML be used in an Agile Project ?

[Ed Merks <Ed.Merks@xxxxxxxxx>]

Vlad,

Comments below.

Vlad Varnica wrote:

Ed,

I agree with you that  Ecore is a language which is used to define UML

It's a fact so that's good. :-)

This is why EclipseUML is directly working at Ecore level and not at just at EMF level.

I don't know what you mean by working at the Ecore level rather than the EMF level.

Don't forget that even if ecore is a language you can only design class diagram.

Yes, that's the design point to keep it simple.  It's not a unification of a very large number of design concepts as is the case for UML.

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.

I'm not sure what else you consider necessary for defining structure.  I think Ecore is very powerful in this regard.

What I also don't like with Ecore diagrams is the use of multiple views in which the diagram is the model.

The diagram and the model are separate things and the diagram is just a view of 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.

It does provide a view of the model and you can edit the model directly, so I'm not sure I've followed this line of reasoning very well...

Doing that allow to:
- use the same element inside different views

It does exactly that as illustrated in this blog:

http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.html

- keep the model logic for the entire project and not just a diagram level (classifier ID remains the same after transformation)

I'm not sure what this means.

- keep traceability of classifiers

I'm not sure what's implied by this.  Keep this where?

- allow to add documentation and keep it synchronized

That's supported via annotations.  Generated Java code (should one choose to use Ecore for that) contains @model tags from which the original Ecore model can be recovered, so one can choose to work directly in Java and synchronize the model from that.  Of course Java doesn't have the concept of containment or bidirectional references so it's necessary to specify this type of information.

- allow live code and model synchronization

Yes, that's supported. This isn't an intrinsic aspect of Ecore or UML but rather a sophistication in the tools themselves.  The EMF tools are not nearly as sophisticated as one might like

- allow java annotation integration

We've not implemented that yet.  There's a bugzilla open though.

- 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.....

Teneo provides integration with Hibernate and EclipseLink and hence JPA.

My vision how modeling tools should work in an agile project is therefore correct :-)

I'm not sure how that follows from the above statements.  It seems to me that design methodologies are often a matter of opinion and involve significant trade-offs as do all designs.  I'd like to think that EMF doesn't impose any specific approach...

Ecore is agile with the use of UML Superstructure (e.g. Omondo) and only MDD with the use of GMF or ecore diagrams.

The implication you're making is that MDD implies not Agile.  Yet you also seem to argue that one should use UML to do all development so you can be Agile.  Somehow you see UML Driven Development as Agile but Model Driven Development as not Agile.  Clearly UML is a model so all this just serves to confuse me...