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.