MARTE 1.0b2 FTF Avatar
  1. OMG Issue

MARTE — ports in GCM

  • Key: MARTE-74
  • Legacy Issue Number: 11820
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Chokri Mraidha)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Wed, 19 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    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
    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
    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT