SYSML17 — Contradiction regarding allowed use of the derived indicator for constraint parameters

There is a contradiction in the SysML spec. regarding whether constraint parameters-as properties of constraint blocks-may use the derived indicator, "/".

Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine."

On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks."

There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this.

As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression.

This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84.

Proposed Resolutions:

1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property.
2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.

Proposal: Constraint parameters do not need to be constrained to not be derived

A constraint parameter is a normal property of a constraint block that is not typed by a constraint block. Therefore, it can also be defined as a derived property. According to the UML definition of derived properties, some constraint parameters might be derived:

"If a Property has isDerived = true, it is derived and its value or values may be computed from other information."

It seems not to be useful to make the distinction of derived and non-derived properties, but there is no need to forbid them, and it does not contradict the non-causal nature of constraints blocks.