Slashdot Mirror
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?"
The first step to recovery is admitting you have a problem...
This space intentionally left blank.
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!
The implementation of said tool was unfortunately fairly mediocre, and I finally gave up on trying anything non-trivial using ECO, after the third time that the source code and model became 'out of synch' and my 1000's of lines of generated code would not compile.
If I had the time, I would like to try an updated version of ECO, or perhaps another alternative, but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.
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
---- It won't be as bad as you fear or as good as you hope, but it will take twice as long as you plan.
I have had (am having) the displeasure of being part of a pilot project for an in-house MDA utility based on Rose and Eclipse. In a nutshell: it sucks.
There are two general problems that I've encountered:
The granularity problem is that you have to spend a lot of time specifying fine-grained details in the model that are more easily expressed in code. Examples are: method calls, persistence, behavior parameters, etc. Often these details don't even show up on the screen. This makes them almost useless for someone trying to understand what is going on. This is a big problem and not going away.
The tool problem is that if the tools don't help you work effectively, the whole process fails. Using Rose is like sticking pins under your toenails and kicking a wall. Rose seems to get in your way on purpose with a hideous interface. Sure, this problem is tool-related, but its impact is huge. It can turn what should be simple into a marathon of pain.
So far, we've spent weeks on a toy application that should have taken two days. Perhaps these in-house tools will evolve to the point of usability, but somehow I doubt it.
Ian