Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

In our last episode, The Reader and The UML Guy explored for inheritance lets you design common behavior and structure, and then describe specific variations of that behavior and structure. Then they showed how some Patterns (reusable solutions to common problems) involve inheritance. But at that moment, The UML Guy was arrested for committing a grievous offense against Process.

(Click picture for a larger image.)

Episode 8

If this episode is at all funny, that's because I started with a great inspiration.

Approximately 50% of the dialog in panel 7 came from the same place as the tribbles in that panel. And if you got that joke without a hint, you probably understand why I added the joke in panel 11 as well.

It is certainly a common process failure for a team to start designing or even writing code before they adequately understand the requirements. Remember our lesson from Steve McConnell: most project failures trace back to requirements failures. And we programmers share the blame for those requirements failures if we shortcut the analysis (i.e., the messy, difficult, talking-to-users part) by jumping too soon to code (i.e., the comfortable fun part). So it's a legitimate concern to raise: are we designing or coding too soon? (But "too soon" is a subject of some debate. Agile practitioners argue that expressing requirements as code is a very powerful and reliable way to refine and correct the requirements.)

So when people see me drawing Class Diagrams during requirements gathering and analysis, there's a tendency to say, "Too soon!" But it really is a programmer-centric (and perhaps egocentric) view to assume Classes == Code. Just because we programmers write object-oriented code by defining Classes doesn't mean we own the concept of Classes. Synonyms for Class include: category, classification, order, and set. I would add type and kind. Well, whatever our problem domain, it includes categories of things and information completely independent of those odd-looking bits of code that programmers call Classes. It's very helpful to build Class Diagrams of your problem domain -- sort of a visual glossary -- long before you get near code. If you keep these diagrams simple (omitting the sort of technical detail you would find in code-focused diagrams), then they should make sense to your customers, even without you teaching them UML. Let me repeat that, with emphasis: even without teaching them UML. This takes a leap of faith, so I understand if you're not ready to trust me on this yet; but I know from direct experience that customers can read simple, well-drawn diagrams that describe things from their problem domain. The hard part is the "well-drawn" part. That takes practice and experience (and maybe a little guidance from The UML Guy).

A common problem individuals and teams have with UML is they're blocked, often for multiple reasons:

  1. They're not sure where to start.
  2. They're not comfortable with a new language.
  3. They're not comfortable with a new UML tool.
  4. They're afraid that if they get the diagrams wrong, they'll build the wrong system, which would be bad.
  5. They're afraid that if they get the diagrams wrong, the UML Police or the Process Cops will lock them up.

Well, I hope that Ulterior Motive Lounge helps to answer 1 and 2, and to answer 3 at least in part. I'm trying to show ways you can put UML to use, and show you how easy it is to understand simple UML, and persuade you to start with the simple stuff as soon as possible.

But 4 is a tricky one. All I can do is advise: don't be afraid to be wrong. The point is not to draw the diagrams correctly; the point is to draw the diagrams, period, and then work with your team and your customers to make them correct. If you're paralyzed by a fear of drawing the wrong thing, you'll have nothing to correct.

And as for 5: as I indicated in this episode, there are no UML Police and no Process Cops. Oh, some workplaces have review processes to ensure you're following procedures; but if these are healthy review processes, they should encourage you to try and get better, not stymie you from trying at all. (If they're not healthy, I recommend you examine your options.)

So often the biggest thing stopping you from using UML on your projects is you. There is no Right Court you have to satisfy. Start drawing, and start communicating through your diagrams. After all, it's all about communication.

Posted on Saturday, November 15, 2008 4:53 PM Ulterior Motive Lounge | Back to top

Comments on this post: Ulterior Motive Lounge Episode 8: Right Court

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: