Issue 19070: About behavior ports (uml2-rtf) Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Uncategorized Issue Severity: Summary: On the semantics of behavior ports, UML 2.5 §11.3.3 says: “A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any” It is not clear whether “the Behavior” refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. Resolution: Revised Text: Actions taken: November 7, 2013: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: "uml2-rtf@omg.org" Date: Thu, 7 Nov 2013 08:33:34 +0100 Subject: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: Ac7biUyuVsYex3HWQfKnk6lBLwrEJA== 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 On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JKosIPdM0W9ZwJWI1Kr08IV+hWIPFPYthXTEzB/fkY0=; b=B1VeHGR/QnCqfsDi6ttcdTD9YzTeLIb7ywns3HF9OwEn8vCqZjjDG5DxBXaEPsE1gP Nj95P7fUjYAdAIxLo4Bg3T5nrCk8FgStaICeCgXOz2oEwXILHmelgVCxD8PK41g7/PEf DfrCaBVu3n+nNjRwK/bPSg16Vc7svhwyPmdn5MC8HNUY6hWHT8GtBg95ZcqdfP4kFNAW d1RRMBIAXD76qvMKOHMwEhvs0YNGuFNm2HuJO1OpbZsHYpbRan7c39Yda8cQBbxiKDBC 5/jDoooCExK9n296OcYc4H96lJdstNDRMyamtHkittUoutKQ+RmkYWYbYb4XlM8MyJim GXiA== X-Received: by 10.221.40.10 with SMTP id to10mr5930831vcb.22.1383815058770; Thu, 07 Nov 2013 01:04:18 -0800 (PST) Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 7 Nov 2013 04:03:38 -0500 X-Google-Sender-Auth: Z3mlnhPmGczoDegW6cKJn1EdI5I Subject: Re: [UML 2.6 RTF] About behavior ports To: "BERNARD, Yves" Cc: "uml2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org It's a good question, Yves. I can say with certainty that the original intent was that behavior ports were connected to the classifier behavior only, because this model was proven in practice (UML-RT, SDL). However, perhaps we need to generalize that, although there is always risk in standardizing something that has not been proven in practice. It's worth investigating. Cheers...Bran On Thu, Nov 7, 2013 at 2:33 AM, BERNARD, Yves wrote: On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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: "uml2-rtf@omg.org" CC: "issues@omg.org" Subject: RE: issue 9070 -- UML 2.6 RTF issue Thread-Topic: issue 9070 -- UML 2.6 RTF issue Thread-Index: Ac7b9B56keMVhhh4T5qVjxBENqC66w== Date: Thu, 7 Nov 2013 20:01:17 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.48.211.97] X-Virus-Scanned: amavisd-new at omg.org While the original intent may have been that the request was always handled by the classifier behavior, it would be more consistent to have it handled simply as called for by the regular common behavior semantics of the owning encapsulated classifier. That is, the request would simply be forwarded to the instance of the owning encapsulated classifier and then handled as if it had been sent directly to that instance. That would leave it up to the modeler to decide how various requests should be handled. If the desire was to have the requests always handled by the classifier behavior, than the owning classifier should have a classifier behavior with appropriate triggers and no behavioral features with methods that match the relevant requests. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, November 07, 2013 9:21 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19070 -- UML 2.6 RTF issue From: "BERNARD, Yves" To: "uml2-rtf@omg.org" Date: Thu, 7 Nov 2013 08:33:34 +0100 Subject: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: Ac7biUyuVsYex3HWQfKnk6lBLwrEJA== 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 On the semantics of behavior ports, UML 2.5 .11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] X-Virus-Scanned: OK From: Ed Seidewitz To: "uml2-rtf@omg.org" CC: "issues@omg.org" Subject: RE: issue 9070 -- UML 2.6 RTF issue Thread-Topic: issue 9070 -- UML 2.6 RTF issue Thread-Index: Ac7b9B56keMVhhh4T5qVjxBENqC66wAAFQsQ Date: Thu, 7 Nov 2013 20:05:25 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.48.211.97] X-Virus-Scanned: amavisd-new at omg.org By the way, this new issue overlaps with existing issue 8748, which says .Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior.. So, when this issue last came up (in 2005!), the consensus at that time seems to have been that operation calls, at least, should be able to be handled by methods (it may not have been clear at the time that signals could also be handled by receptions with methods). -- Ed From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: Thursday, November 07, 2013 3:01 PM To: uml2-rtf@omg.org Cc: issues@omg.org Subject: RE: issue 9070 -- UML 2.6 RTF issue While the original intent may have been that the request was always handled by the classifier behavior, it would be more consistent to have it handled simply as called for by the regular common behavior semantics of the owning encapsulated classifier. That is, the request would simply be forwarded to the instance of the owning encapsulated classifier and then handled as if it had been sent directly to that instance. That would leave it up to the modeler to decide how various requests should be handled. If the desire was to have the requests always handled by the classifier behavior, than the owning classifier should have a classifier behavior with appropriate triggers and no behavioral features with methods that match the relevant requests. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, November 07, 2013 9:21 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19070 -- UML 2.6 RTF issue From: "BERNARD, Yves" To: "uml2-rtf@omg.org" Date: Thu, 7 Nov 2013 08:33:34 +0100 Subject: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: Ac7biUyuVsYex3HWQfKnk6lBLwrEJA== 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 On the semantics of behavior ports, UML 2.5 .11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] X-Virus-Scanned: OK From: Ed Seidewitz To: Bran Selic , Axel Scheithauer CC: "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: RE: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: AQHO3xFVJj0Bg5c6xESYIM6sYooGhpohvm6g Date: Tue, 12 Nov 2013 17:51:56 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.82.136] X-Virus-Scanned: amavisd-new at omg.org Bran . Well, in a UML 2.5 context, Clause 13 on Common Behavior is pretty clear on how requests to instances of behaviored classifiers are handled in general, whether they are serviced by methods or placed in the event pool to be handled by owned behaviors. All that is being suggested is that the semantics of a behavior port should be to simply forward requests to the instance of the owning classifier, which than handles the request per the usual semantics. By the way, this would actually tighten up the specification over presuming that the intent is that the request be handled specifically by the classifier behavior. That is because an object can have multiple owned behaviors, but has only one event pool that potentially dispatches to all those behaviors. So it is not entirely clear what it means for a request to be handled specifically by the classifier behavior: Does it not go in the event pool at all? Does it get prioritized as usual in the event pool, but somehow marked as only handable by the classifier behavior? I think we need to avoid these problems and clarify the semantics of behavior ports so that, at the very least, incoming requests are specified to be placed in the event pool as normal triggered event instances . but, in my opinion, it is cleaner to just specify that the request is forwarded to the owning instance and letting the full common semantics apply. One wrinkle is that EncapsulatedClassifier is not actually a subtype of BehavioredClassifier! This may have been the reason for the circumlocution of not explicitly mentioning .classifier behavior. in the original text. In UML 2.4.1, .behavior. was, indeed, written with a lower case .b., and changing it to an upper case .B. in UML 2.5 was probably an over-enthusiastic application of our convention for referring to metaclasses. Further, interestingly enough, the UML 2.4.1 text is (under Semantics in 9.3.12 for Port) .For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Clause 13, .Common Behaviors.), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.. Note that this specifically mentions that the request is handled .as specified in the behavior [lower case .b.] of the classifier, see Clause 13, .Common Behaviors.. While this cross-reference was unfortunately lost in the UML 2.5 spec, I believe it indicates that the intent in UML 2.4.1 was, indeed, that the request be handled using the common semantics, not as a special case dispatch to the classifier behavior. I would suggest updated wording in UML 2.6 something like the following: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. Requests forwarded by a behavior Port are handled just as if they were sent to the instance of the owning EncapsulatedClassifier directly (per the semantics specified in Clause 13 on Common Behavior). If the owning EncapsulatedClassifier has no Behavior that can handle a forwarded request, then such a communication arriving at a behavior Port is lost. (Note that only instances of BehavioredClassifiers can receive and handle requests, but currently in UML only Classes may be EncapsulatedClassifiers, and Classes are also BehavioredClassifiers.). -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, November 11, 2013 2:05 PM To: Axel Scheithauer Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: [UML 2.6 RTF] About behavior ports I have nothing against expanding the definition of behavior ports to cover more than just classifier behavior (a case, which, as I said, has been proven in practice many times over). However, before we do that, I would really like to know the precise semantics of how this works, preferably in the fUML context. Perhaps Ed was suggesting that this already exists -- which would be great (I haven't had the time to check it out). That way we will be sure that we are not opening ourselves for some unexpected feature interaction problems. Cheers...Bran On Mon, Nov 11, 2013 at 10:29 AM, Axel Scheithauer wrote: I don't understand why a request should be treated differently when received via a behavior port. The port hides whether the classifier itself treats the request or one of it's parts. Once the target of the request is found, the port is transparent and any request is handled the same way as if it was directed to the target classifier. The word "Behavior" below should be lower case, since it refers to the overall behavior of the instance, not to the classifierBehavior or the set of ownedBehaviors. And this behavior is a combination of methods of operations and effects of transitions as specified in 13.3.3. How about deleting "the Behavior of ": .... any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. --Axel Am 07.11.2013 um 10:06 schrieb "Bran Selic" : It's a good question, Yves. I can say with certainty that the original intent was that behavior ports were connected to the classifier behavior only, because this model was proven in practice (UML-RT, SDL). However, perhaps we need to generalize that, although there is always risk in standardizing something that has not been proven in practice. It's worth investigating. Cheers...Bran On Thu, Nov 7, 2013 at 2:33 AM, BERNARD, Yves wrote: On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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 , Bran Selic , Axel Scheithauer CC: "uml2-rtf@omg.org" Date: Wed, 13 Nov 2013 07:49:18 +0100 Subject: RE: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: AQHO3xFVJj0Bg5c6xESYIM6sYooGhpohvm6ggAD73XA= 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 I.m fine with Ed.s proposal: it makes sense to me. Ed, will you fill an issue for it? Thanks, Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Envoyé mardi 12 novembre 2013 18:52 À: Bran Selic; Axel Scheithauer Cc : BERNARD, Yves; uml2-rtf@omg.org Objet : RE: [UML 2.6 RTF] About behavior ports Bran . Well, in a UML 2.5 context, Clause 13 on Common Behavior is pretty clear on how requests to instances of behaviored classifiers are handled in general, whether they are serviced by methods or placed in the event pool to be handled by owned behaviors. All that is being suggested is that the semantics of a behavior port should be to simply forward requests to the instance of the owning classifier, which than handles the request per the usual semantics. By the way, this would actually tighten up the specification over presuming that the intent is that the request be handled specifically by the classifier behavior. That is because an object can have multiple owned behaviors, but has only one event pool that potentially dispatches to all those behaviors. So it is not entirely clear what it means for a request to be handled specifically by the classifier behavior: Does it not go in the event pool at all? Does it get prioritized as usual in the event pool, but somehow marked as only handable by the classifier behavior? I think we need to avoid these problems and clarify the semantics of behavior ports so that, at the very least, incoming requests are specified to be placed in the event pool as normal triggered event instances . but, in my opinion, it is cleaner to just specify that the request is forwarded to the owning instance and letting the full common semantics apply. One wrinkle is that EncapsulatedClassifier is not actually a subtype of BehavioredClassifier! This may have been the reason for the circumlocution of not explicitly mentioning .classifier behavior. in the original text. In UML 2.4.1, .behavior. was, indeed, written with a lower case .b., and changing it to an upper case .B. in UML 2.5 was probably an over-enthusiastic application of our convention for referring to metaclasses. Further, interestingly enough, the UML 2.4.1 text is (under Semantics in 9.3.12 for Port) .For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Clause 13, .Common Behaviors.), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.. Note that this specifically mentions that the request is handled .as specified in the behavior [lower case .b.] of the classifier, see Clause 13, .Common Behaviors.. While this cross-reference was unfortunately lost in the UML 2.5 spec, I believe it indicates that the intent in UML 2.4.1 was, indeed, that the request be handled using the common semantics, not as a special case dispatch to the classifier behavior. I would suggest updated wording in UML 2.6 something like the following: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. Requests forwarded by a behavior Port are handled just as if they were sent to the instance of the owning EncapsulatedClassifier directly (per the semantics specified in Clause 13 on Common Behavior). If the owning EncapsulatedClassifier has no Behavior that can handle a forwarded request, then such a communication arriving at a behavior Port is lost. (Note that only instances of BehavioredClassifiers can receive and handle requests, but currently in UML only Classes may be EncapsulatedClassifiers, and Classes are also BehavioredClassifiers.). -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, November 11, 2013 2:05 PM To: Axel Scheithauer Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: [UML 2.6 RTF] About behavior ports I have nothing against expanding the definition of behavior ports to cover more than just classifier behavior (a case, which, as I said, has been proven in practice many times over). However, before we do that, I would really like to know the precise semantics of how this works, preferably in the fUML context. Perhaps Ed was suggesting that this already exists -- which would be great (I haven't had the time to check it out). That way we will be sure that we are not opening ourselves for some unexpected feature interaction problems. Cheers...Bran On Mon, Nov 11, 2013 at 10:29 AM, Axel Scheithauer wrote: I don't understand why a request should be treated differently when received via a behavior port. The port hides whether the classifier itself treats the request or one of it's parts. Once the target of the request is found, the port is transparent and any request is handled the same way as if it was directed to the target classifier. The word "Behavior" below should be lower case, since it refers to the overall behavior of the instance, not to the classifierBehavior or the set of ownedBehaviors. And this behavior is a combination of methods of operations and effects of transitions as specified in 13.3.3. How about deleting "the Behavior of ": .... any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. --Axel Am 07.11.2013 um 10:06 schrieb "Bran Selic" : It's a good question, Yves. I can say with certainty that the original intent was that behavior ports were connected to the classifier behavior only, because this model was proven in practice (UML-RT, SDL). However, perhaps we need to generalize that, although there is always risk in standardizing something that has not been proven in practice. It's worth investigating. Cheers...Bran On Thu, Nov 7, 2013 at 2:33 AM, BERNARD, Yves wrote: On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jGZCKJvLr8VVxY/89IRZF23+w0nHbX9suTX/ksPk5EM=; b=yVoa272g8Tj0TMg1LL1/NSvqBolk7YwI8IF2hk1Fup6ygb7VIezpO4PePfJSSnOraH AgTB6wBVBYaUdcWu1JeYFfY5oltsFwl86A3ffi/dqng+mlUWfVUcE2TtGyFE/dqsvh5r +qeN7GRcWD6AeBOQaf8AZGTfQVgxe4rvBO7ioBANNJaE4GxWADSG+ciiOpiOflc6lVzI rghSSjfvx/wK+hdwd+MNtbsWCnMcwN/7GUqwIk9+ow4ebXnTvCqK7Up0KjLlbuNBF2Wp qmGp5HC3XTHnOtntsNOaMxRDRtho2fpXQ2Y1EJwg1Y23l3Mu88sVIkpe6Im76OnjX8h9 RDSg== X-Received: by 10.58.46.171 with SMTP id w11mr33442809vem.5.1384331340174; Wed, 13 Nov 2013 00:29:00 -0800 (PST) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 13 Nov 2013 09:28:20 +0100 X-Google-Sender-Auth: 8VGaAUFozTiHLKK2R2ntYrWyj_w Subject: Re: [UML 2.6 RTF] About behavior ports To: Ed Seidewitz Cc: Axel Scheithauer , "BERNARD, Yves" , "uml2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org On Tue, Nov 12, 2013 at 6:51 PM, Ed Seidewitz wrote: Bran . Well, in a UML 2.5 context, Clause 13 on Common Behavior is pretty clear on how requests to instances of behaviored classifiers are handled in general, whether they are serviced by methods or placed in the event pool to be handled by owned behaviors. All that is being suggested is that the semantics of a behavior port should be to simply forward requests to the instance of the owning classifier, which than handles the request per the usual semantics. [bvs] I recall reviewing this section for 2.5 and raising a number of issues with it. However, I don't recall if they've all been resolved or not (although I think that a few remain). By the way, this would actually tighten up the specification over presuming that the intent is that the request be handled specifically by the classifier behavior. That is because an object can have multiple owned behaviors, but has only one event pool that potentially dispatches to all those behaviors. So it is not entirely clear what it means for a request to be handled specifically by the classifier behavior: Does it not go in the event pool at all? Does it get prioritized as usual in the event pool, but somehow marked as only handable by the classifier behavior? I think we need to avoid these problems and clarify the semantics of behavior ports so that, at the very least, incoming requests are specified to be placed in the event pool as normal triggered event instances . but, in my opinion, it is cleaner to just specify that the request is forwarded to the owning instance and letting the full common semantics apply. [bvs] This is precisely what I am looking for: I want to make sure we are clear on how handling by the classifier behavior works in conjunction with handling by any owned behavior. The even pool concept was introduced specifically for processing by the classifier behavior (NB: I would like to make it clear that, when I talk about the history of UML, it is not for nostalgic reasons or with an intent to preserve decisions made in the past, but merely to provide the background necessary to make meaningful decisions -- so, please don't misunderstand these as musings of an old f-f-f-...fUMLer). [bvs] BTW, is there a need for an override of the default handling mechanism; for instance, redirecting or deferring a dispatched message? (From what I recall, currently deferrals are only handled through state machines, which seems needlessly constrained.) One wrinkle is that EncapsulatedClassifier is not actually a subtype of BehavioredClassifier! This may have been the reason for the circumlocution of not explicitly mentioning .classifier behavior. in the original text. In UML 2.4.1, .behavior. was, indeed, written with a lower case .b., and changing it to an upper case .B. in UML 2.5 was probably an over-enthusiastic application of our convention for referring to metaclasses. Further, interestingly enough, the UML 2.4.1 text is (under Semantics in 9.3.12 for Port) [bvs] I am not sure that is the reason. It may even be a mistake due to package merges not being properly ordered in 2.4. .For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Clause 13, .Common Behaviors.), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.. Note that this specifically mentions that the request is handled .as specified in the behavior [lower case .b.] of the classifier, see Clause 13, .Common Behaviors.. While this cross-reference was unfortunately lost in the UML 2.5 spec, I believe it indicates that the intent in UML 2.4.1 was, indeed, that the request be handled using the common semantics, [bvs] Could be. If so, it was likely a change introduced after 2.0. not as a special case dispatch to the classifier behavior. I would suggest updated wording in UML 2.6 something like the following: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. Requests forwarded by a behavior Port are handled just as if they were sent to the instance of the owning EncapsulatedClassifier directly (per the semantics specified in Clause 13 on Common Behavior). If the owning EncapsulatedClassifier has no Behavior that can handle a forwarded request, then such a communication arriving at a behavior Port is lost. (Note that only instances of BehavioredClassifiers can receive and handle requests, but currently in UML only Classes may be EncapsulatedClassifiers, and Classes are also BehavioredClassifiers.). [bvs] It is not clear (to me) how we know which Behavior is associated with a behavior Port -- it seems to be implicit. What happens if more than one Behavior can handle a given reuqest? [bvs] Please forgive me if I am raising issues that have already been resolved (at present I am really not in a position to study this issue in depth). Cheers...Bran X-Virus-Scanned: OK From: Ed Seidewitz To: "BERNARD, Yves" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: AQHO3xFVJj0Bg5c6xESYIM6sYooGhpohvm6ggAD73XCAAKVXAA== Date: Wed, 13 Nov 2013 16:40:23 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.82.136] X-Virus-Scanned: amavisd-new at omg.org Yves . There is already an issue for it, 19070, as well as a related older issue, 8748. -- Ed From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, November 13, 2013 1:49 AM To: Ed Seidewitz; Bran Selic; Axel Scheithauer Cc: uml2-rtf@omg.org Subject: RE: [UML 2.6 RTF] About behavior ports I.m fine with Ed.s proposal: it makes sense to me. Ed, will you fill an issue for it? Thanks, Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Envoyé mardi 12 novembre 2013 18:52 À: Bran Selic; Axel Scheithauer Cc : BERNARD, Yves; uml2-rtf@omg.org Objet : RE: [UML 2.6 RTF] About behavior ports Bran . Well, in a UML 2.5 context, Clause 13 on Common Behavior is pretty clear on how requests to instances of behaviored classifiers are handled in general, whether they are serviced by methods or placed in the event pool to be handled by owned behaviors. All that is being suggested is that the semantics of a behavior port should be to simply forward requests to the instance of the owning classifier, which than handles the request per the usual semantics. By the way, this would actually tighten up the specification over presuming that the intent is that the request be handled specifically by the classifier behavior. That is because an object can have multiple owned behaviors, but has only one event pool that potentially dispatches to all those behaviors. So it is not entirely clear what it means for a request to be handled specifically by the classifier behavior: Does it not go in the event pool at all? Does it get prioritized as usual in the event pool, but somehow marked as only handable by the classifier behavior? I think we need to avoid these problems and clarify the semantics of behavior ports so that, at the very least, incoming requests are specified to be placed in the event pool as normal triggered event instances . but, in my opinion, it is cleaner to just specify that the request is forwarded to the owning instance and letting the full common semantics apply. One wrinkle is that EncapsulatedClassifier is not actually a subtype of BehavioredClassifier! This may have been the reason for the circumlocution of not explicitly mentioning .classifier behavior. in the original text. In UML 2.4.1, .behavior. was, indeed, written with a lower case .b., and changing it to an upper case .B. in UML 2.5 was probably an over-enthusiastic application of our convention for referring to metaclasses. Further, interestingly enough, the UML 2.4.1 text is (under Semantics in 9.3.12 for Port) .For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Clause 13, .Common Behaviors.), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.. Note that this specifically mentions that the request is handled .as specified in the behavior [lower case .b.] of the classifier, see Clause 13, .Common Behaviors.. While this cross-reference was unfortunately lost in the UML 2.5 spec, I believe it indicates that the intent in UML 2.4.1 was, indeed, that the request be handled using the common semantics, not as a special case dispatch to the classifier behavior. I would suggest updated wording in UML 2.6 something like the following: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. Requests forwarded by a behavior Port are handled just as if they were sent to the instance of the owning EncapsulatedClassifier directly (per the semantics specified in Clause 13 on Common Behavior). If the owning EncapsulatedClassifier has no Behavior that can handle a forwarded request, then such a communication arriving at a behavior Port is lost. (Note that only instances of BehavioredClassifiers can receive and handle requests, but currently in UML only Classes may be EncapsulatedClassifiers, and Classes are also BehavioredClassifiers.). -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, November 11, 2013 2:05 PM To: Axel Scheithauer Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: [UML 2.6 RTF] About behavior ports I have nothing against expanding the definition of behavior ports to cover more than just classifier behavior (a case, which, as I said, has been proven in practice many times over). However, before we do that, I would really like to know the precise semantics of how this works, preferably in the fUML context. Perhaps Ed was suggesting that this already exists -- which would be great (I haven't had the time to check it out). That way we will be sure that we are not opening ourselves for some unexpected feature interaction problems. Cheers...Bran On Mon, Nov 11, 2013 at 10:29 AM, Axel Scheithauer wrote: I don't understand why a request should be treated differently when received via a behavior port. The port hides whether the classifier itself treats the request or one of it's parts. Once the target of the request is found, the port is transparent and any request is handled the same way as if it was directed to the target classifier. The word "Behavior" below should be lower case, since it refers to the overall behavior of the instance, not to the classifierBehavior or the set of ownedBehaviors. And this behavior is a combination of methods of operations and effects of transitions as specified in 13.3.3. How about deleting "the Behavior of ": .... any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. --Axel Am 07.11.2013 um 10:06 schrieb "Bran Selic" : It's a good question, Yves. I can say with certainty that the original intent was that behavior ports were connected to the classifier behavior only, because this model was proven in practice (UML-RT, SDL). However, perhaps we need to generalize that, although there is always risk in standardizing something that has not been proven in practice. It's worth investigating. Cheers...Bran On Thu, Nov 7, 2013 at 2:33 AM, BERNARD, Yves wrote: On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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: Bran Selic CC: Axel Scheithauer , "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: RE: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: AQHO3xFVJj0Bg5c6xESYIM6sYooGhpohvm6ggAF8ogCAACVCAA== Date: Wed, 13 Nov 2013 16:51:14 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.82.136] X-Virus-Scanned: amavisd-new at omg.org Bran . I can answer this question: [bvs] It is not clear (to me) how we know which Behavior is associated with a behavior Port -- it seems to be implicit. What happens if more than one Behavior can handle a given reuqest? The UML 2.5 spec, subclause 13.3.3, under Event Dispatching, contains the following clarifying note: NOTE. All Behaviors with the same context object share the event pool of that object, but any Event occurrence in the pool can be consumed by only one Behavior. If more than Behavior is at a wait point with a trigger that matches the next event occurrence to be dispatched from the pool, then the spec does not determine which of the Behaviors consumes the event occurrence, but only one will. -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, November 13, 2013 3:28 AM To: Ed Seidewitz Cc: Axel Scheithauer; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: [UML 2.6 RTF] About behavior ports On Tue, Nov 12, 2013 at 6:51 PM, Ed Seidewitz wrote: Bran . Well, in a UML 2.5 context, Clause 13 on Common Behavior is pretty clear on how requests to instances of behaviored classifiers are handled in general, whether they are serviced by methods or placed in the event pool to be handled by owned behaviors. All that is being suggested is that the semantics of a behavior port should be to simply forward requests to the instance of the owning classifier, which than handles the request per the usual semantics. [bvs] I recall reviewing this section for 2.5 and raising a number of issues with it. However, I don't recall if they've all been resolved or not (although I think that a few remain). By the way, this would actually tighten up the specification over presuming that the intent is that the request be handled specifically by the classifier behavior. That is because an object can have multiple owned behaviors, but has only one event pool that potentially dispatches to all those behaviors. So it is not entirely clear what it means for a request to be handled specifically by the classifier behavior: Does it not go in the event pool at all? Does it get prioritized as usual in the event pool, but somehow marked as only handable by the classifier behavior? I think we need to avoid these problems and clarify the semantics of behavior ports so that, at the very least, incoming requests are specified to be placed in the event pool as normal triggered event instances . but, in my opinion, it is cleaner to just specify that the request is forwarded to the owning instance and letting the full common semantics apply. [bvs] This is precisely what I am looking for: I want to make sure we are clear on how handling by the classifier behavior works in conjunction with handling by any owned behavior. The even pool concept was introduced specifically for processing by the classifier behavior (NB: I would like to make it clear that, when I talk about the history of UML, it is not for nostalgic reasons or with an intent to preserve decisions made in the past, but merely to provide the background necessary to make meaningful decisions -- so, please don't misunderstand these as musings of an old f-f-f-...fUMLer). [bvs] BTW, is there a need for an override of the default handling mechanism; for instance, redirecting or deferring a dispatched message? (From what I recall, currently deferrals are only handled through state machines, which seems needlessly constrained.) One wrinkle is that EncapsulatedClassifier is not actually a subtype of BehavioredClassifier! This may have been the reason for the circumlocution of not explicitly mentioning .classifier behavior. in the original text. In UML 2.4.1, .behavior. was, indeed, written with a lower case .b., and changing it to an upper case .B. in UML 2.5 was probably an over-enthusiastic application of our convention for referring to metaclasses. Further, interestingly enough, the UML 2.4.1 text is (under Semantics in 9.3.12 for Port) [bvs] I am not sure that is the reason. It may even be a mistake due to package merges not being properly ordered in 2.4. .For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Clause 13, .Common Behaviors.), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.. Note that this specifically mentions that the request is handled .as specified in the behavior [lower case .b.] of the classifier, see Clause 13, .Common Behaviors.. While this cross-reference was unfortunately lost in the UML 2.5 spec, I believe it indicates that the intent in UML 2.4.1 was, indeed, that the request be handled using the common semantics, [bvs] Could be. If so, it was likely a change introduced after 2.0. not as a special case dispatch to the classifier behavior. I would suggest updated wording in UML 2.6 something like the following: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. Requests forwarded by a behavior Port are handled just as if they were sent to the instance of the owning EncapsulatedClassifier directly (per the semantics specified in Clause 13 on Common Behavior). If the owning EncapsulatedClassifier has no Behavior that can handle a forwarded request, then such a communication arriving at a behavior Port is lost. (Note that only instances of BehavioredClassifiers can receive and handle requests, but currently in UML only Classes may be EncapsulatedClassifiers, and Classes are also BehavioredClassifiers.). [bvs] It is not clear (to me) how we know which Behavior is associated with a behavior Port -- it seems to be implicit. What happens if more than one Behavior can handle a given reuqest? [bvs] Please forgive me if I am raising issues that have already been resolved (at present I am really not in a position to study this issue in depth). Cheers...Bran X-Virus-Scanned: OK From: Ed Seidewitz To: Bran Selic CC: Axel Scheithauer , "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: RE: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: AQHO3xFVJj0Bg5c6xESYIM6sYooGhpohvm6ggAF8ogCAACVCAIAAA9QA Date: Wed, 13 Nov 2013 16:58:02 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.82.136] X-Virus-Scanned: amavisd-new at omg.org By the way, the note below applies to triggered events whose occurrences go into the event pool. If an object has a type with behavioral features that have methods, then there is a method resolution process that occurs first for an incoming message event occurrence to determine if there is a method Behavior to handle the request (see 13.2.3, under Behavioral Features and Methods). From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: Wednesday, November 13, 2013 11:51 AM To: Bran Selic Cc: Axel Scheithauer; BERNARD, Yves; uml2-rtf@omg.org Subject: RE: [UML 2.6 RTF] About behavior ports Bran . I can answer this question: [bvs] It is not clear (to me) how we know which Behavior is associated with a behavior Port -- it seems to be implicit. What happens if more than one Behavior can handle a given reuqest? The UML 2.5 spec, subclause 13.3.3, under Event Dispatching, contains the following clarifying note: NOTE. All Behaviors with the same context object share the event pool of that object, but any Event occurrence in the pool can be consumed by only one Behavior. If more than Behavior is at a wait point with a trigger that matches the next event occurrence to be dispatched from the pool, then the spec does not determine which of the Behaviors consumes the event occurrence, but only one will. -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, November 13, 2013 3:28 AM To: Ed Seidewitz Cc: Axel Scheithauer; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: [UML 2.6 RTF] About behavior ports On Tue, Nov 12, 2013 at 6:51 PM, Ed Seidewitz wrote: Bran . Well, in a UML 2.5 context, Clause 13 on Common Behavior is pretty clear on how requests to instances of behaviored classifiers are handled in general, whether they are serviced by methods or placed in the event pool to be handled by owned behaviors. All that is being suggested is that the semantics of a behavior port should be to simply forward requests to the instance of the owning classifier, which than handles the request per the usual semantics. [bvs] I recall reviewing this section for 2.5 and raising a number of issues with it. However, I don't recall if they've all been resolved or not (although I think that a few remain). By the way, this would actually tighten up the specification over presuming that the intent is that the request be handled specifically by the classifier behavior. That is because an object can have multiple owned behaviors, but has only one event pool that potentially dispatches to all those behaviors. So it is not entirely clear what it means for a request to be handled specifically by the classifier behavior: Does it not go in the event pool at all? Does it get prioritized as usual in the event pool, but somehow marked as only handable by the classifier behavior? I think we need to avoid these problems and clarify the semantics of behavior ports so that, at the very least, incoming requests are specified to be placed in the event pool as normal triggered event instances . but, in my opinion, it is cleaner to just specify that the request is forwarded to the owning instance and letting the full common semantics apply. [bvs] This is precisely what I am looking for: I want to make sure we are clear on how handling by the classifier behavior works in conjunction with handling by any owned behavior. The even pool concept was introduced specifically for processing by the classifier behavior (NB: I would like to make it clear that, when I talk about the history of UML, it is not for nostalgic reasons or with an intent to preserve decisions made in the past, but merely to provide the background necessary to make meaningful decisions -- so, please don't misunderstand these as musings of an old f-f-f-...fUMLer). [bvs] BTW, is there a need for an override of the default handling mechanism; for instance, redirecting or deferring a dispatched message? (From what I recall, currently deferrals are only handled through state machines, which seems needlessly constrained.) One wrinkle is that EncapsulatedClassifier is not actually a subtype of BehavioredClassifier! This may have been the reason for the circumlocution of not explicitly mentioning .classifier behavior. in the original text. In UML 2.4.1, .behavior. was, indeed, written with a lower case .b., and changing it to an upper case .B. in UML 2.5 was probably an over-enthusiastic application of our convention for referring to metaclasses. Further, interestingly enough, the UML 2.4.1 text is (under Semantics in 9.3.12 for Port) [bvs] I am not sure that is the reason. It may even be a mistake due to package merges not being properly ordered in 2.4. .For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Clause 13, .Common Behaviors.), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.. Note that this specifically mentions that the request is handled .as specified in the behavior [lower case .b.] of the classifier, see Clause 13, .Common Behaviors.. While this cross-reference was unfortunately lost in the UML 2.5 spec, I believe it indicates that the intent in UML 2.4.1 was, indeed, that the request be handled using the common semantics, [bvs] Could be. If so, it was likely a change introduced after 2.0. not as a special case dispatch to the classifier behavior. I would suggest updated wording in UML 2.6 something like the following: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. Requests forwarded by a behavior Port are handled just as if they were sent to the instance of the owning EncapsulatedClassifier directly (per the semantics specified in Clause 13 on Common Behavior). If the owning EncapsulatedClassifier has no Behavior that can handle a forwarded request, then such a communication arriving at a behavior Port is lost. (Note that only instances of BehavioredClassifiers can receive and handle requests, but currently in UML only Classes may be EncapsulatedClassifiers, and Classes are also BehavioredClassifiers.). [bvs] It is not clear (to me) how we know which Behavior is associated with a behavior Port -- it seems to be implicit. What happens if more than one Behavior can handle a given reuqest? [bvs] Please forgive me if I am raising issues that have already been resolved (at present I am really not in a position to study this issue in depth). Cheers...Bran From: Axel Scheithauer To: Bran Selic CC: "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: Re: [UML 2.6 RTF] About behavior ports Thread-Topic: [UML 2.6 RTF] About behavior ports Thread-Index: Ac7biUyuVsYex3HWQfKnk6lBLwrEJAABpCcAANag6IA= Date: Mon, 11 Nov 2013 15:29:31 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org I don't understand why a request should be treated differently when received via a behavior port. The port hides whether the classifier itself treats the request or one of it's parts. Once the target of the request is found, the port is transparent and any request is handled the same way as if it was directed to the target classifier. The word "Behavior" below should be lower case, since it refers to the overall behavior of the instance, not to the classifierBehavior or the set of ownedBehaviors. And this behavior is a combination of methods of operations and effects of transitions as specified in 13.3.3. How about deleting "the Behavior of ": .... any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. --Axel Am 07.11.2013 um 10:06 schrieb "Bran Selic" : It's a good question, Yves. I can say with certainty that the original intent was that behavior ports were connected to the classifier behavior only, because this model was proven in practice (UML-RT, SDL). However, perhaps we need to generalize that, although there is always risk in standardizing something that has not been proven in practice. It's worth investigating. Cheers...Bran On Thu, Nov 7, 2013 at 2:33 AM, BERNARD, Yves wrote: On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2nHgEUA4TOkUIKKthpt1UQ+MM0yU12O/NiL0DvNUKZI=; b=jMm9I6afBn5su5xNTjTgUsFfFQ5rYeelnkDbSPq1UwqgnBc7yAWZmJ7zwVM2mFA9dv M27UEtvKxVB75gihP/s2mHyc6mtsRywryGsqYW+CRFYxw7PAHnbXrS3fmglsVV2G37Qp jjL1jZyQXDfJfdiYPrt3xvMM3+kBTgKVumn0nCZf8dB2PJoHzlDcPI7oCi9VScJeuHDW 2Ks/YhCCwJZXDbQrJGirM1iHR9WZ6pgQSHR5wRMwTWSi/6J+OyNxBywpl2aPA5aQQm8B xv899H913hC/8V+m9iAlqh85Y6fZ5h+kBpQhI9AFn8vr5lG8i7OQ+6qNNX94AReFPjGK bnFQ== X-Received: by 10.221.44.136 with SMTP id ug8mr25122565vcb.13.1384196765747; Mon, 11 Nov 2013 11:06:05 -0800 (PST) Sender: bran.selic@gmail.com From: Bran Selic Date: Mon, 11 Nov 2013 14:05:25 -0500 X-Google-Sender-Auth: 4M6nG1dmxJdQMisual6PF_x-LUY Subject: Re: [UML 2.6 RTF] About behavior ports To: Axel Scheithauer Cc: "BERNARD, Yves" , "uml2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org I have nothing against expanding the definition of behavior ports to cover more than just classifier behavior (a case, which, as I said, has been proven in practice many times over). However, before we do that, I would really like to know the precise semantics of how this works, preferably in the fUML context. Perhaps Ed was suggesting that this already exists -- which would be great (I haven't had the time to check it out). That way we will be sure that we are not opening ourselves for some unexpected feature interaction problems. Cheers...Bran On Mon, Nov 11, 2013 at 10:29 AM, Axel Scheithauer wrote: I don't understand why a request should be treated differently when received via a behavior port. The port hides whether the classifier itself treats the request or one of it's parts. Once the target of the request is found, the port is transparent and any request is handled the same way as if it was directed to the target classifier. The word "Behavior" below should be lower case, since it refers to the overall behavior of the instance, not to the classifierBehavior or the set of ownedBehaviors. And this behavior is a combination of methods of operations and effects of transitions as specified in 13.3.3. How about deleting "the Behavior of ": .... any requests arriving at this Port are handled by the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. --Axel Am 07.11.2013 um 10:06 schrieb "Bran Selic" : It's a good question, Yves. I can say with certainty that the original intent was that behavior ports were connected to the classifier behavior only, because this model was proven in practice (UML-RT, SDL). However, perhaps we need to generalize that, although there is always risk in standardizing something that has not been proven in practice. It's worth investigating. Cheers...Bran On Thu, Nov 7, 2013 at 2:33 AM, BERNARD, Yves wrote: On the semantics of behavior ports, UML 2.5 §11.3.3 says: .A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. It is not clear whether .the Behavior. refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation. This has to be clarified. 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.