Issue 10597: Behavioral port (uml2-rtf) Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com) Nature: Uncategorized Issue Severity: Summary: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Resolution: Revised Text: Actions taken: January 18, 2007: received issue Discussion: End of Annotations:===== ubject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Thu, 18 Jan 2007 19:06:28 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier thread-index: Acc7Xaq12fGpKPJKSSuvAONPTEtWng== From: "Ed Seidewitz" To: Cc: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Subject: Behavioral port Date: Tue, 16 Jan 2007 11:36:02 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Wh37ki6y+240T12coKSQEwCBww== From: "GERARD Sebastien 166342" To: X-OriginalArrivalTime: 16 Jan 2007 10:36:02.0580 (UTC) FILETIME=[1E8DD540:01C7395A] Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 From: "Thomas Weigert" To: "'GERARD Sebastien 166342'" , Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 04:43:16 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc5Wh37ki6y+240T12coKSQEwCBwwAAOeNQ There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "Thomas Weigert" Cc: "'GERARD Sebastien 166342'" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 16 Jan 2007 05:48:51 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/16/2007 05:48:54, Serialize complete at 01/16/2007 05:48:54 To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 12:01:21 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5W/F2l26f2hl8RemKy5LrgcgQwAAAZ13A From: "GERARD Sebastien 166342" To: "Branislav Selic" , "Thomas Weigert" Cc: X-OriginalArrivalTime: 16 Jan 2007 11:01:21.0689 (UTC) FILETIME=[A8037890:01C7395D] Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "GERARD Sebastien 166342" Cc: "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 16 Jan 2007 06:07:05 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/16/2007 06:07:08, Serialize complete at 01/16/2007 06:07:08 Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "GERARD Sebastien 166342" Cc: "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 16 Jan 2007 07:34:01 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/16/2007 07:34:02, Serialize complete at 01/16/2007 07:34:02 yes. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 16:41:07 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMw From: "Alan Moore" To: "Branislav Selic" , "GERARD Sebastien 166342" Cc: "Thomas Weigert" , I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1168966171!4191043!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" , "'GERARD Sebastien 166342'" Cc: Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 10:49:25 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMA= Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 16:54:21 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggA== From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" , "GERARD Sebastien 166342" Cc: OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1168968669!14342273!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" , "'GERARD Sebastien 166342'" Cc: Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 11:31:04 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7Sw What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 18:24:25 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yA= From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" , "GERARD Sebastien 166342" Cc: When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1168972431!7267566!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" , "'GERARD Sebastien 166342'" Cc: Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 12:33:48 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgA== No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 19:27:53 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1A From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" , "GERARD Sebastien 166342" Cc: Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1168978512!3135880!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" , "'GERARD Sebastien 166342'" Cc: Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 14:15:06 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxA= What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 20:40:18 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8A== From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" , "GERARD Sebastien 166342" Cc: As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1168980713!9422801!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" , "'GERARD Sebastien 166342'" Cc: Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 14:51:46 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8AAAxQiw I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 16:35:19 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8AAAxQiwAAC/+UA= From: "Ed Seidewitz" To: "Thomas Weigert" Cc: Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Tue, 16 Jan 2007 23:35:30 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8AAAxQiwAAC/+UAAAsayoA== From: "GERARD Sebastien 166342" To: "Ed Seidewitz" , "Thomas Weigert" Cc: X-OriginalArrivalTime: 16 Jan 2007 22:35:30.0585 (UTC) FILETIME=[A0B0A890:01C739BE] Hi guys, I second the points raised by Alan and Ed on the fact that I do not see any reason to forbid ports on passive objects. Moreover, as I advocate also that it may be useful to specify behaviour of passive object through statemachine (even if I recognize that the actual semantics of statemachine of UML is may be not suited), I would find very useful to have also behavioural ports on passive objects. Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : mardi 16 janvier 2007 22:35 À : Thomas Weigert Cc : uml2-rtf@omg.org Objet : RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Date: Wed, 17 Jan 2007 02:35:58 -0500 From: "Chonoles, Michael J" Subject: RE: Behavioral port To: GERARD Sebastien 166342 , Ed Seidewitz , Thomas Weigert Cc: uml2-rtf@omg.org Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8AAAxQiwAAC/+UAAAsayoAAR6cYg X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 17 Jan 2007 07:36:03.0268 (UTC) FILETIME=[24135840:01C73A0A] I would also agree. It is already standard modeling practice to model ports on passive objects. I also don.t believe that a passive object couldn.t have a state machine. Michael Jesse Chonoles -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 5:35 PM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi guys, I second the points raised by Alan and Ed on the fact that I do not see any reason to forbid ports on passive objects. Moreover, as I advocate also that it may be useful to specify behaviour of passive object through statemachine (even if I recognize that the actual semantics of statemachine of UML is may be not suited), I would find very useful to have also behavioural ports on passive objects. Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : mardi 16 janvier 2007 22:35 À : Thomas Weigert Cc : uml2-rtf@omg.org Objet : RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. smime4.p7s Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 10:09:29 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8AAAxQiwAAC/+UAAGvGoYA== From: "Alan Moore" To: "Ed Seidewitz" , "Thomas Weigert" Cc: Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "Alan Moore" Cc: "Ed Seidewitz" , "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 17 Jan 2007 05:43:40 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/17/2007 05:43:42, Serialize complete at 01/17/2007 05:43:42 The defining feature of behavior ports is that they are connected to classifier behavior. The classifier behavior can do the delegation if the application needs it. If someone wants a new kind of port mechanism, they should raise an issue or draft an RFP. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Alan Moore" 01/17/2007 05:09 AM To "Ed Seidewitz" , "Thomas Weigert" cc Subject RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "Alan Moore" Cc: "Ed Seidewitz" , "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 17 Jan 2007 06:05:23 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/17/2007 06:05:23, Serialize complete at 01/17/2007 06:05:23 Alan, > It sounds like you concur with Thomas that behaviour ports only make > sense where the owning class has a classifierBehavior. Is your > reasoning the same as Thomas.s? Just to note that this is the reasoning that was used when the concept of behavior port was defined. The spec may not properly reflect that, but that is a separate issue. I think it would be wrong to try to opportunistically take advantage of some stylistic deficiency to extend the semantics. If we need to extend the semantics, this should be done properly. > Can either of you point me at areas > of the spec, other than the part that explicitly states the > constraint, that demonstrate why the situation I outlined below won. > t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, > containing Operation op1. I would have thought that if C1 also had > an Operation op1 that did have a Behavior as a method, then it could > forward a Request for op1 on BP1 to that method, even if C1 itself > didn.t have a classifierBehavior.. See above. Bran From: "Thomas Weigert" To: "'Chonoles, Michael J'" , "'GERARD Sebastien 166342'" , "'Ed Seidewitz'" Cc: Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 05:29:50 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc6CxXpFCNUIaYJR1mzVTTgFWbpGAAHyGGg Dear all, in my mother tongue there is a saying which roughly translates to "paper has lots of patience". Yes, I know it does not come across very poetic, but in this context it roughly means that you can make up anything you want in an email. But before you get too excited about such extended features as described below, it would be a good idea to describe the dynamic semantics of the proposed constructs. Without a clear understanding of what it could mean, e.g., to send to a behavior port of a passive object, there is no point discussing whether ruling this out is appropriate or not. Cheers, Th. -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, January 17, 2007 1:36 AM To: GERARD Sebastien 166342; Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I would also agree. It is already standard modeling practice to model ports on passive objects. I also don.t believe that a passive object couldn.t have a state machine. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 5:35 PM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi guys, I second the points raised by Alan and Ed on the fact that I do not see any reason to forbid ports on passive objects. Moreover, as I advocate also that it may be useful to specify behaviour of passive object through statemachine (even if I recognize that the actual semantics of statemachine of UML is may be not suited), I would find very useful to have also behavioural ports on passive objects. -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : mardi 16 janvier 2007 22:35 À : Thomas Weigert Cc : uml2-rtf@omg.org Objet : RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 12:39:17 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc6J1JzRXoJDT7dR2OTuE6MqMWPoQACXjQA From: "Alan Moore" To: "Branislav Selic" Cc: "Ed Seidewitz" , "Thomas Weigert" , Hi Bran, Here are the sentences that describe the semantics of behaviour ports: 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 Chapter 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. My position is that, the sentences under discussion aside, the semantics of behaviours is flexible enough to support a Behavior port without a classifierBehavior and that it is very useful. Further that these sentences should really be derived from more general semantics rather than stated here. Surely the semantics of behaviour ports arise from the fact that they are objects with their own behaviour (at least I assume they are although the sentences are a bit ambiguous) that are forwarding the requests sent to them. So, in summary I think that the semantics described here are arbitrary and don.t arise from my reading at least of the general behavioural semantics expressed in the Common Behaviors chapter. As I said in my previous e-mail, can someone tell me why these more general semantics give rise to the semantics expressed for behaviour ports. Alternatively can someone provide a longer description of the reasoning that Bran refers to below. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 11:05 AM To: Alan Moore Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Alan, > It sounds like you concur with Thomas that behaviour ports only make > sense where the owning class has a classifierBehavior. Is your > reasoning the same as Thomas.s? Just to note that this is the reasoning that was used when the concept of behavior port was defined. The spec may not properly reflect that, but that is a separate issue. I think it would be wrong to try to opportunistically take advantage of some stylistic deficiency to extend the semantics. If we need to extend the semantics, this should be done properly. > Can either of you point me at areas > of the spec, other than the part that explicitly states the > constraint, that demonstrate why the situation I outlined below won. > t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, > containing Operation op1. I would have thought that if C1 also had > an Operation op1 that did have a Behavior as a method, then it could > forward a Request for op1 on BP1 to that method, even if C1 itself > didn.t have a classifierBehavior.. See above. Bran X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1169038139!7048191!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.103] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" Cc: "'Ed Seidewitz'" , Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 06:48:55 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc6J1JzRXoJDT7dR2OTuE6MqMWPoQACXjQAAAE2vHA= As I said earlier, when extending the semantics one needs to show what the intended behavior of the so modified constructs is. Without such, this discussion is not very fruitful... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 6:39 AM To: Branislav Selic Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Hi Bran, Here are the sentences that describe the semantics of behaviour ports: 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 Chapter 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. My position is that, the sentences under discussion aside, the semantics of behaviours is flexible enough to support a Behavior port without a classifierBehavior and that it is very useful. Further that these sentences should really be derived from more general semantics rather than stated here. Surely the semantics of behaviour ports arise from the fact that they are objects with their own behaviour (at least I assume they are although the sentences are a bit ambiguous) that are forwarding the requests sent to them. So, in summary I think that the semantics described here are arbitrary and don.t arise from my reading at least of the general behavioural semantics expressed in the Common Behaviors chapter. As I said in my previous e-mail, can someone tell me why these more general semantics give rise to the semantics expressed for behaviour ports. Alternatively can someone provide a longer description of the reasoning that Bran refers to below. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 11:05 AM To: Alan Moore Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Alan, > It sounds like you concur with Thomas that behaviour ports only make > sense where the owning class has a classifierBehavior. Is your > reasoning the same as Thomas.s? Just to note that this is the reasoning that was used when the concept of behavior port was defined. The spec may not properly reflect that, but that is a separate issue. I think it would be wrong to try to opportunistically take advantage of some stylistic deficiency to extend the semantics. If we need to extend the semantics, this should be done properly. > Can either of you point me at areas > of the spec, other than the part that explicitly states the > constraint, that demonstrate why the situation I outlined below won. > t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, > containing Operation op1. I would have thought that if C1 also had > an Operation op1 that did have a Behavior as a method, then it could > forward a Request for op1 on BP1 to that method, even if C1 itself > didn.t have a classifierBehavior.. See above. Bran Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 12:58:05 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc6J1JzRXoJDT7dR2OTuE6MqMWPoQACXjQAAAE2vHAAACSXgA== From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" Cc: "Ed Seidewitz" , The semantics for both port and port owner are as stated in the semantics expressed in Common Behaviors for BehavioredClassifier: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. i.e. just have this in the semantics for behaviour ports: .For a behavior port, the instance of the owning classifier will handle requests arriving at this port. If there is no behavior able to handle this Request in this classifier, the Request is lost.. Nothing else need be said. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, January 17, 2007 12:49 PM To: Alan Moore; 'Branislav Selic' Cc: 'Ed Seidewitz'; uml2-rtf@omg.org Subject: RE: Behavioral port As I said earlier, when extending the semantics one needs to show what the intended behavior of the so modified constructs is. Without such, this discussion is not very fruitful... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 6:39 AM To: Branislav Selic Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Hi Bran, Here are the sentences that describe the semantics of behaviour ports: 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 Chapter 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. My position is that, the sentences under discussion aside, the semantics of behaviours is flexible enough to support a Behavior port without a classifierBehavior and that it is very useful. Further that these sentences should really be derived from more general semantics rather than stated here. Surely the semantics of behaviour ports arise from the fact that they are objects with their own behaviour (at least I assume they are although the sentences are a bit ambiguous) that are forwarding the requests sent to them. So, in summary I think that the semantics described here are arbitrary and don.t arise from my reading at least of the general behavioural semantics expressed in the Common Behaviors chapter. As I said in my previous e-mail, can someone tell me why these more general semantics give rise to the semantics expressed for behaviour ports. Alternatively can someone provide a longer description of the reasoning that Bran refers to below. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 11:05 AM To: Alan Moore Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Alan, > It sounds like you concur with Thomas that behaviour ports only make > sense where the owning class has a classifierBehavior. Is your > reasoning the same as Thomas.s? Just to note that this is the reasoning that was used when the concept of behavior port was defined. The spec may not properly reflect that, but that is a separate issue. I think it would be wrong to try to opportunistically take advantage of some stylistic deficiency to extend the semantics. If we need to extend the semantics, this should be done properly. > Can either of you point me at areas > of the spec, other than the part that explicitly states the > constraint, that demonstrate why the situation I outlined below won. > t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, > containing Operation op1. I would have thought that if C1 also had > an Operation op1 that did have a Behavior as a method, then it could > forward a Request for op1 on BP1 to that method, even if C1 itself > didn.t have a classifierBehavior.. See above. Bran X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1169039251!12670330!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" Cc: "'Ed Seidewitz'" , Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 07:07:25 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc6J1JzRXoJDT7dR2OTuE6MqMWPoQACXjQAAAE2vHAAACSXgAAAhVfg That is not really a description of behavior. What does it mean to "handle the behavior"? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 6:58 AM To: Thomas Weigert; Branislav Selic Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The semantics for both port and port owner are as stated in the semantics expressed in Common Behaviors for BehavioredClassifier: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. i.e. just have this in the semantics for behaviour ports: .For a behavior port, the instance of the owning classifier will handle requests arriving at this port. If there is no behavior able to handle this Request in this classifier, the Request is lost.. Nothing else need be said. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, January 17, 2007 12:49 PM To: Alan Moore; 'Branislav Selic' Cc: 'Ed Seidewitz'; uml2-rtf@omg.org Subject: RE: Behavioral port As I said earlier, when extending the semantics one needs to show what the intended behavior of the so modified constructs is. Without such, this discussion is not very fruitful... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 6:39 AM To: Branislav Selic Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Hi Bran, Here are the sentences that describe the semantics of behaviour ports: 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 Chapter 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. My position is that, the sentences under discussion aside, the semantics of behaviours is flexible enough to support a Behavior port without a classifierBehavior and that it is very useful. Further that these sentences should really be derived from more general semantics rather than stated here. Surely the semantics of behaviour ports arise from the fact that they are objects with their own behaviour (at least I assume they are although the sentences are a bit ambiguous) that are forwarding the requests sent to them. So, in summary I think that the semantics described here are arbitrary and don.t arise from my reading at least of the general behavioural semantics expressed in the Common Behaviors chapter. As I said in my previous e-mail, can someone tell me why these more general semantics give rise to the semantics expressed for behaviour ports. Alternatively can someone provide a longer description of the reasoning that Bran refers to below. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 11:05 AM To: Alan Moore Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Alan, > It sounds like you concur with Thomas that behaviour ports only make > sense where the owning class has a classifierBehavior. Is your > reasoning the same as Thomas.s? Just to note that this is the reasoning that was used when the concept of behavior port was defined. The spec may not properly reflect that, but that is a separate issue. I think it would be wrong to try to opportunistically take advantage of some stylistic deficiency to extend the semantics. If we need to extend the semantics, this should be done properly. > Can either of you point me at areas > of the spec, other than the part that explicitly states the > constraint, that demonstrate why the situation I outlined below won. > t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, > containing Operation op1. I would have thought that if C1 also had > an Operation op1 that did have a Behavior as a method, then it could > forward a Request for op1 on BP1 to that method, even if C1 itself > didn.t have a classifierBehavior.. See above. Bran Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 13:22:47 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc6J1JzRXoJDT7dR2OTuE6MqMWPoQACXjQAAAE2vHAAACSXgAAAhVfgAAB/SmA= From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" Cc: "Ed Seidewitz" , Do you mean .handle Requests.? That bit I took straight from the current spec. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, January 17, 2007 1:07 PM To: Alan Moore; 'Branislav Selic' Cc: 'Ed Seidewitz'; uml2-rtf@omg.org Subject: RE: Behavioral port That is not really a description of behavior. What does it mean to "handle the behavior"? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 6:58 AM To: Thomas Weigert; Branislav Selic Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The semantics for both port and port owner are as stated in the semantics expressed in Common Behaviors for BehavioredClassifier: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. i.e. just have this in the semantics for behaviour ports: .For a behavior port, the instance of the owning classifier will handle requests arriving at this port. If there is no behavior able to handle this Request in this classifier, the Request is lost.. Nothing else need be said. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, January 17, 2007 12:49 PM To: Alan Moore; 'Branislav Selic' Cc: 'Ed Seidewitz'; uml2-rtf@omg.org Subject: RE: Behavioral port As I said earlier, when extending the semantics one needs to show what the intended behavior of the so modified constructs is. Without such, this discussion is not very fruitful... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 6:39 AM To: Branislav Selic Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Hi Bran, Here are the sentences that describe the semantics of behaviour ports: 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 Chapter 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. My position is that, the sentences under discussion aside, the semantics of behaviours is flexible enough to support a Behavior port without a classifierBehavior and that it is very useful. Further that these sentences should really be derived from more general semantics rather than stated here. Surely the semantics of behaviour ports arise from the fact that they are objects with their own behaviour (at least I assume they are although the sentences are a bit ambiguous) that are forwarding the requests sent to them. So, in summary I think that the semantics described here are arbitrary and don.t arise from my reading at least of the general behavioural semantics expressed in the Common Behaviors chapter. As I said in my previous e-mail, can someone tell me why these more general semantics give rise to the semantics expressed for behaviour ports. Alternatively can someone provide a longer description of the reasoning that Bran refers to below. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 11:05 AM To: Alan Moore Cc: Ed Seidewitz; Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Alan, > It sounds like you concur with Thomas that behaviour ports only make > sense where the owning class has a classifierBehavior. Is your > reasoning the same as Thomas.s? Just to note that this is the reasoning that was used when the concept of behavior port was defined. The spec may not properly reflect that, but that is a separate issue. I think it would be wrong to try to opportunistically take advantage of some stylistic deficiency to extend the semantics. If we need to extend the semantics, this should be done properly. > Can either of you point me at areas > of the spec, other than the part that explicitly states the > constraint, that demonstrate why the situation I outlined below won. > t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, > containing Operation op1. I would have thought that if C1 also had > an Operation op1 that did have a Behavior as a method, then it could > forward a Request for op1 on BP1 to that method, even if C1 itself > didn.t have a classifierBehavior.. See above. Bran Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 10:55:02 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAAH4F8AAAxQiwAAC/+UAAGvGoYAAL13qQ From: "Ed Seidewitz" To: Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 17 Jan 2007 17:35:03 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/17/2007 17:35:05, Serialize complete at 01/17/2007 17:35:05 It is possible to have ports on passive classes, but the semantics of that are not defined. In my view, there are a number of possible interpretations and solutions to the problem of what this means and they need to be debated. I am greatly concerned about solving this problem with a minor "clarification" based on taking advantage of a loophole in the wording of the spec. This needs a systematic and well-understood solution. Alan's solution may be one possible one and it may even be the best one, but I really don't think that we should make a snap decision in this case, without doing a proper analysis. The current solution with active objects and classifiers behavior is based on a lot of practical experience and is well understood. There is no real experience that I know of with passive class ports. My 2 cents' worth. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 10:55 AM To cc Subject RE: Behavioral port Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 17:40:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc6h8n3W65oqED+Q5aETLiFzilNLwAAEIQQ From: "Ed Seidewitz" To: "Branislav Selic" Cc: Bran -- Only behavior ports forward requests to the classifier behavior. I don't believe the semantics of non-behavior ports -- the default -- involves the classifier behavior. Wouldn't this imply that the default situation is to have ports on passive classes? How do you understand the semantics of non-behavior ports? Since, out of all the discussion in the section on Port, there are only a couple of paragraphs or so specifically on behavior ports, wouldn't all the rest apply equally well to non-behavior ports? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port It is possible to have ports on passive classes, but the semantics of that are not defined. In my view, there are a number of possible interpretations and solutions to the problem of what this means and they need to be debated. I am greatly concerned about solving this problem with a minor "clarification" based on taking advantage of a loophole in the wording of the spec. This needs a systematic and well-understood solution. Alan's solution may be one possible one and it may even be the best one, but I really don't think that we should make a snap decision in this case, without doing a proper analysis. The current solution with active objects and classifiers behavior is based on a lot of practical experience and is well understood. There is no real experience that I know of with passive class ports. My 2 cents' worth. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 10:55 AM To cc Subject RE: Behavioral port Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 17 Jan 2007 17:58:41 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/17/2007 17:58:44, Serialize complete at 01/17/2007 17:58:44 The semantics of non-behavior ports, currently, are to simply relay what comes in one one side to the other side -- assuming there is something on the other side. If there is nothing, they simply relay communications into the ethereal Ether; i.e., they are lost. It may be a good idea to add a new category of ports that do something different, but this is what we need to understand. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 05:40 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Behavioral port Bran -- Only behavior ports forward requests to the classifier behavior. I don't believe the semantics of non-behavior ports -- the default -- involves the classifier behavior. Wouldn't this imply that the default situation is to have ports on passive classes? How do you understand the semantics of non-behavior ports? Since, out of all the discussion in the section on Port, there are only a couple of paragraphs or so specifically on behavior ports, wouldn't all the rest apply equally well to non-behavior ports? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port It is possible to have ports on passive classes, but the semantics of that are not defined. In my view, there are a number of possible interpretations and solutions to the problem of what this means and they need to be debated. I am greatly concerned about solving this problem with a minor "clarification" based on taking advantage of a loophole in the wording of the spec. This needs a systematic and well-understood solution. Alan's solution may be one possible one and it may even be the best one, but I really don't think that we should make a snap decision in this case, without doing a proper analysis. The current solution with active objects and classifiers behavior is based on a lot of practical experience and is well understood. There is no real experience that I know of with passive class ports. My 2 cents' worth. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 10:55 AM To cc Subject RE: Behavioral port Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. From: "Thomas Weigert" To: "'Branislav Selic'" , "'Ed Seidewitz'" Cc: Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 17:05:43 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc6i5lKbZchhiA3TLmu2MzRWRVppwAACD8w Actually, the behavior of the ports can be varied depending on the type of the port. However, the default behavior, where the type of the port is an interface or the behavior is not further defined in the type of the port, is as Bran describes. There is a semantic variation as to whether the message is routed on all applicable connectors or whether there is one connector picked to route on. Note that how the behavior of the port is affected by the type (how to define that) is not explicated in the specification. Th. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 4:59 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port The semantics of non-behavior ports, currently, are to simply relay what comes in one one side to the other side -- assuming there is something on the other side. If there is nothing, they simply relay communications into the ethereal Ether; i.e., they are lost. It may be a good idea to add a new category of ports that do something different, but this is what we need to understand. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 05:40 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Behavioral port Bran -- Only behavior ports forward requests to the classifier behavior. I don't believe the semantics of non-behavior ports -- the default -- involves the classifier behavior. Wouldn't this imply that the default situation is to have ports on passive classes? How do you understand the semantics of non-behavior ports? Since, out of all the discussion in the section on Port, there are only a couple of paragraphs or so specifically on behavior ports, wouldn't all the rest apply equally well to non-behavior ports? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port It is possible to have ports on passive classes, but the semantics of that are not defined. In my view, there are a number of possible interpretations and solutions to the problem of what this means and they need to be debated. I am greatly concerned about solving this problem with a minor "clarification" based on taking advantage of a loophole in the wording of the spec. This needs a systematic and well-understood solution. Alan's solution may be one possible one and it may even be the best one, but I really don't think that we should make a snap decision in this case, without doing a proper analysis. The current solution with active objects and classifiers behavior is based on a lot of practical experience and is well understood. There is no real experience that I know of with passive class ports. My 2 cents' worth. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 10:55 AM To cc Subject RE: Behavioral port Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ Subject: RE: Behavioral port Date: Wed, 17 Jan 2007 18:09:05 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc6ixTvjCDepEsJSH+SYSgZtoXC+QAAO4OA From: "Ed Seidewitz" To: "Branislav Selic" Cc: OK, so this means that, as the semantics are currently defined, when you ultimately get to a port that is not connected to anything inside, then you need to have an active class to which the port forwards requests. Then I agree with Alan that this is an unnecessary restriction. However, I also agree with Bran that this is not just a minor tweak -- though I think a relatively straightforward change along the lines of what Alan suggested would probably work. This should be entered as an issue for consideration by this or the next RTF. Until then, folks can just come up with their own semantics for the use of ports with passive classes, as I am sure many have. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:59 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port The semantics of non-behavior ports, currently, are to simply relay what comes in one one side to the other side -- assuming there is something on the other side. If there is nothing, they simply relay communications into the ethereal Ether; i.e., they are lost. It may be a good idea to add a new category of ports that do something different, but this is what we need to understand. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 05:40 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Behavioral port Bran -- Only behavior ports forward requests to the classifier behavior. I don't believe the semantics of non-behavior ports -- the default -- involves the classifier behavior. Wouldn't this imply that the default situation is to have ports on passive classes? How do you understand the semantics of non-behavior ports? Since, out of all the discussion in the section on Port, there are only a couple of paragraphs or so specifically on behavior ports, wouldn't all the rest apply equally well to non-behavior ports? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port It is possible to have ports on passive classes, but the semantics of that are not defined. In my view, there are a number of possible interpretations and solutions to the problem of what this means and they need to be debated. I am greatly concerned about solving this problem with a minor "clarification" based on taking advantage of a loophole in the wording of the spec. This needs a systematic and well-understood solution. Alan's solution may be one possible one and it may even be the best one, but I really don't think that we should make a snap decision in this case, without doing a proper analysis. The current solution with active objects and classifiers behavior is based on a lot of practical experience and is well understood. There is no real experience that I know of with passive class ports. My 2 cents' worth. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 10:55 AM To cc Subject RE: Behavioral port Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 17 Jan 2007 18:20:32 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/17/2007 18:20:34, Serialize complete at 01/17/2007 18:20:34 Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 17 Jan 2007 22:29:51 -0500 To: Branislav Selic , "Ed Seidewitz" From: Juergen Boldt Subject: RE: Behavioral port Cc: uml2-rtf@omg.org I will assign an issue number to this thread.. -Juergen At 06:20 PM 1/17/2007, Branislav Selic wrote: Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Desfray" To: "'Ed Seidewitz'" , "'Branislav Selic'" Cc: Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 12:07:07 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc6ixTvjCDepEsJSH+SYSgZtoXC+QAAO4OAABkOAXA= X-Virus-Scanned: by amavisd-new at softeam.com Dear all, My understanding of ports is close to what Alan and Ed are expressing. I agree with Bran that defining a new semantics (I mean make explicit what some people have implicitly understood) is not a minor change. At least, the minimum to do is start with what Bran wrote: >> It is possible to have ports on passive classes, but the semantics of that are not defined. That is : state that this is possible, make clear in the current semantics when the spec talks about active class or in general, and if necessary leave the .passive. semantics to variation points. ========================================= Philippe -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : jeudi 18 janvier 2007 00:09 À : Branislav Selic Cc : uml2-rtf@omg.org Objet : RE: Behavioral port OK, so this means that, as the semantics are currently defined, when you ultimately get to a port that is not connected to anything inside, then you need to have an active class to which the port forwards requests. Then I agree with Alan that this is an unnecessary restriction. However, I also agree with Bran that this is not just a minor tweak -- though I think a relatively straightforward change along the lines of what Alan suggested would probably work. This should be entered as an issue for consideration by this or the next RTF. Until then, folks can just come up with their own semantics for the use of ports with passive classes, as I am sure many have. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:59 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port The semantics of non-behavior ports, currently, are to simply relay what comes in one one side to the other side -- assuming there is something on the other side. If there is nothing, they simply relay communications into the ethereal Ether; i.e., they are lost. It may be a good idea to add a new category of ports that do something different, but this is what we need to understand. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 05:40 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Behavioral port Bran -- Only behavior ports forward requests to the classifier behavior. I don't believe the semantics of non-behavior ports -- the default -- involves the classifier behavior. Wouldn't this imply that the default situation is to have ports on passive classes? How do you understand the semantics of non-behavior ports? Since, out of all the discussion in the section on Port, there are only a couple of paragraphs or so specifically on behavior ports, wouldn't all the rest apply equally well to non-behavior ports? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 17, 2007 5:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port It is possible to have ports on passive classes, but the semantics of that are not defined. In my view, there are a number of possible interpretations and solutions to the problem of what this means and they need to be debated. I am greatly concerned about solving this problem with a minor "clarification" based on taking advantage of a loophole in the wording of the spec. This needs a systematic and well-understood solution. Alan's solution may be one possible one and it may even be the best one, but I really don't think that we should make a snap decision in this case, without doing a proper analysis. The current solution with active objects and classifiers behavior is based on a lot of practical experience and is well understood. There is no real experience that I know of with passive class ports. My 2 cents' worth. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/17/2007 10:55 AM To cc Subject RE: Behavioral port Alan -- I was just objecting to Thomas' unqualified statement that "I don't even understand what it would mean to have internal structure or ports on passive objects". Note that he does not limit this statement to "behavior ports". Whatever the discussion about behavior ports, certainly passive objects can have ports that are not behavior ports. As to behavior ports, the description for the Port::isBehavior attribute says "Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier". Thus, it seems pretty explicit to me that the who reason for behavior ports at all is to have them direct requests to the classifier behavior. That is currently what it means to be a behavior port. I think you are saying that it makes sense to be able to direct a request arriving at a port to an operation of the classifier owning the port, rather than some internal part of the port. I would agree that this makes sense. However, I believe that it can be covered by the case of a non-behavior port that does not have an "inside" connection to an internal part. If Thomas and Bran say I am mistaken about this, then this would imply that, according to the current spec, any use of ports on a classifier without internal structure would pretty much require that class to be active with a classifier behavior. I would then agree with you that this is a real issue, because I think there are people who believe that it is useful to use ports even when you don't have active classes (me, for instance). So, Thomas and Bran, is it currently allowable to have a class with ports that are not behavior ports, but no internal structure, such that requests to the ports are forwarded to operations of the owning class? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Wednesday, January 17, 2007 5:09 AM To: Ed Seidewitz; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Hi Ed, It sounds like you concur with Thomas that behaviour ports only make sense where the owning class has a classifierBehavior. Is your reasoning the same as Thomas.s? Can either of you point me at areas of the spec, other than the part that explicitly states the constraint, that demonstrate why the situation I outlined below won.t work : .Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior.. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Tuesday, January 16, 2007 9:35 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thomas -- I have been following this thread, and, up to this point, I have been following the points you are making. But I am surprised by your comment about not understanding internal structure or ports on passive objects. If a port is not a behavior port, then calls on behavioral features provided via the port can be just regular operation calls. These calls can then be delegated to interfaces on internal parts. Neither the containing object nor its parts need to be active. Indeed, I would have thought that this is a pretty common conception of the way ports work, particularly given that behavior ports are not the default. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 3:52 PM To: 'Alan Moore'; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port I don't even understand what it would mean to have internal structure or ports on passive objects.... If anything, there are not enough constraints... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 2:40 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port As far as I know there is no constraint in the specification that says that only active objects can have ports, and as I said at the start I don.t think there.s anything in the semantics of UML that make that difficult. Rather I think that the existing (as far as I can tell implied) constraint on classes with behaviour ports requiring a classifierBehavior (and presumably not an Interaction) is overly strict. I can.t see any reason why a Request sent to a Behavior Port cannot be treated as if it were sent directly to the object just like any other Request. I would recommend removing the constraint, or given that there is no actual constraint rewording the couple of sentences in the Semantics that imply the constraint. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 8:15 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What sense would any port make on a passive object? Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 1:28 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Does this mean that only active objects can have behaviour ports? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 6:34 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port No. I am saying the same thing... in addition, I mentioned that the thread of the active object executes the classifier behavior. Typically that would be a long-lived behavior such as a state machine. As such, it can receive the forwarded messages. There is no other behavior which could.... Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 12:24 PM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port When I look in the Common Behaviors chapter I see this for BehavioredClassifier: .When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence).. And this for Class: .A class may be designated as active (i.e., each of its instances having its own thread of control) or passive (i.e., each of its instances executing within the context of some other object).. .An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.. As far as I can see, only an active object has its own thread of execution and an object can respond to event occurrences whether or not it has a classifierBehaviour and whether or not it is Active. It sounds different from what you.ve said below . or have I misinterpreted? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 5:31 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port What I mean is this: The methods of an object are just like function calls, waiting to be invoked. The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:54 AM To: Thomas Weigert; Branislav Selic; GERARD Sebastien 166342 Cc: uml2-rtf@omg.org Subject: RE: Behavioral port OK to the first part . rightly or wrongly that.s what the spec says. on the second part what does .executing independently. mean and why is it significant? Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, January 16, 2007 4:49 PM To: Alan Moore; 'Branislav Selic'; 'GERARD Sebastien 166342' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Per spec the behavior port is an API to the classifier behavior as there is no other behavior to forward to... a method is not executing independently, so the behavior port could not forward to it. Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Tuesday, January 16, 2007 10:41 AM To: Branislav Selic; GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port I.ve never read this bit closely before . it does seem a bit limiting. Say a Class C1 has a behaviour port .BP1. typed by I1, containing Operation op1. I would have thought that if C1 also had an Operation op1 that did have a Behavior as a method, then it could forward a Request for op1 on BP1 to that method, even if C1 itself didn.t have a classifierBehavior. I can.t see any problems with doing that. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, January 16, 2007 11:07 AM To: GERARD Sebastien 166342 Cc: Thomas Weigert; uml2-rtf@omg.org Subject: RE: Behavioral port Yes it is. There is an attribute of Behavior called "classifierBehavior" which is a meber of the "ownedBeahvior" collection of Behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "GERARD Sebastien 166342" 01/16/2007 06:01 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc Subject RE: Behavioral port Ok. And to specify which is the behavior of the classifier the port is linked to ? Is the rule you said explicit in the spec? Sébastien Gérard -------------------------------------------------------------------------------------------------- PhD - Ing. Head of the Accord-UML research project DRT-List/DTSI/SOL/LLSP - CEA/Saclay F-91191 Gif sur Yvette Cedex . France Phone/fax : +33 1 69 08 58 24 / 83 95 -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 16 janvier 2007 11:49 À : Thomas Weigert Cc : GERARD Sebastien 166342; uml2-rtf@omg.org Objet : RE: Behavioral port To be precise, there is AT MOST ONE classifier behavior. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 01/16/2007 05:43 AM To "'GERARD Sebastien 166342'" , cc Subject RE: Behavioral port There is only one classifier behavior.... albeit a classifier may own many behaviors only one is the privileged classifier behavior... Th. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, January 16, 2007 4:36 AM To: uml2-rtf@omg.org Subject: Behavioral port Hi, In case of a behavioural port, if the classifier owning a behaviour port owns several behaviour, how is it possible to specify which behaviour of the classifier the behavioural is attached to? More generally, how and where is it possible to make the link between a behavioural port and the behaviour of the owning class? Thanks, for answers, Cheers, Séb. X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 15:23:38 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc6jn/kJV4v+VVFTWuWRwCCdkpvPgAd731A From: "Eran Gery" To: "Branislav Selic" , "Ed Seidewitz" Cc: Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran To: "Eran Gery" Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 09:53:13 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 09:53:15, Serialize complete at 01/18/2007 09:53:15 Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 16:01:41 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7EHG6WSY5pvtQT7CnD50QBrANmQAACvOg From: "Eran Gery" To: "Branislav Selic" Cc: "Ed Seidewitz" , Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Date: Thu, 18 Jan 2007 15:46:34 +0000 From: Guus Ramackers Reply-To: Guus.Ramackers@Oracle.com User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Eran Gery CC: Branislav Selic , Ed Seidewitz , uml2-rtf@omg.org Subject: Re: Behavioral port X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Eran That would certainly be a consistent solution. The terms "active" and "passive" are informally defined and ideally the port semantics should not depend on those terms. Guus Eran Gery wrote: Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran -- ___________________________________________________ Guus Ramackers Product Manager J2EE, SOA & UML Tools Oracle Corporation JDeveloper group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 To: "Eran Gery" Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 11:27:01 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 11:27:03, Serialize complete at 01/18/2007 11:27:03 The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 18:53:09 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7HZRVAJifonyYRCeXPRHIQ6BUJQAAMACQ From: "Eran Gery" To: "Branislav Selic" Cc: Thanks Bran. apparently there.s one .extra. word in the text. have we removed the word .classifier. below it would have been OK. Beware that this is really .offending. as it cuts out the ability to invoke operations via the ports without having to go via the classifier behavior to .dispatch. them. This is a major pain for service oriented designs. .IsBeahvior: Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see .BehavioredClassifier (from BasicBehaviors, Communications). on page 468). Such ports are referred to as behavior port.. Note the second part of the spec below is good.. I would leave only that part which is the .useful. interpretation of a behavior port. It does not rule out Invocation of operations just because the request comes from a port .Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 6:27 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 13:04:19 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gw From: "Ed Seidewitz" To: "Branislav Selic" Cc: Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1169143473!3289126!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.105] From: "Thomas Weigert" To: "'Eran Gery'" , "'Branislav Selic'" Cc: Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 12:04:26 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc7HZRVAJifonyYRCeXPRHIQ6BUJQAAMACQAAMksFA= Eran, below is specific to behavior ports. I am sure you will agree that behavior ports require a classifier behavior by definition. Leaving the word "classifier" out totally changes the meaning of behavior port. Th. -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 11:53 AM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thanks Bran. apparently there.s one .extra. word in the text. have we removed the word .classifier. below it would have been OK. Beware that this is really .offending. as it cuts out the ability to invoke operations via the ports without having to go via the classifier behavior to .dispatch. them. This is a major pain for service oriented designs. .IsBeahvior: Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see .BehavioredClassifier (from BasicBehaviors, Communications). on page 468). Such ports are referred to as behavior port.. Note the second part of the spec below is good.. I would leave only that part which is the .useful. interpretation of a behavior port. It does not rule out Invocation of operations just because the request comes from a port .Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 6:27 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 13:26:06 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7HZRVAJifonyYRCeXPRHIQ6BUJQAAMACQAAMksFAAAGuAAA== From: "Ed Seidewitz" To: Whether you still call it a behavior port or not, I believe that the desire is to have a kind of port that, like a behavior port, forwards requests to the instance of the owning classifier. But instead of forwarding to the classifier behavior, it forwards directly to some behavioral feature of the classifier. The reason that this is more than a trivial removal of a word, however, is that you would need to specify to which behavior features each request is routed. In the case of a behavior port, as currently specified, all requests are routed to the single, distinguished classifier behavior, and then this can determine how to dispatch them further. Note that the semantics section for Port states that "The owning classifier must offer the features owned by the provided interfaces.", however I can't find any constraint formally requiring this. If the owning classifier conformed to the provided interfaces of a port, then it would offer all the behavioral features provided via that port, and it would be natural to allow for requests to those features through the port to be forwarded to the corresponding methods given by the owning classifier. Working this all out properly is what needs to be discussed as part of the resolution of a formal issue on this. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, January 18, 2007 1:04 PM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Eran, below is specific to behavior ports. I am sure you will agree that behavior ports require a classifier behavior by definition. Leaving the word "classifier" out totally changes the meaning of behavior port. Th. -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 11:53 AM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thanks Bran. apparently there.s one .extra. word in the text. have we removed the word .classifier. below it would have been OK. Beware that this is really .offending. as it cuts out the ability to invoke operations via the ports without having to go via the classifier behavior to .dispatch. them. This is a major pain for service oriented designs. .IsBeahvior: Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see .BehavioredClassifier (from BasicBehaviors, Communications). on page 468). Such ports are referred to as behavior port.. Note the second part of the spec below is good.. I would leave only that part which is the .useful. interpretation of a behavior port. It does not rule out Invocation of operations just because the request comes from a port .Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 6:27 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1169144842!5185384!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] From: "Thomas Weigert" To: "'Ed Seidewitz'" , "'Branislav Selic'" Cc: Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 12:27:19 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAD1h8A= The biggest issue I have with this idea is that the object now looses control over what happens at the ports. The point of the ports was that it was a controlled and well-typed communication to the object. Either it was routed on connections that the object established and knows about, or it was mediated by classifier behavior. No suddenly you open port-based behavior to outside control... this is not in the spirit of ports, in my opinion. What user experience is driving this requirement? Is this just feature creep? Other questions: I assume you would send a "callinvocationrequest" or something like that? Would the purpose be for situations where I don't have the identify of the classifier whose behavior I am invoking but I do have a port or a path to that classifier? You can always invoke an operation on the object, so there must be some reason why it has to be through the port.... Th. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 12:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 Jan 2007 13:28:55 -0500 To: "Ed Seidewitz" , From: Juergen Boldt Subject: RE: Behavioral port Ed, can you provide a formal text for the issue? -Juergen At 01:26 PM 1/18/2007, Ed Seidewitz wrote: Whether you still call it a behavior port or not, I believe that the desire is to have a kind of port that, like a behavior port, forwards requests to the instance of the owning classifier. But instead of forwarding to the classifier behavior, it forwards directly to some behavioral feature of the classifier. The reason that this is more than a trivial removal of a word, however, is that you would need to specify to which behavior features each request is routed. In the case of a behavior port, as currently specified, all requests are routed to the single, distinguished classifier behavior, and then this can determine how to dispatch them further. Note that the semantics section for Port states that "The owning classifier must offer the features owned by the provided interfaces.", however I can't find any constraint formally requiring this. If the owning classifier conformed to the provided interfaces of a port, then it would offer all the behavioral features provided via that port, and it would be natural to allow for requests to those features through the port to be forwarded to the corresponding methods given by the owning classifier. Working this all out properly is what needs to be discussed as part of the resolution of a formal issue on this. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [ mailto:thomas.weigert@motorola.com] Sent: Thursday, January 18, 2007 1:04 PM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Eran, below is specific to behavior ports. I am sure you will agree that behavior ports require a classifier behavior by definition. Leaving the word "classifier" out totally changes the meaning of behavior port. Th. -------------------------------------------------------------------------------- From: Eran Gery [ mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 11:53 AM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thanks Bran. apparently there.s one .extra. word in the text. have we removed the word .classifier. below it would have been OK. Beware that this is really .offending. as it cuts out the ability to invoke operations via the ports without having to go via the classifier behavior to .dispatch. them. This is a major pain for service oriented designs. .IsBeahvior: Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see .BehavioredClassifier (from BasicBehaviors, Communications). on page 468). Such ports are referred to as behavior port.. Note the second part of the spec below is good.. I would leave only that part which is the .useful. interpretation of a behavior port. It does not rule out Invocation of operations just because the request comes from a port .Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.. -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 6:27 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 19:31:46 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngA= From: "Eran Gery" To: "Ed Seidewitz" , "Branislav Selic" Cc: Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Date: Thu, 18 Jan 2007 13:35:08 -0500 From: "Chonoles, Michael J" Subject: RE: Behavioral port To: Ed Seidewitz , Branislav Selic Cc: uml2-rtf@omg.org Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAFseBA= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jan 2007 18:35:11.0977 (UTC) FILETIME=[635B2D90:01C73B2F] Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran smime.p7s Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 13:38:05 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7LqzoqWjkRHjPQJC/n7XGVoQyNgAAQq8A From: "Ed Seidewitz" To: "Juergen Boldt" Cc: Juergen -- I will try to get something formally submitted when I get a chance to catch my breath on the thread! -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, January 18, 2007 1:29 PM To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Ed, can you provide a formal text for the issue? -Juergen At 01:26 PM 1/18/2007, Ed Seidewitz wrote: Whether you still call it a behavior port or not, I believe that the desire is to have a kind of port that, like a behavior port, forwards requests to the instance of the owning classifier. But instead of forwarding to the classifier behavior, it forwards directly to some behavioral feature of the classifier. The reason that this is more than a trivial removal of a word, however, is that you would need to specify to which behavior features each request is routed. In the case of a behavior port, as currently specified, all requests are routed to the single, distinguished classifier behavior, and then this can determine how to dispatch them further. Note that the semantics section for Port states that "The owning classifier must offer the features owned by the provided interfaces.", however I can't find any constraint formally requiring this. If the owning classifier conformed to the provided interfaces of a port, then it would offer all the behavioral features provided via that port, and it would be natural to allow for requests to those features through the port to be forwarded to the corresponding methods given by the owning classifier. Working this all out properly is what needs to be discussed as part of the resolution of a formal issue on this. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [ mailto:thomas.weigert@motorola.com] Sent: Thursday, January 18, 2007 1:04 PM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Eran, below is specific to behavior ports. I am sure you will agree that behavior ports require a classifier behavior by definition. Leaving the word "classifier" out totally changes the meaning of behavior port. Th. -------------------------------------------------------------------------------- From: Eran Gery [ mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 11:53 AM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Thanks Bran. apparently there.s one .extra. word in the text. have we removed the word .classifier. below it would have been OK. Beware that this is really .offending. as it cuts out the ability to invoke operations via the ports without having to go via the classifier behavior to .dispatch. them. This is a major pain for service oriented designs. .IsBeahvior: Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see .BehavioredClassifier (from BasicBehaviors, Communications). on page 468). Such ports are referred to as behavior port.. Note the second part of the spec below is good.. I would leave only that part which is the .useful. interpretation of a behavior port. It does not rule out Invocation of operations just because the request comes from a port .Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.. -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 6:27 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-4.tower-125.messagelabs.com!1169145738!10368700!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] From: "Thomas Weigert" To: "'Eran Gery'" , "'Ed Seidewitz'" , "'Branislav Selic'" Cc: Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 12:42:14 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAKmQ0A== Woah.... the port is an important differentiator... the fact that the request came via a port makes a big difference.... Th. -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 12:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 13:45:00 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAD1h8AAAJrPwA== From: "Ed Seidewitz" To: "Thomas Weigert" Cc: Thomas -- To use currently trendy terminology, to me a port represents a specification of set of services that are provided and/or required together. The key thing is that you can then specify how required services on one side are connected to provided services on the other side, independently of how those services are actually implemented. This generalizes what you can do directly with interfaces, because it allows for reification of interaction points, which provides a richer connection paradigm. What is being suggested has no effect on this basic connection semantics. It only effects how provided/required services are implemented on the "other side" of the port. There is no intent to "open port-based behavior to outside control". How the behavior of the port is implemented should be completely irrelevant to any clients of the port. All that is being suggested is that one way to implement the behavior offered through a port is to map it directly onto behavioral features offered by the owning classifier. I believe this is what a lot of people thought already happened if a non-behavior port was not connected to any internal part. -- Ed -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, January 18, 2007 1:27 PM To: Ed Seidewitz; 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port The biggest issue I have with this idea is that the object now looses control over what happens at the ports. The point of the ports was that it was a controlled and well-typed communication to the object. Either it was routed on connections that the object established and knows about, or it was mediated by classifier behavior. No suddenly you open port-based behavior to outside control... this is not in the spirit of ports, in my opinion. What user experience is driving this requirement? Is this just feature creep? Other questions: I assume you would send a "callinvocationrequest" or something like that? Would the purpose be for situations where I don't have the identify of the classifier whose behavior I am invoking but I do have a port or a path to that classifier? You can always invoke an operation on the object, so there must be some reason why it has to be through the port.... Th. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 12:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 19:53:43 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAKmQ0AAALBQw From: "Eran Gery" To: "Thomas Weigert" , "Ed Seidewitz" , "Branislav Selic" Cc: Thomas . we have many users actually using this. They want to describe architectures using ports (we all agree on the benefits of using ports to describe architectures), but on the other hand they do not want to forced to create .fictitious. classifier behaviors that all they do is dispatch operations. Note also that there are several component frameworks utilizing the port abstraction (CCM, Autosar) allowing mapping them to features of the class. Eran -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, January 18, 2007 8:42 PM To: Eran Gery; 'Ed Seidewitz'; 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Woah.... the port is an important differentiator... the fact that the request came via a port makes a big difference.... Th. -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 12:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 13:55:44 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAOqL4A== From: "Ed Seidewitz" To: "Eran Gery" Cc: Eran -- If the port has connections to internal parts, then it is already clear that the request should be forwarded along those connections. If there are no such connections, then you need a flag to indicate whether the request should forwarded to the classifier behavior or should be handled directly by some behavioral feature of the owning classifier. The isBehavior attribute already exists as such a flag -- it is just that, in the absence of internal connectors, there is no semantics in the (default) case of the flag being false. I suggest is all we need to do is provide standard semantics for that default case. An alternative would be to make the presence or absence of a classifier behavior an implicit flag. That is, all ports without internal connectors forward their requests to the classifier behavior if there is one, or to corresponding behavioral features, if there is no classifier behavior. But I think having an explicit flag on each port is a more flexible approach. In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". -- Ed -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 1:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Date: Thu, 18 Jan 2007 13:57:36 -0500 From: "Chonoles, Michael J" Subject: RE: Behavioral port To: "Chonoles, Michael J" , Ed Seidewitz , Branislav Selic Cc: uml2-rtf@omg.org Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAFseBAAABb2oA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jan 2007 18:57:39.0428 (UTC) FILETIME=[867FE240:01C73B32] In the process of development, I need the ability to treat an object as black box at some level before going lower in design A object would be defined as having many operations (perhaps by conforming to several interfaces). It could have many ports, each port typed to the interface(s) that port supports and the object could be used in connection to other objects in a larger assembly. Requests coming in on these ports should be forwarded to the conforming operations of the object as a whole. Later, in an iterative design approach, I may design the lower-level parts of this object, and formally connect the ports to an appropriate level internal part. This is how OO design works, that is your encapsulated object appears to have a set of behaviors, but they may be implemented by internal parts. If I can.t connect use ports until I make up the parts, this forces a low-level of design that.s usually premature. Michael Jesse Chonoles Principal Member of Engineer Staff -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Thursday, January 18, 2007 1:35 PM To: 'Ed Seidewitz'; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran smime1.p7s X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 20:09:02 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAOqL4AAAcbrg From: "Eran Gery" To: "Ed Seidewitz" Cc: Ed . The important thing to me is to enable the direct mapping to operations. I prefer your alternative proposal as I refer to the behavioral features part of the behavior, and it also resonated very well among our users. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:56 PM To: Eran Gery Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Eran -- If the port has connections to internal parts, then it is already clear that the request should be forwarded along those connections. If there are no such connections, then you need a flag to indicate whether the request should forwarded to the classifier behavior or should be handled directly by some behavioral feature of the owning classifier. The isBehavior attribute already exists as such a flag -- it is just that, in the absence of internal connectors, there is no semantics in the (default) case of the flag being false. I suggest is all we need to do is provide standard semantics for that default case. An alternative would be to make the presence or absence of a classifier behavior an implicit flag. That is, all ports without internal connectors forward their requests to the classifier behavior if there is one, or to corresponding behavioral features, if there is no classifier behavior. But I think having an explicit flag on each port is a more flexible approach. In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". -- Ed -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 1:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Reply-To: From: "Conrad Bock" To: "'Ed Seidewitz'" , "'Branislav Selic'" Cc: Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 15:14:48 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAATdqHA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Ed, et al, >From the Semantics of Port: The provided interfaces characterize the behavioral features that the owning classifier offers to its environment at this interaction point. The owning classifier must offer the features owned by the provided interfaces. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. This strongly implies the classifier owning the port will (in some cases at least) handle operation calls to the port (operations are a kind of feature). > [Ed] If the port is a behavior port, but there is no classifier behavior, > or it is not a behavior port, and there are no internal connections, > then a request directed to the port is simply lost. The spec says "terminate" not "lost": If there is a connector attached to only one side of a port, any requests arriving at this port will terminate at this port. At M0, the port can be an object supporting the interface: When an instance of a classifier is created, instances corresponding to each of its ports are created and held in the slots specified by the ports, in accordance with its multiplicity. The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. and handle the incoming messages. Conrad Reply-To: From: "Conrad Bock" To: "'Thomas Weigert'" , "'Alan Moore'" , "'Branislav Selic'" , "'GERARD Sebastien 166342'" Cc: Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 15:20:04 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc5Xxze/SfVc0QnRT2UFko1cKE/fQALShMwAABmuMAAADWggAABR7SwAAGz0yAAAHzDgAABoN1AAAH3qxAAZJpKkA== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Hi Thomas, > What sense would any port make on a passive object? Th. Holding up the structural applications as usual, connectors to ports on (passive or active) objects can be used to establish links between M0 objects that are values of the port properties . Conrad To: Juergen Boldt Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 15:56:15 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 15:56:16, Serialize complete at 01/18/2007 15:56:16 Yes. Issue. Sorry for the confusion, Juergen. Thanks, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Juergen Boldt 01/18/2007 10:30 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Behavioral port waaa...issue, or not? -Juergen At 09:53 AM 1/18/2007, you wrote: Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [ mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 16:04:06 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 16:04:11, Serialize complete at 01/18/2007 16:04:11 Sounds right. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/18/2007 01:04 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran To: "Chonoles, Michael J" Cc: Ed Seidewitz , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 16:09:00 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 16:09:04, Serialize complete at 01/18/2007 16:09:04 Michael, I must say that this is the first I heard of this assumption and I have been working with ports for about 20 years. So, what may be reasonable to some is not necessarily reasonable to all. I am not sure, therefore, that any of us can claim to know accurately the assumptions of the user community. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Chonoles, Michael J" 01/18/2007 01:35 PM To Ed Seidewitz , Branislav Selic/Ottawa/IBM@IBMCA cc uml2-rtf@omg.org Subject RE: Behavioral port Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Date: Thu, 18 Jan 2007 16:19:52 -0500 From: "Chonoles, Michael J" Subject: RE: Behavioral port To: Branislav Selic Cc: Ed Seidewitz , uml2-rtf@omg.org Thread-Topic: Behavioral port Thread-Index: Acc7RO9J3NHon048Tq6us8mNDOb0SQAADzPw X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jan 2007 21:19:54.0116 (UTC) FILETIME=[6591EC40:01C73B46] Of course, I was being presumptuous about the assumptions, let say that this approach agrees with assumptions from some part of the user community. Remember ,you have a previous experience with ports that were based on your needs/experience with Rose R/T and ObjecTime. For the majority of the IT (and SE) developers, when ports became available to them in UML, they used ports n what seemed natural ways, but ignored any of the types of details that probably came natural to you. Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:09 PM To: Chonoles, Michael J Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Michael, I must say that this is the first I heard of this assumption and I have been working with ports for about 20 years. So, what may be reasonable to some is not necessarily reasonable to all. I am not sure, therefore, that any of us can claim to know accurately the assumptions of the user community. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Chonoles, Michael J" 01/18/2007 01:35 PM To Ed Seidewitz , Branislav Selic/Ottawa/IBM@IBMCA cc uml2-rtf@omg.org Subject RE: Behavioral port Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran smime2.p7s Reply-To: From: "Conrad Bock" To: "'Branislav Selic'" , "'Chonoles, Michael J'" Cc: "'Ed Seidewitz'" , Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 16:20:14 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc7RUKhlUozlSNjQF6k4YjWVdT9GQAASqpg X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Bran, > I must say that this is the first I heard of this > assumption and I have been working with ports for about 20 > years. Talk with Jum A about his application, he's making an assumption like this. Also see the spec reference I sent earlier. Conrad From: "Thomas Weigert" To: "'Chonoles, Michael J'" , "'Branislav Selic'" Cc: "'Ed Seidewitz'" , Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 15:30:28 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc7RO9J3NHon048Tq6us8mNDOb0SQAADzPwAACjbcA= Well, I am sorry to say, but they used them in ways not supported by the specification. That does not necessarily mean we have to change the specification. Th. -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, January 18, 2007 3:20 PM To: Branislav Selic Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Of course, I was being presumptuous about the assumptions, let say that this approach agrees with assumptions from some part of the user community. Remember ,you have a previous experience with ports that were based on your needs/experience with Rose R/T and ObjecTime. For the majority of the IT (and SE) developers, when ports became available to them in UML, they used ports n what seemed natural ways, but ignored any of the types of details that probably came natural to you. To: Cc: "'Ed Seidewitz'" , "'Chonoles, Michael J'" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 16:36:37 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 16:36:42, Serialize complete at 01/18/2007 16:36:42 Sigh. I am not saying that the port concept cannot be generalized -- on the contrary. However, as one of the primary authors who put the concept of ports into UML (along with Thomas and several others), I am trying to explain what was intended when the concept was introduced into the spec. The relationship of this particular interpretation with other concepts was well understood, so we felt that it was safe to introduce it in this well-known form. Before we add further interpretations, we should understand why, how, and what it means. I am pretty sure we can come up with additional "obvious" interpretations. I also believe that we must understand how such an extension interacts with other features. I don't believe that it is merely a question of removing one word from the spec. With that, I think it is in everyone's interest to stop this highly annoying and ineffective means of discussing this topic (via e-mail) until an official issue has been raised. Ed is working on it, I believe, but others can also raise the issue in whatever form they deem appropriate. After that, let's look at a possible solutions and reach a consensus. Cheers...Bran "Conrad Bock" 01/18/2007 04:20 PM Please respond to To Branislav Selic/Ottawa/IBM@IBMCA, "'Chonoles, Michael J'" cc "'Ed Seidewitz'" , Subject RE: Behavioral port Bran, > I must say that this is the first I heard of this > assumption and I have been working with ports for about 20 > years. Talk with Jum A about his application, he's making an assumption like this. Also see the spec reference I sent earlier. Conrad Reply-To: From: "Conrad Bock" To: "'Branislav Selic'" Cc: "'Ed Seidewitz'" , "'Chonoles, Michael J'" , Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 16:40:44 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc7SM0301EJa4HtQh6w2sHdUcHYRQAAIAzg X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Bran, > I am not saying that the port concept cannot be generalized I didn't say you did. Did you get my earlier message with the spec references? > I am trying to explain what was intended when the concept was > introduced into the spec. Sure, which can be different from what the spec actually says. :) > With that, I think it is in everyone's interest to stop > this highly annoying and ineffective means of discussing > this topic (via e-mail) I actually like the email trail. Phone conversations have their own limitations. Conrad To: Cc: "'Ed Seidewitz'" , "'Chonoles, Michael J'" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 18 Jan 2007 16:55:01 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/18/2007 16:55:06, Serialize complete at 01/18/2007 16:55:06 > > I am trying to explain what was intended when the concept was > > introduced into the spec. > > Sure, which can be different from what the spec actually says. :) I guess this is true for all sacred texts. People read into them what they want. Bran Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Thu, 18 Jan 2007 19:06:28 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier thread-index: Acc7Xaq12fGpKPJKSSuvAONPTEtWng== From: "Ed Seidewitz" To: Cc: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 19:11:49 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAATdqHAACChlkA== From: "Ed Seidewitz" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l0J04QOm015623 Conrad -- > From the Semantics of Port: > > The provided interfaces characterize the behavioral > features that the > owning classifier offers to its environment at this interaction > point. The owning classifier must offer the features owned by the > provided interfaces. I have not found any constraint that actually enforces this. > > If the port was typed by an interface, the classifier typing the > interaction point object realizes that interface. > > This strongly implies the classifier owning the port will (in > some cases > at least) handle operation calls to the port (operations are a kind of > feature). Note that the classifier typing the interaction point object is _not_ the same as the owning classifier of the port. In any case, whatever is implied, it is clear that both Thomas and Bran did not intend this. > > > [Ed] If the port is a behavior port, but there is no classifier > behavior, > > or it is not a behavior port, and there are no internal > connections, > > then a request directed to the port is simply lost. > > The spec says "terminate" not "lost": > > If there is a connector attached to only one side of a port, any > requests arriving at this port will terminate at this port. At the end of the next paragraph it says, about behavior ports, "If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost." > > At M0, the port can be an object supporting the interface: > > When an instance of a classifier is created, instances corresponding > to each of its ports are created and held in the slots specified by > the ports, in accordance with its multiplicity. > > The interaction point object must be an instance of a > classifier that > realizes the provided interfaces of the port. > > and handle the incoming messages. But you don't want the interaction point object to handle the incoming message. The interaction point object is just supposed to route requests. The intent of ports is that their "provided interfaces characterize the behavioral features that the owning classifier offers to its environment." It is the instance of the owning classifier, not the interaction object, that needs to handle the incoming messages. -- Ed From: "Desfray" To: "'Ed Seidewitz'" , "'Eran Gery'" Cc: Subject: RE: Behavioral port Date: Fri, 19 Jan 2007 10:03:26 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAOqL4AAdx2Ug X-Virus-Scanned: by amavisd-new at softeam.com ED, >>> In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". There is also the case where the port is typed by a class which can do some specific processing to the received request. In that case, there might be no or few explicit connectors, the remaining aspects being up to the port class.s implementation. ========================================= Philippe -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : jeudi 18 janvier 2007 19:56 À : Eran Gery Cc : uml2-rtf@omg.org Objet : RE: Behavioral port Eran -- If the port has connections to internal parts, then it is already clear that the request should be forwarded along those connections. If there are no such connections, then you need a flag to indicate whether the request should forwarded to the classifier behavior or should be handled directly by some behavioral feature of the owning classifier. The isBehavior attribute already exists as such a flag -- it is just that, in the absence of internal connectors, there is no semantics in the (default) case of the flag being false. I suggest is all we need to do is provide standard semantics for that default case. An alternative would be to make the presence or absence of a classifier behavior an implicit flag. That is, all ports without internal connectors forward their requests to the classifier behavior if there is one, or to corresponding behavioral features, if there is no classifier behavior. But I think having an explicit flag on each port is a more flexible approach. In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". -- Ed -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 1:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Behavioral port Date: Fri, 19 Jan 2007 09:31:02 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port thread-index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAOqL4AAdx2UgAAtFhLA= From: "Ed Seidewitz" To: "Desfray" Cc: Philippe -- It may have been the intent that a port typed by a class can do some sort of explicit routing of requests, but it is not at all clear how to model this in any formal way. How does one notate getting access in the behavioral specification for the port to the instance of the owning classification? How does one specify how a certain request is then actually routed? In any case, the spec says that, for a non-behavior port, "If there is a connector attached to only one side of a port, any requests arriving at this port will terminate at this port." This is independent of whether the port is typed by an interface or a class. Since there is nor further explanation of what it means for a request to "terminate" at a port, I assume it means that the request is not forwarded further. For a behavior port, the spec says "If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost." Again, this is independent of whether the port is typed by a class or an interface. -- Ed -------------------------------------------------------------------------------- From: Desfray [mailto:philippe.desfray@softeam.fr] Sent: Friday, January 19, 2007 4:03 AM To: Ed Seidewitz; 'Eran Gery' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port ED, >>> In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". There is also the case where the port is typed by a class which can do some specific processing to the received request. In that case, there might be no or few explicit connectors, the remaining aspects being up to the port class.s implementation. ========================================= Philippe -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : jeudi 18 janvier 2007 19:56 À : Eran Gery Cc : uml2-rtf@omg.org Objet : RE: Behavioral port Eran -- If the port has connections to internal parts, then it is already clear that the request should be forwarded along those connections. If there are no such connections, then you need a flag to indicate whether the request should forwarded to the classifier behavior or should be handled directly by some behavioral feature of the owning classifier. The isBehavior attribute already exists as such a flag -- it is just that, in the absence of internal connectors, there is no semantics in the (default) case of the flag being false. I suggest is all we need to do is provide standard semantics for that default case. An alternative would be to make the presence or absence of a classifier behavior an implicit flag. That is, all ports without internal connectors forward their requests to the classifier behavior if there is one, or to corresponding behavioral features, if there is no classifier behavior. But I think having an explicit flag on each port is a more flexible approach. In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". -- Ed -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 1:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Behavioral port Date: Mon, 22 Jan 2007 09:45:24 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAEBngAAAOqL4AAdx2UgAAtFhLAAjKpP4A== From: "Alan Moore" To: "Ed Seidewitz" , "Desfray" Cc: X-OriginalArrivalTime: 22 Jan 2007 09:45:28.0934 (UTC) FILETIME=[0CD6B060:01C73E0A] Hi Ed, I agree, so there seems to be an issue with the following text from the semantics of Port: .If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.. I always assumed that the fact that the communications could be .filtered. was the get-out clause that allowed the port.s Class to do whatever it wanted. However you have noted below a number of specific requirements on this Class under certain situations. Does this mean that the modeller designing the Class needs to ensure that it meets these requirements . how can we tell that it doesn.t and even then what is the consequence? It.s all a bit vague. Still worse in my opinion is the obligation on the designer of such a Class for a Behaviour Port to forward Requests to the classifierBehaviour of its parent. It.s easy enough to get hold of the parent object, but try as I might I can.t see any Action that returns the identity of the current execution of the classifierBehaviour for an object. How is the designer then to get hold of it in order to send it requests? Anyway, in summary, I do think there is an issue out there on this concept of typing a Port by a Class. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 2:31 PM To: Desfray Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Philippe -- It may have been the intent that a port typed by a class can do some sort of explicit routing of requests, but it is not at all clear how to model this in any formal way. How does one notate getting access in the behavioral specification for the port to the instance of the owning classification? How does one specify how a certain request is then actually routed? In any case, the spec says that, for a non-behavior port, "If there is a connector attached to only one side of a port, any requests arriving at this port will terminate at this port." This is independent of whether the port is typed by an interface or a class. Since there is nor further explanation of what it means for a request to "terminate" at a port, I assume it means that the request is not forwarded further. For a behavior port, the spec says "If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost." Again, this is independent of whether the port is typed by a class or an interface. -- Ed -------------------------------------------------------------------------------- From: Desfray [mailto:philippe.desfray@softeam.fr] Sent: Friday, January 19, 2007 4:03 AM To: Ed Seidewitz; 'Eran Gery' Cc: uml2-rtf@omg.org Subject: RE: Behavioral port ED, >>> In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". There is also the case where the port is typed by a class which can do some specific processing to the received request. In that case, there might be no or few explicit connectors, the remaining aspects being up to the port class.s implementation. ========================================= Philippe -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Envoyé : jeudi 18 janvier 2007 19:56 À : Eran Gery Cc : uml2-rtf@omg.org Objet : RE: Behavioral port Eran -- If the port has connections to internal parts, then it is already clear that the request should be forwarded along those connections. If there are no such connections, then you need a flag to indicate whether the request should forwarded to the classifier behavior or should be handled directly by some behavioral feature of the owning classifier. The isBehavior attribute already exists as such a flag -- it is just that, in the absence of internal connectors, there is no semantics in the (default) case of the flag being false. I suggest is all we need to do is provide standard semantics for that default case. An alternative would be to make the presence or absence of a classifier behavior an implicit flag. That is, all ports without internal connectors forward their requests to the classifier behavior if there is one, or to corresponding behavioral features, if there is no classifier behavior. But I think having an explicit flag on each port is a more flexible approach. In any case, I don't think there that a request through a port should ever be "just dropped", as it is allowed to be now. Of course, there will always be cases of incomplete models (e.g., you haven't done the model of the internal structure yet), but, in these cases, the execution semantics is just not defined (like in the case of a non-abstract operation for which no method has yet been provided). That is very different than a semantics that explicitly allows for a communication to be "lost". -- Ed -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, January 18, 2007 1:32 PM To: Ed Seidewitz; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed . what I suggest is very similar, but in (3) I would still require that the port is .behavior. to invoke an operation, as I refer to .behavior. in a more general sense which also includes the behavioral features. Note that this is the semantics we have for requests addressed to instances not via a port. We do not require any .intermediary. in that case, and the fact the request came via a port shall not change that. Eran -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 8:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran To: "Alan Moore" Cc: "Ed Seidewitz" , "Desfray" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Mon, 22 Jan 2007 05:54:44 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/22/2007 05:54:46, Serialize complete at 01/22/2007 05:54:46 "Alan Moore" wrote on 01/22/2007 04:45:24 AM: > I always assumed that the fact that the communications could be > .filtered. was the get-out clause that allowed the port.s Class to > do whatever it wanted. That was indeed the intent and you can make the port do what you will. However, any such special semantics would require a profile. > However you have noted below a number of > specific requirements on this Class under certain situations. Does > this mean that the modeller designing the Class needs to ensure that > it meets these requirements . how can we tell that it doesn.t and > even then what is the consequence? It.s all a bit vague. It was intended as a semantic variation point and it should have been explicitly marked as such. > Still worse in my opinion is the obligation on the designer of such > a Class for a Behaviour Port to forward Requests to the > classifierBehaviour of its parent. It.s easy enough to get hold of > the parent object, but try as I might I can.t see any Action that > returns the identity of the current execution of the > classifierBehaviour for an object. How is the designer then to get > hold of it in order to send it requests? As noted above, the details of such a forwarding mechanism are the stuff of profiles (e.g., it could be a special local variable that is automatically assigned by the run-time environment) > Anyway, in summary, I do think there is an issue out there on this > concept of typing a Port by a Class. The only issue, I think is to clarify that this is a semantic variation point as I described it above. Cheers...Bran Subject: RE: Behavioral port Date: Mon, 22 Jan 2007 12:32:22 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc+E6/ZCYwz1rGDTkqlhk47HYJS0gADJsFw From: "Alan Moore" To: "Branislav Selic" Cc: "Ed Seidewitz" , "Desfray" , Thanks Bran, I guess a Behaviour is a class and therefore can have instances that are objects and can therefore be the Targets of CallOperationActions etc. One puzzle I do have though is the effect of an Operation Call whose target is a Behaviour . does it need to offer the Operation being called in its interface? Also, are the semantics of directly performing a CallOperationAction on a classifierBehaviour just the same as performing a CallOperationAction on its context. If not, how does it differ? Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 10:55 AM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port "Alan Moore" wrote on 01/22/2007 04:45:24 AM: > I always assumed that the fact that the communications could be > .filtered. was the get-out clause that allowed the port.s Class to > do whatever it wanted. That was indeed the intent and you can make the port do what you will. However, any such special semantics would require a profile. > However you have noted below a number of > specific requirements on this Class under certain situations. Does > this mean that the modeller designing the Class needs to ensure that > it meets these requirements . how can we tell that it doesn.t and > even then what is the consequence? It.s all a bit vague. It was intended as a semantic variation point and it should have been explicitly marked as such. > Still worse in my opinion is the obligation on the designer of such > a Class for a Behaviour Port to forward Requests to the > classifierBehaviour of its parent. It.s easy enough to get hold of > the parent object, but try as I might I can.t see any Action that > returns the identity of the current execution of the > classifierBehaviour for an object. How is the designer then to get > hold of it in order to send it requests? As noted above, the details of such a forwarding mechanism are the stuff of profiles (e.g., it could be a special local variable that is automatically assigned by the run-time environment) > Anyway, in summary, I do think there is an issue out there on this > concept of typing a Port by a Class. The only issue, I think is to clarify that this is a semantic variation point as I described it above. Cheers...Bran Subject: RE: Behavioral port Date: Mon, 22 Jan 2007 12:49:19 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc+E6/ZCYwz1rGDTkqlhk47HYJS0gADvzoA From: "Alan Moore" To: "Branislav Selic" Cc: "Ed Seidewitz" , "Desfray" , Hi Ban, Actually having thought about it a bit I don.t understand . what is the semantic variation point . surely the Class that implements the Port is just a normal Class and uses standard UML semantics. Are you saying that it is impossible to build a model that contains a port typed by a Class without some further profile that does something (I don.t know what) to the Composite Structure part of UML . that sounds like a constraint, rather than a semantic variation point. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 10:55 AM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port "Alan Moore" wrote on 01/22/2007 04:45:24 AM: > I always assumed that the fact that the communications could be > .filtered. was the get-out clause that allowed the port.s Class to > do whatever it wanted. That was indeed the intent and you can make the port do what you will. However, any such special semantics would require a profile. > However you have noted below a number of > specific requirements on this Class under certain situations. Does > this mean that the modeller designing the Class needs to ensure that > it meets these requirements . how can we tell that it doesn.t and > even then what is the consequence? It.s all a bit vague. It was intended as a semantic variation point and it should have been explicitly marked as such. > Still worse in my opinion is the obligation on the designer of such > a Class for a Behaviour Port to forward Requests to the > classifierBehaviour of its parent. It.s easy enough to get hold of > the parent object, but try as I might I can.t see any Action that > returns the identity of the current execution of the > classifierBehaviour for an object. How is the designer then to get > hold of it in order to send it requests? As noted above, the details of such a forwarding mechanism are the stuff of profiles (e.g., it could be a special local variable that is automatically assigned by the run-time environment) > Anyway, in summary, I do think there is an issue out there on this > concept of typing a Port by a Class. The only issue, I think is to clarify that this is a semantic variation point as I described it above. Cheers...Bran From: "Thomas Weigert" To: "'Alan Moore'" , "'Branislav Selic'" Cc: "'Ed Seidewitz'" , "'Desfray'" , Subject: RE: Behavioral port Date: Mon, 22 Jan 2007 06:55:12 -0600 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc+E6/ZCYwz1rGDTkqlhk47HYJS0gADJsFwAADurNA= I think it is rather unclear what happens when Behaviors are addressed directly (in virtue of being a class). I think it was a mistake that Behaviors were made to be classes (the original intent was to support procedural programming and somehow the author of this "feature" feared that one could not do procedural programs when one required objects to have behavior. Clearly that fear was overblown, but we are now stuck with this abomination. I have yet to see any models that model procedural programs in this way (we do have many non-OO programs captured in SDL and UML and they all work just fine with active objects eventually ending up as functions rather than objects and are conceptually just as clear). Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 6:32 AM To: Branislav Selic Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port I guess a Behaviour is a class and therefore can have instances that are objects and can therefore be the Targets of CallOperationActions etc. One puzzle I do have though is the effect of an Operation Call whose target is a Behaviour . does it need to offer the Operation being called in its interface? Also, are the semantics of directly performing a CallOperationAction on a classifierBehaviour just the same as performing a CallOperationAction on its context. If not, how does it differ? Alan. Subject: RE: Behavioral port Date: Mon, 22 Jan 2007 13:01:04 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc+E6/ZCYwz1rGDTkqlhk47HYJS0gADJsFwAADurNAAAEEfwA== From: "Alan Moore" To: "Thomas Weigert" , "Branislav Selic" Cc: "Ed Seidewitz" , "Desfray" , . and yet we have the conundrum that a Class that types a behaviour Port must somewhere in its behaviour (or behaviours) do just that (directly address a Behavior) in order to conform to the semantics of UML. Alan. -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Monday, January 22, 2007 12:55 PM To: Alan Moore; 'Branislav Selic' Cc: 'Ed Seidewitz'; 'Desfray'; uml2-rtf@omg.org Subject: RE: Behavioral port I think it is rather unclear what happens when Behaviors are addressed directly (in virtue of being a class). I think it was a mistake that Behaviors were made to be classes (the original intent was to support procedural programming and somehow the author of this "feature" feared that one could not do procedural programs when one required objects to have behavior. Clearly that fear was overblown, but we are now stuck with this abomination. I have yet to see any models that model procedural programs in this way (we do have many non-OO programs captured in SDL and UML and they all work just fine with active objects eventually ending up as functions rather than objects and are conceptually just as clear). Th. -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 6:32 AM To: Branislav Selic Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port I guess a Behaviour is a class and therefore can have instances that are objects and can therefore be the Targets of CallOperationActions etc. One puzzle I do have though is the effect of an Operation Call whose target is a Behaviour . does it need to offer the Operation being called in its interface? Also, are the semantics of directly performing a CallOperationAction on a classifierBehaviour just the same as performing a CallOperationAction on its context. If not, how does it differ? Alan. Subject: RE: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Mon, 22 Jan 2007 16:19:23 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Thread-Index: Acc7Xaq12fGpKPJKSSuvAONPTEtWngC4IxcA From: "Alan Moore" To: "Ed Seidewitz" , Cc: Hi Ed, I don.t see why you want to keep the semantics expressed in your resolution point 2. Why can.t we leave it up to the modeller of the port.s parent to decide how to model its internal behaviour. For a given request, if the classifierBehavior exists and can handle the request associated to a given behavioural feature then it does, if the method of the behavioural feature exists and can handle the Request then it does. If neither then it doesn.t get handled. This is the standard semantics for how an object handles a request isn.t it? Why make it any different just because the request comes from a behaviour port? Looking back through various threads the only reason I can see for insisting on the presence of a classifierBehavior is by Thomas: .The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port.. Why does there need to be a thread of execution to respond to events . or even more to the point, why should one be needed in your point 2 below, but not in your point 3 below. The point I.m trying to make and obviously haven.t thus far is that if the requirement that a .request directed to the (behaviour) port via a provided interface is forwarded to the classifier behavior for the owning classifier. was removed it would make no difference to the ability of the modeller to deal with requests coming from a behaviour port. The only significant part of the semantics for behaviour port is that it forwards requests to its parent without the presence of a connector. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 12:06 AM To: issues@omg.org Cc: uml2-rtf@omg.org Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Mon, 22 Jan 2007 11:29:41 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier thread-index: Acc7Xaq12fGpKPJKSSuvAONPTEtWngC4IxcAAADq+VA= From: "Ed Seidewitz" To: "Alan Moore" , Cc: Alan -- OK, now I get your point! Perhaps it is as simple as this: If a port has a connection to an internal part, then requests arriving at that port are forwarded to the internal part. If the port does not have such a connection, then the request is forwarded to the behavioral feature of the instance of the owning classifier, the behavior of which is given either by a method (if there is one) or by the classifier behavior (if there is one) by the usual semantics. Then there would be no need for the distinction between behavior ports and non-behavior ports and, rather than adding an additional case, everything would actually be simpler. Is this what you had in mind? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 11:19 AM To: Ed Seidewitz; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Hi Ed, I don.t see why you want to keep the semantics expressed in your resolution point 2. Why can.t we leave it up to the modeller of the port.s parent to decide how to model its internal behaviour. For a given request, if the classifierBehavior exists and can handle the request associated to a given behavioural feature then it does, if the method of the behavioural feature exists and can handle the Request then it does. If neither then it doesn.t get handled. This is the standard semantics for how an object handles a request isn.t it? Why make it any different just because the request comes from a behaviour port? Looking back through various threads the only reason I can see for insisting on the presence of a classifierBehavior is by Thomas: .The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port.. Why does there need to be a thread of execution to respond to events . or even more to the point, why should one be needed in your point 2 below, but not in your point 3 below. The point I.m trying to make and obviously haven.t thus far is that if the requirement that a .request directed to the (behaviour) port via a provided interface is forwarded to the classifier behavior for the owning classifier. was removed it would make no difference to the ability of the modeller to deal with requests coming from a behaviour port. The only significant part of the semantics for behaviour port is that it forwards requests to its parent without the presence of a connector. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 12:06 AM To: issues@omg.org Cc: uml2-rtf@omg.org Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. To: "Alan Moore" Cc: "Ed Seidewitz" , "Desfray" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Mon, 22 Jan 2007 11:41:58 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/22/2007 11:42:27, Serialize complete at 01/22/2007 11:42:27 The semantics of the class that implements the port IS the semantic variation point. The default is that it simply relays what it receives onwards (e.g., to a connected link or to a classifier behavior). However, it may be required in some systems to give it additional semantics such as the ability of the port object to filter out some messages, modify others, queue them up, etc. I don't see any constraints in this, just the possibility of additional refinements. Cheers...Bran "Alan Moore" 01/22/2007 07:49 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , "Desfray" , Subject RE: Behavioral port Hi Ban, Actually having thought about it a bit I don.t understand . what is the semantic variation point . surely the Class that implements the Port is just a normal Class and uses standard UML semantics. Are you saying that it is impossible to build a model that contains a port typed by a Class without some further profile that does something (I don.t know what) to the Composite Structure part of UML . that sounds like a constraint, rather than a semantic variation point. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 10:55 AM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port "Alan Moore" wrote on 01/22/2007 04:45:24 AM: > I always assumed that the fact that the communications could be > .filtered. was the get-out clause that allowed the port.s Class to > do whatever it wanted. That was indeed the intent and you can make the port do what you will. However, any such special semantics would require a profile. > However you have noted below a number of > specific requirements on this Class under certain situations. Does > this mean that the modeller designing the Class needs to ensure that > it meets these requirements . how can we tell that it doesn.t and > even then what is the consequence? It.s all a bit vague. It was intended as a semantic variation point and it should have been explicitly marked as such. > Still worse in my opinion is the obligation on the designer of such > a Class for a Behaviour Port to forward Requests to the > classifierBehaviour of its parent. It.s easy enough to get hold of > the parent object, but try as I might I can.t see any Action that > returns the identity of the current execution of the > classifierBehaviour for an object. How is the designer then to get > hold of it in order to send it requests? As noted above, the details of such a forwarding mechanism are the stuff of profiles (e.g., it could be a special local variable that is automatically assigned by the run-time environment) > Anyway, in summary, I do think there is an issue out there on this > concept of typing a Port by a Class. The only issue, I think is to clarify that this is a semantic variation point as I described it above. Cheers...Bran Subject: RE: Behavioral port Date: Mon, 22 Jan 2007 16:45:32 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc+REGFDve38TktSgueKkfVzc/PlAAAB9tw From: "Alan Moore" To: "Branislav Selic" Cc: "Ed Seidewitz" , "Desfray" , OK, well all I.m saying is that I don.t. see how one can describe the way a Class should be modelled as a semantic variation point . maybe we can but it seems a bit odd to me. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 4:42 PM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port The semantics of the class that implements the port IS the semantic variation point. The default is that it simply relays what it receives onwards (e.g., to a connected link or to a classifier behavior). However, it may be required in some systems to give it additional semantics such as the ability of the port object to filter out some messages, modify others, queue them up, etc. I don't see any constraints in this, just the possibility of additional refinements. Cheers...Bran "Alan Moore" 01/22/2007 07:49 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , "Desfray" , Subject RE: Behavioral port Hi Ban, Actually having thought about it a bit I don.t understand . what is the semantic variation point . surely the Class that implements the Port is just a normal Class and uses standard UML semantics. Are you saying that it is impossible to build a model that contains a port typed by a Class without some further profile that does something (I don.t know what) to the Composite Structure part of UML . that sounds like a constraint, rather than a semantic variation point. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 10:55 AM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port "Alan Moore" wrote on 01/22/2007 04:45:24 AM: > I always assumed that the fact that the communications could be > .filtered. was the get-out clause that allowed the port.s Class to > do whatever it wanted. That was indeed the intent and you can make the port do what you will. However, any such special semantics would require a profile. > However you have noted below a number of > specific requirements on this Class under certain situations. Does > this mean that the modeller designing the Class needs to ensure that > it meets these requirements . how can we tell that it doesn.t and > even then what is the consequence? It.s all a bit vague. It was intended as a semantic variation point and it should have been explicitly marked as such. > Still worse in my opinion is the obligation on the designer of such > a Class for a Behaviour Port to forward Requests to the > classifierBehaviour of its parent. It.s easy enough to get hold of > the parent object, but try as I might I can.t see any Action that > returns the identity of the current execution of the > classifierBehaviour for an object. How is the designer then to get > hold of it in order to send it requests? As noted above, the details of such a forwarding mechanism are the stuff of profiles (e.g., it could be a special local variable that is automatically assigned by the run-time environment) > Anyway, in summary, I do think there is an issue out there on this > concept of typing a Port by a Class. The only issue, I think is to clarify that this is a semantic variation point as I described it above. Cheers...Bran Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Mon, 22 Jan 2007 16:46:02 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Thread-Index: Acc7Xaq12fGpKPJKSSuvAONPTEtWngC4IxcAAADq+VAAALaWQA== From: "Alan Moore" To: "Ed Seidewitz" , Cc: Yes, exactly. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Monday, January 22, 2007 4:30 PM To: Alan Moore; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Alan -- OK, now I get your point! Perhaps it is as simple as this: If a port has a connection to an internal part, then requests arriving at that port are forwarded to the internal part. If the port does not have such a connection, then the request is forwarded to the behavioral feature of the instance of the owning classifier, the behavior of which is given either by a method (if there is one) or by the classifier behavior (if there is one) by the usual semantics. Then there would be no need for the distinction between behavior ports and non-behavior ports and, rather than adding an additional case, everything would actually be simpler. Is this what you had in mind? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 11:19 AM To: Ed Seidewitz; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Hi Ed, I don.t see why you want to keep the semantics expressed in your resolution point 2. Why can.t we leave it up to the modeller of the port.s parent to decide how to model its internal behaviour. For a given request, if the classifierBehavior exists and can handle the request associated to a given behavioural feature then it does, if the method of the behavioural feature exists and can handle the Request then it does. If neither then it doesn.t get handled. This is the standard semantics for how an object handles a request isn.t it? Why make it any different just because the request comes from a behaviour port? Looking back through various threads the only reason I can see for insisting on the presence of a classifierBehavior is by Thomas: .The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port.. Why does there need to be a thread of execution to respond to events . or even more to the point, why should one be needed in your point 2 below, but not in your point 3 below. The point I.m trying to make and obviously haven.t thus far is that if the requirement that a .request directed to the (behaviour) port via a provided interface is forwarded to the classifier behavior for the owning classifier. was removed it would make no difference to the ability of the modeller to deal with requests coming from a behaviour port. The only significant part of the semantics for behaviour port is that it forwards requests to its parent without the presence of a connector. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 12:06 AM To: issues@omg.org Cc: uml2-rtf@omg.org Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. To: "Ed Seidewitz" Cc: "Alan Moore" , issues@omg.org, uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Mon, 22 Jan 2007 11:50:51 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/22/2007 11:50:53, Serialize complete at 01/22/2007 11:50:53 The problem with that "default-based" solution is the case where the port is intentionally left unconnected in an abstract class to be connected to a specific part in a subclass (a very common usage pattern in practice). If the default rule is used, then the subclass would have completely different behavior from its superclass. This is why it is necessary to be specific about which ports are behavior ports; i.e., ports that terminate a chain of links. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/22/2007 11:29 AM To "Alan Moore" , cc Subject RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Alan -- OK, now I get your point! Perhaps it is as simple as this: If a port has a connection to an internal part, then requests arriving at that port are forwarded to the internal part. If the port does not have such a connection, then the request is forwarded to the behavioral feature of the instance of the owning classifier, the behavior of which is given either by a method (if there is one) or by the classifier behavior (if there is one) by the usual semantics. Then there would be no need for the distinction between behavior ports and non-behavior ports and, rather than adding an additional case, everything would actually be simpler. Is this what you had in mind? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 11:19 AM To: Ed Seidewitz; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Hi Ed, I don.t see why you want to keep the semantics expressed in your resolution point 2. Why can.t we leave it up to the modeller of the port.s parent to decide how to model its internal behaviour. For a given request, if the classifierBehavior exists and can handle the request associated to a given behavioural feature then it does, if the method of the behavioural feature exists and can handle the Request then it does. If neither then it doesn.t get handled. This is the standard semantics for how an object handles a request isn.t it? Why make it any different just because the request comes from a behaviour port? Looking back through various threads the only reason I can see for insisting on the presence of a classifierBehavior is by Thomas: .The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port.. Why does there need to be a thread of execution to respond to events . or even more to the point, why should one be needed in your point 2 below, but not in your point 3 below. The point I.m trying to make and obviously haven.t thus far is that if the requirement that a .request directed to the (behaviour) port via a provided interface is forwarded to the classifier behavior for the owning classifier. was removed it would make no difference to the ability of the modeller to deal with requests coming from a behaviour port. The only significant part of the semantics for behaviour port is that it forwards requests to its parent without the presence of a connector. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 12:06 AM To: issues@omg.org Cc: uml2-rtf@omg.org Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Mon, 22 Jan 2007 11:58:36 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier thread-index: Acc+Ra0EYt1hZeuLTEWmTemoNKh0LgAAEAHA From: "Ed Seidewitz" To: "Branislav Selic" Cc: , Bran -- OK, I see your point, too. But your characterization of behavior port seems to be the right generalization: a behavior port is one that terminates a "chain of links" by not having any connector to internal structure. In this case, rather than requiring that the request be forwarded to a classifier behavior, it just needs to be forwarded to the appropriate behavioral feature of the instance of the owning classifier, which may handle it via a method or via a classifier behavior. I now see that this is what Alan was getting at by saying that all that was necessary was to remove "classifier behavior" from the specification for the semantics of behavior ports (though I still think, in addition to removing these words, more clarification would need to be added to the spec). I also believe that this was the point that Eran was making. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 11:51 AM To: Ed Seidewitz Cc: Alan Moore; issues@omg.org; uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier The problem with that "default-based" solution is the case where the port is intentionally left unconnected in an abstract class to be connected to a specific part in a subclass (a very common usage pattern in practice). If the default rule is used, then the subclass would have completely different behavior from its superclass. This is why it is necessary to be specific about which ports are behavior ports; i.e., ports that terminate a chain of links. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/22/2007 11:29 AM To "Alan Moore" , cc Subject RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Alan -- OK, now I get your point! Perhaps it is as simple as this: If a port has a connection to an internal part, then requests arriving at that port are forwarded to the internal part. If the port does not have such a connection, then the request is forwarded to the behavioral feature of the instance of the owning classifier, the behavior of which is given either by a method (if there is one) or by the classifier behavior (if there is one) by the usual semantics. Then there would be no need for the distinction between behavior ports and non-behavior ports and, rather than adding an additional case, everything would actually be simpler. Is this what you had in mind? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 11:19 AM To: Ed Seidewitz; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Hi Ed, I don.t see why you want to keep the semantics expressed in your resolution point 2. Why can.t we leave it up to the modeller of the port.s parent to decide how to model its internal behaviour. For a given request, if the classifierBehavior exists and can handle the request associated to a given behavioural feature then it does, if the method of the behavioural feature exists and can handle the Request then it does. If neither then it doesn.t get handled. This is the standard semantics for how an object handles a request isn.t it? Why make it any different just because the request comes from a behaviour port? Looking back through various threads the only reason I can see for insisting on the presence of a classifierBehavior is by Thomas: .The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port.. Why does there need to be a thread of execution to respond to events . or even more to the point, why should one be needed in your point 2 below, but not in your point 3 below. The point I.m trying to make and obviously haven.t thus far is that if the requirement that a .request directed to the (behaviour) port via a provided interface is forwarded to the classifier behavior for the owning classifier. was removed it would make no difference to the ability of the modeller to deal with requests coming from a behaviour port. The only significant part of the semantics for behaviour port is that it forwards requests to its parent without the presence of a connector. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 12:06 AM To: issues@omg.org Cc: uml2-rtf@omg.org Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Date: Mon, 22 Jan 2007 17:14:22 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Thread-Index: Acc+Ra0EYt1hZeuLTEWmTemoNKh0LgAAEAHAAACpGEA= From: "Alan Moore" To: "Ed Seidewitz" , "Branislav Selic" Cc: , Thanks Ed, That is the point I was making, although I acknowledge the validity of Bran.s last point also. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Monday, January 22, 2007 4:59 PM To: Branislav Selic Cc: issues@omg.org; uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Bran -- OK, I see your point, too. But your characterization of behavior port seems to be the right generalization: a behavior port is one that terminates a "chain of links" by not having any connector to internal structure. In this case, rather than requiring that the request be forwarded to a classifier behavior, it just needs to be forwarded to the appropriate behavioral feature of the instance of the owning classifier, which may handle it via a method or via a classifier behavior. I now see that this is what Alan was getting at by saying that all that was necessary was to remove "classifier behavior" from the specification for the semantics of behavior ports (though I still think, in addition to removing these words, more clarification would need to be added to the spec). I also believe that this was the point that Eran was making. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 11:51 AM To: Ed Seidewitz Cc: Alan Moore; issues@omg.org; uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier The problem with that "default-based" solution is the case where the port is intentionally left unconnected in an abstract class to be connected to a specific part in a subclass (a very common usage pattern in practice). If the default rule is used, then the subclass would have completely different behavior from its superclass. This is why it is necessary to be specific about which ports are behavior ports; i.e., ports that terminate a chain of links. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 01/22/2007 11:29 AM To "Alan Moore" , cc Subject RE: UML 2.1 Superstructure Issue [10597]: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Alan -- OK, now I get your point! Perhaps it is as simple as this: If a port has a connection to an internal part, then requests arriving at that port are forwarded to the internal part. If the port does not have such a connection, then the request is forwarded to the behavioral feature of the instance of the owning classifier, the behavior of which is given either by a method (if there is one) or by the classifier behavior (if there is one) by the usual semantics. Then there would be no need for the distinction between behavior ports and non-behavior ports and, rather than adding an additional case, everything would actually be simpler. Is this what you had in mind? -- Ed -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, January 22, 2007 11:19 AM To: Ed Seidewitz; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Hi Ed, I don.t see why you want to keep the semantics expressed in your resolution point 2. Why can.t we leave it up to the modeller of the port.s parent to decide how to model its internal behaviour. For a given request, if the classifierBehavior exists and can handle the request associated to a given behavioural feature then it does, if the method of the behavioural feature exists and can handle the Request then it does. If neither then it doesn.t get handled. This is the standard semantics for how an object handles a request isn.t it? Why make it any different just because the request comes from a behaviour port? Looking back through various threads the only reason I can see for insisting on the presence of a classifierBehavior is by Thomas: .The classifier behavior is different. Once it is started up it has a thread of execution and can respond to events coming in. Thus it is the only behavior it makes sense to forward to from a behavior port.. Why does there need to be a thread of execution to respond to events . or even more to the point, why should one be needed in your point 2 below, but not in your point 3 below. The point I.m trying to make and obviously haven.t thus far is that if the requirement that a .request directed to the (behaviour) port via a provided interface is forwarded to the classifier behavior for the owning classifier. was removed it would make no difference to the ability of the modeller to deal with requests coming from a behaviour port. The only significant part of the semantics for behaviour port is that it forwards requests to its parent without the presence of a connector. Alan. -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, January 19, 2007 12:06 AM To: issues@omg.org Cc: uml2-rtf@omg.org Subject: UML 2.1 Superstructure Issue: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. To: "Alan Moore" Cc: "Ed Seidewitz" , "Desfray" , uml2-rtf@omg.org Subject: RE: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Mon, 22 Jan 2007 14:57:26 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 01/22/2007 14:57:28, Serialize complete at 01/22/2007 14:57:28 Keep in mind that a port object is an instance of a special class that already has imposed semantics (i.e., its relaying function). So, you cannot be completely free as to what it does. I would never expect users to actually implement this class, no more than I would expect them to define the behavior of links, whose semantics are defined by the UML standard (excepting those defined by association classes). I see no difference between these two cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Alan Moore" 01/22/2007 11:45 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , "Desfray" , Subject RE: Behavioral port OK, well all I.m saying is that I don.t. see how one can describe the way a Class should be modelled as a semantic variation point . maybe we can but it seems a bit odd to me. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 4:42 PM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port The semantics of the class that implements the port IS the semantic variation point. The default is that it simply relays what it receives onwards (e.g., to a connected link or to a classifier behavior). However, it may be required in some systems to give it additional semantics such as the ability of the port object to filter out some messages, modify others, queue them up, etc. I don't see any constraints in this, just the possibility of additional refinements. Cheers...Bran "Alan Moore" 01/22/2007 07:49 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , "Desfray" , Subject RE: Behavioral port Hi Ban, Actually having thought about it a bit I don.t understand . what is the semantic variation point . surely the Class that implements the Port is just a normal Class and uses standard UML semantics. Are you saying that it is impossible to build a model that contains a port typed by a Class without some further profile that does something (I don.t know what) to the Composite Structure part of UML . that sounds like a constraint, rather than a semantic variation point. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 22, 2007 10:55 AM To: Alan Moore Cc: Ed Seidewitz; Desfray; uml2-rtf@omg.org Subject: RE: Behavioral port "Alan Moore" wrote on 01/22/2007 04:45:24 AM: > I always assumed that the fact that the communications could be > .filtered. was the get-out clause that allowed the port.s Class to > do whatever it wanted. That was indeed the intent and you can make the port do what you will. However, any such special semantics would require a profile. > However you have noted below a number of > specific requirements on this Class under certain situations. Does > this mean that the modeller designing the Class needs to ensure that > it meets these requirements . how can we tell that it doesn.t and > even then what is the consequence? It.s all a bit vague. It was intended as a semantic variation point and it should have been explicitly marked as such. > Still worse in my opinion is the obligation on the designer of such > a Class for a Behaviour Port to forward Requests to the > classifierBehaviour of its parent. It.s easy enough to get hold of > the parent object, but try as I might I can.t see any Action that > returns the identity of the current execution of the > classifierBehaviour for an object. How is the designer then to get > hold of it in order to send it requests? As noted above, the details of such a forwarding mechanism are the stuff of profiles (e.g., it could be a special local variable that is automatically assigned by the run-time environment) > Anyway, in summary, I do think there is an issue out there on this > concept of typing a Port by a Class. The only issue, I think is to clarify that this is a semantic variation point as I described it above. Cheers...Bran Subject: Issue 10597: Behavioral port Date: Wed, 28 Mar 2007 17:40:27 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-index: AcdxTo+lHPc2q4T2SguEbELahwDCGw== From: "Tim Weilkiens" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2SGYhsN007858 Hi, issue 10597 isn't an easy one. There was a long discussion between Ed, Alan, and Bran some weeks ago. The issue summary below was the conclusion of that discussion (if I remind correctly). Unfortunately I've lost the email thread due a server crash. I have some remarks on the suggested resolution: > 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. The constraint is only necessary for ports that have no connectors to internal parts. >3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the > corresponding behavioral feature of the owning classifier (if there is such a method). There seems to be something wrong with the sentence ("with connectors no connectors"). Ed, what do you mean? >4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports >when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Do you mean we should include a semantic variation point? Tim -------------- Issue 10597: Behavioral port Summary: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. ----------------------------------------------------------------- Tim Weilkiens Consultant, Instructor OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de To: "Tim Weilkiens" Cc: uml2-rtf@omg.org Subject: Re: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 28 Mar 2007 16:33:53 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 03/28/2007 16:33:55, Serialize complete at 03/28/2007 16:33:55 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Comments below identified by [bvs] Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Tim Weilkiens" 03/28/2007 11:40 AM To cc Subject Issue 10597: Behavioral port Hi, issue 10597 isn't an easy one. There was a long discussion between Ed, Alan, and Bran some weeks ago. The issue summary below was the conclusion of that discussion (if I remind correctly). Unfortunately I've lost the email thread due a server crash. I have some remarks on the suggested resolution: > 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. The constraint is only necessary for ports that have no connectors to internal parts. [bvs] As stated, this would force even an abstract class to realize these interfaces (I am assuming that realization implies having an implementation method for operations defined on an interface). Clearly, there will be situations where this is inappropriate -- the abstract class may want to defer the realization to a subclass. Also, it may want to delegate the realization to a part. >3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the > corresponding behavioral feature of the owning classifier (if there is such a method). [bvs] First of all, I don't think that there are any special semantics to behavior ports that are different from any other port. ALL ports act as relays, whether they are behavior or not. The only difference is who the request is being relayed to: a classifier behavior or something that sits at the opposite end of the connector attached to the port. Second, it seems like there is an issue here of identifying which method corresponds to which port. Since multiple ports can support the same interface, it is quite reasonable to have a situation where the same method is handled differently based on which port the request arrives. [bvs] Perhaps we need another kind of port for the capability suggested here? After all, I don't believe that we want this kind of behavior in all cases of non-behavior ports. There seems to be something wrong with the sentence ("with connectors no connectors"). Ed, what do you mean? >4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports >when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Do you mean we should include a semantic variation point? [bvs] Some of this requires changing the current semantics of ports -- as implemented in numerous tools. Therefore, it seems preferrable to introduce a new kind of port if we agree that we want the capabilities suggested here. Tim -------------- Issue 10597: Behavioral port Summary: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. ----------------------------------------------------------------- Tim Weilkiens Consultant, Instructor OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de X-VirusChecked: Checked X-Env-Sender: thomas.weigert@motorola.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1175115954!18119902!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.102] From: "Thomas Weigert" To: "'Branislav Selic'" , "'Tim Weilkiens'" Cc: Subject: RE: Issue 10597: Behavioral port Date: Wed, 28 Mar 2007 17:05:45 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdxeQyd4bDGu4AbSCyC+YAXDfuWXwAAzpWQ X-Vontu: Pass X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org I agree with Bran on that this would require a separate port or an additional attribute to change the port behavior IF we think this is a useful enhancement. Personally, I do not see the need for such enhancement based on my experience, but different domains may differ. It would be good to present some compelling use cases that justify this enhancement. Th. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, March 28, 2007 4:34 PM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: Re: Issue 10597: Behavioral port Comments below identified by [bvs] Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Tim Weilkiens" 03/28/2007 11:40 AM To cc Subject Issue 10597: Behavioral port Hi, issue 10597 isn't an easy one. There was a long discussion between Ed, Alan, and Bran some weeks ago. The issue summary below was the conclusion of that discussion (if I remind correctly). Unfortunately I've lost the email thread due a server crash. I have some remarks on the suggested resolution: > 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. The constraint is only necessary for ports that have no connectors to internal parts. [bvs] As stated, this would force even an abstract class to realize these interfaces (I am assuming that realization implies having an implementation method for operations defined on an interface). Clearly, there will be situations where this is inappropriate -- the abstract class may want to defer the realization to a subclass. Also, it may want to delegate the realization to a part. >3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the > corresponding behavioral feature of the owning classifier (if there is such a method). [bvs] First of all, I don't think that there are any special semantics to behavior ports that are different from any other port. ALL ports act as relays, whether they are behavior or not. The only difference is who the request is being relayed to: a classifier behavior or something that sits at the opposite end of the connector attached to the port. Second, it seems like there is an issue here of identifying which method corresponds to which port. Since multiple ports can support the same interface, it is quite reasonable to have a situation where the same method is handled differently based on which port the request arrives. [bvs] Perhaps we need another kind of port for the capability suggested here? After all, I don't believe that we want this kind of behavior in all cases of non-behavior ports. There seems to be something wrong with the sentence ("with connectors no connectors"). Ed, what do you mean? >4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports >when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Do you mean we should include a semantic variation point? [bvs] Some of this requires changing the current semantics of ports -- as implemented in numerous tools. Therefore, it seems preferrable to introduce a new kind of port if we agree that we want the capabilities suggested here. Tim -------------- Issue 10597: Behavioral port Summary: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. ----------------------------------------------------------------- Tim Weilkiens Consultant, Instructor OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Issue 10597: Behavioral port Date: Thu, 29 Mar 2007 10:59:30 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-Index: AcdxeQyd4bDGu4AbSCyC+YAXDfuWXwAAzpWQABe8yOA= From: "Eran Gery" To: "Branislav Selic" , "Tim Weilkiens" Cc: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, March 28, 2007 4:34 PM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: Re: Issue 10597: Behavioral port Comments below identified by [bvs] Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Tim Weilkiens" 03/28/2007 11:40 AM To cc Subject Issue 10597: Behavioral port >3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the > corresponding behavioral feature of the owning classifier (if there is such a method). [bvs] First of all, I don't think that there are any special semantics to behavior ports that are different from any other port. ALL ports act as relays, whether they are behavior or not. The only difference is who the request is being relayed to: a classifier behavior or something that sits at the opposite end of the connector attached to the port. Second, it seems like there is an issue here of identifying which method corresponds to which port. Since multiple ports can support the same interface, it is quite reasonable to have a situation where the same method is handled differently based on which port the request arrives. [bvs] Perhaps we need another kind of port for the capability suggested here? After all, I don't believe that we want this kind of behavior in all cases of non-behavior ports. Eran> Again, This is a very common case. We shall not force users that want to model architecture with ports, to model behavior using a statemachine or activity so they can dispatch a method. Regarding the issue of port qualification, I think we need to allow it (e.g. Autosar), but I would definitely not force explicit port mapping because of that. There are many cases where interfaces are unique per port, and also cases where several ports may ofer the same service while being addressed by the same method. What is important is that we shall not held that amended semantics hostage to a mapping formalism, while I.m not objecting to it. - Eran From: "Thomas Weigert" To: "'Eran Gery'" , "'Branislav Selic'" , "'Tim Weilkiens'" Cc: Subject: RE: Issue 10597: Behavioral port Date: Thu, 29 Mar 2007 07:51:55 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdxeQyd4bDGu4AbSCyC+YAXDfuWXwAAzpWQABe8yOAACVoYAA== X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Eran, I do not see anything in the current spec preventing an Autosar profile to provide some kind of mechanism to that routes messages to behaviors. Note that operation calls on the port would do that in either case, assuming these are behaviors of the object under question. Th. -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, March 29, 2007 3:59 AM To: Branislav Selic; Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran> Again, This is a very common case. We shall not force users that want to model architecture with ports, to model behavior using a statemachine or activity so they can dispatch a method. Regarding the issue of port qualification, I think we need to allow it (e.g. Autosar), but I would definitely not force explicit port mapping because of that. There are many cases where interfaces are unique per port, and also cases where several ports may ofer the same service while being addressed by the same method. What is important is that we shall not held that amended semantics hostage to a mapping formalism, while I.m not objecting to it. To: "Eran Gery" Cc: "Tim Weilkiens" , uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 29 Mar 2007 10:38:17 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 03/29/2007 10:38:17, Serialize complete at 03/29/2007 10:38:17 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran To: "Thomas Weigert" Cc: "'Eran Gery'" , "'Tim Weilkiens'" , uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 29 Mar 2007 10:45:16 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 03/29/2007 10:45:15, Serialize complete at 03/29/2007 10:45:15 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Agreed. See my previous e-mail on this about the general approach I think we should take in such cases. Cheers, Bran "Thomas Weigert" 03/29/2007 08:51 AM To "'Eran Gery'" , Branislav Selic/Ottawa/IBM@IBMCA, "'Tim Weilkiens'" cc Subject RE: Issue 10597: Behavioral port Eran, I do not see anything in the current spec preventing an Autosar profile to provide some kind of mechanism to that routes messages to behaviors. Note that operation calls on the port would do that in either case, assuming these are behaviors of the object under question. Th. -------------------------------------------------------------------------------- From: Eran Gery [mailto:Eran.Gery@telelogic.com] Sent: Thursday, March 29, 2007 3:59 AM To: Branislav Selic; Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran> Again, This is a very common case. We shall not force users that want to model architecture with ports, to model behavior using a statemachine or activity so they can dispatch a method. Regarding the issue of port qualification, I think we need to allow it (e.g. Autosar), but I would definitely not force explicit port mapping because of that. There are many cases where interfaces are unique per port, and also cases where several ports may ofer the same service while being addressed by the same method. What is important is that we shall not held that amended semantics hostage to a mapping formalism, while I.m not objecting to it. Subject: RE: Issue 10597: Behavioral port Date: Fri, 30 Mar 2007 16:53:23 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-index: AcdyEYeWsO6yZzXhSQWE+kBxD8MpHwAyGFZw From: "Tim Weilkiens" To: "Branislav Selic" , "Thomas Weigert" Cc: "Eran Gery" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2UFm3vv021590 Bran, Eran, Thomas, et.al., to summarize your discussion: There is no need to change anything. The solution is to define a profile, if someone wants that special behavior. If it is not possible to define such stereotypes, we need to change something. UML should not prevent users from doing such things. @Eran: Could you provide a concrete example if you still has concerns about this? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, March 29, 2007 4:45 PM > To: Thomas Weigert > Cc: 'Eran Gery'; Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Agreed. See my previous e-mail on this about the general > approach I think we should take in such cases. > > Cheers, > Bran > > > > > "Thomas Weigert" > > 03/29/2007 08:51 AM To > "'Eran Gery'" , Branislav > Selic/Ottawa/IBM@IBMCA, "'Tim Weilkiens'" > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > Eran, > > I do not see anything in the current spec preventing an > Autosar profile to provide some kind of mechanism to that > routes messages to behaviors. Note that operation calls on > the port would do that in either case, assuming these are > behaviors of the object under question. > > Th. > > > ________________________________ > > From: Eran Gery [mailto:Eran.Gery@telelogic.com] > Sent: Thursday, March 29, 2007 3:59 AM > To: Branislav Selic; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Eran> Again, This is a very common case. We shall not force > users that want to model architecture with ports, to model > behavior using a statemachine or activity so they can > dispatch a method. Regarding the issue of port > qualification, I think we need to allow it (e.g. Autosar), > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are > unique per port, and also cases where several ports may ofer > the same service while being addressed by the same method. > What is important is that we shall not held that amended > semantics hostage to a mapping formalism, while I'm not > objecting to it. > > X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Issue 10597: Behavioral port Date: Fri, 30 Mar 2007 19:39:23 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-Index: AcdyEYeWsO6yZzXhSQWE+kBxD8MpHwAyGFZwAAUhsGA= From: "Eran Gery" To: "Tim Weilkiens" Cc: , "Branislav Selic" , "Thomas Weigert" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Tim - I think that this is rather a fundamental thing (invoking operations via a port), and not some domain specific requirement, this is w.r.t Bran's proposal to make this be part of a profile. I believe many UML users assume this happens by default. This is why I think the spec better be amended to accommodate this. I did find something Michael Chonoles sent out at the time attached that provides motivation to that. Note that Michael does not refer to any domain specific usage. I can send out a system model with tons of ports offering services, but anyone can make it up very easily... I do not think anyone questions this. Regards, Eran -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, March 30, 2007 4:53 PM To: Branislav Selic; Thomas Weigert Cc: Eran Gery; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Bran, Eran, Thomas, et.al., to summarize your discussion: There is no need to change anything. The solution is to define a profile, if someone wants that special behavior. If it is not possible to define such stereotypes, we need to change something. UML should not prevent users from doing such things. @Eran: Could you provide a concrete example if you still has concerns about this? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, March 29, 2007 4:45 PM > To: Thomas Weigert > Cc: 'Eran Gery'; Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Agreed. See my previous e-mail on this about the general > approach I think we should take in such cases. > > Cheers, > Bran > > > > > "Thomas Weigert" > > 03/29/2007 08:51 AM To > "'Eran Gery'" , Branislav > Selic/Ottawa/IBM@IBMCA, "'Tim Weilkiens'" > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > Eran, > > I do not see anything in the current spec preventing an > Autosar profile to provide some kind of mechanism to that > routes messages to behaviors. Note that operation calls on > the port would do that in either case, assuming these are > behaviors of the object under question. > > Th. > > > ________________________________ > > From: Eran Gery [mailto:Eran.Gery@telelogic.com] > Sent: Thursday, March 29, 2007 3:59 AM > To: Branislav Selic; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Eran> Again, This is a very common case. We shall not force > users that want to model architecture with ports, to model > behavior using a statemachine or activity so they can > dispatch a method. Regarding the issue of port > qualification, I think we need to allow it (e.g. Autosar), > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are > unique per port, and also cases where several ports may ofer > the same service while being addressed by the same method. > What is important is that we shall not held that amended > semantics hostage to a mapping formalism, while I'm not > objecting to it. > > Received: from semlm-shield2.tlogic.telelogic.com ([172.18.2.45]) by semlm-exch.tlogic.telelogic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 20:13:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0088_01C73B08.9C342A30"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Received: From mail1.telelogic.com ([192.168.99.10]) by semlm-shield2.tlogic.telelogic.com (WebShield SMTP v4.5 MR1a P0803.345); id 1169147591920; Thu, 18 Jan 2007 20:13:11 +0100 Received: from deframx04.softcom.dk (deframx04.softcom.dk [80.237.210.74]) by mail1.telelogic.com (8.13.2/8.13.2) with ESMTP id l0IJD1N5023648 for ; Thu, 18 Jan 2007 20:13:01 +0100 Received: from amethyst.omg.org (192.67.184.64) by deframx04.softcom.dk (envelope-from ) with ESMTP. tag msg.1169147571.217006.15016 (Processed in 4.73767 secs); 18 Jan 2007 19:12:55 -0000 Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by amethyst.omg.org (8.13.8/8.12.11) with ESMTP id l0IIvhE8011153 for ; Thu, 18 Jan 2007 13:57:43 -0500 Received: from mailgw1a.lmco.com [192.31.106.7] by hobbit.omg.org asmtp(4.3a1) id 7049; Thu, 18 Jan 2007 13:49:37 -0500 (EST) Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54])by mailgw1a.lmco.com (LM-6) with ESMTP id l0IJ38KG005158;Thu, 18 Jan 2007 12:03:08 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.3-x3 #31239) id <0JC200301V06I5@lmco.com>; Thu, 18 Jan 2007 12:03:08 -0700 (MST) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.3-x3 #31239) with ESMTP id <0JC2005RNVC6RQ@lmco.com>; Thu, 18 Jan 2007 11:57:49 -0700 (MST) Received: from EMSS04M20.us.lmco.com ([129.204.56.82]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Jan 2007 13:57:39 -0500 Content-class: urn:content-classes:message Subject: RE: Behavioral port Date: Thu, 18 Jan 2007 20:57:36 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Behavioral port Thread-Index: Acc7HYyiwVqqT3uiTDChjbffDihpngADA0gwAAFseBAAABb2oA== References: <4F65F8D37DEBFC459F5A7228E5052044154D16@DATCENTRALSRV.datcentral.local> From: "Chonoles, Michael J" To: "Chonoles, Michael J" , "Ed Seidewitz" , "Branislav Selic" Cc: In the process of development, I need the ability to treat an object as black box at some level before going lower in design A object would be defined as having many operations (perhaps by conforming to several interfaces). It could have many ports, each port typed to the interface(s) that port supports and the object could be used in connection to other objects in a larger assembly. Requests coming in on these ports should be forwarded to the conforming operations of the object as a whole. Later, in an iterative design approach, I may design the lower-level parts of this object, and formally connect the ports to an appropriate level internal part. This is how OO design works, that is your encapsulated object appears to have a set of behaviors, but they may be implemented by internal parts. If I can.t connect use ports until I make up the parts, this forces a low-level of design that.s usually premature. Michael Jesse Chonoles Principal Member of Engineer Staff -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Thursday, January 18, 2007 1:35 PM To: 'Ed Seidewitz'; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran smime2.p7s To: "Eran Gery" Cc: "Thomas Weigert" , "Tim Weilkiens" , uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Fri, 30 Mar 2007 15:53:40 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 03/30/2007 15:53:41 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Eran, When ports were introduced into UML there was no notion of invoking methods directly through a port, only the classifier behavior. The latter model came from many years of experience with ports in industrial projects and is, therefore, extensively proven in practice and safe. OTOH, it is not fully clear to me what all the issues might be when invoking methods from ports, although some are obvious, such as that there is likely to be a lot of variations in how this could be done. There may be a solution, such as the one you state, that may be obvious to a certain group of users, but that does not mean that it is obvious or suitable to all. I would much prefer that we experimented with this first, through one or more profiles and then to standardize the patterns that emerge as useful and non-contentious. Having said that, as an RTF member, you have the right to propose a resolution that you think is suitable. The only thing that I ask is that you format it as a proper resolution. I think the monkey here is off Tim's back and on yours Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 03/30/2007 01:39 PM To "Tim Weilkiens" cc , Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" Subject RE: Issue 10597: Behavioral port Tim - I think that this is rather a fundamental thing (invoking operations via a port), and not some domain specific requirement, this is w.r.t Bran's proposal to make this be part of a profile. I believe many UML users assume this happens by default. This is why I think the spec better be amended to accommodate this. I did find something Michael Chonoles sent out at the time attached that provides motivation to that. Note that Michael does not refer to any domain specific usage. I can send out a system model with tons of ports offering services, but anyone can make it up very easily... I do not think anyone questions this. Regards, Eran -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, March 30, 2007 4:53 PM To: Branislav Selic; Thomas Weigert Cc: Eran Gery; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Bran, Eran, Thomas, et.al., to summarize your discussion: There is no need to change anything. The solution is to define a profile, if someone wants that special behavior. If it is not possible to define such stereotypes, we need to change something. UML should not prevent users from doing such things. @Eran: Could you provide a concrete example if you still has concerns about this? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, March 29, 2007 4:45 PM > To: Thomas Weigert > Cc: 'Eran Gery'; Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Agreed. See my previous e-mail on this about the general > approach I think we should take in such cases. > > Cheers, > Bran > > > > > "Thomas Weigert" > > 03/29/2007 08:51 AM To > "'Eran Gery'" , Branislav > Selic/Ottawa/IBM@IBMCA, "'Tim Weilkiens'" > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > Eran, > > I do not see anything in the current spec preventing an > Autosar profile to provide some kind of mechanism to that > routes messages to behaviors. Note that operation calls on > the port would do that in either case, assuming these are > behaviors of the object under question. > > Th. > > > ________________________________ > > From: Eran Gery [mailto:Eran.Gery@telelogic.com] > Sent: Thursday, March 29, 2007 3:59 AM > To: Branislav Selic; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Eran> Again, This is a very common case. We shall not force > users that want to model architecture with ports, to model > behavior using a statemachine or activity so they can > dispatch a method. Regarding the issue of port > qualification, I think we need to allow it (e.g. Autosar), > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are > unique per port, and also cases where several ports may ofer > the same service while being addressed by the same method. > What is important is that we shall not held that amended > semantics hostage to a mapping formalism, while I'm not > objecting to it. > > ----- Message from "Chonoles, Michael J" on Thu, 18 Jan 2007 20:57:36 +0200 ----- To: "Chonoles, Michael J" , "Ed Seidewitz" , "Branislav Selic" cc: Subject: RE: Behavioral port In the process of development, I need the ability to treat an object as black box at some level before going lower in design A object would be defined as having many operations (perhaps by conforming to several interfaces). It could have many ports, each port typed to the interface(s) that port supports and the object could be used in connection to other objects in a larger assembly. Requests coming in on these ports should be forwarded to the conforming operations of the object as a whole. Later, in an iterative design approach, I may design the lower-level parts of this object, and formally connect the ports to an appropriate level internal part. This is how OO design works, that is your encapsulated object appears to have a set of behaviors, but they may be implemented by internal parts. If I can.t connect use ports until I make up the parts, this forces a low-level of design that.s usually premature. Michael Jesse Chonoles Principal Member of Engineer Staff -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Thursday, January 18, 2007 1:35 PM To: 'Ed Seidewitz'; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran smime3.p7s To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Fri, 30 Mar 2007 16:41:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 03/30/2007 16:41:46, Serialize complete at 03/30/2007 16:41:46 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Thanks, Ed. Some replies below in red. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 03/29/2007 01:24 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 10597: Behavioral port Bran -- The current spec says clearly that a behavior port always forwards requests to the classifier behavior and that a non-behavior port always forwards requests along connectors to internal parts (see, in particular, the last two paragraphs under Semantics in Section 9.3.11). To me this seems to specifically not allow what a number of people think is an expected case: a port forwarding a request to the instance of the owning classifier but not to the classifier behavior. A profile that allowed that would seemingly violate the basic semantics of ports as defined in the spec. [bvs] You and I discussed this already but, for the benefit of the other folks on the UML 2 list, let me clarify my position. I can see the rationale for a request received on a port resulting in the activation of a method that realizes the invoked feature. But, there could be valid cases where there might be different methods realizing the same interface, which, I suspect does not fall under the "expected case". I suspect that there are other issues like this and, before we rush off and implement something for the "expected case" we really should understand the problem better. [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. Now, the spec also says that typing a port by a class "allows elaborate specification of the communication over a port." But it is not at all clear how one might model such an elaborate specification, or when or how it has to be compatible with the basic routing semantics described in the two paragraphs following this statement. I would agree that it should be up to profiles to provide a means for "elaborate specification" of routing. But it should also be clear how that fits into the fundamental framework of port semantics, and the fundamental port semantics should clearly allow flexibility in the specification of such routing, if desired. In my opinion, the current specification text for port is not clear on either of these things. If we really want to allow for reasonable profiles in this area, then we should keep the basic port semantics simple an clear. I would suggest the following: A behavior port forwards requests to the instance of the owning classifier. The request is then handled as if it had directly come to the instance, and it may be handled by a method or by the classifier behavior, as could any request coming to the instance. Any more specific specification of how the request is routing is a semantic variation point that could be further defined in a profile. [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). A non-behavior port forwards requests along one or more connectors to internal parts of the owning classifier. If there are multiple internal connectors out of a port, then it is a semantics variation point (which could be further defined in a profile) as to whether and how a request is routed along one or more of the outgoing connectors. (This is actually already a semantic variation point in the spec.) Any request that for which there is no destination to route it (e.g., the instance of the owning classifier is not ready to handle a request from a behavior port or there is no outgoing connector for a non-behavior port) then the request is dropped. (That is, the port should not be able to handle the request itself without forwarding it, because that would violate the fundamental semantics of a port as a mediator.) -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, March 29, 2007 10:38 AM To: Eran Gery Cc: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Issue 10597: Behavioral port Date: Sun, 1 Apr 2007 12:59:44 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-Index: AcdzBStLIlwhOeQcTeGkjw55LxQ/pgBOwXCw From: "Eran Gery" To: "Branislav Selic" Cc: "Thomas Weigert" , "Tim Weilkiens" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Bran OK . that.s a fair proposal. As far as the history . I am well aware of both the ROOM and SDL predecessors of the ports (gates). Note though that we started to generalize them to a more .SW generic. from the very beginning of the UML2.0 work. The fact we utilized concepts such as required/provided interfaces to capture the .contract. of the port signifies that change. Both SDL and ROOM used different concept to characterize the port (e.g. protocols, signal-lists), and both those predecessor languages were much more domain specific that UML, and therefore UML shall be more accommodating. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, March 30, 2007 9:54 PM To: Eran Gery Cc: Thomas Weigert; Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, When ports were introduced into UML there was no notion of invoking methods directly through a port, only the classifier behavior. The latter model came from many years of experience with ports in industrial projects and is, therefore, extensively proven in practice and safe. OTOH, it is not fully clear to me what all the issues might be when invoking methods from ports, although some are obvious, such as that there is likely to be a lot of variations in how this could be done. There may be a solution, such as the one you state, that may be obvious to a certain group of users, but that does not mean that it is obvious or suitable to all. I would much prefer that we experimented with this first, through one or more profiles and then to standardize the patterns that emerge as useful and non-contentious. Having said that, as an RTF member, you have the right to propose a resolution that you think is suitable. The only thing that I ask is that you format it as a proper resolution. I think the monkey here is off Tim's back and on yours Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 03/30/2007 01:39 PM To "Tim Weilkiens" cc , Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" Subject RE: Issue 10597: Behavioral port Tim - I think that this is rather a fundamental thing (invoking operations via a port), and not some domain specific requirement, this is w.r.t Bran's proposal to make this be part of a profile. I believe many UML users assume this happens by default. This is why I think the spec better be amended to accommodate this. I did find something Michael Chonoles sent out at the time attached that provides motivation to that. Note that Michael does not refer to any domain specific usage. I can send out a system model with tons of ports offering services, but anyone can make it up very easily... I do not think anyone questions this. Regards, Eran -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, March 30, 2007 4:53 PM To: Branislav Selic; Thomas Weigert Cc: Eran Gery; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Bran, Eran, Thomas, et.al., to summarize your discussion: There is no need to change anything. The solution is to define a profile, if someone wants that special behavior. If it is not possible to define such stereotypes, we need to change something. UML should not prevent users from doing such things. @Eran: Could you provide a concrete example if you still has concerns about this? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, March 29, 2007 4:45 PM > To: Thomas Weigert > Cc: 'Eran Gery'; Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Agreed. See my previous e-mail on this about the general > approach I think we should take in such cases. > > Cheers, > Bran > > > > > "Thomas Weigert" > > 03/29/2007 08:51 AM To > "'Eran Gery'" , Branislav > Selic/Ottawa/IBM@IBMCA, "'Tim Weilkiens'" > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > Eran, > > I do not see anything in the current spec preventing an > Autosar profile to provide some kind of mechanism to that > routes messages to behaviors. Note that operation calls on > the port would do that in either case, assuming these are > behaviors of the object under question. > > Th. > > > ________________________________ > > From: Eran Gery [mailto:Eran.Gery@telelogic.com] > Sent: Thursday, March 29, 2007 3:59 AM > To: Branislav Selic; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Eran> Again, This is a very common case. We shall not force > users that want to model architecture with ports, to model > behavior using a statemachine or activity so they can > dispatch a method. Regarding the issue of port > qualification, I think we need to allow it (e.g. Autosar), > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are > unique per port, and also cases where several ports may ofer > the same service while being addressed by the same method. > What is important is that we shall not held that amended > semantics hostage to a mapping formalism, while I'm not > objecting to it. > > ----- Message from "Chonoles, Michael J" on Thu, 18 Jan 2007 20:57:36 +0200 ----- To: "Chonoles, Michael J" , "Ed Seidewitz" , "Branislav Selic" cc: Subject: RE: Behavioral port In the process of development, I need the ability to treat an object as black box at some level before going lower in design A object would be defined as having many operations (perhaps by conforming to several interfaces). It could have many ports, each port typed to the interface(s) that port supports and the object could be used in connection to other objects in a larger assembly. Requests coming in on these ports should be forwarded to the conforming operations of the object as a whole. Later, in an iterative design approach, I may design the lower-level parts of this object, and formally connect the ports to an appropriate level internal part. This is how OO design works, that is your encapsulated object appears to have a set of behaviors, but they may be implemented by internal parts. If I can.t connect use ports until I make up the parts, this forces a low-level of design that.s usually premature. Michael Jesse Chonoles Principal Member of Engineer Staff -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Thursday, January 18, 2007 1:35 PM To: 'Ed Seidewitz'; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed.s request pretty much matches the assumptions among the user community Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) 199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057 Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies OMG-Certified UML Advanced Professional (856) 359-1383 NJ -- Voice/Voice Mail (610) 644-8404 PA -- Voice/Voice Mail (215) 790-2976 E-Fax (609) 760-2180 Mobile mjchonoles Skype -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Thursday, January 18, 2007 1:04 PM To: Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Actually, Bran, I think the semantics is a little better defined than just for behavior ports. Here is my summary understanding of the currently specified execution semantics around ports, based on my reading of the spec and the comments made in this discussion thread. 1. If the port is a behavior port, then a request directed to the port is forwarded to the classifier behavior for the owning classifier. This is what it means to be a behavior port -- requests are forwarded to the classifier behavior. 2. If the port not a behavior port, but is connected to internal parts of the owning classifier, then a request directed to the port is forwarded along those connectors. 3. If the port is a behavior port, but there is no classifier behavior, or it is not a behavior port, and there are no internal connections, then a request directed to the port is simply lost. What is being suggested is changing the semantics of 3 above to allow something like having a request to a port directed to an operation of the owning classifier, without having to have the intermediary of a classifier behavior. Is that about right? -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 11:27 AM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port The point is that we have really only defined the semantics of behavior ports for the case of objects that have a classifier behavior (and only really for active objects). We need to discuss and agree on what it might mean in other cases. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 10:01 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Behavioral port Bran . I do not see an issue with both. Again, whether an invoked operation is being .forwarded. or handled directly by the instance, both cases do not require an object to be .active.. In both cases it can operate in the context of the invocation. Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 4:53 PM To: Eran Gery Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Behavioral port Are you talking about behavior ports or non-behavior ports? Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 01/18/2007 09:23 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Behavioral port Bran, I have not scanned all the text in the spec, but at least from an intent point of view there shall be no connection between port usage and whether a class is active or not. Ports are just named interaction points. For example if you look at CCM ports they are mostly applied to passive classes. I.m sure there.s also a variation in how the term .passive. is interpreted once you look at a real life case (e.g. CCM) but regardless, the fact an instance is invoked via a port, as opposed to invoking an operation defined on a plain interface shall not change the nature of the class from .passive. to .active.. BR, Eran -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 18, 2007 1:21 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Behavioral port Ed wrote: > This should be entered as an issue for consideration by this or the > next RTF. Agreed. > Until then, folks can just come up with their own > semantics for the use of ports with passive classes, as I am sure many have. Provided they do so in a profile -- whenever you add semantics that are outside of the standard, you should define an explicit profile. Otherwise, people will be confused. Cheers...Bran Subject: RE: Issue 10597: Behavioral port Date: Mon, 2 Apr 2007 13:43:12 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-Index: AcdzDEKnQFaQX44dSCWHGNcF+LI0awCF4AvA From: "Alan Moore" To: "Branislav Selic" , "Ed Seidewitz" Cc: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Bran, I.m intrigued by your third red paragraph: [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). How currently is the classifier Behavior informed about the source behaviour port for an incoming request? ( I had a quick look but it wasn.t obvious to me) Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, March 30, 2007 9:42 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Thanks, Ed. Some replies below in red. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 03/29/2007 01:24 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 10597: Behavioral port Bran -- The current spec says clearly that a behavior port always forwards requests to the classifier behavior and that a non-behavior port always forwards requests along connectors to internal parts (see, in particular, the last two paragraphs under Semantics in Section 9.3.11). To me this seems to specifically not allow what a number of people think is an expected case: a port forwarding a request to the instance of the owning classifier but not to the classifier behavior. A profile that allowed that would seemingly violate the basic semantics of ports as defined in the spec. [bvs] You and I discussed this already but, for the benefit of the other folks on the UML 2 list, let me clarify my position. I can see the rationale for a request received on a port resulting in the activation of a method that realizes the invoked feature. But, there could be valid cases where there might be different methods realizing the same interface, which, I suspect does not fall under the "expected case". I suspect that there are other issues like this and, before we rush off and implement something for the "expected case" we really should understand the problem better. [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. Now, the spec also says that typing a port by a class "allows elaborate specification of the communication over a port." But it is not at all clear how one might model such an elaborate specification, or when or how it has to be compatible with the basic routing semantics described in the two paragraphs following this statement. I would agree that it should be up to profiles to provide a means for "elaborate specification" of routing. But it should also be clear how that fits into the fundamental framework of port semantics, and the fundamental port semantics should clearly allow flexibility in the specification of such routing, if desired. In my opinion, the current specification text for port is not clear on either of these things. If we really want to allow for reasonable profiles in this area, then we should keep the basic port semantics simple an clear. I would suggest the following: A behavior port forwards requests to the instance of the owning classifier. The request is then handled as if it had directly come to the instance, and it may be handled by a method or by the classifier behavior, as could any request coming to the instance. Any more specific specification of how the request is routing is a semantic variation point that could be further defined in a profile. [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). A non-behavior port forwards requests along one or more connectors to internal parts of the owning classifier. If there are multiple internal connectors out of a port, then it is a semantics variation point (which could be further defined in a profile) as to whether and how a request is routed along one or more of the outgoing connectors. (This is actually already a semantic variation point in the spec.) Any request that for which there is no destination to route it (e.g., the instance of the owning classifier is not ready to handle a request from a behavior port or there is no outgoing connector for a non-behavior port) then the request is dropped. (That is, the port should not be able to handle the request itself without forwarding it, because that would violate the fundamental semantics of a port as a mediator.) -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, March 29, 2007 10:38 AM To: Eran Gery Cc: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran Subject: RE: Issue 10597: Behavioral port Date: Mon, 2 Apr 2007 15:29:45 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-index: AcdzDPEeAwS+F/K/SdWnr7auCBdcIQCHHlzQ From: "Tim Weilkiens" To: "Branislav Selic" , "Ed Seidewitz" Cc: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. To be more concrete: We need a stereotype of a Behavior that * is the classifier behavior of the classifier with the ports * forwards all requests at the port to method invocations For example a state machine with appropriate CallOperationActions. Right? To breathe life into such a stereotype we need a profile and to make it public. Otherwise we won't collect experience with that approach. @Eran, any ideas or do you want to make a proposal for this issue? Tim -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, March 30, 2007 10:42 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Thanks, Ed. Some replies below in red. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 03/29/2007 01:24 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 10597: Behavioral port Bran -- The current spec says clearly that a behavior port always forwards requests to the classifier behavior and that a non-behavior port always forwards requests along connectors to internal parts (see, in particular, the last two paragraphs under Semantics in Section 9.3.11). To me this seems to specifically not allow what a number of people think is an expected case: a port forwarding a request to the instance of the owning classifier but not to the classifier behavior. A profile that allowed that would seemingly violate the basic semantics of ports as defined in the spec. [bvs] You and I discussed this already but, for the benefit of the other folks on the UML 2 list, let me clarify my position. I can see the rationale for a request received on a port resulting in the activation of a method that realizes the invoked feature. But, there could be valid cases where there might be different methods realizing the same interface, which, I suspect does not fall under the "expected case". I suspect that there are other issues like this and, before we rush off and implement something for the "expected case" we really should understand the problem better. [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. Now, the spec also says that typing a port by a class "allows elaborate specification of the communication over a port." But it is not at all clear how one might model such an elaborate specification, or when or how it has to be compatible with the basic routing semantics described in the two paragraphs following this statement. I would agree that it should be up to profiles to provide a means for "elaborate specification" of routing. But it should also be clear how that fits into the fundamental framework of port semantics, and the fundamental port semantics should clearly allow flexibility in the specification of such routing, if desired. In my opinion, the current specification text for port is not clear on either of these things. If we really want to allow for reasonable profiles in this area, then we should keep the basic port semantics simple an clear. I would suggest the following: A behavior port forwards requests to the instance of the owning classifier. The request is then handled as if it had directly come to the instance, and it may be handled by a method or by the classifier behavior, as could any request coming to the instance. Any more specific specification of how the request is routing is a semantic variation point that could be further defined in a profile. [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). A non-behavior port forwards requests along one or more connectors to internal parts of the owning classifier. If there are multiple internal connectors out of a port, then it is a semantics variation point (which could be further defined in a profile) as to whether and how a request is routed along one or more of the outgoing connectors. (This is actually already a semantic variation point in the spec.) Any request that for which there is no destination to route it (e.g., the instance of the owning classifier is not ready to handle a request from a behavior port or there is no outgoing connector for a non-behavior port) then the request is dropped. (That is, the port should not be able to handle the request itself without forwarding it, because that would violate the fundamental semantics of a port as a mediator.) -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, March 29, 2007 10:38 AM To: Eran Gery Cc: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran To: "Alan Moore" Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Mon, 2 Apr 2007 17:27:21 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/02/2007 17:27:23, Serialize complete at 04/02/2007 17:27:23 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Hi Alan, We had long discussions on this point when we were drawing up the submission and decided that, rather than choose a specific mechanism, this had to be a semantic variation point. This is in line with the decision to make the mechanism by which the received signal is made available to the classifier behavior an SVP. This supports what I said earlier as well as what Thomas noted: there are so many different ways that people want to use ports, that it is very difficult to come up with "the right way". Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Alan Moore" 04/02/2007 08:43 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Issue 10597: Behavioral port Bran, I.m intrigued by your third red paragraph: [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). How currently is the classifier Behavior informed about the source behaviour port for an incoming request? ( I had a quick look but it wasn.t obvious to me) Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, March 30, 2007 9:42 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Thanks, Ed. Some replies below in red. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 03/29/2007 01:24 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 10597: Behavioral port Bran -- The current spec says clearly that a behavior port always forwards requests to the classifier behavior and that a non-behavior port always forwards requests along connectors to internal parts (see, in particular, the last two paragraphs under Semantics in Section 9.3.11). To me this seems to specifically not allow what a number of people think is an expected case: a port forwarding a request to the instance of the owning classifier but not to the classifier behavior. A profile that allowed that would seemingly violate the basic semantics of ports as defined in the spec. [bvs] You and I discussed this already but, for the benefit of the other folks on the UML 2 list, let me clarify my position. I can see the rationale for a request received on a port resulting in the activation of a method that realizes the invoked feature. But, there could be valid cases where there might be different methods realizing the same interface, which, I suspect does not fall under the "expected case". I suspect that there are other issues like this and, before we rush off and implement something for the "expected case" we really should understand the problem better. [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. Now, the spec also says that typing a port by a class "allows elaborate specification of the communication over a port." But it is not at all clear how one might model such an elaborate specification, or when or how it has to be compatible with the basic routing semantics described in the two paragraphs following this statement. I would agree that it should be up to profiles to provide a means for "elaborate specification" of routing. But it should also be clear how that fits into the fundamental framework of port semantics, and the fundamental port semantics should clearly allow flexibility in the specification of such routing, if desired. In my opinion, the current specification text for port is not clear on either of these things. If we really want to allow for reasonable profiles in this area, then we should keep the basic port semantics simple an clear. I would suggest the following: A behavior port forwards requests to the instance of the owning classifier. The request is then handled as if it had directly come to the instance, and it may be handled by a method or by the classifier behavior, as could any request coming to the instance. Any more specific specification of how the request is routing is a semantic variation point that could be further defined in a profile. [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). A non-behavior port forwards requests along one or more connectors to internal parts of the owning classifier. If there are multiple internal connectors out of a port, then it is a semantics variation point (which could be further defined in a profile) as to whether and how a request is routed along one or more of the outgoing connectors. (This is actually already a semantic variation point in the spec.) Any request that for which there is no destination to route it (e.g., the instance of the owning classifier is not ready to handle a request from a behavior port or there is no outgoing connector for a non-behavior port) then the request is dropped. (That is, the port should not be able to handle the request itself without forwarding it, because that would violate the fundamental semantics of a port as a mediator.) -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, March 29, 2007 10:38 AM To: Eran Gery Cc: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran Subject: RE: Issue 10597: Behavioral port Date: Tue, 3 Apr 2007 08:00:57 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-index: Acd1bvk6KcQnjkE5TOy6GGaBNN5FCAARaKFg From: "Tim Weilkiens" To: "Branislav Selic" , "Alan Moore" Cc: "Ed Seidewitz" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l336sDlL000541 Bran, Do you propose the SVP as a resolution of the issue? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Monday, April 02, 2007 11:27 PM > To: Alan Moore > Cc: Ed Seidewitz; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Hi Alan, > > We had long discussions on this point when we were drawing up > the submission and decided that, rather than choose a > specific mechanism, this had to be a semantic variation > point. This is in line with the decision to make the > mechanism by which the received signal is made available to > the classifier behavior an SVP. > > This supports what I said earlier as well as what Thomas > noted: there are so many different ways that people want to > use ports, that it is very difficult to come up with "the right way". > > Regards, > Bran Selic > IBM Distinguished Engineer > > IBM Rational Software > 770 Palladium Drive > Kanata, Ontario, Canada > K2V 1C8 > ph.: (613) 591-7915 > fax: (613) 599-3912 > e-mail: bselic@ca.ibm.com > > > > "Alan Moore" > > 04/02/2007 08:43 AM To > Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" > > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > Bran, > > I'm intrigued by your third red paragraph: > > [bvs] If it is handled "as if it had directly come to the > instance" then the information on which port the request > arrived would be lost. That information is quite crucial -- > in fact, I would say that one of the basic value points of > ports is to be able to differentiate between different > sources of a request (but, without having to know who > actually sent the request). > > How currently is the classifier Behavior informed about the > source behaviour port for an incoming request? ( I had a > quick look but it wasn't obvious to me) > > Alan. > > ________________________________ > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Friday, March 30, 2007 9:42 PM > To: Ed Seidewitz > Cc: uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Thanks, Ed. Some replies below in red. > > Cheers, > Bran Selic > IBM Distinguished Engineer > > IBM Rational Software > 770 Palladium Drive > Kanata, Ontario, Canada > K2V 1C8 > ph.: (613) 591-7915 > fax: (613) 599-3912 > e-mail: bselic@ca.ibm.com > > > "Ed Seidewitz" > > 03/29/2007 01:24 PM > > To > Branislav Selic/Ottawa/IBM@IBMCA > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > > > > > > Bran -- > > The current spec says clearly that a behavior port always > forwards requests to the classifier behavior and that a > non-behavior port always forwards requests along connectors > to internal parts (see, in particular, the last two > paragraphs under Semantics in Section 9.3.11). To me this > seems to specifically not allow what a number of people think > is an expected case: a port forwarding a request to the > instance of the owning classifier but not to the classifier > behavior. A profile that allowed that would seemingly violate > the basic semantics of ports as defined in the spec. > > [bvs] You and I discussed this already but, for the benefit > of the other folks on the UML 2 list, let me clarify my > position. I can see the rationale for a request received on a > port resulting in the activation of a method that realizes > the invoked feature. But, there could be valid cases where > there might be different methods realizing the same > interface, which, I suspect does not fall under the "expected > case". I suspect that there are other issues like this and, > before we rush off and implement something for the "expected > case" we really should understand the problem better. > > [bvs] I disagree that a profile that realizes the "expected > case" would violate the basic semantics of ports, because the > classifier behavior could do the all the dispatching of > methods in either standard or non-standard ways. For those > who would prefer not to see the hairy details of such > dispatching, this could be hidden through a stereotype. And, > naturally, an implementation could optimize any such overhead > out, so that the result would not really require the > invocation of the classifier behavior. > > Now, the spec also says that typing a port by a class "allows > elaborate specification of the communication over a port." > But it is not at all clear how one might model such an > elaborate specification, or when or how it has to be > compatible with the basic routing semantics described in the > two paragraphs following this statement. > > I would agree that it should be up to profiles to provide a > means for "elaborate specification" of routing. But it should > also be clear how that fits into the fundamental framework of > port semantics, and the fundamental port semantics should > clearly allow flexibility in the specification of such > routing, if desired. In my opinion, the current specification > text for port is not clear on either of these things. > > If we really want to allow for reasonable profiles in this > area, then we should keep the basic port semantics simple an > clear. I would suggest the following: > > * A behavior port forwards requests to the instance of > the owning classifier. The request is then handled as if it > had directly come to the instance, and it may be handled by a > method or by the classifier behavior, as could any request > coming to the instance. Any more specific specification of > how the request is routing is a semantic variation point that > could be further defined in a profile. > > > [bvs] If it is handled "as if it had directly come to the > instance" then the information on which port the request > arrived would be lost. That information is quite crucial -- > in fact, I would say that one of the basic value points of > ports is to be able to differentiate between different > sources of a request (but, without having to know who > actually sent the request). > > * A non-behavior port forwards requests along one or more > connectors to internal parts of the owning classifier. If > there are multiple internal connectors out of a port, then it > is a semantics variation point (which could be further > defined in a profile) as to whether and how a request is > routed along one or more of the outgoing connectors. (This is > actually already a semantic variation point in the spec.) > * Any request that for which there is no destination to > route it (e.g., the instance of the owning classifier is not > ready to handle a request from a behavior port or there is no > outgoing connector for a non-behavior port) then the request > is dropped. (That is, the port should not be able to handle > the request itself without forwarding it, because that would > violate the fundamental semantics of a port as a mediator.) > > -- Ed > > ________________________________ > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, March 29, 2007 10:38 AM > To: Eran Gery > Cc: Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Eran, > > I have some comments below: > > > > [bvs] Perhaps we need another kind of port for the capability > > suggested here? After all, I don't believe that we want this kind of > > behavior in all cases of non-behavior ports. > > > Eran> Again, This is a very common case. > > Given the relatively recent introduction of ports into UML, I > am not sure that I agree that this case is "very common". > However, I can see the argument for it. The issue, in my > view, is whether it is something we want to put into > mainstream UML or into a profile. I would prefer the latter > especially since I can see a number of possible variations on > how such a capability can work. > > There are many precedents for this type of approach: For > instance, in our tools, we introduce the notion of event > priorities that have a major impact on event scheduling and > dispatching. However, since we recognized that this was not a > general requirement, we refrained from asking that this > capability be put into standard UML. We have enough > complaints about the complexity of UML as it is. > > > We shall not force users > > that want to model architecture with ports, to model behavior using > > a statemachine or activity so they can dispatch a method. Regarding > > the issue of port qualification, I think we need to allow it (e.g. > > Autosar), > > You can define a stereotype of Behavior that does the method > dispatch and does it in a way that is (a) hidden from the > user and (b) according to the needs of the application domain > > > but I would definitely not force explicit port mapping > > because of that. There are many cases where interfaces are unique > > per port, and also cases where several ports may ofer the same > > service while being addressed by the same method. What is important > > is that we shall not held that amended semantics hostage to a > > mapping formalism, while I'm not objecting to it. > > The choices you describe here illustrate my point about the > variations that can exist. We could define a general solution > that somehow realizes all these variations or we could leave > it up to profiles to solve as they deem appropriate. The > advantage of the latter is that it requires no changes to the > standard, since the current standard allows such variations. > > This brings me to a major point of principle: In cases where > the base standard does not prevent the introduction of some > new feature, I believe that we should refrain from adding the > new feature to the standard, but leave it up to a profile. > This will prevent us from gradually ending up with a > Swiss-army knife monster (although some folks claim that it > is too late already ). > > Cheers...Bran > > Subject: RE: Issue 10597: Behavioral port Date: Tue, 3 Apr 2007 11:58:24 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-Index: Acd1bboGO/LSNTTXTwmEPB9yygSD2QAcMFXg From: "Alan Moore" To: "Branislav Selic" Cc: "Ed Seidewitz" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Hi Bran, Given that why can.t the dispatch of methods based on the source Port for a Request also be an SVP? Sounds like an orthogonal issue to me. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, April 02, 2007 10:27 PM To: Alan Moore Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Hi Alan, We had long discussions on this point when we were drawing up the submission and decided that, rather than choose a specific mechanism, this had to be a semantic variation point. This is in line with the decision to make the mechanism by which the received signal is made available to the classifier behavior an SVP. This supports what I said earlier as well as what Thomas noted: there are so many different ways that people want to use ports, that it is very difficult to come up with "the right way". Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Alan Moore" 04/02/2007 08:43 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Issue 10597: Behavioral port Bran, I.m intrigued by your third red paragraph: [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). How currently is the classifier Behavior informed about the source behaviour port for an incoming request? ( I had a quick look but it wasn.t obvious to me) Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, March 30, 2007 9:42 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Thanks, Ed. Some replies below in red. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 03/29/2007 01:24 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 10597: Behavioral port Bran -- The current spec says clearly that a behavior port always forwards requests to the classifier behavior and that a non-behavior port always forwards requests along connectors to internal parts (see, in particular, the last two paragraphs under Semantics in Section 9.3.11). To me this seems to specifically not allow what a number of people think is an expected case: a port forwarding a request to the instance of the owning classifier but not to the classifier behavior. A profile that allowed that would seemingly violate the basic semantics of ports as defined in the spec. [bvs] You and I discussed this already but, for the benefit of the other folks on the UML 2 list, let me clarify my position. I can see the rationale for a request received on a port resulting in the activation of a method that realizes the invoked feature. But, there could be valid cases where there might be different methods realizing the same interface, which, I suspect does not fall under the "expected case". I suspect that there are other issues like this and, before we rush off and implement something for the "expected case" we really should understand the problem better. [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. Now, the spec also says that typing a port by a class "allows elaborate specification of the communication over a port." But it is not at all clear how one might model such an elaborate specification, or when or how it has to be compatible with the basic routing semantics described in the two paragraphs following this statement. I would agree that it should be up to profiles to provide a means for "elaborate specification" of routing. But it should also be clear how that fits into the fundamental framework of port semantics, and the fundamental port semantics should clearly allow flexibility in the specification of such routing, if desired. In my opinion, the current specification text for port is not clear on either of these things. If we really want to allow for reasonable profiles in this area, then we should keep the basic port semantics simple an clear. I would suggest the following: A behavior port forwards requests to the instance of the owning classifier. The request is then handled as if it had directly come to the instance, and it may be handled by a method or by the classifier behavior, as could any request coming to the instance. Any more specific specification of how the request is routing is a semantic variation point that could be further defined in a profile. [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). A non-behavior port forwards requests along one or more connectors to internal parts of the owning classifier. If there are multiple internal connectors out of a port, then it is a semantics variation point (which could be further defined in a profile) as to whether and how a request is routed along one or more of the outgoing connectors. (This is actually already a semantic variation point in the spec.) Any request that for which there is no destination to route it (e.g., the instance of the owning classifier is not ready to handle a request from a behavior port or there is no outgoing connector for a non-behavior port) then the request is dropped. (That is, the port should not be able to handle the request itself without forwarding it, because that would violate the fundamental semantics of a port as a mediator.) -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, March 29, 2007 10:38 AM To: Eran Gery Cc: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran To: "Tim Weilkiens" Cc: "Alan Moore" , "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 3 Apr 2007 09:37:57 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/03/2007 09:37:59, Serialize complete at 04/03/2007 09:37:59 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org In a sense, the SVP solution is what is implied by the spec, but it could be spelled out explicitly. However, let's see what proposals come in. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Tim Weilkiens" 04/03/2007 02:00 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Alan Moore" cc "Ed Seidewitz" , Subject RE: Issue 10597: Behavioral port Bran, Do you propose the SVP as a resolution of the issue? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Monday, April 02, 2007 11:27 PM > To: Alan Moore > Cc: Ed Seidewitz; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Hi Alan, > > We had long discussions on this point when we were drawing up > the submission and decided that, rather than choose a > specific mechanism, this had to be a semantic variation > point. This is in line with the decision to make the > mechanism by which the received signal is made available to > the classifier behavior an SVP. > > This supports what I said earlier as well as what Thomas > noted: there are so many different ways that people want to > use ports, that it is very difficult to come up with "the right way". > > Regards, > Bran Selic > IBM Distinguished Engineer > > IBM Rational Software > 770 Palladium Drive > Kanata, Ontario, Canada > K2V 1C8 > ph.: (613) 591-7915 > fax: (613) 599-3912 > e-mail: bselic@ca.ibm.com > > > > "Alan Moore" > > 04/02/2007 08:43 AM To > Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" > > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > Bran, > > I'm intrigued by your third red paragraph: > > [bvs] If it is handled "as if it had directly come to the > instance" then the information on which port the request > arrived would be lost. That information is quite crucial -- > in fact, I would say that one of the basic value points of > ports is to be able to differentiate between different > sources of a request (but, without having to know who > actually sent the request). > > How currently is the classifier Behavior informed about the > source behaviour port for an incoming request? ( I had a > quick look but it wasn't obvious to me) > > Alan. > > ________________________________ > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Friday, March 30, 2007 9:42 PM > To: Ed Seidewitz > Cc: uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Thanks, Ed. Some replies below in red. > > Cheers, > Bran Selic > IBM Distinguished Engineer > > IBM Rational Software > 770 Palladium Drive > Kanata, Ontario, Canada > K2V 1C8 > ph.: (613) 591-7915 > fax: (613) 599-3912 > e-mail: bselic@ca.ibm.com > > > "Ed Seidewitz" > > 03/29/2007 01:24 PM > > To > Branislav Selic/Ottawa/IBM@IBMCA > cc > > Subject > RE: Issue 10597: Behavioral port > > > > > > > > > > > > Bran -- > > The current spec says clearly that a behavior port always > forwards requests to the classifier behavior and that a > non-behavior port always forwards requests along connectors > to internal parts (see, in particular, the last two > paragraphs under Semantics in Section 9.3.11). To me this > seems to specifically not allow what a number of people think > is an expected case: a port forwarding a request to the > instance of the owning classifier but not to the classifier > behavior. A profile that allowed that would seemingly violate > the basic semantics of ports as defined in the spec. > > [bvs] You and I discussed this already but, for the benefit > of the other folks on the UML 2 list, let me clarify my > position. I can see the rationale for a request received on a > port resulting in the activation of a method that realizes > the invoked feature. But, there could be valid cases where > there might be different methods realizing the same > interface, which, I suspect does not fall under the "expected > case". I suspect that there are other issues like this and, > before we rush off and implement something for the "expected > case" we really should understand the problem better. > > [bvs] I disagree that a profile that realizes the "expected > case" would violate the basic semantics of ports, because the > classifier behavior could do the all the dispatching of > methods in either standard or non-standard ways. For those > who would prefer not to see the hairy details of such > dispatching, this could be hidden through a stereotype. And, > naturally, an implementation could optimize any such overhead > out, so that the result would not really require the > invocation of the classifier behavior. > > Now, the spec also says that typing a port by a class "allows > elaborate specification of the communication over a port." > But it is not at all clear how one might model such an > elaborate specification, or when or how it has to be > compatible with the basic routing semantics described in the > two paragraphs following this statement. > > I would agree that it should be up to profiles to provide a > means for "elaborate specification" of routing. But it should > also be clear how that fits into the fundamental framework of > port semantics, and the fundamental port semantics should > clearly allow flexibility in the specification of such > routing, if desired. In my opinion, the current specification > text for port is not clear on either of these things. > > If we really want to allow for reasonable profiles in this > area, then we should keep the basic port semantics simple an > clear. I would suggest the following: > > * A behavior port forwards requests to the instance of > the owning classifier. The request is then handled as if it > had directly come to the instance, and it may be handled by a > method or by the classifier behavior, as could any request > coming to the instance. Any more specific specification of > how the request is routing is a semantic variation point that > could be further defined in a profile. > > > [bvs] If it is handled "as if it had directly come to the > instance" then the information on which port the request > arrived would be lost. That information is quite crucial -- > in fact, I would say that one of the basic value points of > ports is to be able to differentiate between different > sources of a request (but, without having to know who > actually sent the request). > > * A non-behavior port forwards requests along one or more > connectors to internal parts of the owning classifier. If > there are multiple internal connectors out of a port, then it > is a semantics variation point (which could be further > defined in a profile) as to whether and how a request is > routed along one or more of the outgoing connectors. (This is > actually already a semantic variation point in the spec.) > * Any request that for which there is no destination to > route it (e.g., the instance of the owning classifier is not > ready to handle a request from a behavior port or there is no > outgoing connector for a non-behavior port) then the request > is dropped. (That is, the port should not be able to handle > the request itself without forwarding it, because that would > violate the fundamental semantics of a port as a mediator.) > > -- Ed > > ________________________________ > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, March 29, 2007 10:38 AM > To: Eran Gery > Cc: Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: Issue 10597: Behavioral port > > > Eran, > > I have some comments below: > > > > [bvs] Perhaps we need another kind of port for the capability > > suggested here? After all, I don't believe that we want this kind of > > behavior in all cases of non-behavior ports. > > > Eran> Again, This is a very common case. > > Given the relatively recent introduction of ports into UML, I > am not sure that I agree that this case is "very common". > However, I can see the argument for it. The issue, in my > view, is whether it is something we want to put into > mainstream UML or into a profile. I would prefer the latter > especially since I can see a number of possible variations on > how such a capability can work. > > There are many precedents for this type of approach: For > instance, in our tools, we introduce the notion of event > priorities that have a major impact on event scheduling and > dispatching. However, since we recognized that this was not a > general requirement, we refrained from asking that this > capability be put into standard UML. We have enough > complaints about the complexity of UML as it is. > > > We shall not force users > > that want to model architecture with ports, to model behavior using > > a statemachine or activity so they can dispatch a method. Regarding > > the issue of port qualification, I think we need to allow it (e.g. > > Autosar), > > You can define a stereotype of Behavior that does the method > dispatch and does it in a way that is (a) hidden from the > user and (b) according to the needs of the application domain > > > but I would definitely not force explicit port mapping > > because of that. There are many cases where interfaces are unique > > per port, and also cases where several ports may ofer the same > > service while being addressed by the same method. What is important > > is that we shall not held that amended semantics hostage to a > > mapping formalism, while I'm not objecting to it. > > The choices you describe here illustrate my point about the > variations that can exist. We could define a general solution > that somehow realizes all these variations or we could leave > it up to profiles to solve as they deem appropriate. The > advantage of the latter is that it requires no changes to the > standard, since the current standard allows such variations. > > This brings me to a major point of principle: In cases where > the base standard does not prevent the introduction of some > new feature, I believe that we should refrain from adding the > new feature to the standard, but leave it up to a profile. > This will prevent us from gradually ending up with a > Swiss-army knife monster (although some folks claim that it > is too late already ). > > Cheers...Bran > > To: "Alan Moore" Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 3 Apr 2007 15:33:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/03/2007 15:33:46, Serialize complete at 04/03/2007 15:33:46 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Apologies, Alan, but your message looks a bit garbled, so I am not sure what you are asking. But, if it means what I think it means, then I agree: the dispatching of methods should be an SVP. My objection was to Ed's formulation about messages arriving at a port "as if they had arrived directly at the instance". If I interpret that statement at face value (which Ed is always instructing me to do when it comes to the spec), then, because things arriving directly to an instance implies bypassing ports, the implication I draw is that the arrival port information would be lost. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Alan Moore" 04/03/2007 06:58 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "Ed Seidewitz" , Subject RE: Issue 10597: Behavioral port Hi Bran, Given that why can.t the dispatch of methods based on the source Port for a Request also be an SVP? Sounds like an orthogonal issue to me. Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, April 02, 2007 10:27 PM To: Alan Moore Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Hi Alan, We had long discussions on this point when we were drawing up the submission and decided that, rather than choose a specific mechanism, this had to be a semantic variation point. This is in line with the decision to make the mechanism by which the received signal is made available to the classifier behavior an SVP. This supports what I said earlier as well as what Thomas noted: there are so many different ways that people want to use ports, that it is very difficult to come up with "the right way". Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Alan Moore" 04/02/2007 08:43 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Ed Seidewitz" cc Subject RE: Issue 10597: Behavioral port Bran, I.m intrigued by your third red paragraph: [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). How currently is the classifier Behavior informed about the source behaviour port for an incoming request? ( I had a quick look but it wasn.t obvious to me) Alan. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, March 30, 2007 9:42 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Thanks, Ed. Some replies below in red. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 03/29/2007 01:24 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 10597: Behavioral port Bran -- The current spec says clearly that a behavior port always forwards requests to the classifier behavior and that a non-behavior port always forwards requests along connectors to internal parts (see, in particular, the last two paragraphs under Semantics in Section 9.3.11). To me this seems to specifically not allow what a number of people think is an expected case: a port forwarding a request to the instance of the owning classifier but not to the classifier behavior. A profile that allowed that would seemingly violate the basic semantics of ports as defined in the spec. [bvs] You and I discussed this already but, for the benefit of the other folks on the UML 2 list, let me clarify my position. I can see the rationale for a request received on a port resulting in the activation of a method that realizes the invoked feature. But, there could be valid cases where there might be different methods realizing the same interface, which, I suspect does not fall under the "expected case". I suspect that there are other issues like this and, before we rush off and implement something for the "expected case" we really should understand the problem better. [bvs] I disagree that a profile that realizes the "expected case" would violate the basic semantics of ports, because the classifier behavior could do the all the dispatching of methods in either standard or non-standard ways. For those who would prefer not to see the hairy details of such dispatching, this could be hidden through a stereotype. And, naturally, an implementation could optimize any such overhead out, so that the result would not really require the invocation of the classifier behavior. Now, the spec also says that typing a port by a class "allows elaborate specification of the communication over a port." But it is not at all clear how one might model such an elaborate specification, or when or how it has to be compatible with the basic routing semantics described in the two paragraphs following this statement. I would agree that it should be up to profiles to provide a means for "elaborate specification" of routing. But it should also be clear how that fits into the fundamental framework of port semantics, and the fundamental port semantics should clearly allow flexibility in the specification of such routing, if desired. In my opinion, the current specification text for port is not clear on either of these things. If we really want to allow for reasonable profiles in this area, then we should keep the basic port semantics simple an clear. I would suggest the following: A behavior port forwards requests to the instance of the owning classifier. The request is then handled as if it had directly come to the instance, and it may be handled by a method or by the classifier behavior, as could any request coming to the instance. Any more specific specification of how the request is routing is a semantic variation point that could be further defined in a profile. [bvs] If it is handled "as if it had directly come to the instance" then the information on which port the request arrived would be lost. That information is quite crucial -- in fact, I would say that one of the basic value points of ports is to be able to differentiate between different sources of a request (but, without having to know who actually sent the request). A non-behavior port forwards requests along one or more connectors to internal parts of the owning classifier. If there are multiple internal connectors out of a port, then it is a semantics variation point (which could be further defined in a profile) as to whether and how a request is routed along one or more of the outgoing connectors. (This is actually already a semantic variation point in the spec.) Any request that for which there is no destination to route it (e.g., the instance of the owning classifier is not ready to handle a request from a behavior port or there is no outgoing connector for a non-behavior port) then the request is dropped. (That is, the port should not be able to handle the request itself without forwarding it, because that would violate the fundamental semantics of a port as a mediator.) -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, March 29, 2007 10:38 AM To: Eran Gery Cc: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Issue 10597: Behavioral port Eran, I have some comments below: > > [bvs] Perhaps we need another kind of port for the capability > suggested here? After all, I don't believe that we want this kind of > behavior in all cases of non-behavior ports. > Eran> Again, This is a very common case. Given the relatively recent introduction of ports into UML, I am not sure that I agree that this case is "very common". However, I can see the argument for it. The issue, in my view, is whether it is something we want to put into mainstream UML or into a profile. I would prefer the latter especially since I can see a number of possible variations on how such a capability can work. There are many precedents for this type of approach: For instance, in our tools, we introduce the notion of event priorities that have a major impact on event scheduling and dispatching. However, since we recognized that this was not a general requirement, we refrained from asking that this capability be put into standard UML. We have enough complaints about the complexity of UML as it is. > We shall not force users > that want to model architecture with ports, to model behavior using > a statemachine or activity so they can dispatch a method. Regarding > the issue of port qualification, I think we need to allow it (e.g. > Autosar), You can define a stereotype of Behavior that does the method dispatch and does it in a way that is (a) hidden from the user and (b) according to the needs of the application domain > but I would definitely not force explicit port mapping > because of that. There are many cases where interfaces are unique > per port, and also cases where several ports may ofer the same > service while being addressed by the same method. What is important > is that we shall not held that amended semantics hostage to a > mapping formalism, while I.m not objecting to it. The choices you describe here illustrate my point about the variations that can exist. We could define a general solution that somehow realizes all these variations or we could leave it up to profiles to solve as they deem appropriate. The advantage of the latter is that it requires no changes to the standard, since the current standard allows such variations. This brings me to a major point of principle: In cases where the base standard does not prevent the introduction of some new feature, I believe that we should refrain from adding the new feature to the standard, but leave it up to a profile. This will prevent us from gradually ending up with a Swiss-army knife monster (although some folks claim that it is too late already ). Cheers...Bran Subject: Issue 10597: Behavioral port Date: Wed, 28 Mar 2007 17:40:27 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597: Behavioral port Thread-index: AcdxTo+lHPc2q4T2SguEbELahwDCGw== From: "Tim Weilkiens" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2SGYhsN007858 Hi, issue 10597 isn't an easy one. There was a long discussion between Ed, Alan, and Bran some weeks ago. The issue summary below was the conclusion of that discussion (if I remind correctly). Unfortunately I've lost the email thread due a server crash. I have some remarks on the suggested resolution: > 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. The constraint is only necessary for ports that have no connectors to internal parts. >3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the > corresponding behavioral feature of the owning classifier (if there is such a method). There seems to be something wrong with the sentence ("with connectors no connectors"). Ed, what do you mean? >4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports >when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Do you mean we should include a semantic variation point? Tim -------------- Issue 10597: Behavioral port Summary: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. ----------------------------------------------------------------- Tim Weilkiens Consultant, Instructor OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 OMG Issue No: 10597 Title: Behavioral port Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s@modeldriven.com seidewitz@acm.org) Summary: Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02) Section: 9.3.11 Port Description: Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. Resolution: The discussions about this issue have led to the conclusion that the requested feature can be achieved by a profile. Disposition: Closed, no Change Subject: RE: Resolution 10597 - Closed, no change Date: Wed, 9 May 2007 15:11:26 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change thread-index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQ From: "Ed Seidewitz" To: "Tim Weilkiens" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l49J9bx3023300 Tim -- I don't agree that this issue should be closed with no change. And I don't think the discussion reached a consensus that a profile is sufficient. At the very least, I think everyone agreed that the section on ports needs to be rewritten to be clearer. The reason I hav not sent a new proposal is that we started a major project recently, and I just haven't had time. But I will write one up before the end of this RTF... -- Ed > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Wednesday, May 09, 2007 7:18 AM > To: uml2-rtf@omg.org > Subject: Resolution 10597 - Closed, no change > > We had long discussions about that issue without a > resolution. I've waited some time for > new proposals, but didn't receive any. The disposition is > closed, no change. > > @Bran: Please add the resolution to the next ballot (no. 3, I think). > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Consultant, Instructor > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > CEO Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de Subject: RE: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 08:55:25 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change Thread-Index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABh/j7A= From: "Tim Weilkiens" To: "Ed Seidewitz" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A6rjjO020527 Ok. I'll wait for new proposals. @Bran: Please do NOT add the resolution to ballot 3. Tim > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@modeldriven.com] > Sent: Wednesday, May 09, 2007 9:11 PM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > Tim -- > > I don't agree that this issue should be closed with no > change. And I don't think the discussion reached a consensus > that a profile is sufficient. At the very least, I think > everyone agreed that the section on ports needs to be > rewritten to be clearer. > > The reason I hav not sent a new proposal is that we started a > major project recently, and I just haven't had time. But I > will write one up before the end of this RTF... > > -- Ed > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Wednesday, May 09, 2007 7:18 AM > > To: uml2-rtf@omg.org > > Subject: Resolution 10597 - Closed, no change > > > > We had long discussions about that issue without a > > resolution. I've waited some time for > > new proposals, but didn't receive any. The disposition is > > closed, no change. > > > > @Bran: Please add the resolution to the next ballot (no. 3, > I think). > > > > Tim > > > > ----------------------------------------------------------------- > > Tim Weilkiens > > Consultant, Instructor > > OMG Representative, INCOSE member > > > > oose Innovative Informatik GmbH > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > CEO Bernd Schröder-Oestereich, Christian Weiss > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > Internet: www.oose.de, E-Mail: office@oose.de > > > Subject: RE: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 09:18:04 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change Thread-index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABuDpZA= From: "Alan Moore" To: "Ed Seidewitz" , "Tim Weilkiens" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A8H3Yr025353 I agree with Ed. There are also several other outstanding issues on the Ports chapter that should be rolled into such a rewrite. Alan. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, May 09, 2007 8:11 PM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Resolution 10597 - Closed, no change Tim -- I don't agree that this issue should be closed with no change. And I don't think the discussion reached a consensus that a profile is sufficient. At the very least, I think everyone agreed that the section on ports needs to be rewritten to be clearer. The reason I hav not sent a new proposal is that we started a major project recently, and I just haven't had time. But I will write one up before the end of this RTF... -- Ed > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Wednesday, May 09, 2007 7:18 AM > To: uml2-rtf@omg.org > Subject: Resolution 10597 - Closed, no change > > We had long discussions about that issue without a > resolution. I've waited some time for > new proposals, but didn't receive any. The disposition is > closed, no change. > > @Bran: Please add the resolution to the next ballot (no. 3, I think). > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Consultant, Instructor > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > CEO Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de > X-SoftScan-Status: clean (virus: 1/1/1/1, spam: 0, paranoid: 1/1) Subject: RE: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 10:28:13 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change Thread-Index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABuDpZAAADAjsA== From: "Eran Gery" To: "Alan Moore" , "Ed Seidewitz" , "Tim Weilkiens" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A8QQbf025995 I'm also objecting to this resolution. At the time Bran requested me (or anyone else) to propose a resolution, but definitely we did not mean to this kind of resolution. Eran -----Original Message----- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Thursday, May 10, 2007 11:18 AM To: Ed Seidewitz; Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Resolution 10597 - Closed, no change I agree with Ed. There are also several other outstanding issues on the Ports chapter that should be rolled into such a rewrite. Alan. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, May 09, 2007 8:11 PM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Resolution 10597 - Closed, no change Tim -- I don't agree that this issue should be closed with no change. And I don't think the discussion reached a consensus that a profile is sufficient. At the very least, I think everyone agreed that the section on ports needs to be rewritten to be clearer. The reason I hav not sent a new proposal is that we started a major project recently, and I just haven't had time. But I will write one up before the end of this RTF... -- Ed > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Wednesday, May 09, 2007 7:18 AM > To: uml2-rtf@omg.org > Subject: Resolution 10597 - Closed, no change > > We had long discussions about that issue without a > resolution. I've waited some time for > new proposals, but didn't receive any. The disposition is > closed, no change. > > @Bran: Please add the resolution to the next ballot (no. 3, I think). > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Consultant, Instructor > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > CEO Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de > Subject: RE: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 10:44:23 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change Thread-Index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABuDpZAAALiXIA== From: "Tim Weilkiens" To: "Alan Moore" , "Ed Seidewitz" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A8bt2u026973 Alan, if there are other issues we should mark them as duplicates and refer to 10597. I don't know the other issues. Could you send us a list? Tim > -----Original Message----- > From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] > Sent: Thursday, May 10, 2007 10:18 AM > To: Ed Seidewitz; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > I agree with Ed. There are also several other outstanding > issues on the Ports chapter that should be rolled into such a rewrite. > > Alan. > > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@modeldriven.com] > Sent: Wednesday, May 09, 2007 8:11 PM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > Tim -- > > I don't agree that this issue should be closed with no > change. And I don't think the discussion reached a consensus > that a profile is sufficient. At the very least, I think > everyone agreed that the section on ports needs to be > rewritten to be clearer. > > The reason I hav not sent a new proposal is that we started a > major project recently, and I just haven't had time. But I > will write one up before the end of this RTF... > > -- Ed > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Wednesday, May 09, 2007 7:18 AM > > To: uml2-rtf@omg.org > > Subject: Resolution 10597 - Closed, no change > > > > We had long discussions about that issue without a > > resolution. I've waited some time for > > new proposals, but didn't receive any. The disposition is > > closed, no change. > > > > @Bran: Please add the resolution to the next ballot (no. 3, > I think). > > > > Tim > > > > ----------------------------------------------------------------- > > Tim Weilkiens > > Consultant, Instructor > > OMG Representative, INCOSE member > > > > oose Innovative Informatik GmbH > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > CEO Bernd Schröder-Oestereich, Christian Weiss > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > Internet: www.oose.de, E-Mail: office@oose.de > > > Subject: RE: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 10:49:49 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change Thread-Index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABuDpZAAADAjsAAAlSRA From: "Tim Weilkiens" To: "Eran Gery" , "Alan Moore" , "Ed Seidewitz" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A8hIGl027342 I've withdrawn the resolution from the next ballot. However this time we should come to a new proposal for that issue. We had severals pros and cons in our last discussion. The only agreement I could extract from the email thread is that dispatching operations should be an SVP. I think that must be a new issue. Tim > -----Original Message----- > From: Eran Gery [mailto:Eran.Gery@telelogic.com] > Sent: Thursday, May 10, 2007 10:28 AM > To: Alan Moore; Ed Seidewitz; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > I'm also objecting to this resolution. At the time Bran > requested me (or anyone else) to propose a resolution, but > definitely we did not mean to this kind of resolution. > > Eran > > -----Original Message----- > From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] > Sent: Thursday, May 10, 2007 11:18 AM > To: Ed Seidewitz; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > I agree with Ed. There are also several other outstanding > issues on the Ports chapter that should be rolled into such a rewrite. > > Alan. > > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@modeldriven.com] > Sent: Wednesday, May 09, 2007 8:11 PM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > Tim -- > > I don't agree that this issue should be closed with no > change. And I don't think the discussion reached a consensus > that a profile is sufficient. At the very least, I think > everyone agreed that the section on ports needs to be > rewritten to be clearer. > > The reason I hav not sent a new proposal is that we started a > major project recently, and I just haven't had time. But I > will write one up before the end of this RTF... > > -- Ed > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Wednesday, May 09, 2007 7:18 AM > > To: uml2-rtf@omg.org > > Subject: Resolution 10597 - Closed, no change > > > > We had long discussions about that issue without a > > resolution. I've waited some time for > > new proposals, but didn't receive any. The disposition is > > closed, no change. > > > > @Bran: Please add the resolution to the next ballot (no. 3, > I think). > > > > Tim > > > > ----------------------------------------------------------------- > > Tim Weilkiens > > Consultant, Instructor > > OMG Representative, INCOSE member > > > > oose Innovative Informatik GmbH > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > CEO Bernd Schröder-Oestereich, Christian Weiss > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > Subject: RE: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 09:47:28 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution 10597 - Closed, no change Thread-index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABuDpZAAALiXIAAASbhg From: "Alan Moore" To: "Tim Weilkiens" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A8jfej027524 They're not duplicates, but related to Ports. They are 10788/89. I am also reminded that I was going to raise another, which I will now do. Alan. -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, May 10, 2007 9:44 AM To: Alan Moore; Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Resolution 10597 - Closed, no change Alan, if there are other issues we should mark them as duplicates and refer to 10597. I don't know the other issues. Could you send us a list? Tim > -----Original Message----- > From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] > Sent: Thursday, May 10, 2007 10:18 AM > To: Ed Seidewitz; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > I agree with Ed. There are also several other outstanding > issues on the Ports chapter that should be rolled into such a rewrite. > > Alan. > > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@modeldriven.com] > Sent: Wednesday, May 09, 2007 8:11 PM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > Tim -- > > I don't agree that this issue should be closed with no > change. And I don't think the discussion reached a consensus > that a profile is sufficient. At the very least, I think > everyone agreed that the section on ports needs to be > rewritten to be clearer. > > The reason I hav not sent a new proposal is that we started a > major project recently, and I just haven't had time. But I > will write one up before the end of this RTF... > > -- Ed > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Wednesday, May 09, 2007 7:18 AM > > To: uml2-rtf@omg.org > > Subject: Resolution 10597 - Closed, no change > > > > We had long discussions about that issue without a > > resolution. I've waited some time for > > new proposals, but didn't receive any. The disposition is > > closed, no change. > > > > @Bran: Please add the resolution to the next ballot (no. 3, > I think). > > > > Tim > > > > ----------------------------------------------------------------- > > Tim Weilkiens > > Consultant, Instructor > > OMG Representative, INCOSE member > > > > oose Innovative Informatik GmbH > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > CEO Bernd Schröder-Oestereich, Christian Weiss > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > Internet: www.oose.de, E-Mail: office@oose.de > > > Subject: Port Issues 10597/10788/10789 - was: Resolution 10597 - Closed, no change Date: Thu, 10 May 2007 11:00:03 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Port Issues 10597/10788/10789 - was: Resolution 10597 - Closed, no change Thread-Index: AceSKuIadK+pVntJSMmFQeKuwYlbBAAQrBXQABuDpZAAALiXIAAASbhgAAAon2A= From: "Tim Weilkiens" To: "Alan Moore" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A8rQWQ027904 Great. I summarize 10597/10788/10789 to have all issues in mind for our discussion. Sorry for the redundant information. 10597 Currently, the semantics of ports may be summarized as follows: 1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port." 2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port -- requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost." Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port. Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect. Suggested resolution: 1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports. 2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior. 3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method). 4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method. 10788 Where the spec currently says: "If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port." Consider whether this should in fact be defined as a semantic variation point. 10789 The spec for Port.provided:Interface says: "References the interfaces specifying the set of operations and receptions that the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface." This would seem to indicate that a Port typed by an Interface cannot have more than one provided interface. Clarify that this was the intention, or fix if not. Tim > -----Original Message----- > From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] > Sent: Thursday, May 10, 2007 10:47 AM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > They're not duplicates, but related to Ports. They are > 10788/89. I am also reminded that I was going to raise > another, which I will now do. > Alan. > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Thursday, May 10, 2007 9:44 AM > To: Alan Moore; Ed Seidewitz > Cc: uml2-rtf@omg.org > Subject: RE: Resolution 10597 - Closed, no change > > Alan, > > if there are other issues we should mark them as duplicates > and refer to 10597. > I don't know the other issues. Could you send us a list? > > Tim > > > -----Original Message----- > > From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] > > Sent: Thursday, May 10, 2007 10:18 AM > > To: Ed Seidewitz; Tim Weilkiens > > Cc: uml2-rtf@omg.org > > Subject: RE: Resolution 10597 - Closed, no change > > > > I agree with Ed. There are also several other outstanding > > issues on the Ports chapter that should be rolled into such > a rewrite. > > > > Alan. > > > > -----Original Message----- > > From: Ed Seidewitz [mailto:ed-s@modeldriven.com] > > Sent: Wednesday, May 09, 2007 8:11 PM > > To: Tim Weilkiens > > Cc: uml2-rtf@omg.org > > Subject: RE: Resolution 10597 - Closed, no change > > > > Tim -- > > > > I don't agree that this issue should be closed with no > > change. And I don't think the discussion reached a consensus > > that a profile is sufficient. At the very least, I think > > everyone agreed that the section on ports needs to be > > rewritten to be clearer. > > > > The reason I hav not sent a new proposal is that we started a > > major project recently, and I just haven't had time. But I > > will write one up before the end of this RTF... > > > > -- Ed > > > > > -----Original Message----- > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > Sent: Wednesday, May 09, 2007 7:18 AM > > > To: uml2-rtf@omg.org > > > Subject: Resolution 10597 - Closed, no change > > > > > > We had long discussions about that issue without a > > > resolution. I've waited some time for > > > new proposals, but didn't receive any. The disposition is > > > closed, no change. > > > > > > @Bran: Please add the resolution to the next ballot (no. 3, > > I think). > > > > > > Tim > > > > > > ----------------------------------------------------------------- > > > Tim Weilkiens > > > Consultant, Instructor > > > OMG Representative, INCOSE member > > > > > > oose Innovative Informatik GmbH > > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 > Hamburg, Germany > > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > > CEO Bernd Schröder-Oestereich, Christian Weiss > > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > To: "Ed Seidewitz" Cc: "Tim Weilkiens" , uml2-rtf@omg.org Subject: RE: Resolution 10597 - Closed, no change X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Mon, 14 May 2007 08:53:36 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 05/14/2007 08:53:39, Serialize complete at 05/14/2007 08:53:39 Ed and Tim, I will keep this one on the back burner for a little bit longer. When do you think you can submit a new proposal? Thanks, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Ed Seidewitz" 05/09/2007 03:11 PM To "Tim Weilkiens" cc Subject RE: Resolution 10597 - Closed, no change Tim -- I don't agree that this issue should be closed with no change. And I don't think the discussion reached a consensus that a profile is sufficient. At the very least, I think everyone agreed that the section on ports needs to be rewritten to be clearer. The reason I hav not sent a new proposal is that we started a major project recently, and I just haven't had time. But I will write one up before the end of this RTF... -- Ed > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Wednesday, May 09, 2007 7:18 AM > To: uml2-rtf@omg.org > Subject: Resolution 10597 - Closed, no change > > We had long discussions about that issue without a > resolution. I've waited some time for > new proposals, but didn't receive any. The disposition is > closed, no change. > > @Bran: Please add the resolution to the next ballot (no. 3, I think). > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Consultant, Instructor > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > CEO Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de > Subject: Issue 10597 [RE: Draft Ballot #3] Date: Sat, 9 Feb 2008 17:03:23 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 10597 [RE: Draft Ballot #3] thread-index: AchlHHv1+Cgo6EuUTJyZKsr5WTBM5gGSsBmg From: "Ed Seidewitz" To: I would like to request that the proposed resolution of issue 10597 be withdrawn from Ballot #3. I would like to take a little more time to consider the current situation with the issue under discussion here before we vote on it. If I can.t get my thoughts organized in time for Ballot #4, I will not oppose the .closed no change. resolution at that time. -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, February 01, 2008 4:44 PM To: uml2-rtf@omg.org Subject: Draft Ballot #3 Attached, please find the first draft of ballot 3, due to become official in 2 weeks. So, you have 2 weeks to review these proposed resolutions and raise objections to them. Thanks to Thomas in particular, we have an exceptionally large batch of proposed resolutions. It will take a fair amount of time to review them all and some of them are likely to be critical and contentious, so please do not leave your review until the very end. Once a resolution has been adopted, there is no real way of getting back. I apologize for the irregular format for many of the resolutions, but that is how I got them (you will be doing me a great favour in the future, if you used the official format for your resolution proposals -- this is why there is a blank issue resolution page at the end of the draft ballot). I will clean them up for the official ballot (a lot of tedious work), but I believe that this is still sufficient for you to understand what is being proposed. Please raise any concerns you have via e-mail. Regards...Bran Selic