Issue 11835: RTEConnector should be removed from RTEMoCC (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Revision Severity: Significant Summary: Subject: RTEConnector should be removed from RTEMoCC The chapter 13 defines a model of computation for active objects and passive objects. It precisely defines the metaclasses involved in this model of computation, building upon the MARTE foundation packages (e.g. GRM). Additionally, chapter 13 introduces the concept of RteConnector, which is basically a specialization of a UML connector with additional NFP. While the definition of active/passive object provide useful features for RTES design. The concept of real-time connector is more discutable. This concept overlaps with GRM::CommunicationMedia. It seems that all that relates to NFP characterics of a communications between entities should be defined in GRM::CommunicationMedia (latency, jitter, bandwith) As a beneficial side effect, removing RTEConnector whould remove the depdendency from RTEMoCC to GCM, which is not usued anywhere else. Proposed resolution: remove RTEConnector metaclass and stereotype and push the related attributes (bandwith, blockT, packetT, transMode) into GRM (e.g., in CommunicationMedia). Resolution: Remove RTEMoCC::RteConnector and refactor GRM::CommunicationsMedia to gain the attributes of the deleted RteConnector, and update the elements that use similar attributes in the rest of the spec so that they become consistent, that is at least in HwMedia. Revised Text: Delete Figure 13.7 and the last paragraph of page 154 which continues onto page 155. Delete entirely Section 13.3.2.8 on page 161. Delete entirely Section F.7.11 on page 549. Delete attribute bandwith in the definition of HwMedia in section 14.2.3.2, in section F.9.28, and in Figure 14.70 In Section 10.3.2.4, on page 101, add the following bullet phrases: o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. In Section F.4.7, on page 515, add the following bullet phrases: o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. In Figure 10.8, on page 91, show the attributes for CommunicationMedia as stated in Section 10.3.2.4. Actions taken: December 20, 2007: received issue February 17, 2010: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 20 Dec 2007 13:39:56 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: UML profile for MARTE Section: 13 FormalNumber: 07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 155 Nature: Revision 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 Subject: RTEConnector should be removed from RTEMoCC The chapter 13 defines a model of computation for active objects and passive objects. It precisely defines the metaclasses involved in this model of computation, building upon the MARTE foundation packages (e.g. GRM). Additionally, chapter 13 introduces the concept of RteConnector, which is basically a specialization of a UML connector with additional NFP. While the definition of active/passive object provide useful features for RTES design. The concept of real-time connector is more discutable. This concept overlaps with GRM::CommunicationMedia. It seems that all that relates to NFP characterics of a communications between entities should be defined in GRM::CommunicationMedia (latency, jitter, bandwith) As a beneficial side effect, removing RTEConnector whould remove the depdendency from RTEMoCC to GCM, which is not usued anywhere else. Proposed resolution: remove RTEConnector metaclass and stereotype and push the related attributes (bandwith, blockT, packetT, transMode) into GRM (e.g., in CommunicationMedia). Date: Thu, 24 Apr 2008 20:54:15 +0200 From: Julio Medina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Sébastien Demathieu , marte-ftf@omg.org Subject: MARTE FTF: Issue 11835 please consider also Issue 11842 for consistency X-OriginalArrivalTime: 24 Apr 2008 18:54:16.0073 (UTC) FILETIME=[9822DF90:01C8A63C] X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:5.5.1026(15870.001) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:2 S:2 R:2 (0.0000 0.0000) Seb, Murray I do not know who wrote the resolution for Issue 11835, but may you please change a bit the text of the resolution so that it takes into account the issue 11842 that closely relates to this..? I include in attachment the modified resolution for this issue for your consideration. If RTEConnector is removed from RTEMoCC, the attributes in there go to CommunicationMedia in GRM, but they must be explained with some more general text. For consistency, as stated in issue 11842 (placed in GRM_WG). The bandwidth attribute should be removed from HwMedia (it is accessible inherited from GRM::CommunicationMedia. This solution unfortunately may impact terminology in future GQAM variations, where different names are used for the same concepts. Now the conflict is not present since there is not direct inheritance. Considering that issue 11835 is in the same ballot all changes should be consistently indicated to vote for them in that issue. For this reason I have marked 11842 as duplicated, and insert the corresponding changes over the current draft for 11835. If the lack of inheritance in GQAM is a mistake, then this nomenclature will have to be aligned/refined, I guess this may be inserted as an additional issue today or tomorrow and marked as deferred of course. Thanks, Julio