Issue 15081: GCM behavioral representation (marte-rtf) Source: Fundacion Tecnalia Research and Innovation (Mr Adrian Noguero, adrian.noguero(at)tecnalia.com) Nature: Enhancement Severity: Significant Summary: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. Resolution: The issue addresses two different problems. The first one regarding receptions in Activity diagrams and the second one regarding invocations in state machine diagrams. The first part of the issue can be closed, since it is possible to model this kind of receptions using UML AcceptEventActions; which can be associated with a GCMTrigger. Example 3, on Figure 12.23, illustrates this. The second part of the issue; however it is not currently covered by MARTE or UML. The proposed resolution is to add a new stereotype, GCMInvocatingBehavior, which models the invocations taking place inside a behavior without having to look at its internals (particularly interesting in the case of OpaqueBehaviors). This stereotype will allow specifying communications in the scope of a single component and independently from other components (in opposition with Interactions, which specify communications between different components, with a system wide scope). Revised Text: see pages 138 - 141 of ptc/2010-08-30 for revised text Actions taken: February 23, 2010: received issue January 14, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 23 Feb 2010 08:18:56 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: AdriáNoguero Company: ESI mailFrom: adrian.noguero@esi.es Notification: Yes Specification: MARTE Section: 12 FormalNumber: formal/2009-11-02 Version: 1.0 RevisionDate: 11/02/2009 Page: 139-176 Title: GCM behavioral representation Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Mon, 29 Mar 2010 15:17:31 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qw From: "CUCCURU Arnaud" To: "Adrian Noguero" , Séstien Demathieu Cc: "Huascar Espinoza" , X-OriginalArrivalTime: 29 Mar 2010 13:17:31.0427 (UTC) FILETIME=[300A8F30:01CACF42] Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Mon, 29 Mar 2010 15:42:13 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62A= From: "Adrian Noguero" To: "CUCCURU Arnaud" , Séstien Demathieu Cc: "Huascar Espinoza" , 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 (timed out) X-MailScanner-From: adrian.noguero@esi.es Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Fri, 23 Apr 2010 12:33:04 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4A== From: "CUCCURU Arnaud" To: "Adrian Noguero" Cc: , "GERARD Sebastien 166342" X-OriginalArrivalTime: 23 Apr 2010 10:33:04.0986 (UTC) FILETIME=[5B82E3A0:01CAE2D0] Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Fri, 23 Apr 2010 14:08:03 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQ From: "Adrian Noguero" To: "CUCCURU Arnaud" Cc: , "GERARD Sebastien 166342" 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 (timed out) X-MailScanner-From: adrian.noguero@esi.es Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** 15081_resolved_v01.doc Date: Fri, 23 Apr 2010 09:48:11 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Adrian Noguero cc: CUCCURU Arnaud , marte-rtf@omg.org, GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) Adrians proposal meshes very well with GQAM, since GQAM::WorkloadEvent can be applied to NamedElement, which is a generalization of both of the base classes for these invocation/event acceptance stereotypes. Thus a GQAM Scenario can be attached to these events, and they will be effective for analysis as well as modeling. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Fri, 23 Apr 2010, Adrian Noguero wrote: Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian ____________________________________________________________________________________________________ From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud ____________________________________________________________________________________________________ De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian ____________________________________________________________________________________________________ From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UM L Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationA ctions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in th e later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can?t say if this kind of information is useful or not (and therefore I can?t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don?t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud ____________________________________________________________________________________________________ De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): [IMAGE] With this modification, again using Papyrus for my example, I get the following diagram: [IMAGE] I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Fri, 23 Apr 2010 18:41:16 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NA= From: "CUCCURU Arnaud" To: "Adrian Noguero" Cc: , "GERARD Sebastien 166342" X-OriginalArrivalTime: 23 Apr 2010 16:41:16.0785 (UTC) FILETIME=[CB3FE610:01CAE303] Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** oledata4.mso image0015.emz Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Wed, 5 May 2010 09:01:58 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIA== From: "Adrian Noguero" To: "CUCCURU Arnaud" Cc: , "GERARD Sebastien 166342" 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.08, required 3, autolearn=not spam, AWL 0.92, BAYES_00 -3.00, HTML_MESSAGE 0.00) X-MailScanner-From: adrian.noguero@esi.es Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Fri, 21 May 2010 18:26:41 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIAM4nWsg From: "CUCCURU Arnaud" To: "Adrian Noguero" Cc: , "GERARD Sebastien 166342" X-OriginalArrivalTime: 21 May 2010 16:26:41.0845 (UTC) FILETIME=[654FA650:01CAF902] Hi Adrian, all, Sorry for not reacting earlier. Have you finalized a resolution including the minor modifications you mention in your email? If it is the case, could you please forward it on the list (well, I think that the discussion period finishes today, but maybe we can find time to react before the voting period starts)? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mercredi 5 mai 2010 09:02 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Mon, 24 May 2010 09:47:20 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) thread-index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIAM4nWsgAITMo2A= From: "Adrian Noguero" To: "CUCCURU Arnaud" Cc: , "GERARD Sebastien 166342" 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.158, required 3, autolearn=not spam, AWL 0.84, BAYES_00 -3.00, HTML_MESSAGE 0.00, HTML_NONELEMENT_00_10 0.00) X-MailScanner-From: adrian.noguero@esi.es Dear Arnaud and all, Please find attached a revised resolution proposal for issue 15081. If we are on time perhaps we can still include it in the resolutions for this ballot; else the work can be reused in following versions of the profile. Arnaud, do you think we would need an example about the usage of the new stereotype? If so we could include the example you sent in a previous mail, which I think is very good. Regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 21 de mayo de 2010 18:27 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Sorry for not reacting earlier. Have you finalized a resolution including the minor modifications you mention in your email? If it is the case, could you please forward it on the list (well, I think that the discussion period finishes today, but maybe we can find time to react before the voting period starts)? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mercredi 5 mai 2010 09:02 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** 15081_resolved_v03.doc Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Tue, 25 May 2010 11:08:30 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIAM4nWsgAITMo2AANQ9LQA== From: "CUCCURU Arnaud" To: "Adrian Noguero" Cc: , "GERARD Sebastien 166342" X-OriginalArrivalTime: 25 May 2010 09:08:32.0408 (UTC) FILETIME=[D93CE980:01CAFBE9] Hi Adrian, all, Thank you for the formalized proposal. Indeed, I think it is a good idea to include an example. You.ll find in attachment the visio sources for the example I sent last time. Feel free to modify it if needed. Sebastien is packaging the proposed resolution for this ballot, and plans to post it this afternoon for voting. Hopefully, your resolution can be included in it. Thank you, and best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 24 mai 2010 09:47 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and all, Please find attached a revised resolution proposal for issue 15081. If we are on time perhaps we can still include it in the resolutions for this ballot; else the work can be reused in following versions of the profile. Arnaud, do you think we would need an example about the usage of the new stereotype? If so we could include the example you sent in a previous mail, which I think is very good. Regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 21 de mayo de 2010 18:27 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Sorry for not reacting earlier. Have you finalized a resolution including the minor modifications you mention in your email? If it is the case, could you please forward it on the list (well, I think that the discussion period finishes today, but maybe we can find time to react before the voting period starts)? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mercredi 5 mai 2010 09:02 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** figure_issue_15081.VSD Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Tue, 25 May 2010 14:41:24 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) thread-index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIAM4nWsgAITMo2AANQ9LQAAH2ExA From: "Adrian Noguero" To: "CUCCURU Arnaud" Cc: , "GERARD Sebastien 166342" 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=-1.784, required 3, autolearn=not spam, AWL 1.07, BAYES_00 -3.00, HTML_80_90 0.15, HTML_MESSAGE 0.00) X-MailScanner-From: adrian.noguero@esi.es Hi Arnaud, all, Thank you for your input and your help. Here is an enriched version of the resoluton proposal including your example. Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: martes, 25 de mayo de 2010 11:09 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Thank you for the formalized proposal. Indeed, I think it is a good idea to include an example. You.ll find in attachment the visio sources for the example I sent last time. Feel free to modify it if needed. Sebastien is packaging the proposed resolution for this ballot, and plans to post it this afternoon for voting. Hopefully, your resolution can be included in it. Thank you, and best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 24 mai 2010 09:47 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and all, Please find attached a revised resolution proposal for issue 15081. If we are on time perhaps we can still include it in the resolutions for this ballot; else the work can be reused in following versions of the profile. Arnaud, do you think we would need an example about the usage of the new stereotype? If so we could include the example you sent in a previous mail, which I think is very good. Regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 21 de mayo de 2010 18:27 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Sorry for not reacting earlier. Have you finalized a resolution including the minor modifications you mention in your email? If it is the case, could you please forward it on the list (well, I think that the discussion period finishes today, but maybe we can find time to react before the voting period starts)? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mercredi 5 mai 2010 09:02 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** 15081_resolved_v04.doc Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Tue, 25 May 2010 15:16:46 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIAM4nWsgAITMo2AANQ9LQAAH2ExAAAFRk5A= From: "GERARD Sebastien 166342" To: "Adrian Noguero" , "CUCCURU Arnaud" Cc: X-OriginalArrivalTime: 25 May 2010 13:16:47.0915 (UTC) FILETIME=[87A6E7B0:01CAFC0C] Thanks. Adrian, can you put it on the MARTE wiki if it is not yet done? Thanks, 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 -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mardi 25 mai 2010 14:41 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, all, Thank you for your input and your help. Here is an enriched version of the resoluton proposal including your example. Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: martes, 25 de mayo de 2010 11:09 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Thank you for the formalized proposal. Indeed, I think it is a good idea to include an example. You.ll find in attachment the visio sources for the example I sent last time. Feel free to modify it if needed. Sebastien is packaging the proposed resolution for this ballot, and plans to post it this afternoon for voting. Hopefully, your resolution can be included in it. Thank you, and best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 24 mai 2010 09:47 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and all, Please find attached a revised resolution proposal for issue 15081. If we are on time perhaps we can still include it in the resolutions for this ballot; else the work can be reused in following versions of the profile. Arnaud, do you think we would need an example about the usage of the new stereotype? If so we could include the example you sent in a previous mail, which I think is very good. Regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 21 de mayo de 2010 18:27 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Sorry for not reacting earlier. Have you finalized a resolution including the minor modifications you mention in your email? If it is the case, could you please forward it on the list (well, I think that the discussion period finishes today, but maybe we can find time to react before the voting period starts)? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mercredi 5 mai 2010 09:02 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Date: Wed, 2 Jun 2010 10:56:18 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thread-Index: AcrPHJHq0uC5A0zJQByIQGlCuMLFXQAGs7qwAALu62AE4iiX4AAB/2eQAArs9NACR53nIAM4nWsgAITMo2AANQ9LQAAH2ExAAAFRk5ABiEyNsA== From: "BERNARD, Yves" To: "GERARD Sebastien 166342" , "Adrian Noguero" , "CUCCURU Arnaud" Cc: X-OriginalArrivalTime: 02 Jun 2010 08:56:19.0072 (UTC) FILETIME=[7770B800:01CB0231] Sorry for not having joint this discussion in time. I.m going to vote .No. on this resolution. The main reasons is that to model the invocations taking place inside a behavior independently of its internal may lead to consistency issues if not a derived information: this is not the way to go. More, we have currently in-deep discussion in the SysML RTF about the concept of port and it appears that there are inconsistencies in the UML specification about it. On the top of that, there is the ability for a port to be typed by a class, what would indicate that instances of ports have slots for properties at runtime. But on the other hand, UML §9.3.11 states clearly that port types define port.s owner features available at that port (and not features of the port itself), which is only an interaction point at runtime, what seems to indicate the opposite. From my point of view, it would be better to clarify the UML specification before adding any new construct involving ports in MARTE or any other profile. Yves De : GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Envoyé mardi 25 mai 2010 15:17 À: Adrian Noguero; CUCCURU Arnaud Cc : marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Thanks. Adrian, can you put it on the MARTE wiki if it is not yet done? Thanks, 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 -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mardi 25 mai 2010 14:41 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, all, Thank you for your input and your help. Here is an enriched version of the resoluton proposal including your example. Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: martes, 25 de mayo de 2010 11:09 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Thank you for the formalized proposal. Indeed, I think it is a good idea to include an example. You.ll find in attachment the visio sources for the example I sent last time. Feel free to modify it if needed. Sebastien is packaging the proposed resolution for this ballot, and plans to post it this afternoon for voting. Hopefully, your resolution can be included in it. Thank you, and best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 24 mai 2010 09:47 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and all, Please find attached a revised resolution proposal for issue 15081. If we are on time perhaps we can still include it in the resolutions for this ballot; else the work can be reused in following versions of the profile. Arnaud, do you think we would need an example about the usage of the new stereotype? If so we could include the example you sent in a previous mail, which I think is very good. Regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 21 de mayo de 2010 18:27 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, Sorry for not reacting earlier. Have you finalized a resolution including the minor modifications you mention in your email? If it is the case, could you please forward it on the list (well, I think that the discussion period finishes today, but maybe we can find time to react before the voting period starts)? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé mercredi 5 mai 2010 09:02 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud, all, First of all sorry for my delay in responding, I've been really busy these past weeks. You are absolutely right about atomic ports; thus we cannot have the onPorts and the onFeatures lists to have the same lengths. However, I think that the proposal is still valid as you presented it in the sensor example. In this case we should remove the constraint about the lengths of the list and we may include two extra constraints: - non-atomic ports cannot be contained in the onPorts list more than once. - If a feature is contained in the onFeatures list the port implementing the specification must be on the onPorts list. I also agree with you that making this link between feature and port more explicit would be very useful. However I cannot think of any way to do it without including an extra element definition (perhaps a DataType?). Cheers, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 18:41 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Adrian, I think I see a first problem with the current proposal. In GCM, the usage of a Flowport (respectively ClientServerPort) does not imply the usage of a FlowProperty (respectively ClientServerFeature). Indeed, FlowPort as well as ClientServerPort can be atomic, and this case, no FlowSpecification or ClientServerSpecification are used (which implies the absence of a FlowProperty or ClientServerFeature to be referenced). In the example below, Sensor owns an atomic flow port (outAtomic) as well as a non-atomic flow ports. According to the spec of the behavior Update (which is the effect of the transition in the classifier behavior of Sensor), there are two invocation actions nested in it. If we want to use the properties onPorts and onFeatures of GCMInvocatingBehavior to capture this information (this is what is done here), we cannot have the same number of elements in the two collections (here, 2 elements in onPorts, and one element in onFeatures). I think that a mechanism where the (potential) link between a port and a feature is made more explicit is needed. For the moment, I have however no idea on how it could be done. Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé vendredi 23 avril 2010 14:08 À: CUCCURU Arnaud Cc : marte-rtf@omg.org; GERARD Sebastien 166342 Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Arnaud, Séstien and all, Regarding your comments I have the following ideas that I would like to discuss with you: - I don't think that this stereotype should be moved to another chapter, since for me it seems to be very much related to components and the interactions between them. Adding this feature will be very useful for compositional verification; however I don't think this is the main reason why it should be included in MARTE, but for its expressivity. As Arnaud pointed out in a previous email, the main goal of the stereotype is to provide any Behavior the ability to define which interactions are triggered by it, without requiring to go deep into the internals of a behavior. I fully agree with you that it shouldn't be included in the profile as a feature for state machines, since it can be useful in sequence diagrams. - Regarding the means of specifying the interactions, I think that using features and ports makes sense with the spirit of GCM. Nevertheless, I think that it could also be a very good idea to provide an alternative way of specifying interactions. - Lastly, in my opinion interactions should be used in a broader scope. What I mean is that interactions describe communications between several components, while GCM stereotypes should help defining communications in the scope of a single component, independently from the component receiving the message. Taking your comments into account, I tried to write a resolution so that we can work on top a document. It's attached to the mail. Please feel free to change whatever you like, make any comments. Track changes is on. Best regards! Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: viernes, 23 de abril de 2010 12:33 To: Adrian Noguero Cc: marte-rtf@omg.org; GERARD Sebastien 166342 Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hi Adrian, all, After a brief discussion with Sebastien, here are some comments / ideas that you could consider for your resolution: - Since the extensions you are proposing are related to verification activities, should not they be introduced in an analysis chapter of MARTE (e.g., GQAM?) ? What I understand is that the stereotype GCMInvocationBehavior is used to provide an abstraction of a Behavior. This abstraction focuses on communication aspects, as it captures the list of messages that will be emitted when the behavior will be executed. Can this kind of abstraction be useful for other kind of analysis? And in this case, should it be introduced in the spec in a more neutral way (I mean, independently of state machines)? - Have you think about alternative ways (i.e., instead of a list of ports and a list of features) of representing the information of interest for your analysis techniques? What do you think about an ordered list of InvocationActions (note that this invocation action could be referenced from an actual behavior, which in your case would be the behavior used as an effect of a transition)? For the sake of generality (i.e., in the case where an ordered list is not sufficient), why not using directly an Interaction? Cheers, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 15:42 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza; marte-rtf@omg.org Objet : RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Hello Arnaud and all, I fully agree with your first comment; indeed the AcceptEventAction enables modelling receptions in activity diagrams; so I guess this first part of the issue can be closed. Regarding your comment about the semantics of the {ordered} qualifier, my idea was to include the semantics that the port list and the features list should be ordered in such a way that the first invocation would happen at the first port and the first feature. Lastly my proposal aims at enabling the definition of Port State Machines, as defined in [1]. This state machines are triggered by events generted by message receptions (that is, GCMTriggers) and in the effect side they generate messages that will trigger other state machines. This last part is not currently supported by MARTE and it is very interesting for implementing compositional model-based verification. Refs: [1] Vladimir Mencl. "Specifying Component Behavior with Port State Machines", ENTCS, vol. 101, pps. 129-153, November 2004. Best regards, Adrian -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: lunes, 29 de marzo de 2010 15:18 To: Adrian Noguero; Séstien Demathieu Cc: Huascar Espinoza; marte-rtf@omg.org Subject: RE: [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Adrian, Thank you for initiating the discussion. I have a few remarks regarding the issue itself. The issue says: The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases. A reception can be modelled in an Activity. It can be done using an AcceptEventAction (which can be associated with e.g., a GCMTrigger). Do you have in mind some cases where this mechanism would not be sufficient? I agree with your remark on the fact that it is not possible to directly specify an invocation (in the sense that it is not possible to explicitly specify an InvocationAction) in the context of a StateMachine (invocations are only implicitly specified, using the effect behavior of Transition, or the doActivity, entry or exit behaviors of State). (BTW, I do not know how these implicit invocations behave if the behaviors have parameters). More specifically about your proposition, I think it indirectly addresses the issue you are raising, since the information captured by the «GCMInvocatingBehavior» is not restricted to the context of a StateMachine (i.e., it more generally captures the fact that the execution of the behavior will raise some invocation actions, which may or may not be related to specific ports / features of the context class. The advantage I see is that the information is made available, without having to look at the details of the Behavior internals). I am not an expert of state machines, so I can.t say if this kind of information is useful or not (and therefore I can.t say if it is good idea or not to add this capability to statemachines). If I correctly understand your proposition, you are able to capture lists of port / features, such that: - the property onPorts enables to reference ports on which invocations will be raised - the property onFeatures enables to reference a specific property in the context of the port (e.g. a specific output flow property in the context of FlowPort, or a specific behavioral feature in the context of a ClientServerPort) Is the {ordered} qualifier on these properties carrying particular semantic information, e.g., does it represent the order in which the invocation will be raised? And in this case, is the order of invocation occurrences sufficient information for you (I mean, don.t you also need to capture receptions that will occur in the «GCMInvocatingBehavior»? Best regards, Arnaud -------------------------------------------------------------------------------- De : Adrian Noguero [mailto:Adrian.Noguero@esi.es] Envoyé lundi 29 mars 2010 10:48 À: CUCCURU Arnaud; Séstien Demathieu Cc : Huascar Espinoza Objet : [MARTE-RTF] Resolution proposal for issue 15081 (GCM) Dear Arnaud and Séstien, I would like to propose a resolution to issue 15081 related to MARTE::GCM profile. The issue, which is has been reported by myself :), has to do with the representation of invocations in state machine diagrams. This kind of interactions is very important for compositional model checking, as shown in the works by Vladimir Mencl about Port State Machines. My proposal is to include a new stereotype: <> that specifies that inside a behavior one or more invocations are taking place. I made some experiments using Papyrus, with the following stereotype definition (to be included, if accepted in Fig 12.9): With this modification, again using Papyrus for my example, I get the following diagram: I think this kind of representation is easy to understand. What do you think about this? If you agree on the proposal I am available for working in the formal resolution of the issue. Best regards, AdriáNoguero R&D Project Area adrian.noguero@esi.es European Software Institute (ESI) Corporacióecnolóa Tecnalia Parque Tecnolóo de Zamudio, # 204 E-48170 Zamudio Bizkaia - Spain Tel.: + 34.94 420 9519 http://www.esi.es Fax: + 34.94 420 9420 E-mail: info@esi.es ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** ************************************ 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. ***************************************************************************************** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. ************************************ 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. ***************************************************************************************** The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases.