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.

---