
Key: SYSML17140

Status: closed

Source: Kenntnis ( Richard Welling)

Summary:
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
SYSMLR99,SYSMLR47, andSYSMLR38. 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 noncausal 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 noncausality 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 nonmandatory to simplify the modeler’s task, then one could say parameters are assumed to be noncausal unless specified explicitly as such.
 Michael Chonoles proposal (
SYSMLR47) to interpret parameters bound to derived values as dependent (output) and those bound to readonly 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 noncausal 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 {readonly}.
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.

Reported: SysML 1.4 — Sun, 22 Nov 2015 00:40 GMT

Disposition: Deferred — SysML 1.7

Disposition Summary:
Defer
Issue deferred

Updated: Thu, 22 Dec 2022 13:45 GMT
SYSML17 — Causality of constraints in parametric diagrams
 Key: SYSML17140
 OMG Task Force: SysML 1.7 RTF