hide all comments


13 reasons for UML's descent into darkness

May 20, 2008 01:16:30 +0300 (EEST)

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.


Agree on DSLs are the way to go versus general purpose UML

[Sean Walsh] May 28, 2008 17:53:25 +0300 (EEST)

Steven - Agree completely that UML is going in the wrong direction.  You can never describe everything in a modeling language and Domain Specific Models and Languages are more appropriate.  

Here at Skyway Software we have produced a Domain Specific Language for producing Rich Internet Applications and Web Services based in Eclipse using EMF and GMF. 

If you have a chance - and interest - check us out.  Given your expertise I would be interested in your feedback.   I am reading your book now. 

Sean Walsh President/CEO Skyway Software     

Shlaer-Mellor Comments

[Sean Kavanagh] September 02, 2008 02:07:56 +0300 (EEST)

For a start, its Shlaer-Mellor not Schlaer-Mellor!

Next, why did it take 2 weeks to generate code from the Shlaer-Mellor models? If you are using a model compiler (even if its being updated regularly) then it should run in minutes not weeks! If you have to manually generate parts of the code then use a better model compiler.

Last, I would describe Executable UML as a UML profile for Shlaer-Mellor. Executable UML is closer to Shlaer-Mellor than it is to full UML. The only thing added to Executable UML that isn't in Shlaer-Mellor already is Use Case Diagrams.

Check out the Shlaer-Mellor OOA/RD Portal for more information on Shlaer-Mellor.



[Steven Kelly] September 08, 2008 17:13:49 +0300 (EEST)

Sean: it is of course Shlaer-Mellor, as you say: I just copied the mistake in the quote. Note that the quote is from a comment on the original "13 reasons" article, not something that I wrote. Thus your guess is as good as mine as to why their generation took 2 weeks. Given that there are cases today where poor tools mean generation can take nearly a day, I suppose it's just about possible that it really took that long. More likely is that there were manual steps involved, e.g. in what the commenter called "processing the models".