Few people would advise you to slap a UML modeling tool on top of XDoclet (assuming some sort of slick integration), and then sink your time into making XDoclet generate all of your code, yet that's precisely what the vendors seem to want, and that time investment's justified because, heck, you've already invested so much money in the tool. At some point, you get to the level where the code is so custom that it's not going to be reused, and MDA tools become a golden hammer. Additionally, you can end up with so many options of how to generate the same code, you lose the simplicity the tool is supposed to provide. This is apparently the vendor's opinion of how it should work. The other option is to use it merely as an expensive version of XDoclet that happens to have UML integration. In this case, it still gets ugly, because they want you to bind the attributes in your UML model to database tables and columns. There's enough debate about enshrining DB mappings in your value objects for code generation purposes, but it seems blatantly messy to do this in your UML tool. So apparently the options are either monkeying with the tool, or using it as an expensive code generator that violates abstraction. Where do I sign up? Of course the whole thing comes from the pipe-dream that we can turn software development into a turn-key, assembly line process, the same dream that's been selling CASE and RUP tools for decades. - Rob Kischuk...
Previous Topic
