Well, I take issue with most formalized diagrams that represent code elements, rather than "business" entities. It leads to a kind of thinking that is wrong IMO

Well, I take issue with most formalized diagrams that represent code elements, rather than "business" entities. It leads to a kind of thinking that is wrong IMO, where you mechanically represent every business object by a class, say Customer and Employee. I tend to think of OOP as a way to rewrite 'if's now. When you have the same huge 'if' or 'switch' in a couple of places, you can usually rewrite it to use polymorphism, and it becomes clearer. But it is totally fine to use procedural or functional idioms most of the time. I don't know the whole breadth of the actual standard UML, and I don't know anybody who does. When I say UML, I mean as practiced and not as written, and that means: Boxes for classes, methods below, various kinds of arrows that I have to look up. For sure there are good parts in the standard, but that is not really relevant here. As the sibling comment says, sequence diagrams are usually more useful. Or state machine diagrams. Or a diagram showing data dependencies.