Community
Participate
Working Groups
Contrary to other diagrams, it seems to be unlikely that the SysML modeler wants to recur to OCL constraints as _default_, especially since a lot of parameters are likely to be typed by complex types for which most mathematical operators are undefined
Ocl is the default constraint language for UML. So it seems natural to use it for SysML. I understand you concern about complex type. Do you have a proposition to replace Ocl ? Something that is also normative ?
[cc: EdW since he might also have a valuable opinion on this topic] (In reply to Benoit Maggi from comment #1) > Ocl is the default constraint language for UML. So it seems natural to use > it for SysML. I don't fully agree here. The SysML spec states [quote from section 10.1] Constraint blocks provide a mechanism for integrating engineering analysis such as performance and reliability models with other SysML models. Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system. Such constraints can also be used to identify critical performance parameters and their relationships to other parameters, which can be tracked throughout the system life cycle. ... Such constraints can be arbitrarily complex mathematical or logical expressions ... 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 [/quote] So at least a (the?) major goal of the constraint blocks in SysML is to link with (external) engineering tools and languages. Furthermore, one of the problems with OCL is the fact that it cannot express many _mathematical_ relationships (for instance the https://en.wikipedia.org/wiki/Sine function is not part of OCL) Section 10.4.1 states [quote] These particular constraints are specified only in an informal language, but a more formal language such as OCL or MathML could also be used. [/quote] So in my opinion, there is no 'guidance' (and certainly no "proof") in the SysML standard that OCL should be the standard choice for SysML constraints in constraint blocks. [off-topic] One interesting thing is that the SysML spec introduces a mechanism (constraintBlocks) to make constraints 'reusable'. This is currently not possible in UML+ OCL, and I wonder to what extent this mechanism is "compatible" with UML+OCL... [/off-topic] > I understand you concern about complex type. > > Do you have a proposition to replace Ocl ? > Something that is also normative ? My proposition would be to consider "natural language" as a default for constraints in a constraint block/parametric diagram, as this seems to I think it is more important that a particular user/DSML creator can easily connect its (embedded xtext editors) particular language of choice to papyrus.
(In reply to Benoit Maggi from comment #1) > Ocl is the default constraint language for UML. So it seems natural to use > it for SysML. OCL is only the default in so far as the null body language is to be interpreted as OCL. IMHO, leaving the body language null is poor practice, so the default is an irrelevance. I think changing the default in the models to something else for SysML would be confusing rather than helpful. If permissible than an OMG issue should be raised to endorse such a change. ---- Within the UI, pull-down menus can easily have different defaults. But is it helpful to have different defaults for UML and SysML diagrams. Perhaps you give the users a (per-diagram) preference of the default UI language. ---- OCL 2.5 is moving to modeled libraries. Eclipse OCL already demonstrates this with an extended modeled library for code generation. Eclipse QVTd provides another extended modeled library. There is now no reason why an OCL Maths library should not be developed providing all the usual functionality. Since most of the functions would just redirect to Java, the implementation is rather easy. I anticipate that it would take longer to 'design' a maths library in terms of deciding on consistent spelling, invocations, than to actually implement it. (My TODO list has had exploiting URI qualifiers for external language calls on it for a long time: 'java:java.lang.Math'::sin(1.2345) The foregoing is syntactically legal OCL today. It just needs a bit of implementation support.)
Klaas are you convinced by Ed arguments ? If so, I will close this task. If not what would be your proposition for default language ? It probably won't become the default one but we can maybe work something with preferences.
Created attachment 256908 [details] Working example In attach a nice example of how this _could_ decently work for the user. Note that this currently requires - the use of the OCLforUML profile, which is currently not a registered profile (See Bug 470242 and Bug 476759) - All SysML ValueTypes to be _manually_ stereotyped by the user using the <<Real>> stereotype (See also Bug 478602) Advanced mathematical functions still not available ATM (at the cost of having nice syntax checking for 'simple' mathematical expressions.
