Thanks Peter. I was aware of the plans to use "Replication", but I wasn't aware that legacy models could provide it as a string.
Currently the code generator obtains the multiplicity from the port, part or any property via the org.eclipse.uml2.uml.Property.lowerBound and org.eclipse.uml2.uml.Property.upperBound and both return an int, so that limits the user by allowing only LiteralInteger and LiteralUnlimitedNatural.
I do not know how the tooling populates the relevant features in the model.
To support LiteralStrings, one possibility would be for us to get the ValueSpecification instead of the int (calling e.g. getUpperValue), and then either trying to resolve the symbol if the ValueSpecification is a LiteralString (which in the general case may not be possible), or (probably better) updating the intermediate meta-model to support such strings and adapting the part of the generator that emits type declarations accordingly. I think this is doable, so we could generate the corresponding array declarations with constants and then the user can create his own headers with constant definitions, or define them in any other way in which constants can be defined.
If the tooling adds a browse button and lets you select any constant, I'll expect the constant to be a ValueSpecification, and we would deal with it accordingly.
Would you mind opening a bugzilla with this issue, since the others are assigned to tooling?
Thanks
