SYSML11 — 10.3.2.2 ConstraintProperty

10.3.2.2 ConstraintProperty: rewrite constraint [2] so does not refer to 'a SysML Block that is typed by a ConstraintBlock' SysML1.0, 10.3.2.2 ConstraintProperty: 'A constraint property is a property of any block that is typed by a constraint block. .. [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock.' These may both be misinterpreted as applying to "any block that is typed by a constraint block" and "a SysML Block that is typed by a ConstraintBlock" rather than a constraint property typed by a constraint block. Rewrite so that the type condition clearly applies to the owned constraint property, not the owning block, thus: 'A constraint property is a property that is typed by a constraint block and is owned by a block. . [2] The ConstraintProperty stereotype must be applied to any property that is typed by a ConstraintBlock.' (Note that the first constraint already makes it clear that a constraint property is owned by a SysML Block: '[1] A property to which the ConstraintProperty stereotype is applied must be owned by a SysML Block'.)

The ConstraintProperty stereotype expresses a condition that can be entirely derived
from other information in the metamodel, in this case a property of a block that is
typed by a ConstraintBlock. Property stereotypes are not defined for other categories
of property, such as part, reference, or value properties.
The constraints which currently appear under Section 10.3.2.2 ConstraintBlock, only
serve to define the ConstraintProperty category. A definition of the term “constraint
property” can be provided by language under 10.3.2.1 ConstraintBlock, similar to
how categories of part, reference, and value properties are defined under Section
8.3.2.2 Block.
OMG Issue No: 12130 Disposition: Resolved
SysML 1.4 RTF Report Page 25 of 341
Discussion in previous RTF's suggested that a consistent policy be adopted for
“calculated stereotypes” which only classify existing elements. Tools are still free to
establish internal stereotypes or other means to carry such information, but since no
other such calculated stereotypes remain in SysML, the consistent policy is to
remove the ConstraintProperty stereotype from the normative specification. Impact
on existing implementations should be minimal since they may still preserve such a
stereotype if it is useful to their implementation, but this specific stereotype would no
longer be required by the specification.
In the stereotypes for measures of effectiveness defined in Table D.5, require that
the base element for the «objectiveFunction» stereotype be a ConstraintBlock, as
stated in the immediately preceding text: "The objective function is a stereotype of a
ConstraintBlock and the measure of effectiveness is a stereotype of a block
property."