A post by guest author Axel Scheithauer:
SysML is based on the UML, and I think that was a good choice. However, some concepts of the UML don’t make sense in the world of systems and then sometimes lead to not so useful ideas, like typed binding connectors (how many user defined types of equality are there?).
One of these concepts is the possibility to conjugate ports. You probably know that ports are interaction points of blocks, used to connect them in an internal block diagram with other parts of the system. In the diagram below the Fuel Dispenser is connected via ports of type FuelpumpInterface with the Tank.
Ports have types and these are used to determine, whether it makes sense to connect two ports. This compatibility test is quite easy when both ports have the same type. Or course ports of the same type are not directly compatible. They need to complement each other: What one of them is requiring, like the operation isFull():Boolean, must be provided by the other side. When we want to use the same type on both sides, the type of the other side has to be turned inside out in a way: All provided features have to be required and vice versa. That’s what the conjugation does, shown in the diagram with a prepended tilde (~FuelpumpInterface).
So far so good. The problem starts, as soon as the model gets developed further. At the end of the day, some block needs to provide the required features. This block should be a specialization of the interface block since the interface block specifies what needs to be provided and the implementing block describes how it is done.
For the conjugated port, this type is only existing virtually. And it is not possible to specialize a non-existing block. That is not necessarily a problem since it is possible to prove the compatibility between the conjugated port and the implementing block by comparing feature by feature. In practice, though it would be desirable to have a more formal connection between the block and the corresponding interface block.
To find a solution, it pays to consider the original semantics for the conjugation. Unfortunately, the UML-specification is of no great help here. However, I have a mail from Bran Selic, author of this part of the specification, where he writes, that the type of a port describes a “system defined” object, whose embodiment is not accessible to the modeler. Insofar it poses no problem to think about a conjugated object. This is just another “system defined” object.
This interpretation doesn’t work for the SysML though. Here we talk about ports being abstract proxies for the real, modeler created blocks (full ports are a different subject and not relevant to this discussion).
The natural relation between abstract proxy and concrete block is the specialization. This means we need real types on both sides of a connector. These types need only to specify, what must be provided by the specializing block. What this block is requiring is not implemented by it, thus it doesn’t need to be a feature of the specialized interface block. But how can we specify then, that an interface block requires certain features from the block on the opposite side of the connector? Well, the problem is solved already: In SysML 1.2 a usage relation was designated for this. Admittedly they are mentioned only for UML interfaces (which have fallen out of favor in SysML 1.3), but nothing stops us from using them between interface blocks. Then we get the adjacent diagram: Two interface blocks describing two sides of one interface. Therefore I gave them the same name and only prepended respectively appended a tilde.
This is an elegant solution to the problem. It works with existing elements and looks clearly laid out.
Why did I choose such a provocative title? If the problem is not solved in this way, the only other possibility seems to be a monster of a construction: The type of the conjugated port needs to get devirtualized, i.e. become a real type. Either this is work for the modeler or for the tool. With the exception of a few properties (provided↔required), the original and the conjugated type are equal and the tool has to synchronize any changes. A four page OCL-constraint is needed to define this formally (see SysML-Issue SYSML16-132. This will be by far the longest constraint in the specification). When it takes such an effort to assure that two elements are equal – maybe, in reality, they are the same element? Just to keep the conjugation, the language would get bloated and the semantics of their elements obnubilated.
In my view, this enormous effort only shows, that the conjugation is a concept inapt for SysML. What do you think?
PS: The conjugation can still be useful in simple cases. Just don’t use it, if you plan to specify concrete implementations of the proxies.