For an unusually calm and reasoned assessment of the demise of UML, read 13 reasons for UML's descent into darkness -- and the comments. I don't suppose there's much there that's earth-shatteringly new for most of us but it's refreshing to see accurate criticism of the problems many find with UML, without falling into the trap of tarring all graphical modeling or code generation with the same brush.

Trying to capture everything is an impossible task - even at 800 pages, UML covers only a small part of the complexity of software engineering needs. It is too big but still too generic and abstract.

That for me is the reason why UML couldn't succeed - many of the others are reasons why it fell from grace, and they might have been avoided.

Juha-Pekka tells in the Code Generation 2007 panel on UML vs. Domain-Specific Languages (mp3) how he was happy to implement the UML 0.8 specification in the mid-90's -- there were big gaps, some things were inconsistent, but it was manageable. A few versions later the attempt to build a universal language for all discrete software systems was already revealed as an impossible dream. The choices were either a language that was so low-level it could express everything, but too verbosely and with no visible understanding of the actual system; or a language that was so high-level that a diagram could mean widely different things to different people; or an unwieldy and unintegrable collection of languages for looking at a system from many different viewpoints. Or, as actually happened, all three.

One of the comments was particularly interesting, given my earlier entry on code generation performance:

I worked on a project that decided to generate all of its code from diagrams (not UML but Schlaer-Mellor) and it took two weeks to get the models processed and the code compiled. Given that the code generator was being tweaked often, this slow turn-around really impacted the project.

If your code generation takes two weeks, you might be glad to see it happen 30 times faster!

By the way, the Schlaer-Mellor mentioned there is the ancestor of "executable UML", whose promoters include Allan Kennedy, a panellist on the above panel. Allan's view was refreshingly simple, given his commercial background: if you can use domain-specific languages for any of your development, you should; for the bits left over, (x)UML can be useful. I heartily agree -- even the Digital Watch example in MetaEdit+, surely the most demonstrated example of DSM :-), includes a UML Class Diagram to document the little hand-written framework of Java code that runs below the generated code.