I can remember deciding protocols (actual protocols, not data types) around message sequence diagrams, and a lot of people certainly think around entity-relationship models (yeah, those are UML too).
You will notice that those aren't the design of OO systems that UML was created for, but they exist. Also, there are better diagrams for protocols than message sequence UML, but those don't have good tooling.
Besides those, use-case diagrams are nice too. They also emanate that strong feeling that they don't describe the correct idea (just like message sequence for protocols), but I don't know of a better replacement, just worse ones. People try to replace this one with all kinds of canvas too, but those just bring different problems.
> a lot of people certainly think around entity-relationship models (yeah, those are UML too).
Chen notation entity-relationship models are about 20 years older tha the first work on UML. UML class diagram notation is sometimes pressed into service for ER Modeling by people already invested in UML, but that’s about the extent of the relationship.
> Besides those, use-case diagrams are nice too. They also emanate that strong feeling that they don't describe the correct idea (just like message sequence for protocols), but I don't know of a better replacement, just worse ones.
The problem I have with Use Case models is that they combine abstract requirements/domain modeling with implementation design in an opinionated OO way. They may be the best way to do those together in one diagram, but I just think that’s usually a bad idea to do. For the first part, I think Level 0 Yourdon-style DFDs are a better tool; for the second, if you need OO-focused diagrams, I would probably go with UML class diagrams, recognizing that interactions are nouns in the domain.
When people get to publish papers in distributed computing, they always use free-hand drawn graphs, not UML.
The format varies a lot, but there is a popular one where time usually flows at the horizontal, lanes do not necessarily go through all of the diagram, the arrows are more angular, and there are very diverse conventions on the message label. The angular arrows are a very impactful change by themselves.
There are also data flow diagrams, when you don't need to represent causality.
protocols design would have been a step up already, but I find sequence diagram barely adequate here, better than nothing but really a disgrace compared to a lot of tools we use (property based testing for instance, or state space like proofs, instead of ad-hoc manual drawing you know)
You will notice that those aren't the design of OO systems that UML was created for, but they exist. Also, there are better diagrams for protocols than message sequence UML, but those don't have good tooling.
Besides those, use-case diagrams are nice too. They also emanate that strong feeling that they don't describe the correct idea (just like message sequence for protocols), but I don't know of a better replacement, just worse ones. People try to replace this one with all kinds of canvas too, but those just bring different problems.