SYSML17 — Suggest not allow an AssociationBlock to type a BindingConnector used for pure proxying

This issue report illustrates two separate (but apparently related) issues:

DISCLAIMER: The example shown for modelling an electronics jack or socket in electronics is not an approach advocated by this reporter. It is however a frequently used or attempted approach.

Primary issue: When a BindingConnector used to indicate pure proxying is typed by an AssociationBlock, the AssociationBlock can be used to undermine the claimed equality of the proxy, at least when nested Ports are involved.

In the attached example, the L and R channels of a stereo system have been swapped by the AssociationBlock (which swapping is invisible at the level of the BindingConnector it types).

It is proposed that constraint(s) be introduced for BindingConnector and/or AssociationBlocks, along with improved explanations for ParticipantProperty, to prevent the typing of BindingConnectors by AssociationBlocks used for pure proxying.

(AssociationBlocks are otherwise very useful, it is not suggested here that their use should be otherwise prevented.)

A 2nd issue was identified by John Brush of 7Sigma. In the situation as modelled, tools report that the innermost BindingConnectors (owned by the AssociationBlock) between the nested Ports have invalid flow directions.

That issue can be avoided by instead using a non-behavioral Port or a FullPort with additional inner-facing nested Ports to model the jack/socket, however that 2nd issue may be a valid concern for some other modelling cases.