MARTE — ports in GCM

This issue is about ports in GCM. In UML if a port is typed with an interface, this interface is automatically considered as provided by the port (see port description section 9.3.11 in UML Superstructure). In GCM it is possible to type a MessagePort with an interface (BFeatureSpecification). Moreover if a MessagePort direction is specified to be "required", and if the port is typed with a BFeatureSpecification interface, this interface contents are considered to be provided by the port according to UML. This results in a confusing specification: a MessagePort specifying a required interface provides that interface at the same time.

Using message ports may create redundancy and inconsistency with the UML composite
structures, as mentioned in the summary of this issue. Indeed, BFeatureSpecification can own
FlowBFeatures, where some of the features may have their ‘’kind’’ set to ‘’provided’’, and some
others set to ‘’required’’. According to UML interface derivation rules, this may lead to ambiguous
cases where a BFeatureSpecifcation (used to type a message port) is considered to be provided
by the port, even if some of the behavioral features of the BFeatureSpecification actually
represent ‘’required’’ features. A similar problem appears when a message port, with direction set
to Required, is typed by an interface (i.e. the default rule in UML is that this interface is supposed
to be provided by the port). [Note: More generally, the issue described here also concerns
non-atomic flow ports, i.e. flow ports that are typed by a FlowSpecification. According to
UML interface derivation rule, the FlowSpecification used to type the port would also be
considered as a provided interface.].
The proposed resolution for issue 11820 is designed according to the following guidelines:
• it provides a mechanism for specifying provided and required interfaces of standard UML
ports, in a way that is more intuitive and direct that the standard UML mechanism (which
relies on derivation rules based on the port type, and which is particularly tedious for defining
interfaces required by a port. Indeed, it technically implies to define a Classifier with a « use » relationship that targets the set of Interfaces to be required). It was indeed the original
motivation for the ClientServerPort stereotype.
• it should avoid conflicts with default UML rules concerning interface derivation, based on port
type.
The general idea behind the proposal is that ClientServerPorts can be used in different ways. The
current solution explicitly identifies two usages (c.f. definition of /isAtomic = true or false) whereas
in the resolution we identify three potential usages according to designer intent:
• atomic usage: the designer wants to directly associate a signal with the port (i.e. the port is
typed by the signal), specifying that the component owning the port is either able to send (i.e.
ClientServerPort::kind = required) or receive (i.e. ClientServerPort::kind = provided) the signal
via this port.
• interface-based usage: the designer wants to directly provide and/or require standard UML
interfaces on a port.
• feature-based usage: the designer wants to associate a ClientServerSpecificaion (i.e. a
consistent set of behavioral features, some of which may be provided or required) with the
port.
Additionally, issues 12802 (difference UML Port and MessagePorts) and 12801 (semantic
difference between an atomic FlowPort typed by a signal and a MessagePort typed by a signal)
have been stated as duplicate/merge with this issue. We provide a resolution for these issues in
the revised text of the GCM chapter, described in this document. For issue 12802: Some text is
added to explain that ClientServerPort (formerly MessagePort) is just a kind of syntactic sugar for
UML Ports. Concerning issue 12801: we explain that FlowPorts and ClientServerPorts are almost
semantically equivalent when signals are used to characterize their potential interactions (i.e.
atomic FlowPort typed by a signal S, atomic ClientServerPort typed a signal S, or non-atomic
ClientServerPort exposing a Reception for a signal S).
Additionally, issue 12579 (that has been stated as duplicate/merge with this issue) concerns the
renaming of elements (i.e. FlowBFeature) that are involved in the definition of MessagePort itself.
We start this ‘’merged resolution’’ with the resolution of issue 12579.
The primary reason of this name was to have a name constructed in a similar way than to the one
of the FlowPorperty but dedicated to BehavioralFeature. I (Me, Sébastien Gérard, the original
author of that concept) agree that this name is may be not the best one…
Moreover as similar concepts exist in AUTOSAR, a very important standard for automotive
domain and with which it is expected that MARTE will have strong relationships in near future, I
propose to do following renamings:
• FlowBFeature => ClientServerBFeature • BFeatureSpecification => ClientServerSpecification
• MessagePort => ClientServerPort
PS: I propose not only to rename FlowBFeature, but also the other concepts related to
MessagePort, for global consistency of the specification.