Just the other day I was sent a link to a recent survey conducted by Dwayne Anius and Brian Dobing on the topic “Programmer’s views on the usefulness of UML diagrams”; a topic I am acutely interested in. In the survey approximately 100 developers responded providing information on their development experience and use of different UML diagrams. (you can add to this number by participating here) With millions of developers worldwide and only 100 represented in this survey it is difficult to get a general picture of the usefulness of UML but it is apparent from a cursory glance at the stats that Class Diagrams are the most widely utilized. This fits with the general consensus that class and sequence diagrams are the most preferred UML diagrams.
This isn’t too surprising since Class Diagrams can be created quickly with or without software tools and easily adapted to many scenarios. Many UML diagrams such as Deployment diagrams are often better suited to the design phase of development while Class diagrams can be adapted to be used effectively with code maintenance and understanding. Since pretty much every programmer has done some sort of maintenance and significantly fewer have participated in designing the nuts and bolts of a complex project it only makes sense that more are familiar with Class Diagrams.
But are Class Diagrams the last word in Diagramming? Yes, they are very versatile and do not require special tools to generate. But perhaps other UML diagrams are better at visualizing other important portions of a software product and designers ignore them because they aren’t familiar with their specification.
It is important to realize that the UML diagrams can be made with no more than a pen and paper. In todays world IDEs, diagramming, and project management software are ubiquitous and it only makes sense to utilize them to their full potential. Perhaps we need to rely more and more on new diagram types that go above and beyond the scope of the UML in order to allow programmers to effectively design, communicate, and understand large software projects.
</td> </tr> </tbody> </table>