Issue 11820: ports in GCM (marte-ftf) Source: Commissariat a l Energie Atomique-CEA (Dr. Chokri Mraidha, chokri.mraidha(at)cea.fr) Nature: Clarification Severity: Significant 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. Resolution: 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. Revised Text: see ptc/2009-05-12 pages 30 -36 Actions taken: December 19, 2007: received issue October 16, 2009: closed issue Discussion: Discussion: While flow ports brings new concepts that are relevant for the real-time and embedded domain (flow-oriented communications), message ports have been introduced in MARTE just as a short-hand notation for existing UML features (provided and required interfaces). As a consequence, using message ports may create redundancy and inconsistency with the UML composite structures, as mentioned in the summary of this issue. Providing a clarification on this issue might require starting a discussion on the rationale of message ports in GGM. Unfortunately, this discussion cannot be organized in the time frame of the current FTF. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 19 Dec 2007 09:00:23 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Chokri Mraidha Company: CEA LIST mailFrom: Chokri.Mraidha@cea.fr Notification: Yes Specification: UML profile for MARTE Section: 11 FormalNumber: ptc/07-08-04 Version: Beta 1 RevisionDate: August 2007 Page: 117-127 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description 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.