Sequence diagrams are quite useful, static diagrams, not so much. I only find myself drawing them if I'm trying to do a necropsy to figure out hosed up object relationships.

The other useful diagram tfa doesn't cover is the finite state machine diagram. Handy, plus, they look cool.

As an aside, I find it's much, much easier to do with pen & paper than in any tool i've ever used (looking at you omnigraffle & visio!)

  > UML was supposed to foster communication

  > could supposedly "round-trip" between UML and code, but I never saw that actually work

This is the root of the problem with UML-as-spec: it's used as a tool for one-way communication, for open-loop management that doesn't want to have feedback or dialogue stages in development.

I think this is the real problem with UML. It first kinda seems to work when project is managed with waterfall-style, but when actual development is done iteratively (when is it not?) it just adds confusion or work either by providing out-of-date spec or introducing more stuff to keep in sync.

UML is a way to talk about things. Just having a standard-ish way to draw on whiteboards is pretty helpful, even if the diagrams are super temporary.

In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts).

There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable.

I've not even seen some of the "stuff you have to know" (ball and socket, etc) used.

I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems.

UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)

If you have a problem with out of date documentation, I think you might have a problem with the development team rather than the documentation.

If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense.

My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists.

Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.

There are two types if UML diagrams I willingly used: sequence diagrams and deployment diagrams.

ER diagrams are super useful, too.

Do you have link to an example of a "realistic"/real-world deployment diagrams? In my courses they always looked quite silly and useless, but I wouldn't be surprised if that's due to bad examples...

It can be hard to convey the proper use of a technology/framework in academia when there is not a lot of background to work with. I felt the same about unit testing (shouldn't you know how your code works?) and UML diagrams (shouldn't you know the class/object relationships?) as well. They're all bigger picture than that.

The point at which I started to realize the usefulness of diagrams was when I started working on projects that were more than a few hours worth of coding (my first internship). UML provides a way to visually represent how your code will both relate to itself (classes, interfaces, objects) and the overall project to both the developer AND the business analysts who have no idea what inheritance or polymorphism mean. I've included an early draft of a piece of a rather large data model. It won't mean anything to you without the overall diagram, but you see some relationships between the customer's account, application and product: http://s18.postimg.org/gxfkjytft/diag.png

You probably had an example like grocery store checkout software, hotel booking software, or library cataloging software. A UML diagram can show to everyone all the possible routes a customer can take such at starting points, ending points, resume milestones, activities that are and are not allowed, transient and permanent data and everything in between. This all applies to the academic scenarios listed above, but it's more in depth (likely) than an assignment that you'll have when learning about UML.

Just keep in mind that large project will have multiple developers of varying expertise with business people who likely cannot write "Hello World!" in any language. UML attempts to bridge the gap between you, your superiors, your subordinates, and the non-tech side of the project.

Together J had always in sync Code and UML. It was a really neat IDE.