In my wunderlist‘s “watch this” list I found this dinosaur movie to watch: MDA: A forlorn hope. by Uncle Bob. It was posted over two years ago and it was viewed almost 55 thousand times.
MDA is easy isn’t it? The MDA Guid has only 62 pages. We need some modeling tools and another tool for model to code transformation. Sounds easy 🙂
Few years ago, we’ve been using MDA approach in our project. We used MagicDraw for UML part and AndroMDA for UML to Java code generation (of course there are many other tools). From my point of view it was great experience. I share with my opinion below:
- (pros) Model and Factory for free.
- (pros) Hibernate mapping for free.
- (pros) Documentation is up to date – you have to modify it to generate changes.
- (pros) We focused on design, before coding.
- (pros) All you hibernate mapping/DAO/etc is similar ( standardized – we can modify template)
- (pros/cons) We can/have to change templates to align to ours standards.
- (cons) Lot of code you prefer to never read :/
- (cons) Every time you change something, you have to regenerate code.
- (cons) You have codebase divided into “read only” and “change here”.
- (cons) If you forget to put additional metadata into model you’ll be doomed in future.
- (cons) Once you change template, it is harder to upgrade tools and we have to regenerate code.
Nowadays I compare that experience to modern frameworks such as Rails or Django. I have to add comment here, what I really mean is that by using MDA approach I do not think about database mapping, DAO/repository object, I started at service level, and I have similar fillings when I’m using Rails or Django framework. I’m focusing on business logic, not how to get or save data into persistence storage.
Uncle Bob is talking about analyst as software creators, and this idea fortunately for my salary is impossible ;).
I totally agree, doing software is on much more detail level than model thinking, but … I think it wasn’t so bad to think about design on high level and then generate code and go deep in business logic details. How many times Java programers do the same job: create POJO, annotate or write XML descriptor, create DAO which looks more or less the same as another one, etc.
Let cite some smart guys from Uncle Bob post:
- Uncle Bob: “Programmers are details managers – sorry MDA” 🙂
- Comment: “MDA is actually based on two grand ideas:
– raising the level of abstraction above programming language.
– satisfying everyone with universal set of *standard* abstractions. Most of MDA failures is due to the the second idea, which is why MDA (not MDE in general) may be indeed a forlorn hope.”
I don’t want to force you to use MDA, just think about it and in …meantime … find the difference :).
Yep, posterous is dead. Is MDA dead? Please share your opinion in comments.
Good question but what is the right answer? RT @pedrowaty: Model Driven Architecture live or dead? http://t.co/Y24TrluaIa
Thanks for your interesting and provocative post.
My first reaction was to say “Good question, but what is the right answer?” Your post is certainly very interesting. However, before declaring MDA dead or alive, we should precisely characterize what is MDA.
Even if we take the “orthodox” vision, given by the OMG MDA(tm) guide, there are several very different visions that are mentioned there.
Some of them are probably deprecated. But others have been taking shape since the OMG white MDA paper was published in late 2000 (less than 13 years ago). And we may be surprised when we’ll see the new software modeling frameworks arriving in some years. The new wave of ModelEngineering2.0
Mda or not mda? http://t.co/mI0oZ1vrrF
Génération Y tells us no, and you?
@JBezivin @pedrowaty Would Continuous MDA (the like of Continuous Integration) address some of these cons?