The Number One Rule of UML Tools

The Number One Rule of UML Tools: They all have quirks. Every single one of them. They’ll all drive you nuts, and frustrate you, and disappoint you. So a little frustration and disappointment shouldn’t make you give up on a good tool. You just gotta compare it to other tools, see if it does what you need, and then learn to cope with/circumvent its quirks.

(And you whiteboard guys who say, “See? Quirks! You should just give up and use a whiteboard! It has no quirks!”… It has no memory and no consistency, and those are just the start of its quirks. I’m not saying you picked “the wrong tool”. I’m saying you have compared it to other tools, decided it does what you need, and learned to cope with/circumvent its quirks. Don’t think it doesn’t have them, too.)

Here I just got done praising Enterprise Architect from Sparx Systems; and today I run smack dab into what I find to be a really annoying quirk. It will not allow me to show a stereotype on an actor. Oh, I can show the stereotype if I use the class notation, but not if I use the stick figure notation. Somehow deep in their engine, I think the stick figure is highjacking the stereotype display mechanism. (After all, actors were originally added to UML as a stereotype of classes.)

Grrr…

Where’d You Get Those Pretty Pictures, UML Guy?

They are pretty, aren’t they?

Layers

MissionPlanner

MissionComponents

I draw many of my production diagrams these days with Enterprise Architect from Sparx Systems. I also like Visual Studio Team System, with its tight integration with process tools. I find that to be top-notch; but Enterprise Architect is my second-favorite UML tool. It’s incredibly powerful and full-featured, especially at the low price of $199 a seat!

EA is the primary UML tool I use in my consulting work, and I often persuade my clients to purchase it as well. It’s also the tool I use when I given UML talks. And although I teach my one-day UML class with just pen and paper to keep things simple, I teach the students to use EA in my longer classes. I have them install the trial version; but by the end of the week, they usually decide to buy it. It’s that good, and I show them how to get productive use of it quickly.

Absolutely! (Not!)

There are only two words you should never believe: “only” and “never”.

Oh, and “always”. And “every”, “each”, “none”…Yeah, that’s more than two. You didn’t believe “only”, did you? Never do that!

Only and Always

Whenever the stakeholders tell you an absolute, don’t believe them. Challenge them on it. Make them prove it. Make them defend it. Make them put it in writing.

Or if it’s not the right time to be challenging them, make a note of it; and then later, come back and challenge them and make them defend it and prove it and put it in writing.

To programmers, absolutes like these are mathematical statements:

  • Only == 1 (or 2, or whatever follows “Only”)
  • Never == 0
  • Always == 1..*
  • Every == 1..*
  • Each == 1..*
  • None == 0

And so on. But to stakeholders, as my buddy Curtis Gray says, absolutes are figures of speech, meaning “mostly” or “seldom” or “as far as I can recall”.

So developers need to nail down these assumptions. Probe and question to determine whether these are really absolutes, or only general rules. Assuming that they’re absolutes can be a major cause of unforeseen bugs. “But they told us they would never do that!” Well, they did it. The code’s broken. Everyone’s unhappy. All because you weren’t just a little more persistent during the requirements analysis stage.

In terms of UML, this commonly comes into play with multiplicity, the range of possible participants in a relationship. This can be stated as a number, a set of numbers, a range of numbers, or any combination of the above; but most commonly, you’ll see:

  • 0..1
  • 1
  • *
  • 0..*
  • 1..*

In UML-speak, * stands for what mathematicians and others have commonly called n: an unspecified quantity. So if a publisher, for example, tells me that a book has 1 or more chapters and some number of authors, each of whom may be an author of multiple books, I’ll draw this picture:

Book (Version 1)

But I won’t stop there. I’ll use this diagram to start asking questions, and responding to answers:

  • Does a book ever have zero authors? No. Even if it’s just a compendium, we list the compiler as an author. OK, then let’s be explicit: it’s 1..* authors, because there’s never 0.
  • Does an author ever have zero books? Yes, because these are our published books. Some of the authors we work with, haven’t published yet. OK, then let’s be explicit: it’s 0..* books, because there’s a chance of 0.
  • Can a chapter ever be in more than 1 book? Wellllll… Yes, and no. Sometimes we make a combined volume out of two previous volumes, and the chapter then appears twice. So do you consider that the same chapter in two books, or two identical chapters? Oh, no, they’re not identical. We usually do some clean-up and additions on these combined volumes, to entice people who have the originals. Ah, if they’re not even identical, then they’re definitely two chapters, not one chapter in two books? Yep. OK, let’s leave that at 1.
  • Can a book ever have 0 chapters? No, of course not. Are you sure? What about a book without any formal chapter structure? We still organize that as a single chapter. What about a book where you haven’t received any chapters from the authors yet? Oh, wait a minute, you said these were only published books. That’s right. OK, then we’ll leave this at 1..*.

Then I would redraw the picture just slightly to reflect what I learned:

Book2

I would use the diagram both to capture information and to promote further conversation. Never just draw what you “know”. And never accept an absolute at face value!