SYSML16 — Constraint clarification

SysML deviates significantly from the latest UML specification in its concept of constraint, and not in a bad way. But the resulting differences are not well defined in the SysML specification. The UML spec is quite explicit in restricting constraints only to ValueExpressions which not only evaluate to Boolean but, when evaluated, have no side effects on the model. From the UML 2.5 specification:

7.6.3 Semantics. The specification of a Constraint is given by a ValueSpecification (see Clause 8) of type Boolean…A Constraint is evaluated by evaluating its specification. If the specification evaluates to true, then the Constraint is satisfied at that time. If the specification evaluates to false, then the Constraint is not satisfied, and the realization of the model in which the evaluation occurs is not valid.
7.6.4 Notation. The Constraint may then be notated textually within braces ({}) according to the following BNF:
<constraint> ::= ‘{‘ [ <name> ‘:’ ] <boolean-expression> ‘ }’
7.8.3.6 Constraints (of Constraint Classifier).

• boolean_value - The ValueSpecification for a Constraint must evaluate to a Boolean value.
• no_side_effects - Evaluating the ValueSpecification for a Constraint must not have side effects.

8.3.1 Expressions-Summary. Expressions are ValueSpecifications that specify values resulting from a computation.

Moreover, the UML spec makes no qualification for the evaluation of OpaqueExpressions, i.e., they must evaluate to Boolean. This is clearly not the case for SysML-style constraints, which include mathematical expressions (i.e., ValueSpecification<OpaqueExpression) that can be evaluated to type real and can cause state transitions and other changes to a model. It is difficult to understand how one could execute a model without this capability. Perhaps the Boolean constraint on constraints is a holdover from the earliest days of UML. It is one thing to constrain the mere logic of code and quite another to constrain the reality of real world objects. Essentially, all constraints in SysML are expressed as OpaqueExpressions, with special cases (i.e., a<b) evaluating as Boolean. Since most tools make this SysML assumption, this difference needs to be formalized, or at least reconciled, in SysML Clause 10.

Constraint clarification

It appears more to be a conceptual change than a bug which we can fix in the RTF of 1.6. That's why we think it should go as requirement to SysML 2.