Issue 18777: UML 2.5 FTF Receptions may not have a method (uml25-ftf) Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Uncategorized Issue Severity: Summary: According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception. context Reception inv: self.method->isEmpty() What do you think? Resolution: Revised Text: Actions taken: June 12, 2013: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: "uml25-ftf@omg.org" Date: Wed, 12 Jun 2013 08:34:19 +0200 Subject: [UML 2.5 FTF] Receptions may not have a method Thread-Topic: [UML 2.5 FTF] Receptions may not have a method Thread-Index: Ac5nNt5hjYHqR7bLRPqpwLsbdEk7VQ== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception. context Reception inv: self.method->isEmpty() What do you think? Yves 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. X-Virus-Scanned: OK From: Ed Seidewitz To: "BERNARD, Yves" CC: "uml25-ftf@omg.org" Subject: Re: [UML 2.5 FTF] Receptions may not have a method Thread-Topic: [UML 2.5 FTF] Receptions may not have a method Thread-Index: Ac5nNt5hjYHqR7bLRPqpwLsbdEk7VQAA3daL Date: Wed, 12 Jun 2013 06:59:08 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Virus-Scanned: amavisd-new at omg.org Yves -- No, there are specific semantics for receptions with methods.. If a class has such a reception, then, when an instance gets a signal matching the reception, the method is executed, rather than a signal event occurrence being placed in the event pool for instance. This is capability is not often used, but it is allowed. (Sorry, I am not at my computer, so I can't look up the exact reference right now, but I think it is in Clause 13.) Ed Sent from my iPhone On Jun 12, 2013, at 2:35 AM, "BERNARD, Yves" wrote: According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception. context Reception inv: self.method->isEmpty() What do you think? Yves 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. From: "BERNARD, Yves" To: Ed Seidewitz CC: "uml25-ftf@omg.org" Date: Wed, 12 Jun 2013 14:03:15 +0200 Subject: RE: [UML 2.5 FTF] Receptions may not have a method Thread-Topic: [UML 2.5 FTF] Receptions may not have a method Thread-Index: Ac5nNt5hjYHqR7bLRPqpwLsbdEk7VQAA3daLAAnxuaA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Ed, Thanks. I think §13.3.3 (semantics of events) is the part of the spec you refer to. The point is that if this clause as written today does not prevent using receptions with immediate effects there is nowhere in the spec where it is clearly stated this it can works like that. Conversely, there is a constraint specified for Class implying that only an active class may have receptions. Does this constraint make sense if receptions may have immediate effects? Is it possible to manage asynchronous invocation and immediate effect together? Yves From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: mercredi 12 juin 2013 08:59 To: BERNARD, Yves Cc: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Receptions may not have a method Yves -- No, there are specific semantics for receptions with methods.. If a class has such a reception, then, when an instance gets a signal matching the reception, the method is executed, rather than a signal event occurrence being placed in the event pool for instance. This is capability is not often used, but it is allowed. (Sorry, I am not at my computer, so I can't look up the exact reference right now, but I think it is in Clause 13.) Ed Sent from my iPhone On Jun 12, 2013, at 2:35 AM, "BERNARD, Yves" wrote: According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception. context Reception inv: self.method->isEmpty() What do you think? Yves 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. 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. X-Virus-Scanned: OK From: Ed Seidewitz To: "BERNARD, Yves" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Receptions may not have a method Thread-Topic: [UML 2.5 FTF] Receptions may not have a method Thread-Index: Ac5nNt5hjYHqR7bLRPqpwLsbdEk7VQAA3daLAAnxuaAAB89ggA== Date: Wed, 12 Jun 2013 15:33:17 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.91.76.209] X-Virus-Scanned: amavisd-new at omg.org Yves . In 13.3.3, under Message Events, it says: .In the case of a CallEvent for an Operation or a SignalEvent for a Signal that matches a Reception on the receiver, if the Operation or Reception has one or more methods, then the method resolution process described for Behavioral Features and Methods in sub clause 13.2.3 shall be carried out to determine a method to be used to handle a MessageEvent occurrence. If a method is so identified, it is invoked to respond to the message request. Otherwise, the MessageEvent occurrence is saved in the event pool of the receiving object. When a MessageEvent occurrence is dispatched from the event pool and matches a Trigger defined in the Behavior specification for the receiver, it causes the execution of a response within the Behavior.. This seems pretty explicit to me, noth for CallEvents and SignalEvents. And yes, only an active class can have receptions. But there is no requirement that an active class has a classifier behavior (just that a passive class cannot have one). An active class could have methods for all its receptions. -- Ed From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, June 12, 2013 8:03 AM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Receptions may not have a method Ed, Thanks. I think §13.3.3 (semantics of events) is the part of the spec you refer to. The point is that if this clause as written today does not prevent using receptions with immediate effects there is nowhere in the spec where it is clearly stated this it can works like that. Conversely, there is a constraint specified for Class implying that only an active class may have receptions. Does this constraint make sense if receptions may have immediate effects? Is it possible to manage asynchronous invocation and immediate effect together? Yves From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: mercredi 12 juin 2013 08:59 To: BERNARD, Yves Cc: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Receptions may not have a method Yves -- No, there are specific semantics for receptions with methods.. If a class has such a reception, then, when an instance gets a signal matching the reception, the method is executed, rather than a signal event occurrence being placed in the event pool for instance. This is capability is not often used, but it is allowed. (Sorry, I am not at my computer, so I can't look up the exact reference right now, but I think it is in Clause 13.) Ed Sent from my iPhone On Jun 12, 2013, at 2:35 AM, "BERNARD, Yves" wrote: According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception. context Reception inv: self.method->isEmpty() What do you think? Yves 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. 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.