I took a class at work called, "Real-Time Software Design with UML 2.0." The instructor seemed to think that it was destined to be the Next Big Language. I have my doubts.
When I design with code, I can type it very quickly and even somewhat sloppily into a code editor. The editor will then take care of formatting it all nicely, indenting, spacing, presenting with an nice font, colorizing the various code constructs, and so forth. I just have to get the ideas expressed and the tool takes care of most of the formatting for me. Even more, it's saved in a simple text format that is universal. Any text editor on any operating system will understand it. Once I've written the code, I then have a compiler and/or linter that will tell me if I've left off any key constructs, made any syntax mistakes, or any of a number of common logical errors. Basically, with the good tool support that is out there, I can write code as fast or faster than I can dream it up.
With UML, from what I can gather, it seems like you get none of that. You either draw on paper or a whiteboard which obviously makes the formatting a manual process. At least a whiteboard is easier to erase and redraw something than paper, but I'm still very slow at drawing stuff out, and I find myself either spending too much time making sure my boxes and lines are neat and nice, or I end up with an incredibly messy drawing. With Visio or other diagramming tools, you get nice straight lines, but you still get to worry about the niggly things like where to place your bubbles and boxes, how to arrange your arrows. Should it flow from left to right or top to bottom or just have a spaghetti mess of boxes and arrows all over the place? Not to mention there is nothing to verify that you are using proper UML syntax, and that you haven't left anything basic to a coherent design out. I find that having to think about all these details distracts me from the actual design work. Then, once you've painstakingly drawn it all out in one tool, you are stuck with that tool. Want to share your design with someone else? Sure, you can print it (did you draw it so that it fits nicely on letter size sheets of paper?), or export it to a PDF, but if someone else wants to edit the diagrams, they need to use the same tool you did. Let's not even mention collaborative design editing and revision control.
Despite all this, Glennan Carnie from Feabhas told a very convincing story this week. I came into this course very skeptical, and for the most part he had an answer for all of my concerns. And pretty good answers too. In a short, intense, week-long course it's hard to evaluate whether everything he says is really practical and useful in the real world, but the way he tells it I'm at a point where I'd be willing to give it a try...I mean, have a go at it (did I mention Glen is British?).
This course was not at all what I expected. Glennan freely pointed out all the flaws, idiosyncrasies, and shortcomings of the UML standard, other UML proponents, and even his own lecture slides. He made sure to point out more than once that UML is no silver bullet and that design is still difficult to get right. Instead of presenting UML in glowing worshipful tones, he presented it as a useful tool that can help you systematically design an entire object oriented software system. A tool which can be used to design first at a high level, ignoring implementation details, and then which can be used to refine the design down in a number of steps all the way to the nitty-gritty details of deciding how big a message queue is needed to communicate between two threads, and what the format of the message should be. It's very impressive.
Still, I wonder how it would work to go from an ideal solution to the heavily constrained designs that are needed for my work. Low-level ASIC driver stuff would be an interesting case-study. Too bad we didn't have more time with him to get into some of our own stuff like that.