We help IT Professionals succeed at work.

Anyone still using UML?

Massimo Scola
Massimo Scola used Ask the Experts™
I am currently studying software development at a university part-time. I also have to learn UML which I am having difficulties with because I cannot see any vocational relevance.
Where I work, we work agile and I was told that we do not have time to draw diagrams for hours and then make changes to it whenever the code changes.

Does anyone still use UML or is it only used in academia; that is: in research, study etc..

I assume that UML was used when working in the "waterfall model"?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I used UML on multiple projects. It is more than drawing pictures. There are many words describing aspects of the pictures. From the words and the pictures (called diagrams), I was able to make a successful presentation to the customer, and then once approved, I pressed a button, and I got a lot of working C++ code.

In my current project, the analysts are building models in both UML and SysML which they will then hand over to the developers. So, yes, UML is being used. Some tools, such as IBM Rational Rhapsody Developer allow 30 software developers to write different modules, and the Rhapsody identifies during the design phase inconsistencies in the interfaces between the module. As a result of having a clean design, the integration of all the modules was one of the smoothest experiences I have witnessed.
>> I assume that UML was used when working in the "waterfall model"?
What is the basis for your assumption?
The Rhapsody license is not cheap, and that may be a reason why they are not used. Also, if a project only has a couple of developers, then you may be able to work out the kinks yourselves. But for large projects having 20-100 developers, knowing that Rhapsody has performed dozens of integrity checks among all the developers is comforting, and leads to a less expensive integration.

Part of UML is to break down a complex system into pieces, and that is partly what the agile methodology is trying to do. So I don't see anything incompatible in doing that.

If you can do the design in your head, and can implement the program without UML, then there is no reason to invest in learning a new language. Also, if you have a lot of legacy code that you are adding functions to it, then UML may not be the best route to take.
Top Expert 2014

Are you doing OO programming in your Agile environment?  If so, UML (Model-Driven Architecture) is great for specifying your classes and generating that part of your code.
Massimo ScolaSoftware Engineer


Yes, we use OO in the backend and functional programming in the front end.
While I understand where UML comes from and its advantages, I was surprised to see that it was not used in the company where I am working.
Is it used in big(ger) projects or teams? Our team here is 20 people and a few more in the US.
>> I was surprised to see that it was not used in the company where I am working.
What design documentation do you use before implementing code?
Massimo ScolaSoftware Engineer


What design documentation do you use before implementing code?
I have just attended a meeting about agile/scrum and in it, and I addressed the issue of documentation.
Here is what I can tell you: We do have a wiki .. but the team believes in code over documentation.
Update: I was told that an agile project has documentation in the form of user stories and tests.

But the important thing for me to know is, that UML is still being used.
In other words: It is not taught at universities because it is used in academia - it is still being used in the industry.
And: Some companies still use UML and other's do not, as they consider it obsolete (like where I am working).
I never heard anyone saying UML is obsolete. They just say that we don't need to document the design. There must be a design in the implementer's head in order to write the code. Maybe the design's are not considered complex enough to warrant the time for documentation. One purpose of a documented design is to handle system complexity.
If your project has a framework with good hooks to insert your new modules, then that framework is a large part of the existing design. In that case, with a team of 10 developers, we didn't use UML. The interactions between one developer and another was all handled by the framework. For that project, we used Doxygen notation to produce our Design Description Document which is generated directly from the code.

Each developer had their own sandbox to design as they chose, and only after the code review, did we see the design. But this approach had its downfall since as the project kept growing, the interactions grew as well, and the design flaws became more prevalent. And when that happened, then we had to have design meetings and redo multiple modules with multiple developers to get the right design.

That alone doesn't mean you have to have design reviews. It depends on the expected cost in producing quality, maintainable programs in developing with or without design reviews (whether the design be in UML or some other approach).