Is UML useful to describe templated code?

Question

I'd like to know if UML is useful to describe heavily-templated code. I know that there is a notion of parametrized classes in UML (vector<T> <---- <<bind>> ---- vector<int>), but this won't be enough to describe complex duck-typed relationships that we can have with templates. I can always put associations between such classes, but it seems to me that it won't actually help to understand how it works.

Moreover, considering for example the STL library, the algorithms are often implemented as functions, and thus don't fit very well into the OOP model, though they still behave quite like objects introducing associations between classes.

So, does it make sense to draw UML diagrams to describe such templated code? If so, which kinds of diagrams would be most useful - in "standard" OOP I've seen class diagrams being used most of the time, but probably for templated code some other kinds of diagrams would be more helpful? If UML is not well suitable for that, what else could I use?

Answer 1

I think it depends.

If different instantiations will lead to significantly different behaviours or relationships, then while it would be possible to model with UML, it would be ugly. On the other hand, if the behaviour is really that different with different instantiations, I'm not sure templates are a good idea, anyway.

But if the relationships between classes remain more or less the same no matter how they're instantiated then an UML class diagram is going to be just as useful to model those relationships as it would be for non-parameterized classes.