If you learn only one diagram from UML, take the time to understand and use Sequence Diagrams [1].
Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
The only problem with UML is that it was used as a method of intellectual masturbation by people who love massive class hierarchies. There's a lot of good stuff in UML, the problem is that the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code. There are the same guys who spent years building up formalisms in tools like Rational Rose and other pseudo-engineering tools.
When used by good programmers to illustrate specific hard-to-reason about components of the system, it is a useful tool. Activity diagrams, sequence diagrams, use case diagrams and communication diagrams are all useful.
> the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code
Sounds like the same people who became Agile consultants in the early 2000's. Perhaps they realized activity and sequence diagrams can get fairly complicated soon enough, so they looked for a bandwagon requiring no technical chops whatever.
I co-wrote a book on UML years ago, used to be an enthusiast. Now I write some sequence diagrams, and once in a while might write a high level class diagram.
It is all about communication, and a sequence diagram is good for that.
The most common cause of individual [dead] comments on an otherwise not-banned account is double posting. If you accidentally submit the same comment twice, the second one is killed. Since both show as live on your screen, when you delete one of the duplicates, you may delete the one that's live to everyone else, while leaving the one that's dead to everyone else.
I'm not sure, but I'm guessing it's because of the dismissive tone regarding early proponents. I lived through this period and remember being attracted to Booch notation and similar early efforts (as well as GoF patterns, etc.). Ours is still a relatively young profession and before UML codified some of the ways to view problems clearly (from a particular perspective), one was often reduced to writing out algorithms and data structures and diagramming in off-the-cuff ways.
Because business users can understand them and the process flow is important to them (entity-relationship diagrams work well too for modeling the data and establishing a basic glossary for future communication)
After that it usually turns out to be simpler to create a prototype or wireframe than UML diagrams these days (IMO).
Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
[1] http://en.wikipedia.org/wiki/Sequence_diagram