Pros and Cons of MDA Code Generators?

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?"

Comments

MDA - for gaming

[QuantumFTL]

I really like MDA for game creation because it allows me to focus on game mechanics (great for simulation/conquest games) rather than coding. With all the tweaking of game mechanics and in-game entities, code changes can be very tedious. Having auto-generated database and XML mappings doesn't hurt either!

My advise...

[malraid]

Pick a tool that you are comfortable with, code with it. It should be fast to code. Once you have your application working, it might become obvious that you need more control over your architecture. Then you are at square one, writing a costume MDA that works for you. At least that's how it happened to me. It might sound like re inventing the wheel, but I feel there's a time and a place to REALLY tweak your code to make something great. I've been migrating my application to my own architecture, and while it still needs some tweaking and optimizing, the product is quite nice. In fact right now it does a couple of things that some experts believed that were impossible.

ArgoUML + EMF + Hibernate

[infra j]

I'm using a conglomeration of tools to develop a tiered application that uses Eclipse as the primary client.

The model is developed using ArgoUML. The output is a zipped XMI file that I convert to a EMF ecore model using the argo2ecore Eclipse plug-in. From there I generate the model and editor code using EMF. After that, I use the Elver 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

[ahodgkinson]

Please forgive the provocative subject line. :)

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:

• The application required many many hours to generate/compile.
• The resulting code was so large and complex that any meaningful analysis of it was virtually impossible.
• It was also impossible to try out quick changes or do any kind of rapid prototyping.
• The architecture and tools were so complex that new staff required long training periods in order to be productive,

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

[vrmlguy]

I wish you guys still in school or freshly graduated knew how often the rest of us roll our eyes every time we hear "my thesis" or "my prof". Your college education will be of marginal vaule to you as a programmer. Most of what you use will be from experience gained after you graduated. You won't necessarily be a good programmer just because you made good grades either.

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.