So when I was at university I was educated on the benefits of UML and its future in code development.

But from my industry experience, I've found that while we do use diagrams—ranging from ER diagrams, class diagrams, state diagrams, to work flow diagrams—all of it is for communication purposes.

That is, I've never generated code automatically from diagrams, and from a communication standpoint, I generally try to keep my diagrams as simple and easy to understand as possible. 

But when I look at Visio and Enterprise Architect, it seems they have many different types of graphs, shapes, properties objects, most of which I don't use.

Do people use UML to do more sophisicated things such as code or database generation?

Yes, UML CASE tools were one of the hot items of the 90s... and then failed to deliver.

The fundamental reason for this is that UML (or most any other kinds of) diagrams help to understand the problem and/or the program solving it only insofar the diagram is abstracting away the implementation details of the actual code. Thus (for any nontrivial piece of code), a diagram which is easy to understand is inherently useless for code generation, because it lacks the necessary details. And vice versa, a diagram which is directly usable for code generation doesn't help you much to understand the program any better than code itself. If you have ever seen a UML class diagram reverse engineered from production code, you probably know what I mean.

The only potential exception to this I know of is Entity-Relationship diagrams, which don't encompass code per se, only (as their name implies) pieces of data and their relationships. But I have never heard of a successful attempt to use any kind of UML diagrams for real code generation [Update] - i.e. more than class skeletons and trivial code like getters/setters -, except in special purpose tools/areas like ORM, as testified by Doc Brown below [/Update], and I think this is no accident.

I personally do not hate UML - I think that UML diagrams can be a great tool of communication - to show your intent and ideas during design discussions, or to visualize the architecture of your app. But it's best to keep them to this, and not try to use them for things they aren't good in.
