SYSML17 — BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features

EDIT: from SysML-1.6 p.52:

A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.'

—

SysML-1.6 p.52 states:

1_compatible_types

The two ends of a binding connector shall have either the same type or types that are compatible so that equality of their values can be defined.

self.base_Connector.end->at(1).role.type.conformsTo(self.base_Connector.end
 ->at(2).role.type) or self.base_Connector.end
 ->at(2).role.type.conformsTo(self.base_Connector.end->at(1).role.type)

OCL-1.4 states concerning conformsTo:

8.2.1 Type Conformance

The type conformance rules are formally underpinned in the Semantics sub clause of the specification. To ensure that the rules are accessible to UML modelers they are specified in this sub clause using OCL. For this, the additional operation conformsTo(c : Classifier) : Boolean is defined on Classifier. It evaluates to true, if the self Classifier conforms to the
argument c.

...

[2] Classes conform to superclasses and interfaces that they realize.
context Class
inv : self.generalization.general->forAll (p |
(p.oclIsKindOf(Class) or p.oclIsKindOf(Interface)) implies
self.conformsTo(p.oclAsType(Classifier)))

As far as this submitter can tell, there is no sense in which OCL conformsTo is not Type-based at the level of a Classifier.

This renders numerous desirable ProxyPort connection scenarios invalid.

Case: A ProxyPort of InterfaceBlock type PP1 and an internal part property of block type Standalone, where PP1 and StandalonePart have identical Feature signatures, but do not share a Type relationship.

From SysML-1.6 p.52:

9.3.2.13 ProxyPort

...

When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector (the value of the proxy port and the connected internal part are the same; links of associations typing the connector are between all objects and themselves, and no others).

Whether one uses a BindingConnector or a Connector with the same semantics, the reported constraint renders the Connection from proxy port :PP1 to internal part :Standalone invalid, even though all Features match, because there is no type "value" equivalence.

Consider now from p.103:

When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate as if they were to those parts, and flows and invocations it receives from those parts as if they were to the outside.

ASIDE: The spec could make clearer in the above whether the Connectors that are used for such multiple connections are NOT BindingConnectors

An attempt to work around it using multiple Connectors from the proxy port :PP1 to at least all of the Property features of internal part :Standalone - which are themselves 'parts' in the UML sense - also leads to a contradiction w.r.t:

the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features ..

The attempt was to aggregate the Property features themselves, not their features.

And even if the above were to work, it does not address the compatibility with Operations, and is also highly impractical in tools when there are many Properties to bind (collect).

The complexity and number of possible contradictions explodes when indeed connections are made to multiple parts.

What is needed is a completely different definition of compatibility that is not bound in any way to types, but primarily to matching Features (including Operations, Receptions and Properties) by "collecting" the Features via Connectors to their owners.

This would then support common engineering scenarios where subsets of Features of internal parts are aggregated and then "exported" via a single exposed Port.

This would greatly reduce the number of Connectors needed, and would make validation in tools much easier. Type-based compatibility can still be kept, but it is just a special case of Feature-wise compatibility.

The Property features of internal part :Standalone clearly count as 'multiple internal parts'. Assuming regular Connectors are used (but not BindingConnectors) from proxy port :PP1 to every Property of internal part :Standalone