In the latest UML specification for 2.5.1, the implementation in the OCL language of the overridden StringExpression::stringValue()
is given at section 8.6.17.5 "Operations" on page 130:
body: if subExpression->notEmpty() then subExpression->iterate(se; stringValue: String = '' | stringValue.concat(se.stringValue())) else operand->iterate(op; stringValue: String = '' | stringValue.concat(op.stringValue())) endif
The intent of this is perfectly clear; however, for example in specifying an ordered list of function parameters, there is always some kind of separator token (usually the comma) to delimit the individual arguments passed to a function. AFAICT the OCL 'concat' operation does not supply any separator token.
Since theoretically a StringExpression's subexpressions might return their own concatenated subexpressions, ending up with some kind of nesting of operands, it seems that no separator at all would quickly lead to confusion and errors.
It doesn't seem to be specified anywhere as to whether the concatenated operands or subexpressions need to be separated by commas or perhaps some other token? There might be languages in use where something other than the comma is used (perhaps a space?), so it is conceivable that the behavior could be overridden by a Profile in some form or fashion.
Is this a defect in the specification?
OCL concat
doesn't add any separators, but this no problem for stringValue
since it doesn't need them. As you can see in figure 7.6 StringExpressions
are mainly used to name elements that are created by binding a TemplateParameter
to a LiteralString
. If you want to include a separator, you can do it in the specification of the nameExpression
(e.g. $foo, <Resource>, <ResourceKind>, ba$
).
By the way, I tried to replicate the diagram in figure 7.6, but it seems that my tool doesn't completely support templates and name expressions. It's very likely that other tools will also fail. Seems this part of the specification has been neglected by the tool vendors.