Pros and Cons of MDA Code Generators? 62
amartel asks: "Four years ago, Ask Slashdot asked if anyone was using a Model-Driven Architecture. The number of MDA tools are now almost overwhelming, and I strongly believe that comments to the same questions would be rather different nowadays. What are the drawbacks, difficulties and limitations of MDA? What percentage of code can actually be generated? I would like to add a few more: is it realistic to create a custom GUI rather than CRUD operations with these tools? Finally, what about Microsoft, the new competitor on the scene, and their DSL Tools?"
MDA - for gaming (Score:5, Interesting)
My advise... (Score:3, Interesting)
ArgoUML + EMF + Hibernate (Score:3, Interesting)
The model is developed using ArgoUML [tigris.org]. The output is a zipped XMI file that I convert to a EMF ecore model using the argo2ecore [sourceforge.net] Eclipse plug-in. From there I generate the model and editor code using EMF [eclipse.org]. After that, I use the Elver [elver.org] plugin to generate the corresponding hibernate mappings.
So from the UML source, I can generate EMF model and edit code to serve the presentation and hibernate mappings for persistence to an RDBMS -- all using free software.
There are a couple of big challenges, namely distributed object persistence (including transactions). For this we're attempting to use the EMF SDO (Service Data Objects) implementation. Also implementing business behavior is a bit of a challenge since ideally we'd be able to mark certain EMF methods as "biz logic" such that the factory generates a stub for the client, and I could fill in real business logic for the server side.
MDA = Mass Destruction of Application (Score:5, Interesting)
My experience with Model Driven Architecture left me with a bad feeling about it. While the theory and goals are admirable, I worry that practical implementations don't meet expectations. Basically, I think that MDA is presented as a silver bullet, and the type of companies likely to by 'targeted' by MDA (e.g. those that must 'fix' their development methodology) are the least likely to benefit from it. I am willing to accept that highly skilled and well managed project teams will experience massive productivity gains using MDA, but such project teams (unfortunately rare in our industry) would probably succeed using pretty much any methodology.
I worked one summer on a Java based project whose goal was to develop a system for managing health insurance policies. The company and project were flawed for a number of reasons, not directly related to MDA, but the choice of MDA made the situation much worse. The end of this story is that the company went out of business because it was unable to deliver the software it had promised.
Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.
The state of the project when I arrived (which was to implement optimizations to one of XML based parts of the code generator) was:
I think the worst result of MDA, was that the nature of the MDA process caused a large divide to develop between the 'system' programmers, maintaining the underlying MDA library, and the 'application' developers.
The system people, generally well qualified programmers, had little or no interest in the end application. The were fascinated by the tools and viewed the production of a functioning application as 'an exercise for the application programmers'.
The application programmers, on the other hand, had absolutely no understanding (though through necessity they had interest) of the underlying architecture and no ability to predict the performance implications of their design choices.
The result was a massive resource hog. The two system programmers, truly interested in ensuring the that MDA system could actually be used create an salable application had to work overtime to try to hold everything together. Unfortunately, they failed, though not for want of trying.
The main technical problem, beyond the complexity of the tools, was their attempt to map the MDA's OO data model to a relational database. (I'm not sure if this is a core principal of MDA, so I welcome your feedback). While OO data modeling might be good for user interfaces. I don't feel it's that suitable for modeling typical business data, like insurance policies. And the OO modeling concepts seemed to confuse the business domain experts, who tended to think in relational model terms.
It may well have been that this particular implementation of MDA was badly flawed. That said, the nature of MDA, that of hoping to implement your application by 'drawing pictures', and then filling in snippets of code to complete the it, seems naive. It reminds me of the early 90s when 'strong CASE' was the rage and the CASE proponents said all application design would be done using diagramming tools and then filling in the bodies of the subroutines.
I suspect that over the years, MDA will generate a minor following, like strong CASE did, but then a new fashion will emerge and interest in MD
Re:MDA vs MDD (Score:3, Interesting)
Yeah, tell that to Larry Page and Sergey Brin (Google), Scott McNealy, Andy Bechtolsheim, Bill Joy and Vinod Khosla (Sun Microsystems) and Fred Smith (FedEx). Those companies all started out as college term papers.