SYSML16 — Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous

Constraint [4] of a Block says:

[4] In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association.
(An inverse end of this association, whether owned by another block or the association itself, must always be
present so there is always a metamodel element to record the inverse multiplicity of the reference.)

The referenced constraint in the UML metamodel does not exist. The UML specification says:

A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.

I propose to remove the constraint [4], i.e. to allow to model part properties without an association. The reduces the number of model elements (1 property versus 2 properties + 1 association), makes the model simpler for the model builder and user, and reduces the effort for model maintenance.

In particular it is valuable when using generalization and redefinition. Without an association an inherited property could simply be redefined. An inherited property defined by an association that should be redefined, requires to create a new association that specializes the association and lots of redefinitions. That makes modeling very cumbersome.

Remove constraint [4] from the Block stereotype: Block-typed properties must be defined by an association

There is no justification for the constraint [4]. Without the constraint is still allowed to define those properties by an association, but it is not mandatory.

[4] In the UML metamodel on which SysML is built, a Property that is typed by a block must [sic] be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)

Removing Block constraint [4] enables more efficient implementation of applications that don't depend much on graphics, but have very large numbers of associated blocks, possibly importing from other systems.

However, in order to avoid any ambiguity, the association-like notation which was not used so far in SysML because of this constraint#4 (see SYSML16-314) need to be explicitly excluded from SysML.