SYSMLR — SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are

SysML 1.3 section 9.1.3 Proxy Ports and Full Ports states:

Full ports cannot be behavioral in the UML sense of standing in for the owning object, because they handle features themselves, rather than exposing features of their owners, or internal parts of their owners.

This is incorrect; see UML 2.5, section 11.3.3 Structured Classifier Semantics:

A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. If there is no Behavior defined for this EncapsulatedClassifier, any communication arriving at a behavior Port is lost.

Based on the UML 2.5 semantics of behavioral ports, there is no legitimate reason to exclude a SysML 1.3 FullPort to be behavioral in the UML sense.

This is inconsistent with SysML 1.3, section 9.3.2.7 FlowProperty:

Items going to or from behavioral ports (UML isBehavior = true) are actually going to or from the owning block. (See “Block” on page 66 for definition of owning block of proxy ports in this case.)

The above is consistent with the UML 2.5 semantics but it is inconsistent with the SysML 1.3 semantics of FullPort above.

Finally, SysML 1.3 section 9.3.2.8 FullPort states:

They cannot be behavioral ports, or linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts.

The notion that a behavioral port implies identity with the owning block or internal parts is incorrect and does not make sense.

It would require that a behavioral port to be typed by its owning block or internal part.

It would be impossible for a block A to have a behavioral port typed by B for example.

Defer

Postponed to the next RTF