I am trying to understand how the UML specifies templates. In general, templates whose parameters are not bound to concrete types are represented in most programming languages with a notation including placeholder strings, i.e. the T, K or V in List<T> or Map<K,V>.

Formal TemplateParameters expose one or more ParameterableElements and are owned by their TemplateSignature. But I cannot see any attributes for ParameterableElement which would enable a modeler to store the placeholder names she might define when modeling a new template. Instead of List<T>, it could be named List<NodeType> or maybe List<MyStrangeAndWonderfulThing>…

In order to do this, it seems that there should be a name attribute (or operation) in the abstract interface either of TemplateParameter or ParameterableElement which could be accessed by TemplateSignature. But Both TemplateParameter and ParameterableElement inherit directly from Element which has no such interface.

Under section 7.3.4 Notation on p. 68 of the UML 2.5.1 specification, it says this about the template signature:

The formal TemplateParameter list may be shown as a comma-separated list, or it may be one
formal TemplateParameter per line. The general notation for a TemplateParameter is a string
displayed within the TemplateParameter list for the template:
    <template-parameter> ::= <template-param-name> [‘:’ <parameter-kind> ] [‘=’ <default>]
where <parameter-kind> is the name of the metaclass for the exposed element.

The syntax of <template-param-name> and <default> depend on the kind of ParameteredElement
for this TemplateParameter.

The last sentence in that paragraph is worth re-reading.

IOW, must a conforming C++ implementations of UML first perform an ugly dynamic_cast on the pointer or reference to ParameteredElement in order to fetch the placeholder name? The point is, we don’t know what type to cast to yet if the template is not bound to a concrete type. And when we do create a binding, we need to know which name (especially since the same placeholder can be used more than once).

Perhaps this is related to this UML issue raised by Ed Willink back in 2017? https://issues.omg.org/issues/UMLR-741