John Ferguson Smart's Blog

Java Power Tools: who uses MDA these days?

I've been thinking about MDA tools of late. The Java Power Tools book way initially supposed to include a chapter on these tools, but I'm not sure how much interest there is out there . There are a few O/S UML modeling tools such as ArgoUML and Umbrello (a KDE tool), and MDA tools such as AndroMDA. ArgoUML was a bit limited for round-trip work the last time I looked at it. I haven't played around with Umbrello, which looks like a nice tool, but I intend to.

The Java Power Tools book is about Open Source solutions, but I can talk about non-OS solutions here a little. Many companies use expensive, heavy-weight UML tools (think "Rational Rose" and the like) - or at least they buy the licenses. I'm not sure how many of these tools end up as "shelfware". Others use cheaper tools such as Sparx Enterprise Architect, especially for the requirements analysis/design phase. UML has always struck me as an excellent communication tool. But does anyone do full-on, round-trip UML modeling today for real-life projects?

What are people's thoughts on this? Is MDA a fading trend in the face of the newer, Agile-style methodologies, or is open source MDA just floundering because no top-notch O/S tools capable of nice IDE integration and round-trip engineering are available? Thoughts, anyone? (You can also share your in the Case Studies page of the Java Power Tools website).

Comments

• John,

  why is people's focus always limited to "use an UML tool" when they are talking about MDA?
  MDA (and MDD) is NOT just UML and doing some round-trip engineering: http://www.omg.org/mda

  Best,
  Matthias

  Posted by: mpscholz on March 01, 2007 at 12:27 AM

• Fair point - there is more to MDA than just UML modeling and code generation. But the question remains: who is currently using tools like AndroMDA in real-world, client-paid projects? What tools are you using? Does it work well?

  Posted by: johnsmart on March 01, 2007 at 02:44 PM

• From the glacial progress of ArgoUML it looks like that project (which showed some hope a few years ago) is all but dead.
  I've not worked in an environment where UML (or modelling tools in general) tools were used at anything approaching a consistent basis. Often there's talk of starting to use them at some point, but nothing seems to ever happen except a few individuals using their personal Enterprise Architect licenses to get a feel for the class structure of the more complext parts of the system.
  "why is people's focus always limited to "use an UML tool" when they are talking about MDA? " Marketing. There's (and always has been for as long as I've been in the industry) a perception with management that just using XXX (where XXX shifts, it's UML now (or was last year)) will guarantee perfection. It never works of course, as developers get handed a set of tools to use and told to use them without any training or rationale, let alone any consultancy with them about whether those tools make sense before the decision to use them is made by people who've never written a line of code in their lifes and likely can't even find the on/off button on their computers if their lifes depended on it.

  Posted by: jwenting on March 02, 2007 at 05:59 AM

• 
  MDA isn't dead, I'm not sure it was ever really alive. There are so many problems with it.

  Many people don't find diagrams useful so they won't produce them or maintain them.
  The UML tools I have used are almost, without exception, too limited to be useful. They always run out of steam and are often unreliable.
  Object-oriented programs are models. Those "class" things are exactly the same as the boxes on the diagram and I have a reliable tool to produce them - a text editor.
  UML models are useful but they need to be created as part of the build - not using some fancy tool. UML Graph shows promise here.
  MDA is based on the assumption that models are expressive enough to generate all the code. This is not true for 99% of real world problems.

  Posted by: ifairman on March 02, 2007 at 09:08 AM

• well said that. I vividly remember the salespitches of slick suited marketeers who visited us regularly 7 years ago claiming that using their product you'd never have to write a single line of code again. All you had to do was put in your business requirements in the form of a script (doh!) and your corporate standard for screen layout in the form of a template (more doh!) and it would generate everything for you, you only had to implement some method bodies (more doh!) but "the next version" (which of course never arrived) would make that unnecessary.
  They were of course dead wrong. MDA and UML tools salesmen made the same promise a few years later, and were just as wrong.
  UML can be nice to express the structure and flow of an application, and drive you in the right direction for some implementation choices, but it's not going to write your application for you. I've seen the results of architects who thought it can, and it wasn't pretty.

  Posted by: jwenting on March 02, 2007 at 10:44 PM

• Interesting. I work for a big (very big!) company and am involved in large scale software project based on MDA.

  We use some of the "expensive" MDA tools and added a lot of our own tools to the suite. Indeed, the expensive tools are not great. We have done a lot with them but we're in the process of moving to another set of tools that are all integrated and are better fit to our needs (we are able to feed requirements to the creators of those tools).

  Surprise: The overall methodology appears to work. It's only a matter of management and correct artifacts generation. True enough: most developers are not crazy about UML or diagrams. However, if you generate an appropriate set of artifacts that match the needs of the developers, the scheme works. It does in my project and this is a large project with hundreds of developers...

  The jury is still out because we'll have to see how the benefits materialize -- do we have a more efficient change control? Do we have a central single source of truth? Are generated artifacts used correctly? Will this work for the 2nd, 3rd and higher number releases? Will we be extending and refining the model or will we remodel everything? Will the model mature into a standard? Will the code remain in sync with the model (and not hacked to death to resolve local issues)?

  Certainly the answers are not all in but the beginning is very promising. No, it is not true that you feed the tool business requirement and need not write a single line of code. No it is not true that diagramming does everything. However, when enough effort is invested in the artifact generation mechanisms and patterns and in documentation and education, things may just work...

  I'm not giving up on the methodology. I'm giving up on some of the commonly used tools.

  *Loopi

  Posted by: loopi on March 03, 2007 at 10:31 AM

• Diagrams can be a really good way to communicate with non technical stakeholders. The methodologies that work best with that are obviously the ones that don't overload the diagram with technical nuances and minutiae.

  Everybody can relate to the stick figure.

  Also, high level diagrams can be really good for communicating with other members of the team. Eg the programmer you are talking to might not have anything to do with the reporting module, but it helps you explain how their part of the bigger picture fits in with respect to other parts of the system (such as the reporting module).

  The NLP people have some interesting ideas about how people primarily learn: 40% visual, 40% auditory, 20% kinesthetic (by doing). With the implication that if you just hand out a diagram you will miss 60% of your audience. But that if you hand out a diagram _and then_ verbally walk through it, you reach 80%. And then the remaining 20% will pick it up by tinkering with it later (yikes! Better give them something to play around with that _isn't_ the production system!!!) :D

  Posted by: rickcarson on March 04, 2007 at 03:29 PM

This work is licensed under a Creative Commons License.