UML22 — New proposal for conjugate types for ports

The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

Is this acceptable?

This issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive.
But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces.
For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted.
This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient.
However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types.
Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.