Issue 11544: Annex D (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Enhancement Severity: Minor Summary: Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart Resolution: One aspect that appears here is that the operations for NFP types like NFP_Real, NFP_String, etc, should be the same as the primitive type counterparts. So, it seems natural to reuse those operation definitions. One mechanism to reuse the operations (e.g., +, -, *, /, =, <, >) is to inherit NFP types from the primitive types. Hence, this resolution proposes to define the operations of Nfp_Types by inheriting from the corresponding MARTE primitive types. In addition, the semantic of such NfpTypes operations (in physical Nfp_Types such as NFP_Duration, NFP_Temperature, etc.) are different than their primitive type counterparts (Real primitive types). Indeed, operations in NfpTypes involve evaluating not only the “value” part but also the measurement “unit” part. This is left out of the scope of this specification, and an implementation supporting measurement unit conversion should take care of this. Revised Text: see ptc/2009-05-12 pages 16 - 17 Actions taken: October 8, 2007: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 08 Oct 2007 11:08:56 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: A UML Profile for MARTE Section: Annex D FormalNumber: realtime/07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 437 Nature: Enhancement Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Description Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart. Subject: Issues 11876 and 11544 Date: Wed, 23 Apr 2008 10:54:42 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 11876 and 11544 Thread-Index: AcilH6uC6rVdtVioQxyhyz4YpLBwDQ== From: "ESPINOZA Huascar 218344" To: Cc: Sébastien Demathieu X-OriginalArrivalTime: 23 Apr 2008 08:54:42.0961 (UTC) FILETIME=[AC13D810:01C8A51F] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m3N8vFod016436 Hi all, [to ask your viewpoint before writing a resolution] There are two issues in Annex D (11878, 11544) that could be solved in a simple way by adding inheritance between primitive types. 11544 asks for adding operations to NFP types (+, -, * etc.), and 11878 asks for inheriting MARTE primitive types from UML primitive types of the same name. Thus for example, for 11544, if we add an inheritance to NFP_Real from Real, we will also have the same operations of Real (+, -, abs, etc.) in NFP_Real. Do you know some limitation in UML to specialize primitive types? Thank you for your help. Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE Date: Wed, 23 Apr 2008 15:38:41 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org, Laurent Rioux Subject: Re: Issues 11876 and 11544 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m3NDeaT8031041 Hi Huascar, In your e-mail below, I understand that you are referring to 11876 (primitive type inheritance in Annex D) and not 11878 (another issue in Annex B). Regarding 11876, I think it would be good, if possible, that MARTE primitive types extend UML primitive types. However, as you mentioned in your e-mail, I do not know if we are allowed to do that. Regarding 11544, I do not think that making NFP_BasicTypes subclasses of MARTE primitive types would be a good strategy, *even if it was allowed by UML*. Types defined in NFP_BasicTypes (such as NFP_Duration, NFP_Energy, NFP_Power) are tuples and cannot be considered as primitive types. Moreover, primitive types are currently gathered in another package of Annex D: MARTE_PrimitiveTypes. Introducing primitive types in other packages would be a change the organisation of Annex D. Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : Hi all, [to ask your viewpoint before writing a resolution] There are two issues in Annex D (11878, 11544) that could be solved in a simple way by adding inheritance between primitive types. 11544 asks for adding operations to NFP types (+, -, * etc.), and 11878 asks for inheriting MARTE primitive types from UML primitive types of the same name. Thus for example, for 11544, if we add an inheritance to NFP_Real from Real, we will also have the same operations of Real (+, -, abs, etc.) in NFP_Real. Do you know some limitation in UML to specialize primitive types? Thank you for your help. Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE Date: Fri, 24 Apr 2009 11:00:36 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Sebastien.GERARD@cea.fr CC: marte-ftf@omg.org Subject: MARTE: Thales votes to ballot 4 Thales votes Yes to the resolutions in ballot 4, except for 11838, 13341 (Abstain) and 11544 (No). In the case of 11544, the resolution does not adress the initial problem because operators can not apply to homogeneous types (e.g. a NFP_Real cannot be compared with another NFP_Real, a NFP_Duration cannot be compared with another one, etc.) Furthermore, the resolution to 11544 introduces a non-necessary and confusing generalization link between primitives types and NFP types. NFP types already aggregate primitive types, through a property "value" defined in all the NFP types. Thanks, Sébastien marte_ftf2_ballot4_Thales_2009-04-24.xls