Application Generation Using MDA in CF (Chip Temms CFDJ article)

First, Chip’s Article If you haven’t already, go read his article - it is both interesting and well written. Basically Chip has written a script that will pull the XMI generated by any popular UML editor and use it to generate templates and save them to files.

He uses the same basic approach as CF Template in terms of replacing angle brackets and pounds signs in his templates with other characters to allow his generator to differentiate generation time ColdFusion from runtime ColdFusion. I still think this is the easiest and most elegant approach for ColdFusion developers without deep XSLT experience to start generating their code.

The biggest issue with his approach is that currently it is a passive (one time) generator. You have to add a little more complexity to allow for the round trip generation that is required to make this more than a proof of concept. But by using the approach Doug Hughes does in Reactor of extending generated classes with custom classes this can be accomplished quite easily. Basically you regenerate the generated classes each time and then generate the custom classes but only save them if NOT FileExists(). For all I know Chip may be doing this already – you can only fit so much into 2500 words! Whatever your approach to application generation, the article is well worth reading.

If you like UML, you’ll love MDA The idea of MDA is that UML diagrams are good, that you shouldn’t repeat yourself (DRY) and that if your diagrams describe your code, they should be able to generate it as well. It is very popular within IBM and many companies are suggesting MDA as a credible approach for generating applications.

Not everyone likes MDA Scott Ambler raises a number of great issues that MDA has to address. For me the root question is how suitable are UML diagrams for fully describing the requirements of you code base. While a lot of work has been done in this area I find visual models an imperfect metaphor for fully describing metadata.

Limited Reuse The biggest problem I have personally with using MDA is that I’m developing a software product line designed to quickly generate a large number of applications with documented variability. Because of that I need automated tools for retrieving packages of metadata based on business rules so a user can just go through a web based wizard and have a pretty good cut of their metadata automatically pulled from a databased metabase. MDA has very little to say to this approach as there is no easy way to write a script to pull together elements from hundreds of small UML diagrams to completely automatically generate a new diagram (no doubt you could write a solution that would generate the XMI programmatically, but I just don’t need the diagrams that badly!).

Use Cases The choice of MDA over (say) a databased metabase is partially driven by preferences, but MDA lends itself to a particular set of use cases (IMO).

• If you have to draw the diagrams anyway, give MDA a shot.
• If you are working on a smaller number of larger projects, MDA might be a good fit
• If you are working on a larger number of smaller projects, the time taken to draw the diagrams and the lack of systematic reusability of subsets of a diagram (they’re working on it, but there isn’t a great answer to this problem yet) means that a databased approach might be a better fit.