What the UML Can’t Do
Aug 15th, 2005 by phil
The UML is a very effective notation for object oriented software designs. However, as with many useful tools, there seems to be some misunderstanding about what the UML can and cannot do. This misunderstanding can lead to organizations failing to meet their goals because they are not using their tools properly. This is unfortunate since the tools may ultimately receive the blame. In particular, it is important to understand what a tool cannot do as well as what it can. In that spirit, here are three things that the UML cannot do.
The UML Can’t Solve Problems
It is not uncommon to see companies who are looking for Java developers to ask for UML experience. In many cases this is appropriate as the UML is well suited for describing OO designs. Most developers these days should be able to at least read UML class diagrams. The problem is that some companies confuse the solution (OO design) with the method (UML).
Consider the following requirement from a job ad for a Java architect: “Proficient in the application of UML to real world problems.” You cannot really apply the UML to real world problems since the UML is not a solution but a tool for describing solutions. What the ad should have asked for is proficiency in using the UML to describe real world problems and their solutions.
The confusion between the result and the method of achieving the result is also apparent with software development methodologies. Many organizations take on the task of “implementing the RUP” without stopping to think about what benefits this will bring for them. Their business goal becomes “implement process” when it should be “reduce cost” or “reduce time to market.” In the case of the UML, organizations are saying they want UML when what they really want is the ability to design OO solutions and to be able to communicate those solutions to the rest of the team.
The UML Can’t Make Good Designers
Knowing UML does not make someone a good OO designer. To use an analogy, the idea that knowing the UML makes one a good designer is a bit like suggesting that knowing the English language makes one a good playwright. While a strong knowledge of the English language is required if you are going to write plays in English, there is also a creative component and other talents that are necessary. Of course, one need not even know English if they are going to write plays in another language, but the other skills are still necessary. The same can be said of OO application design. While knowledge of the UML can be beneficial, and may even be required depending on the circumstances, it is not even close to being enough.
Yet it seems that many organizations are relying on UML knowledge to cover gaps in overall design experience. There is a hope that the use of the UML will compensate for a lack of design skills. While learning the UML “vocabulary” for expressing system design may help an architect to improve their overall design skills, those skills must already exist.
The UML Can’t Write Your Code For You
Code generation tools notwithstanding, you cannot build an application with pictures. Code generation may be helpful as a time saver, depending on the circumstances, but the core logic still needs to be written by a developer. What makes the UML so useful is that it is a very high level notation, meaning that it can easily represent very abstract concepts. That same feature makes it very difficult to generate more than class skeletons from UML diagrams. While the UML is useful for design and documentation, it still requires actual code to implement the design.
Conclusion
The UML is a very useful and powerful tool. Like any other tool different people judge its usefulness differently, but most can agree that there is a place in every architect’s toolbox for the UML. However, the UML can be misused, and the results are not likely to be pleasing. Therefor, it is in everyone’s best interest, from developers to managers, to understand what the UML can and cannot do for them.
