Why Do Analysis and Design?

When it comes down to it, the real point of software development is cutting code. Diagrams are, after all, just pretty pictures. No user is going to thank you for pretty pictures; what a user wants is software that executes.

So when you are considering using the UML, it is important to ask yourself why you are doing it and how it will help you when it comes down to writing the code. There's no proper empirical evidence to prove that these techniques are good or bad, but the following subsections discuss the reasons that I often come across for using them.

In this section, I talk a little about techniques that I'll discuss later. If you find these forward references confusing, just skip this section and come back to it later.

Communication

The fundamental reason to use the UML involves communication. I use the UML because it allows me to communicate certain concepts more clearly than the alternatives. Natural language is too imprecise and gets tangled when it comes to more complex concepts. Code is precise but too detailed. So I use the UML when I want a certain amount of precision but I don't want to get lost in details. That doesn't mean I avoid details; rather, I use the UML to highlight important details.

As a consultant, I often have to breeze into a complex project and look intelligent in a very short period of time. I find the UML invaluable for that because it helps me acquire an overall view of the system. A look at a class diagram can quickly tell me what kinds of abstractions are present in the system and where the questionable parts are that need further work. As I probe deeper, I want to see how classes collaborate, so I ask to see interaction diagrams that illustrate key behaviors in the system.

If this is useful to me as an outsider, it is just as useful to the regular project team. It's easy to lose sight of the forest for the trees on a large project. With a few choice diagrams in hand, you can find your way around the software much more easily.

To build a road map of a large system, use package diagrams (see Chapter 7) to show the major parts of a system and their interdependencies. For each package, you can then draw a class diagram. When you draw a class diagram in this context, take a specification perspective. It is very important to hide implementations with this kind of work. You should also draw interaction diagrams for the key interactions in the package.

Use patterns(see page 34) to describe the important ideas in the system that appear in multiple places. Patterns help you to explain why your design is the way it is. It is also useful to describe designs you have rejected and why you rejected them. I always end up forgetting that kind of decision.

When you follow these guidelines, keep the results brief. An important part of communication is in highlighting the important things to say. You don't have to show every feature of every class; you should instead show