Issue 14910: NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). (marte-rtf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Revision Severity: Critical Summary: NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation Resolution: The issue addresses the absence of operations for the datatype NFP_CommonType (and its children types such as NFP_Duration) capturing predefined operators applying on these types. One of the consequences of this absence is that it is not possible to manipulate values of these in datatypes in VSL infix expressions (such as “"(end - start) < (value=10.0, unit=ms)", which would imply that operator ‘<’ is available for NFP_Duration). As suggested by the issue description, one possible solution would be to modify the existing MARTE libraries, by adding required operations to NFP_CommonType or its children datatypes. The main drawback of this approach is that, each time a user identifies a need for an operator which is not supported by a datatype from the MARTE libraries, the library needs to be modified, by adding the corresponding operation to the datatype. This solution is not flexible. The idea of the resolution described in the section “revised text” is to provide users with a flexible mechanism for stating that a given predefined operator can be used on a particular type (in the context of infix VSL expressions). The core idea behind this resolution is to rely on the new features introduced in the resolution to issue 15100. The resolution to this issue introduces additional syntactic rules to VSL for expressing behavior calls (i.e., BehaviorCallExpression). As described in the resolution to this issue, defining behavior signatures following a procedural style (i.e., capturing signatures by behaviors instead of operations on DataTypes) can help to limit the coupling between type definitions and behavior signature definitions (since signatures are no longer captured as operations of data types). Relying on Behaviors instead of Operations for capturing new operators (e.g., adding predefined operators for NFP_CommonType) would therefore avoid modifications of existing libraries. In order to capture the fact that a given behavior actually represents an operator, a new stereotype, « Operator », is introduced in this resolution. Some text is also provided regarding how this information can be automatically exploited by a VSL parser, regarding type inference and scoping. Revised Text: see pages 98 - 104 of ptc/2010-08-30 for revised text Actions taken: December 31, 2009: received issue January 14, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 31 Dec 2009 08:03:56 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: SĂ©stien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: MARTE Section: Annex D FormalNumber: 09-11-02 Version: 1.0 RevisionDate: 11/2009 Page: 490 Title: NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). Currently two NFP_Duration cannot be compared one another. Nature: Revision Severity: Critical test: 3qw8 B1: Report Issue Description: Date: Mon, 15 Mar 2010 16:34:52 +0100 From: SĂ©stien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Huascar Espinoza CC: GERARD Sebastien 166342 , marte-rtf@omg.org Subject: Re: MARTE: issue http://www.omg.org/issues/marte-rtf.html#Issue14910 Huascar, The primitive type Integer has an operation +(i: Integer): Integer. NFP_Integer extends Integer and implicitly inherits the + operation. As a consequence, quite a number of combinations are considered as valid from a typing point of view, even though the semantics are not clear : Integer + Integer => Integer (OK) NFP_Integer + NFP_Integer => NFP_Integer (OK) Integer + NFP_Integer => Integer (?) NFP_Integer + Integer => Integer (?) NFP_Integer + Integer => NFP_Integer (?) Integer + NFP_Integer => NFP_Integer (?) As you can see, there are some cases where the types of these expressions are not so clear. However, a parser needs to distinguish these situations. Thanks, SĂ©stien Huascar Espinoza a Ă©it : Sebastien D., It could be useful to start by telling why "Figure D.7 - Inherited Operations for NfpTypes" is not implementable in parsers. I agree that perhaps this is not the best solution, but I cannot realize why is not implementable. Thank you! Huascar -------------------------------------------------------------------------------- From: SĂ©stien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Sent: lunes, 08 de marzo de 2010 11:44 To: GERARD Sebastien 166342 Cc: Huascar Espinoza; marte-rtf@omg.org Subject: Re: MARTE: issue http://www.omg.org/issues/marte-rtf.html#Issue14910 SĂ©stien, The primary need is to support expressions like : (end - start) < (value=10.0, unit=ms) These expression involve above all "==", "<", ">" operators. Other operators could interesting and supported as well, but they are maybe not in our high-priority list. Thanks, SĂ©stien GERARD Sebastien 166342 a Ă©it : Dear Huascar and Sebastien, Could you start a discussion (please let the marte mailing list in copy or at leat me of your exchanges) about that issue http://www.omg.org/issues/marte-rtf.html#Issue14910. SĂ©stien, why did you not mention operator / ? Cheers. SĂ©stien G. Dr. SĂ©stien GĂ©rd Head of MDD for DRES research project CEA LIST, Laboratoire d.IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE) BoĂ® courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment ************************************ DISCLAIMER ***************************************** This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ************************************* AVISO LEGAL **************************************** Este mensaje puede contener informaciĂłonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ***************************************************************************************** Date: Mon, 08 Mar 2010 11:51:33 +0100 From: =?ISO-8859-4?Q?S=E9bastien_Demathieu?= Organization: Thales Research & Technology User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Huascar Espinoza CC: marte-rtf@omg.org, GERARD Sebastien 166342 , CUCCURU Arnaud Subject: Re: [MARTE] NFPs, VSL, and Library Huascar, Regarding 14910, we should consider duplicating/specialising operators for each NFP type. It may not be an optimal solution but it would make some very useful VSL expressions implementable in a tool. Regarding 14893, we indeed agreed to sync with the QUVD working group. We could however provide a resolution that cover part of the issue by renaming the Dimension stereotype into QuantityKind (like in the SysML 1.2 spec). Thanks, SĂ©stien Huascar Espinoza a Ă©it : Sorry it was not 14919... it is 14910 -------------------------------------------------------------------------------- From: Huascar Espinoza Sent: lunes, 08 de marzo de 2010 11:32 To: marte-rtf@omg.org Cc: SĂ©stien Demathieu; GERARD Sebastien 166342; 'CUCCURU Arnaud' Subject: [MARTE] NFPs, VSL, and Library Hi, In addition to Arnaud's issues, I'd like to let you know that there were some short emails to try to clarify some issues related to NFP, VSL, and MARTE Library: --> 14910. NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -) The RTF solved this issue by adding an inheritance between MARTE primitive types and MARTE NFP data types. This is not sufficient, according to Sebastien D., to implement in VSL parsers. So far, I don't have another solution, but maybe we should look at Issue 15100 (recently commented by Arnaud) to have a flexible solution to add new function/operations (math, logical functions, etc.) without changing the MARTE library every time. --> 14893: Align the NFP profile and domain model with the QUVD meta-model We agreed with Sebastien D. (source of the issue) that we should look at the work of the QUVD SysML sub-group (there is a mailing list for that) and wait to have an stable version before proposing any change in MARTE. QUVD is working in aligning SysML QUVD with other Onologies and Time groups at OMG. --> The other issues are easy to solve (mistakes or trivial modifications), and I plan to provide some resolutions on the upcoming days. All feedback is welcome. Regards, Huascar ************************************ DISCLAIMER ***************************************** This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ************************************* AVISO LEGAL **************************************** Este mensaje puede contener informaciĂłonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ***************************************************************************************** Date: Fri, 28 May 2010 13:25:41 -0400 From: "Chonoles, Michael J" Subject: RE: MARTE Ballot 2: Problem with resolution of Issue 14910 To: "Chonoles, Michael J" , GERARD Sebastien 166342 , "marte-rtf@omg.org" Thread-Topic: MARTE Ballot 2: Problem with resolution of Issue 14910 Thread-Index: Acr8DzFGhiB+VCqbR2y6U/G7O41oSgCdSC1AAAA8MrAAALi2AA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: I.m sorry but the issue is not resolved there. The resolution is as given Revised Text: TBD I don.t think that is any resolution. Are we to vote on this? From: Chonoles, Michael J Sent: Friday, May 28, 2010 12:52 PM To: Chonoles, Michael J; GERARD Sebastien 166342; marte-rtf@omg.org Subject: RE: MARTE Ballot 2: Problem with resolution of Issue 13655 In this issue, Dr. Espinoza, identifies a missing attribute for the GRM::SchedulableResource. The responder indicates that the missing attribute does not belong on SchedulableResource and closes it as not in the scope of GRM. See below: Discussion: The activation pattern is a characteristic of the application, not of the platform. In fact it is usually different in each execution scenario. The concept of task, as used in languages and formalisms is for all of them a way to create an application, not a description of the platform. A modeling element that may serve for this purpose would be much closer in meaning to an RTUnit than to a SchedulableReource. So the extension requested is not in the scope of GRM. A task is clearly a design modeling element and if not in HLAM it may probably fit in SRM. Is this RTF for GRM or for MARTE as a whole? We normally don.t require the issue writer to completely describe the fix. Are you requesting Dr Espinoza to reword it against HLAM, and if that doesn.t work, to reissue it against SRM? I believe the RTFs responses should speak for the RTF, not just the area of one package leader. Michael Lockheed Martin From: Chonoles, Michael J Sent: Friday, May 28, 2010 12:43 PM To: 'GERARD Sebastien 166342'; marte-rtf@omg.org Subject: MARTE Ballot 2: Problem with resolution of Issue 12411 Looking at the resolution 12411 (no-change), the discussion says: Discussion: The example is not a composite structure; the caption text of the figure may have mislead the reader. It shows just a class diagram with dependencies among them. It seems to me, that if we can find a part of the spec to blame for the confusion, then that part of spec should be changed. In this case, the change should be simple and non-controversial. But as currently stated, LMCO would not vote for ignoring a confusing caption. Michael Jesse Chonoles Lockheed Martin From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, May 25, 2010 9:36 AM To: marte-rtf@omg.org Subject: MARTE 1.1 RTF: start of ballot 2 voting period Hi all, Following this link you will find a bundle of the resolutions gathered in the ballot 2 for MARTE 1.1 RTF: http://www.omgwiki.org/marte1.1-rtf/doku.php?id=marte_1.0_rtf_ballot_2#voting_material_for_ballot_2 The timing for the MARTE 1.1 RTF ballot 2 voting period is: From Mai 25 to June 5 (12 pm CET), 2010. For memory, following companies did not vote on ballot1: 88solutions (Manfred Koethe), BAE SYSTEMS (Stu Lewin), EADS (Yves Bernard), International Business Machines (Irv Badr - co-chair), No Magic, Inc. (Andrius Strazdauskas) and Universidad de Cantabria (Julio Mdeina). èf these companies miss the next vote, according to the rules, they will lost their voting right from the RTF!!! Thanks for your incoming votes, Best. SĂ©stien. Dr. SĂ©stien GĂ©rd Head of MDD for DRES research project CEA LIST, Laboratoire d.IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE) BoĂ® courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment Subject: MARTE Ballot 2: Problem with resolution of Issues 14910 Date: Sat, 29 May 2010 19:08:59 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MARTE Ballot 2: Problem with resolution of Issues 14910 Thread-Index: Acr8DzFGhiB+VCqbR2y6U/G7O41oSgCdSC1AAAA8MrAAALi2AAAyR3YA From: "GERARD Sebastien 166342" To: "Chonoles, Michael J" , X-OriginalArrivalTime: 29 May 2010 17:08:59.0196 (UTC) FILETIME=[A0FEAFC0:01CAFF51] Hi Michael, Thanks for the feedback. For issue 14910: yes you are right. I thought this issue was solved but I was wrong. I will withdraw this latter from Ballot2. Thanks, Best. SĂ©stien. Ps: For all, again I would have appreciated much more feedback on the issues contained within the ballot at the time of the discussion period instead at the time of voting period. Dr. SĂ©stien GĂ©rd Head of MDD for DRES research project CEA LIST, Laboratoire d.IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE) BoĂ® courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] EnvoyĂ© vendredi 28 mai 2010 19:26 Ă€: Chonoles, Michael J; GERARD Sebastien 166342; marte-rtf@omg.org Objet : RE: MARTE Ballot 2: Problem with resolution of Issue 14910 I.m sorry but the issue is not resolved there. The resolution is as given Revised Text: TBD I don.t think that is any resolution. Are we to vote on this? From: Chonoles, Michael J Sent: Friday, May 28, 2010 12:52 PM To: Chonoles, Michael J; GERARD Sebastien 166342; marte-rtf@omg.org Subject: RE: MARTE Ballot 2: Problem with resolution of Issue 13655 In this issue, Dr. Espinoza, identifies a missing attribute for the GRM::SchedulableResource. The responder indicates that the missing attribute does not belong on SchedulableResource and closes it as not in the scope of GRM. See below: Discussion: The activation pattern is a characteristic of the application, not of the platform. In fact it is usually different in each execution scenario. The concept of task, as used in languages and formalisms is for all of them a way to create an application, not a description of the platform. A modeling element that may serve for this purpose would be much closer in meaning to an RTUnit than to a SchedulableReource. So the extension requested is not in the scope of GRM. A task is clearly a design modeling element and if not in HLAM it may probably fit in SRM. Is this RTF for GRM or for MARTE as a whole? We normally don.t require the issue writer to completely describe the fix. Are you requesting Dr Espinoza to reword it against HLAM, and if that doesn.t work, to reissue it against SRM? I believe the RTFs responses should speak for the RTF, not just the area of one package leader. Michael Lockheed Martin From: Chonoles, Michael J Sent: Friday, May 28, 2010 12:43 PM To: 'GERARD Sebastien 166342'; marte-rtf@omg.org Subject: MARTE Ballot 2: Problem with resolution of Issue 12411 Looking at the resolution 12411 (no-change), the discussion says: Discussion: The example is not a composite structure; the caption text of the figure may have mislead the reader. It shows just a class diagram with dependencies among them. It seems to me, that if we can find a part of the spec to blame for the confusion, then that part of spec should be changed. In this case, the change should be simple and non-controversial. But as currently stated, LMCO would not vote for ignoring a confusing caption. Michael Jesse Chonoles Lockheed Martin From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, May 25, 2010 9:36 AM To: marte-rtf@omg.org Subject: MARTE 1.1 RTF: start of ballot 2 voting period Hi all, Following this link you will find a bundle of the resolutions gathered in the ballot 2 for MARTE 1.1 RTF: http://www.omgwiki.org/marte1.1-rtf/doku.php?id=marte_1.0_rtf_ballot_2#voting_material_for_ballot_2 The timing for the MARTE 1.1 RTF ballot 2 voting period is: From Mai 25 to June 5 (12 pm CET), 2010. For memory, following companies did not vote on ballot1: 88solutions (Manfred Koethe), BAE SYSTEMS (Stu Lewin), EADS (Yves Bernard), International Business Machines (Irv Badr - co-chair), No Magic, Inc. (Andrius Strazdauskas) and Universidad de Cantabria (Julio Mdeina). èf these companies miss the next vote, according to the rules, they will lost their voting right from the RTF!!! Thanks for your incoming votes, Best. SĂ©stien. Dr. SĂ©stien GĂ©rd Head of MDD for DRES research project CEA LIST, Laboratoire d.IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE) BoĂ® courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment BSubject: RE: [MARTE] NFPs, VSL, and Library Date: Mon, 8 Mar 2010 11:32:43 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MARTE] NFPs, VSL, and Library thread-index: Acq7obJc8sOhcYTRQ3yET2mPlSsptQAACNagAMD5YCAAAKubwAAAjAoQ From: "Huascar Espinoza" To: Cc: Sébastien Demathieu , "GERARD Sebastien 166342" , "CUCCURU Arnaud" X-ESI-MailScanner-Information: Please contact the ISP for more information X-ESI-MailScanner: Found to be clean X-ESI-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.882, required 3, autolearn=not spam, AWL 0.12, BAYES_00 -3.00, HTML_MESSAGE 0.00) X-MailScanner-From: huascar.espinoza@esi.es Sorry it was not 14919... it is 14910 -------------------------------------------------------------------------------- From: Huascar Espinoza Sent: lunes, 08 de marzo de 2010 11:32 To: marte-rtf@omg.org Cc: Sébastien Demathieu; GERARD Sebastien 166342; 'CUCCURU Arnaud' Subject: [MARTE] NFPs, VSL, and Library Hi, In addition to Arnaud's issues, I'd like to let you know that there were some short emails to try to clarify some issues related to NFP, VSL, and MARTE Library: --> 14910. NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -) The RTF solved this issue by adding an inheritance between MARTE primitive types and MARTE NFP data types. This is not sufficient, according to Sebastien D., to implement in VSL parsers. So far, I don't have another solution, but maybe we should look at Issue 15100 (recently commented by Arnaud) to have a flexible solution to add new function/operations (math, logical functions, etc.) without changing the MARTE library every time. --> 14893: Align the NFP profile and domain model with the QUVD meta-model We agreed with Sebastien D. (source of the issue) that we should look at the work of the QUVD SysML sub-group (there is a mailing list for that) and wait to have an stable version before proposing any change in MARTE. QUVD is working in aligning SysML QUVD with other Onologies and Time groups at OMG. --> The other issues are easy to solve (mistakes or trivial modifications), and I plan to provide some resolutions on the upcoming days. All feedback is welcome. Regards, Huascar ************************************ DISCLAIMER ***************************************** This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ************************************* AVISO LEGAL **************************************** Este mensaje puede contener información confidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado está prohibido legalmente. ***************************************************************************************** B B B B B B NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation).