UPR — The specification property of a UPRConstraint cannot be a string

In the definition of the UPRConstraint::comparisonOperator in subclause 7.3.2.2, it is assumed that the name of the comparison operator is given by the string value of the constraint specification property. However, UML requires that a constraint specification evaluates to a Boolean value, not a string (see the well-formedness constraint Constraint::boolean_value, UML 2.5.1, 7.8.3.6).

An alternative would be to require the constraint specification property to be an opaque expression returning a Boolean value, whose body is the name of the comparison operator. If the language property was also required to be "UPR", then this would indicate that the comparison for the constraint was to be carried out using the semantics as given in the UPR specification.

UPRConstraint specified by an OpaqueExpression

UPRConstraint specified by an OpaqueExpression

This resolution proposal is based on the principle described in the comments of the related issue, with slight modifications as suggested in the issue description.

The Constraint::Specification property of an UPRConstraint will use a OpaqueExpression. The language of that opaque expression shall be "UPR" and its body shall be the symbol of the operator to be applied. The semantics of the operator is encoded in a class specializing OperatorSematicsClass. This abstract class has two operations:

• a "symbol" operation, with no input parameter, returning the string value representing the operator symbol to be used in the body of the UPRConstraint specification
• an applyTo operation, with two input parameters (one for each operand), intended for returning the result of the comparison specified by this operator

The symbol() operation provided with the OperatorSemanticsClass makes the ComparisonOperator stereotype useless. It can removed from the profile, making it simpler.

The library shall be adjusted to cope with the modification described above.

The normative XMI for the profile and library needs to be correspondingly updated.

The updated XMI, profiles in .MDZip files (MagicDraw), and diagrams shall be provided in the submission package.