Who uses UML nowadays anyway?
An interesting thing occurred recently — I was asked “Do you use UML at work?”. In all honesty I had to say no, or at least, rarely.
That answer felt weird — we had so much pressure in University to really dive in: class diagrams, sequence diagrams, component diagrams… you name it.
What happened? Did UML just “die”? Do we still need to “learn” it? Is the company that uses UMLs in their interviews just a dinosaur waiting for its extinction?
Unfortunately for some, no, UML isn’t dead, it’s there to stay. Yes, you learn it. And yes, you forget it — but you know what ? That’s fine! Let me explain this a bit more.
The real world
There probably wouldn’t be a situation at work where you get your assignment, then you immediately turn to the whiteboard, pick a marker and start drawing your fancy class diagram. That’s what University wants you to think happens, but in truth, it almost never does. What usually happens is that you design your classes directly in code. Given the problem you probably already have a good idea what to do, then why draw it in the first place? And let’s face it — real world problems are rarely as complicated as all those Design Patterns you meticulously studied before entering the interview room.
But (you knew this one was coming) — you do use it when you need to communicate an idea. You don’t want to share 100s of lines of code just to illustrate new design and dependencies — you need something that’s easily read and understood. You need to give somebody this solution design for them to implement it. This is where UML comes in. In truth, the only two UML diagrams you’ll probably be seeing is the Class Diagram and the Sequence Diagram.
The Class Diagram
Class diagram I’ve mostly used to quickly discuss dependencies with my co-workers on the project (but this happens once in a blue moon… let’s say every 1/2 year). Here we don’t care about the correct syntax (and honestly nobody even remembers what that is). We want to communicate an idea, and we just scramble some squares and draw various made-up lines between them — that usually works to get the thoughts through.
The Sequence Diagram
Sequence diagram is actually used much more often. Every now and then there’s some process involved. You need to illustrate this process when designing solution and the sequence diagram fits here very nicely. And on a plus side — it’s very easy to draw and understand. People also tend to make up their own syntax and that works too. Because it’s simple, and it just works.
The other diagrams
What other diagrams? For example, let’s look at this “component diagram” — that’s just a bunch of squares connected with lines, right? Is there really a need to learn this? You already know it, even if you’ll see it for the first time. If you get to the point where you need to write it then you’ll find no issues in looking it up to use appropriate symbols. The thing is that you draw these using plain-old common sense, just like everybody else. I’ve seen tons of ridiculous drawings, made up symbols, and guess what — they all worked in illustrating what’s going on. Don’t stress about it, it’s fine.
Conclusion
From my perspective, you don’t need to know the syntax, you need to know to read it. You need to know to look up the syntax when you’re tasked to draw it. For example, in interviews I don’t care if you don’t know which diamond is for what type of dependency — I want to see that you can think and I don’t want to see you typing out 250 lines of code to show me your idea, when you can easily do that with a couple of squares.
UML isn’t that hard, you don’t even have to know all of it to use it. But you should know your way around solution designs that involve them, as that will most likely meet you from time to time when you sit behind your desk.
