I spent many years at university and was always confronted with UML diagrams. My professors and teachers were always quite conservative and we often had to draw UML diagrams (class diagrams, component diagrams, sequence diagrams, etc. ...) for every program we wrote or architecture we designed.<p>In the last jobs I worked, this was somehow never a thing. I don't mean that there was no documentation at all regarding the given software architecture or components and interfaces, but if there was, it was rather informal. If there were diagrams, then loosely drawn with draw.io or some icons and arrows that are supposed to somehow represent the services and relationships from various cloud providers.<p>Therefore my question is: Is UML still a thing nowadays or is it just too formal? Is it used in your current job?
This is based on my experience across a variety of startups and small internet-focused companies. YMMV.<p>Some UML diagrams are useful, but only a small subset of the entirety of UML, and never very formally. Sequence diagrams and class diagrams are especially common. Also, UML officially is very specific about the details of each diagram, but rarely do the details matter very much. The subset supported by PlantUML seems to be plenty. Some of the diagram<p>Get a copy of Fowler & Scott's UML Distilled and that's as much as you'll ever need to know.
The research group I was in when I did my PhD focused on modelling. This was 7 years ago and back then UML was considered to be dead. It's all moved on to Domain Specific Modelling Languages (DSMLs). Who's using DSMLs you might ask? Your car manufacturer is using them for writing the software for your engine. They draw out a diagram and both the code and safety cases they need to submit to the regulators are auto generated.
I am a volunteer working on the ISO 20022 standard and we use Ecore, an object modelling system that was designed to bootstrap UML, to represent financial messages.<p>I developed a toolset for working with Ecore that was adequate for what I needed to do. I took a crack at bootstrapping UML 2 but I found there were "chicken an egg" problems that I figured would take me a month to resolve, probably some important objects would have to be duplicated but then hidden from the upper layers.<p>(Resolving "chicken and egg" problems is something I do very well but I've been burned by spending a month working on something I felt uniquely inspired to do and then spending much more than a month trying to sell it and finding nobody gives a damn.)<p>UML has a fascinating vision which parallels the W3C's vision of the the semantic web, particularly "executable UML" ought to be possible, but it is held back by vendors who thrive on almost-functional standards that require proprietary additions to really work.
A few weeks back I had occasion to read some SCTE (cable TV + descendents) signalling specifications, and I was tickled because they used enough UML that I had to actually go look up what the different arrows meant.<p>Other than that, don't think I've seen formal UML, just informal diagrams with boxes, arrows, and icons.
I would say most of the industry just "wants to get it done", everyone is really confused, lack of communication, no time to design, customers changing project direction fast. Requirements/design/diagrams are replaced with tasks in Jira because that is "agile"<p>I would say if it is a new project it's useful to do some UML diagrams to get through discussions. But after the first milestones it is impossible to keep diagrams updated in sync with code, they normally just get left behind<p>For the reasons above anything with arrows works, it does not need to be UML, but it is a useful to know, making diagrams that present all in a useful way is hard and all knowledge and thinking is welcome<p>My current company we just have a designer doing/updating wireframe/mockups after meeting which then we discuss
Class diagrams are way too fine grained to bother with and most IDEs have good enough tools for exploring large code bases. Service architecture diagrams and message sequence charts are super helpful. Especially for communicating with other teams and for making design proposals. I wouldn't be able to get traction on a new project without them, people really need pictures to see how something that doesn't exist yet will fit together with existing components.
It's a thing for architects, and sometimes product owners. Regular-old programmers could care less what they build or how or if it will work; they'd rather write code randomly than model. The Agile paradigm dictates that those regular-old programmers control the work, so most work today doesn't use rigor. If you're lucky you'll run into people using C4 diagrams and ADRs, but more frequently "big ball of mud" diagrams.
UML's problem is not really that it's too formal but that it's usually too detailed, too vague or too out of sync with the real system to be useful.<p>It was also heavily associated with Big Design Up Front, which has been more or less trashed in favor of agile / iterative improvements / spikes / whatever you want to call it.<p>PlantUML still seems to be a thing, although perhaps more for general diagramming.
My experience matches yours. We draw diagrams all the time to explain systems, but we rarely use UML to do it.<p>If you think about it, the point of using diagrams is to simplify an explanation. Making explainers and listeners learn a formal language just to understand diagrams defeats this purpose.
Still used for solving mazes I believe: <a href="https://youtu.be/v2uAipnt2nw" rel="nofollow">https://youtu.be/v2uAipnt2nw</a>