To what extent should UML be covered in the context of a degree?

Question

As part of my Computer Science degree, we covered UML in quite a bit of depth as part of a software engineering module. Whilst some parts did seem useful, a lot of it was interesting but not very practical. The specification itself was also not very accessible when I tried to read it.

With that said, I've never come across UML being used a lot in the context of an actual software engineering role (perhaps with the exception of sequence diagrams to model protocols). Sometimes a vaguely UML-ish class diagram might be drawn on the whiteboard, but it's very informal.

Assuming that most CS degrees will incorporate some amount of software engineering theory alongside the usual computation theory and data structures etc. style modules, to what extent (if any) should UML be covered?

Answer 1

From my software engineering experience.

Some of it is useful some is not. It was put together by a committee of organisations that had a product to sell. (state machines got in there because a committee member had a state-machine editor.) A lot of other useful stuff was missed out.

Take what is useful, leave the rest, and use stuff from elsewhere.

There is nothing unified about it. I have used mainly class diagrams, some dataflow (I think it may be called), but as you say not too much formality. We never passed them through a linter. At one time we were drawn in to using them to create code. This was an expensive lesson.

Most of the diagrams (may be all) existed before the UML. I tell my pupils that some of the diagrams are useful, but also look else where. I tell them which ones I have found useful. And I tell them what I have said here: there is nothing special about the UML (or the process of collecting together, arbitrarily, some diagrams notations).