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.

After a shameless plug for my UML Applied Class, I tried to give some answers to the question: "I want to learn UML, where do I start?" I also demonstrated how I like to give multiple answers to seemingly simple questions. I want to add yet more answers to that question.

I discussed how a sequence diagram lets you explore and document how objects call other objects to carry out some requirement. A related diagram is a communication diagram, which shows which objects are allowed to communicate with and call which other objects. The lines between objects indicate allowed communications paths, and the arrows that follow those paths indicate messages (calls) from object to object during a specific scenario. A communications diagram is a useful way to design and enforce architectural constraints: code can only call objects and methods allowed by the architecture.

Stable Communication Diagram

It surprises some people, but one place I seldom start modeling is with class diagrams. Why is this a surprise? There are two reasons that many people equate UML with class modeling:

  1. UML began as a notation for analyzing, designing, and developing object-oriented software. Objects and software equals classes, in common thinking. OO programmers are especially prone to thinking that the project is all about the classes they build (forgetting all the requirements and communication that lead up to those classes).

  2. Many otherwise good UML tools have started the user out directly in class modeling mode.

Pointless Class Diagram

Well, despite those reasons, I think class modeling is way over-emphasized in many UML tools and many UML books. It's not that class diagrams are unimportant, but they're only a part of the full range of communications tools that make up the Unified Modeling Language.

In fact, I think this emphasis on class modeling by tool vendors has actually hindered many teams in adopting UML. Even a good UML tool has a significant learning curve; and when a programmer sits down with a complex tool and spends an hour drawing that first simple class diagram and then looks at the result, what I inevitably hear is, "I could've written the code faster than that!"

And you know what? They're right. Even I, an experienced UML tool user, could probably write that code faster than I could draw that diagram. (I'm no slouch as a programmer, after all.) In fact, if all I needed was a diagram that simple, I would probably write the code, and then use a UML tool to reverse engineer the diagram.

But frankly, a diagram that simple is a waste of everyone's time. It's not just easier to write the code; it's easier to read the code. There's more rich detail avalable in the code than in the diagram. Remember: text tells you things pictures don't, and pictures tell you things text doesn't. They're complementary, and you need some amount of both.

Where class diagrams shine is when you use them to show relationships between classes, especially as the number of classes grows. It may be easier to read a class file than it is to read a diagram with one class; but it's all but impossible to read nine class files simultaneously and grok how they interrelate. It's easy to draw and read a diagram of nine related classes.

While I'll seldom start a project with class modeling, usually early on I'll start drawing a class diagram as a sort of "visual glossary" of the problem domain. I'll put down classes that represent things in the domain: information things, like schedules and assignments and invoices; but also physical things, like tools and merchandise and locations. These are not classes that represent code, necessarily, which again is something of a surprise to us code-focused programmers. Rather, they are simply categories of things, things which everyone on the team should understand if we want to build a successful system.

As I add classes, I'll then add attributes that describe them, and relationships between them, and other details that reflect what I've learned about the domain. Then I'll share the diagram with the team and the customers, revising it until we all agree that it's right (more or less) and complete (for now).

Stable Class Diagram

Earlier, I discussed modeling to communicate vs. modeling to understand. Another reason I might start a modeling effort with class diagrams is if I were trying to understand an existing system, especially a large existing object-oriented system. Most UML tools will reverse engineer class models and even class diagrams from existing code. Now the diagrams they create will likely be an unreadable mess. Real code is often like that, especially if the real code developed without a strict design. But you're not trying to get them right; you're just trying to get started. Once the tool has done the mechanical work of modeling the classes, read the code and compare to the classes and start building your own class diagrams. As you think about how to make these diagrams make sense, you'll necessarily think about the code from a broader perspective. You may also find that these reverse-engineered classes and manual class diagrams help you in building sequence diagrams, as I discussed yesterday. Experience tells me that reverse engineering a design from code is a highly effective way to learn a new code base quickly and effectively.

Although class diagrams are my default tool for modeling domain concepts and a domain glossary, sometimes an object diagram makes more sense. In object-oriented analysis, a class represents a category of things, while an object represents one thing from a given category. Often, the distrinction between class and object is unimportant during analysis and design. (The decision is vitally important during programming; but we expect programmers to keep that straight -- sometimes with a little help from the compiler.) But sometimes we need to discuss the scenarios where the particular objects matter more than the general categories. For instance, in the class diagram above, we see that a Stall may have as many as two Horses assigned to it, but it doesn't explain why there might be two Horses in one Stall. In this object diagram, though, we see an example: a Mare and her Foal share a Stall.

Stable Object Diagram

There! In two essays, I've answered the question "Where Do I Start?" by giving examples of how I start modeling on different projects. That should spark some ideas for your project, I hope. Of course, if you're still looking for inspiration and guidance, I have a suggestion for where you can learn more..

Posted on Saturday, November 15, 2008 3:21 PM UML | Back to top

Comments on this post: "Where Do I Start?" Part II

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

Copyright © Martin L. Shoemaker | Powered by: