UML is just a communication tool. Knowing UML would help you to communicate with other persons who know it too, but only in that case.

• If you work with peers who use UML daily, then go for it.

  UML is a great tool which helps communicating clearly, presenting things in a visual way and reducing verbosity.

  It’s like using technical terms with people who know them. Instead of saying:

  Here, you find the set of classes implement a common class and enable to create instances of that thing, which helps separating the code required to create instances from the business code itself.

  I can simply say:

  Here, you find the abstract factory and its concrete implementations.

• If you’re the only one in your team to know what UML is about, learning UML more would only cause communication issues if other developers don’t want to learn it: when you will think the diagram you created is clear enough, your colleagues will understand this diagram in their own way, which has nothing to do with yours.

  It’s like using technical terms in a team of beginner programmers. You tell:

  In order to change the aspects of the price, you have to use the Change method overloads, but you can get the actual price by simply using the Price property. Note that tax is a readonly field.

  while they don’t know the difference between a method and a function nor between a property and a field, and they don’t know what is the usage of readonly keyword or what an overload is.

Also note that:

• Different persons use different styles: MetaFight already commented on that above. See it like the RFC for e-mail addresses: it’s clear and unambiguous, and still, nearly everyone gets it wrong.

• UML is difficult, and some parts are tricky enough to be ignored by many people. As an example, here’s my answer on Stack Overflow to a question where the actually accepted answer is plainly wrong.

There are two ways that UML can be used:

1. To specify a system or module
2. To describe a system or module

In the first case, the UML will likely be used to automatically generate code from, so you need to know enough of the details of UML that you get the expected results from your code generation tool.

In the second case, the UML diagrams are only used to support or illustrate a written or verbal explanation. In other words, they are used as a communication tool. In this case it does not matter that much if you get some of the details wrong (especially if you are present to clarify and questions that arise), as long as you get your meaning across.

UML has some nice parts, but it’s not good for everything. There are better notations to communicate certain information (e.g. high level software architecture). It can also be very complicated. I found that it’s often better to invent notation on-the-fly while drawing a diagram. If I carefully define meanings for my boxes and arrows, diagram is cleaner and more understandable than UML.

As for specifying program structure in UML, IMHO it’s a doubtful feature. I know that it can be amusing how well some tools work with class diagrams today, but what’s more usable are code generation and refactoring tools in modern IDEs. It’s a lot faster to write code of a class than to click it out in UML tool. Secondly, class diagrams that are used to generate code from (or are generated from code) are not usable as a documentation, because they contain too much detail and/or they describe too large parts of a system.

Answering your questions:

1. I would say that it’s good to know UML. Not to use this language in particular, but to compare it to other notations and be able to choose/invent/mix proper form of communication for each situation. The best source is the official specification. Chapters 9 and 10 should be enough for a first grasp of UML.
2. Nuances are important only if you want to generate code from UML.