How necessary is UML for a course in object programming patterns?
As a professional software developer, I would recommend minimizing the time spent teaching UML.  Teach the patterns.  If they learn some UML along the way, so much the better.  But don't burden them.
In my experience, I've found value in using UML for somewhere around 3-5% of my work.  It usually provides its value after the fact, once I've already identified the design patterns, and I need to describe them to others quickly.  Often they don't actually need to understand, they just need enough of a warm-fuzzy to check off on my work.  UML is great for this!
All too often I find that I need something that isn't handled in UML (like handling dependent types), or something that can easily be explained in one sentence rather than a dozen fancy boxes (like object lifespan management).  I can't think of a time where I've ever looked at a UML diagram and thought, &quot;wait... if I use the Decorator pattern here, I can make this diagram look better.&quot;  It never helped me for actual understanding of the patterns.  And I can't count the number of times where neither aggregation nor composition adequately described my relationships, leading me to fall back on just drawing a line between them and calling it a day!
That being said, use a tool for what it is good for.  In the cases where UML does a good job of describing the pattern, use it!  I love UML for drawing basic inheritance hierarchies.  But I don't think it needs to be taught.   It's simply the way you choose to draw the patterns so that you can point to boxes and talk to them.  If a sequence diagram is the right way to describe Mediator, use it.  Use it correctly, and don't spend too much time explaining what all of the symbols mean or why.  Don't worry about explaining why the activation box on the Mediator in the Wikipeida page is broken into two part.  Doing so will teach UML as one learns a natural language.
If any of your students go on to become systems engineers, they will have to learn UML the &quot;right&quot; way.  And they will get to learn all of the kludges we use to make UML work in situations where it shouldn't.  You wont want any of those in your course.
If you wish to support the students who will work under a systems person in the future, go with the natural learning approach -- show them the tools, and let them riff on them.  Let them express themselves in almost-UML.  Then construct the assignments in a way where requirements come down from a systems person in proper UML speak, and use that as your tool for teaching UML.