Perhaps UML ceased to be a fad for some, but to this day UML is still the best tool (and practically only tool) that helps describe and document code effectively and efficiently, from requirements to what classes comprised a submodule.
The "oversimplified and overcomplicated" jab makes no sense at all. UML is used to provide a view of a system without needing to go too much into detail (that's what code is for), and just because a bunch of people did a great job putting up a specification aimed at software developers intending to develop UML editora and code generators it does not mean it is overcomplicated". Anyone can use UML extensively if they can draw rectangles and lines on a piece of paper, or click and drag around in an editor. That's hardly a downside or a sign it's "overcomplicated".
UML activity diagrams let you specify, in full detail, the semantics of a trivial 3-line constructor using a ridiculously large amount of arrows and boxes. You can get good at this (even though it serves no purpose whatsoever) and get "UML Certified" stamps on your forehead.
UML use case diagrams, hardly useful for anything at all, have a rule that you can put the name of the actor either above or below the actor stick figure. The name of a use case (an ellipsis), however, may only be above or inside the ellipsis, but not below. Put the name below the ellipsis and your UML is syntactically incorrect. Volumes of books were written about nonsense like this. The UML spec is many hundreds of pages. If you don't think this is overspecified and overcomplicated then I want some of what you're smoking.
I believe it is these aspects of UML that made it unpopular among the "get things done" crowd. I agree that UML class diagrams and UML state charts, when you just use the normal, useful parts of them, are super useful and currently underrated.
If the UML people had remembered they were making a communication tool and not a programming tool, then maybe so many people hadn't run away screaming.
You're either very disingenuous or deeply confused. You don't need to hold a Master's degree in English to hold a conversation with English speakers. You don't need academic certification to use a tool to communicate ideas.
It makes no sense to assert that the usefulness and ease of use of a language is demonstrated by how far and how extensively it may be covered in an academic setting.
Lines and boxes. It's not that hard, is it?
We agree that UML has a subset of common features that are super useful to communicate about software. That doesn't make UML as a whole any less overcomplicated and overspecified, though!
Most people agree that languages like C++ or Scala are large and complicated. The fact that you can choose to write C++ code that only uses functions and structs and pointers doesn't change anything about that.
I said nothing about UML's ease of use. I said something about its drop in popularity and about the swathes of useless features UML fans promoted when it was at the peak of its hype cycle. I mean, I assume you agree that UML is less popular now than it used to be?
Sidenote: nothing about UML was ever intended to be academic, I'm not sure where you got that term from all of a sudden. It was all very industry driven. People wanted to do "model driven development" and realized if only UML could have super precise semantics, you could generate entire programs from UML. This actually works and serious amounts of software have been painstakingly written this way. It's totally nuts.
The problem is OMG turns every analytical tool into programming tools, sacrificing focus on the core purpose; they did the same thing (with similar effect) with BPMN.
but classical OO is not appropriate methinks
Of course, you can just ignore the UML semantics and draw something that looks like UML. That might be still useful. However, it then isn't UML anymore.
UML sucks for requirements (outside of, maybe, sequence diagrams); BPMN—which OMG overcomplicated the same way it did UML—is far superior for most requirements-relates diagramming, and honestly DFD’s and minispecs in the style of (Yourdon, et al.) old-school structured analysis beat UML for requirements.
For classes in a module, well, despite the wide availability of tools that will generate UML from code for that, the dominant mechanism seems to be autogenerated text documentation. That suggests people don't find UML adding a lot of value in that role.
UML is, however, pretty much the ultimate tool for communicating the structure of an object-oriented system to someone familiar with UML but not the implementation language. And UML sequence diagrams are, if not necessarily the best, at least a useful and popular way of showing interaction patterns even outside of OOP.
What if your system isn't designed around OO-style classes?
I think the missing part is distributed / protocol like interaction between pure agents. Maybe we should ask the erlang crowd. Or the smalltalk crowd.
Also, who uses petri nets ?
Data structures?
Some 5-10 years ago when UML went out of vogue (for good reasons; much of it is overspecified and overcomplicated), and around the same time FP started getting traction, I think we accidentally lost something.
I like FP and I also like using FP principles in not-strictly-FP language's such as JavaScript, but I miss OO's drawability.
If anyone knows of a compelling diagram syntax for FP style software, I'm deeply interested.
The best I've seen so far is abusing class diagrams for modules, which kinda sorta works when you follow a convention (common in eg Elixir) of having each module export one struct type plus some functions that operate on that struct. It's basically OO without inheritance that way so not surprising that it fits. But that feels a bit like shoehorning my FP into class diagrams rather than anything else. Any takers?