Musings on MDA

The noise about MDA generally has died down, and I think that has to do with expectations having met reality. MDA can do really good things, when expectations are set right. If not, disappointment is pretty much guaranteed.

In example, I was overseeing a diploma thesis about transforming EJB 2.x persistence into EJB 3.x persistence. This worked very well because the input data was already modeled in a machine-readable form (in example, EJB 2.x-style XML descriptors), that is, the human part of the work was largely done.

Regarding MDA often promises are made – especially by vendors of MDA products – that inevitably create disappointment because improvements by an order of magnitude rarely materialize, for various reasons inherent to the way software development works.

First off, “coding” (I hate this term) is only a small part of the whole process of creating software. Even if you could reduce code production effort to 10% of the conventional approach: if code production is 20% of the overall cost, you achieved an overall reduction of 8% (which still is not bad, but not as spectacular as 90%).

Secondly, all automatic approaches require that some human already did the thinking part. You’ll never get a class model generated from requirements written in prose (but you can create the DB from a class model), and you’ll never get code generated from the informal description of an algorithm (but you can create method stubs and calls from a sequence diagram).

One (big) problem that keeps me at a distance from MDA approaches so far is that round trip engineering often works rather poorly. If you always generate foward there is no problem; if you need changes in the generated code reflected back into the model (refactoring comes to mind; try that with your MDA tool), you’re often out of luck.

Leave a Reply

Your email address will not be published. Required fields are marked *