Warning    Do not follow the five steps we’ve just outlined (but you knew that). They lead to splitting up attributes and operations. Big mistake.

 Tip    Make your classes whole by putting the attributes and operations that need each other together in one class.

Figure 21-1 shows classes with attributes and classes with operations—separately (and confusingly). The Vehicle class works with the Truck class. The Tools class is similar to the ToolKit class. The Person class is another name for the Employee class. Figure 21-2 shows a better model, with the attributes and operations put together.

Figure 21-1: Example of a split-classes mistake.

Figure 21-2: Example of classes made whole.

Using Too Few or Too Many Diagram Types

We’ve observed some developers use just one diagram for every situation. They forget that other UML diagrams are there to help them understand, communicate, analyze, design, and implement. They build class diagrams to capture classes (and their static relationships), but also try to represent object interactions, data flows, and system decompositions with those same class diagrams. Unfortunately, the class diagram was never meant to capture that other stuff very well—but use-case, sequence, state, and activity diagrams seem foreign to these experts.

Some developers produce only class diagrams because that’s what translates most easily into object-oriented programming code. Alas, the code they produce is not dynamic enough (because the developer didn’t consider state diagrams) or even what the user wants (because the developer never thought about the use cases for the application).

Other developers seem compelled to use every single UML diagram whether they need to or not. Some people pride themselves on their knowledge of UML notation. They show off their abilities by using every diagram on every project. You waste valuable time trying to decipher these extra diagrams without making any progress toward completing the project.

 Tip    Every UML diagram has a purpose and value, but not every diagram is necessary on every project. Your project is unique; some—but not all—UML diagrams will help you get the job done. If your project involves maintaining an existing system (for example), then some class diagrams, a couple of sequence diagrams, and a deployment diagram may be all you need. However, if you build real-time embedded systems, you need state diagrams along with sequence diagrams (because you want the team to understand timing issues), and some class diagrams. Every project is different.

Check out Chapter 24, where we list ten useful diagrams to get you started. Our aim here is to avoid getting stuck on just one diagram—but also to spare you the confusion of trying to use all the possible UML diagrams.