Whenever you use UML, remember that the people who you ask to write UML might not be as proficient in it as you might assume.
I fully agree with Stan's observations. They are almost exactly what happened in one of my projects. It takes extreme discipline to maintain a consistent relationship between your diagrams and code, a discipline that almost often is impractical.
Ask yourself what diagrams are really needed. Typically, some sketches of class and sequence diagrams should be more than sufficient to elucidate fine points.
Instead of emphasizing on UML, try to get your developers to document the code better using Javadoc or even by making them write
test cases with proper names. This goes a long way in explaining the code than the diagrams.
One mechanism that I used in a project was to draw the diagrams on a whiteboard as a part of brainstorming and then simply capturing it as an image (with digicams, this is a cinch). That done, you can paste it in your documents, or if it is client-facing, ask someone to redraw it in a popular tool and paste it in the document.