At university most of us, future Software Engineers, are introduced to the fundamentals of the Unified Modeling Language (UML), myself I took at least a couple of classes that covered three or four types of UML diagrams. However, in an interview when I am asked to quickly draw the design of a project or other system, I get confused: should I try it in UML or is any “sketch” acceptable? Is it ok if I make mistakes during my attempt at UML? This confusion takes over, because UML is a relatively new standard for software design as it was accepted in 2000 and has been a very controversial topic in large scale development since. Hence, you never know what others think about it. The main reasons against UML use are deemed to be the large variety of diagram types, the use of it for different purposes and that not everyone is familiar with it. Myself, I strongly believe that every software engineer, who one day hopes to successfully contribute to the design of large scale projects should be familiar with the “basics”of it in order to communicate ideas freely.
The “three types” of UML
In large scale development it is important to be able to communicate the system design to all team members. Martin Fowler describes three types of UML that serve different purposes:
UML as “sketch”. This type of sketching allows to draw diagrams only for the processes of interest at time of discussion in order to clarify the code to be written or an already implemented system. 
UML as “blue print”. This type is to represent the whole system design with great detail and tools are mostly used to produce them. 
UML as “programming language”. This type with very detailed UML diagrams is to compile the diagrams drawn into executable code. 
It is evident that all the types are useful in different contexts, to my mind, every developer that wants to collaborate in a team in order to contribute to a project would benefit from knowing how to use UML as “sketch”. This is because, it’s main purpose is to convey ideas and share understanding rather than guarantee completeness of the design in mind, which may be documented in other ways. The other two types of UML described are admittedly not as straight forward and need a lot more practice and detailed knowledge of UML in order to produce good results. These advanced skills should come with time and depending on what depending on the documentation and coding conventions within the company.
Know the basics and navigate
The idea of using UML diagrams for “sketching” purposes in order to clarify the main components of the design raises the questions: why is the formality of using UML needed? Wouldn’t simple box and line diagrams be enough? . From the first glimpse they seem to suffice, however using UML should be much simpler. This is because in order to draw a simple box and line diagram, one would have to take time to invent their own notation on the spot and explain it to others. Also this notation would have to be explained in writing if the “sketch” ends up being used in documentation. However, when using UML there is a high possibility that other software developers have some knowledge of it or at least would be able to read most of it and ask for some clarification. Moreover, as UML is a standard notation that can be easily looked up. Of course, no one is expected to know the 14 different diagram types in UML and their notations. Surveys have shown that engineers are familiar with about only 20% of UML which is in their sphere of interest and suffices for communication. During my summer internship at a larger company, at first I had to familiarize myself with the system architecture, before diving into the formalities of the code and the JavaDocs. The documentation that I read to do that contained just some very simple UML diagrams to illustrate the how different components come together and what responsibilities they have. Being a newcomer I could “google” all the notation that I was not familiar with, without disturbing my colleagues for explanation. Hence, speaking from experience, trying to put together sketch diagrams using UML notation saves time and facilitates the overall understanding.
Forgetting notation & making up as you go along
Easily forgetting the notation is a common problem, when Joshua Bloch, the author of “Effective Java”, was asked about the use of UML, he said: “I think it’s nice to be able to make diagrams that other people can understand. But honestly I can’t even remember which components are supposed to be round or square.” When notation is forgotten in a middle of a discussion, one automatically switches to some made-up intuitive notation. Making adjustments to UML is acceptable during interactive discussion as the importance lies in conveying the message, but obviously cannot be included in documentation as others may not understand. Hence, the diagrams have to be brushed up with the conventional notation for inclusion in more formal documentation. Once, again it can be argued that not everybody is familiar with the notation, hence it may not matter what is used, or that everyone who is going to be looking at the documentation was at the meeting and will be able to understand the diagram. However, remember, in software engineering people move on and new ones join, they will want to and have to understand everything, UML makes this easier.
Embarrassment and jeopardy of mixing up details
The ultimate danger when trying to “sketch” in UML is to mix up the notation and illustrate something different. It is not a surprize that this happens especially if one does not use the notation regularly. The most common problems include mixing up composition and aggregation arrows and forgetting to use the fork node from to indicate that both actions should be carried out from the initial node and not one of them. Such misunderstandings may cause different comprehension of the problem and lead to wrong implementations, that may cause even larger problems as the project scales up. A way to avoid mistakes is to go through the diagram with colleagues and hope that they will point out the mistakes. Therefore, it is important that many would be familiar with the basics of UML in order to catch propagating errors. Also, some people may know more on that particular notation, hence admitting early that there is some uncertainty about the notation may reduce the number of problems and allow one to learn from others.
All in all…
I believe that knowing the basics of UML is very useful in large scale development, because it provides an easier way to communicate a design. As discussed UML can be used for multiple purposes, to my mind, the most important one to all developers is to have the ability to use UML as “sketch” to convey the main ideas rather than details, which can be easily done by knowing the basics. Discussing designs in person is much more flexible in notation rather when one wants to include a “sketch” in documentation. In person discussions allow alterations to notation, but for global understanding the actual UML notation has to be used for even simple diagrams that want to convey the idea. Surely, it is easy to forget or mix up the notation, as admittedly sometimes it is complicated, but in my opinion practice makes perfect 🙂 The simple “sketch” is only simple when it can be easily understood by others and this is achieved by using basic UML.
 Paulo Merson, Five Reasons Developers Don’t Use UML and Six Reasons to Use it: http://saturnnetwork.wordpress.com/2010/10/22/five-reasons-developers-dont-use-uml-and-six-reasons-to-use-it/
 Martin Fowler, UmlAsSketch: http://martinfowler.com/bliki/UmlAsSketch.html
 Martin Fowler, UmlAsBlueprint: http://martinfowler.com/bliki/UmlAsBlueprint.html
 Martin Fowler, UmlAsProgramminLanguage: http://martinfowler.com/bliki/UmlAsProgrammingLanguage.html
 Joshua Bloch interview, http://www.cs.umd.edu/class/fall2009/cmsc132H/JoshuaBloch.pdf
 Markus Sprunck, Three Common Errors in Whiteboard Job Interviews with UML Diagrams: http://www.sw-engineering-candies.com/blog-1/commonerrorsinwhiteboardjobinterviewswithumldiagrams
*The illustration above was made using the BitStrips app and some personalization