UML Doesn't Know When to Stop

I was looking at a UML sequence diagram today (one that had an internal state diagram inside one of the objects), when it dawned on me precisely what bothers me about UML: There's no easy way of knowing when to stop.

I was looking at this diagram (beautifully rendered by the way) and I thought to myself: "What is the inherent advantage of putting this state notation in a document over into the source code?" On the surface, for the particular example, none, of course. It was a trivial sample meant to show how you would diagram such a thing in UML. Here's the question that goes unanswered though: When then, if not now?

When would it be appropriate for a designer to put that state diagram inside of his sequence diagram, or as a seperate diagram altogether or any of the other hojillion diagram types (which is another barrel of monkeys, but not central here) that UML provides? Well, none of the tutorials I've seen talk about it, none of the documents on UML talk about that.

The reason they don't, I think, is because it's called a "Language". And technical guys think about it like a language in that all of the paradigms should still apply. So they go and write the tutorials like its a language and show you all the doodads inside of it without explaining the use, assuming that you can parlay your expertise of how to program into writing UML.

This is a dirty fallacy that's hurting everyone. UML is a tool (they should probablly call it UMT). It has highly specific tasks that it is very good at. Namely fleshing out ideas in areas of a system where there is ambiguity, either between the customer and the designer, or the designer and the coding team. If you treat it like a language, something that gets used almost uniformly thoughout a project, then all of the different screws and bolts start looking like nails. If we treat it like a tool, like a unit testing framework or a version control system, then we can use it when it's appropriate and leave it alone when it's not. After all, you don't try to implement your network stack with Subversion.

Maybe this is a culture problem. I remember taking Software Design and Development and we spent a whoooole lot of time talking about requirements, understanding them, and expressing them in UML diagrams. But, again, there wasn't a lot of discussion about when enough is enough, issues of scale, issues of responsibility for different parts of design. Those things, the things that I would think are more important, less specific technical knowledge, just got glossed over.

That's all I'm going to write about that for now. I've got some more ideas brewing on this subject, but there's nothing worse than a long-winded blog entry.