Tags and keywords
You might want some coffee or beer for this one.
Everything you wanted to know about ProxyPorts but were too afraid to ask! We work through most possible cases of "delegation" connections from ProxyPort on the boundary of a Block to itself or to its interior parts (or their ports).
SysML-1.6: 'A completely specified proxy port shall describe how any interaction through the port is handled or initiated. This can be achieved in several ways. For instance by making it behavioral, by binding it to a fully specified internal part or by having all its properties individually bound to internal parts.'
DISCLAIMER: It is not of course Webel Best Practice to use the word 'port' in the names of blocks that type ports, it's just done here so we can trace it a bit easier:
Case:
Case:
Case:
Case: The type of
Case: The type of
Case:
Case:
Case:
Case:
And finally, we show (only) a nested proxy port
Are you dizzy yet ? Head hurting? Don't fear, just follow the Webel Best Practice tips and modelling examples here and soon you'll develop a pattern for modelling with ports and "get in the flow" so-to-speak.
Webel Best Practice: DO NOT name ports with first letter capital (like 'Port'), DO NOT name ports 'port' (except for educational illustration), and DO NOT use port names that do not indicate a role.
Case:
pBehavioral:ProxyPortType1: The owning block handles any interactions because the port has 'isBehavior' set. No BindingConnector is required.
Case:
pDelegatesToPart:ProxyPortType2 has a BindingConnector to a part :Delegate, where block Delegate specialises the InterfaceBlock ProxyPortType2. These are compatible "by design". No features are shown; In practice, Delegate would have parts and behaviors to help implement ProxyPortType2.
Case:
pDelegatesToPortOfPart:ProxyPortType3 has a BindingConnector to a port p:DelegatePortType of part :DelegateWithPort, where block DelegatePortType specialises the InterfaceBlock ProxyPortType3. These are compatible "by type design"; the details of DelegatePortType are completely irrelevant, as long as the contract matches such that the proxy port and the delegate port can be considered to have the same "value".
It does NOT matter whether the Port on the delegate is a "standard" Port, a ProxyPort, or a FullPort, neither the ProxyPort nor the client to the ProxyPort know or care, and it can even be changed any time during the design, as long as the "exported" contract is still met!
Case: The type of
pRequiresProvides1:ProxyPortType4 provides (has an InterfaceRealization to) Interface IProvide and requires (has a Usage to) Interface IRequire. The proxy port has a BindingConnector to a part :DelegateRP, where block DelegateRP provides and requires the same Interfaces.
Case: The type of
pRequiresProvides2:ProxyPortType4 provides (has an InterfaceRealization to) Interface IProvide and requires (has a Usage to) Interface IRequire. The proxy port has a BindingConnector to a port p:PortTypeRP of part :DelegateWithPortRP, where block PortTypeRP provides and requires the same Interfaces and is specialised by the InterfaceBlock ProxyPortType4. It's done that way round deliberately here as a kind of counter-example:
If you try to manage compatibility (say to reuse an existing block library) by extending a Block by an InterfaceBlock for a ProxyPort yourmust be very careful not to inherit behaviors or internal parts into the InterfaceBlock, because they are not allowed!
In any case, the ports are compatible "by type design" and the validation engine approves.
Case:
pFlow1:ProxyPortWithFlow has a BindingConnector to a part :SpecialFlowDelegate, where block SpecialFlowDelegate specialises the InterfaceBlock ProxyPortWithFlow, which has a FlowProperty i:Water. These are compatible "by type design".
Case:
pFlow2:ProxyPortWithFlow has a BindingConnector to a part sfd1:StandaloneFlowDelegate, where the block StandaloneFlowDelegate has exactly the same FlowProperty i:Water as InterfaceBlock ProxyPortWithFlow but does not have an explicit type relationship to it.
Whether one thinks it should validate depends somewhat on one's interpretation of equal "value" binding as intended by the SysML spec, but it is asserted here that it should work.
Case:
pFlow3:ProxyPortWithFlow has a BindingConnector from its FlowProperty i:Water to a matching FlowProperty i:Water of a part sfd2:StandaloneFlowDelegate.
The validation engine likes it; but it's a tedious strategy if you have lots of properties to bind, and it does not address Operation or Reception compatibility anyway.
Case:
pFlow4:ProxyPortWithFlow has a BindingConnector to a port i:PortWithFlow of a part :FlowDelegateWithPort, where block PortWithFlow specialises the InterfaceBlock ProxyPortWithFlow, which has a FlowProperty i:Water. These are compatible "by type design".
Case: pFlow3:ProxyPortWithFlow has a BindingConnector to a port i:PortWithFlow of a part :FlowDelegateWithPort, where block PortWithFlow specialises the InterfaceBlock ProxyPortWithFlow, which has a FlowProperty i:Water. These are compatible "by type design".
And finally, we show (only) a nested proxy port
pStructured:ProxyPortTypeStructured which itself has a proxy port pNested:ProxyPortNested, noting that nested ports of proxy ports must also be proxy ports.
SysML-1.6: 'InterfaceBlock::3_interfaceblock_typed_ports Ports owned by interface blocks shall only be typed by interface blocks.'
The connection cases for the nested port are too complex to handle here now, so the nested port is simply shown
Are you dizzy yet ? Head hurting? Don't fear, just follow the Webel Best Practice tips and modelling examples here and soon you'll develop a pattern for modelling with ports and "get in the flow" so-to-speak.
Ultimately, the many cases we've just inspected correspond to situations that do occur in a wide range of real-world engineering situations, and reveal the power and flexibility of Systems Modeling Language v1 (SysML®) that simulation tools are already beginning to build upon.