SYSML17 — Causality of constraints in parametric diagrams

Having occasion to review all outstanding constraint block issues, I have read more closely the overview and find that the last paragraph on page 97 of the SysML 1.4 specification has significant problems. It also is the only mention in the SysML spec of constraint causality. This proposal is an attempt to clarify that paragraph while addressing concerns about constraint causality, affecting SYSMLR-99, SYSMLR-47, and SYSMLR-38. This is the paragraph as written:

SysML identifies and names constraint blocks, but does not specify a computer interpretable language for them. The interpretation of a given constraint block (e.g., a mathematical relation between its parameter values) must be provided. An expression may rely on other mathematical description languages both to capture the detailed specification of mathematical or logical relations, and to provide a computational engine for these relations. In addition, 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.

• The first sentence is not describing constraint blocks but rather a language for constraint expressions.
• The second sentence again says, “block” when it is clearly referring to expressions, but then, says an “interpretation…must be provided.” By whom? Presumably by the tool provider but that's not clear.
• The third sentence seems to say “An expression may rely on other mathematical description languages…to provide a computational engine for these relations.” It is clearly not the language that provides the computational engine but the tool implementing the language.
• The treatment of causality is puzzling. Why was non-causality specified when causality is always at least implicit? In the F = m*a example, F is implicitly the dependent variable while a = F/m would indicate a as dependent. If the intent was to make causality non-mandatory to simplify the modeler’s task, then one could say parameters are assumed to be non-causal unless specified explicitly as such.
• Michael Chonoles proposal (SYSMLR-47) to interpret parameters bound to derived values as dependent (output) and those bound to read-only values as independent (input) is not only useful but it should be noted that MagicDraw notates derived properties in recursive parametric diagram patterns and these clearly represent dependent variables. This is standard UML notation.

Replace the above paragraph with the following:

Constraint expressions may rely on any suitable mathematical description language to capture the detailed specification of mathematical or logical relations between parameters. The syntax and interpretation of the language and its associated computational engine are a tool responsibility. By default, constraints are assumed to be non-causal and do not necessarily specify dependent or independent variables, in which case specific dependent and independent variables may be defined by initial conditions and determined by the computational engine. Alternatively, dependent and independent variables (constraint parameters) may be expressed by designating their bound values as, respectively, derived ("/" prefix) or {read-only}.

Move this paragraph to be the fourth paragraph on page 97, after paragraph starting with "Parametric diagrams include..." and before the paragraph starting with "Time can be modeled..." This places it in a logical flow that follows discussions of constraint blocks, constraints, and bindings.

Defer

Issue deferred