UML and UML tools seem to always be getting a lot ofUML LOGO bad press. This might be the result of developers not utilizing them for their intended purposes. As they were originally imagined, UML diagrams should only be used when designing code. They should not be used when sitting down to detangle a pile of incomprehensible logic or making sense of an alien design pattern; and especially not for generating all your project’s code. Experienced designers may already have come to this realization but for others some explanation is in order.

There are a lot of options when it comes to UML diagrams. Other than the ever present Class Diagram there are: Structure Diagrams (class, deployment, package, etc), Behavior Diagrams (activity, usecase, etc), and Interaction Diagrams (communication, sequence, etc). They are all used to meet a very specific need; communicating design requirements from product management to the development team. This is very important when working with most software processes since they require all functionality to be determined during the design phase. Five months later when features are added/removed and code is re-factored, maintaining the UML diagrams becomes tedious and the diagrams are no longer helpful.

The strict guidelines governing UML usage are great for preventing ambiguity during the design process but immediately become a nuisance when a new team member needs to understand how a new feature relates to the existing codebase. Software Architects can take advantage of the power of the UML to create detailed specifications that would be difficult to create with other tools. However, much of the information in UML diagrams is represented by unintuitive, non-graphical symbols. For example, the 1-* notation in class diagrams conveys that a one to many relationship exists but this may not be immediately obvious from a cursory glance at the diagram. In fact, it is often difficult to get a quick overview of a feature or concept since most aspects are broken into separate UML diagrams. Someone new to a large project would have to pour over piles of diagrams to get a clear idea of the task at hand.

Some UML tools are marketed with claims that they can provide unlimited diagramming abilities and solve all your programming problems; allowing you to understand existing code and even generate code. However they often fall short when it comes to keeping diagrams concise or modifying existing diagrams. These UML tools are not flexible or adaptable, which makes understanding and code maintenance difficult, but some new tools may help with these challenges. Dynamic modeling tools will help users easily generate, modify, share, and save different types of UML diagrams. Automatically generated, interactive varieties of diagrams may soon become the norm, allowing users to understand their code faster and more intuitively.

As these tools become more intelligent and continue to stretch the boundaries of UML standards we can expect to see a rise in diagrams being used at all stages of development. But for now keep UML where it belongs, in the hands of experienced developers during the design process.

I am writing new articles once every 2-3 months. Interested in getting notified? Sign up here.