Some properties are defined as subsets of inherited properties with the {ordered} constraint, for example: RedefinableTemplateParameter::/inheritedParameter subsets TemplateSignature::parameter (see p. 196 and p. 99 of the PDF file for the UML 2.5.1 specification). The latter is {ordered}, but the subset is not defined as ordered.
In fact, the OCL implementation given for the derived property RedefinableTemplateParameter::/inheritedParameter is as follows:
inheritedParameter() : TemplateParameter [0..*]
Derivation for RedefinableTemplateSignature::/inheritedParameter
body: if extendedSignature->isEmpty() then Set{} else extendedSignature.parameter->asSet()
endif
Perhaps the inherited property does not need to be ordered? Or is it implicitly assumed that the ordering of the superset would carry over to the subset?
A subset of an ordered set does not need to be ordered.
The set of people in a waiting queue is ordered. But the subset of the people in this queue wearing a hat is not ordered.
The fact that one set is a subset doesn't have any influence on the ordering. It is even possible, that the subset has a different ordering.
There is an exception: If the superset is defined as a union of the subsets (isDerivedUnion), then the subsets must be ordered, since the superset doesn't have any direct content. In fact the UML contains 5 cases where this rule is violated. I think this is a minor bug.
inheritedParameter however, is not one of these cases. The ordered set TemplateSignature::Parameter is not derived. The reason why inheritedParameter is not ordered is probably, because extendedSignature is not ordered. So, the derivation can in general not come up with an order of the inherited parameters (in the context of templates). Of course, this could be solved by defining an order, but then, for what purpose? There is no specific semantics for the order of TemplateParameters. It is convenient for the modeler to define them in an order which is preserved. That doesn't apply to a derived property.
I only found three places in the specification, where the order does carry some meaning:
the ordering of the union is defined by evaluating the subsetting properties in the order in which they appear in the result of allAttributes()
Lifeline::events[*] {ordered}
The argument Pins of a CallAction are matched, in order, to the sublist of input Parameters,...
Please note, that the parameters mentioned here are not TemplateSignature::parameter but rather Operation::ownedParameter and Behavior::ownedParameter,