Is UML Really Dead, Or Only Cataleptic?

danielstoner writes "Recently UML was pronounced dead as a tool for all programming needs by an article posted on Little Tutorials: 13 reasons for UML's descent into darkness. The author suggests UML was killed by, among other causes, greed, heavy process, and design-by-committee. Is UML really a fading technology? Is it useful beyond a whiteboard notation for designers? Is there any value in code generation?"

Re:Just le

[antek9]

Dang, I just bought a book on UML 2. I should have read the writing on the wall, though: it was heavily discounted...

Re:UML great for design

[GileadGreene]

We often find the "loopholes" in our methodology by drawing it out first. We plug those glaring holes. Then start coding.

Pretty much anything you do to think through your design before committing to code will help to uncover inconsistencies and holes. It's just a question of what medium you use as your motivating tool to spur the "design analysis". Diagramming in UML is one approach. For the TDD fetishists, writing a bunch of tests tends to help uncover facets of the design that hadn't previously considered (subtle aspects of particular use cases, corner cases that the design needs to handle, etc.). A large part of the value to be found in modeling the design in a precise language like Z, Alloy, or CSP is the thought about the design that's required in order to construct a model (the other part of the value being the model-checking or other automated analysis that helps you to find holes that aren't quite so "glaring"). Almost any kind of "design analysis" (read "thinking about how the design operates and whether it will work as intended") will help. The more interesting question is "which approaches to analysis give me the most bang for the buck?"

We use it...

[fitten]

We use it fairly often to express things such as cardinalities in problems and the like, but we pretty much limit it to diagramming so we can better understand how some things interact. I've never used it to automagically generate code.

Re:Please people, please- it's *The* UML

[julesh]

//not a troll, just a person with a pet peeve ///hopefully there's a difference.

Of course there's a difference. If the moderators agree with you, the post is informative. If they disagree, its a troll.

Re:pieces can be usefull

[CastrTroy]

UML is a nice concept. You draw little pictures to make it easier to understand the architecture and behaviour of your system. In university, we had a term for professors who were really pendantic about UML. UML Nazis. Really UML should just be a set of loose rules and semi conventions so that people can get the gist of what your program does. The UML Nazis try to turn it into more of a programming language, where everything is ultra specific, and where using a filled in arrowhead instead of an empty one is punishable by death. Which is the real reason UML died. Too many symbols that look almost, but not quite exactly the same which are supposed to represent different concepts.

Re:Just le - Remember Jackson & Ward/Mellor &a

[ahodgkinson]

> Anyone remember Jackson Structured Programming?

..or flow charts and those cool green templates from IBM for drawing them.

This was all part of the set of diagraming methodologies for structured programming. They are all gone now, which is unfortunate, and they have lessons for today's object oriented world. Which is to say that we're now re-living the same evolution for object oriented systems. The results will probably be the same. System generation from diagrams (now called MDA) probably isn't worth it.

For the uninitiated, Jackson (structure charts) and Ward & Mellow (real-time system modelling) were diagramming methodologies to help design systems written in structured languages (assembly, COBOL, FORTRAN, C, etc.). There were lots of others, but I can't remember all the names.

It all culminated in CASE (Computer Aided Software Engineering). Which, in it's extreme form, called 'strong case', was trying to be a CAD system for replacing programming. Like today's UML the intent was to generate code directly from the diagrams. It didn't work too well on real projects and gradually faded away.

There was also a 'weak case' faction, that wanted to use the diagrams merely to do early design and document the resulting system. The intent was to have a lingua-franca in which you could quickly express design concepts using a simple standardized notation. This is where ULM started. It not a bad idea, as long as you keep the diagramming system fairly simple, which means it won't be rich enough to generate code from.

The 'strong case' equivalent in the object world is MDA (Model Driven Architecture), which from what I've seen and read about is doomed to failure. I believe that the diagram to code gap is just too large and the programming detail required to actually implement a system is too difficult to capture in simple diagrams (which is what you want in the design stage).

Have a look at Pros and Cons of MDA Code Generators? [slashdot.org] and my experience on a MDA project [slashdot.org].

I suspect frameworks, like Struts and the like, are a much better approach.