Best practices
UML class diagrams are easy to create and understand, or at least they should be. Unfortunately, many diagrams fall victim to the same forces I covered in Chapter 1. They can be a Golden Hammer, and they can grow uncontrollably to become too complicated to be useful. Software succumbs to these forces slowly over time. Sometimes, it takes years to make a repository full of spaghetti. Diagrams tend to fall apart over the space of days. UML is a plan. If your plan is a messy disaster, how can your software be anything else?
To curb the tide of these destructive forces, I’m going to give you four hints to keep your diagrams useful, easy to read, and hopefully, keep you out of analysis paralysis.
Less is more – don’t try to put everything in one big diagram
UML diagrams are meant to be used by the development team, but they are often shared with other project stakeholders. If you go to a meeting with a diagram that looks like the guidance system...