Clarification on UML/MDA

It just goes to show that I shouldn’t write about things I haven’t been keeping up with.
Apologies also for taking so long to respond. Last week was pretty hectic, and I was in catch-up mode all week after being sick the week before.
Stefan Tilkov takes me to task on my statements about the “grand vision” of MDA in the Graphically Yours posting.
I checked, and some of the more recent whitepapers and descriptions of MDA indeed talk about it more as a “productivity” tool than as a complete, end-to-end programming environment.
Some of the material on the OMG site still positions MDA as a solution for multi-platform interoperabilty through code generation. The troubles arise when people try to think about UML/MDA as an executable system, however, and that gets them to thinking everything can be done using heavily annotated diagrams.
A couple of years ago, when IONA was a bigger company and into MDA, and I had the pleasure of working with David Frankel, the vision for MDA included “using the modeling language as a programming language” – as Slide 33 of Dave’s presentation shows. Also check slides 3 and 22-27 for more about this original (or at least one-time) vision for MDA.
Though a strong proponent, Dave always acknowledged the MDA was subject to over-hype, and tried to present a balanced view, as he does in his book, which I’m very happy to recommend. But I think the vision as articulated at the time included the ability to work entirely in the graphical environment, abstracting completely the underlying execution environment, whatever it was.
On Stefan’s page he references his answer to Martin Fowler’s critique, but he also acknowledges the main point I was trying to make (and which Martin also makes), which is that pictures are just not going to replace words in software development.
My experience with UML-generated code seems to be in line with what Stefan is saying, and with a more practical view of UML and MDA that now seems to be emerging. I was running a COM+ architecture lab program at the time for Compaq services. We started with UML to capture the use cases and create the initial class diagrams, from which we generated the initial VB skeletons. However, once we got into the code we never went back to the diagrams. True round-tripping, as far as I know, remains an unrealistic goal.
The current thinking about modeling tools seems to be that they are not intended to completely replace coding, as Stefan says, but to generate as much code as possible. It’s good to see a more realistic view being promoted nowadays, and yes, if I’d been aware of this shift I would certainly not have taken the old vision to task.
A recent statement from Bill Gates is interesting in this light, including the observation that UML is too complex (which I agree with for what it’s worth), although modeling is definitely the future. He includes Web services in the picture by saying that you need modeling for them.
I’m not sure about that, but I certainly agree that UML and MDA are not right for Web services, as I said. And I am sticking to that part of the original post!

Advertisements

One response to “Clarification on UML/MDA

  1. UML to model Web Services?

    Eric Newcomer answers some of my criticisms of his recent posting on MDA. Great to see that we’re not that far apart, and kudos to Eric for openly acknowledging a slight change of mind — something you don’t find very often. Interestingly, many op…