Issue 15145: Modeling sent messages in State Machines (uml2-rtf) Source: Fundacion Tecnalia Research and Innovation (Mr Adrian Noguero, adrian.noguero(at)tecnalia.com) Nature: Enhancement Severity: Significant Summary: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference Resolution: Revised Text: Actions taken: March 24, 2010: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. Subject: RE: issue 15145 -- UML 2 RTF issue Date: Wed, 7 Apr 2010 15:58:23 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWUVmBTUxELG/vTbyma0GXe+8hbwACERtw From: "BERNARD, Yves" To: , X-OriginalArrivalTime: 07 Apr 2010 13:58:24.0043 (UTC) FILETIME=[63A1CFB0:01CAD65A] From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=dLRLJHTIBqu7jyfv3wsnk35RTxUq25DKoM8xxgx96Ew=; b=qS4n88P2N+ya+h64lYNllI6FNzmMlmbXfr/fsDJyXD+D8SQQXhXno/H+VVRQs8OjXz Y2o9uQPMwo+1/kx/RJfq7uH6t+SiaHstcaDEEU9MPLoxF4prxqiIsrZIeeIcXVhXwf4R 9HGspq5wTiuqY0t/sU0TpNQs/77VAULxkjuRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=SNHyepgfuWM+gxzbfzbNTu5fN20S4ertQT9c/9yrlprSd7oXnCKJ73/BUpnh4wgQdG giO5s0vQ3HSA7S/k+XrAP4b06c7IxDzMZjFN9i1mHJiCCDxdYE844TWTyN85A4jRE9jW Yno4ho+vifupbOh1CigXX8zTvMMi3vtI8dHXg= Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 7 Apr 2010 10:17:54 -0400 X-Google-Sender-Auth: c380b2b53162e4a9 Subject: Re: issue 15145 -- UML 2 RTF issue To: "BERNARD, Yves" Cc: issues@omg.org, uml2-rtf@omg.org Yves, I think you are reading too much into the term "through" here. I don't think the intent was to say that the behavior sees what is beyond the port. Instead, I think the complaint was , for actions in state machines transitions, there is no way of specifying that a message to be sent is directed to a particular port. For example, see figure 15.44, which has two send operations specified. However, if these messages are intended to be sent via specific ports, there is no standard way to specify that. In contrast, in Interactions you can be quite specific about which messages are going through which ports (see, for example, figure 14.21 in the spec). Cheers...Bran On Wed, Apr 7, 2010 at 9:58 AM, BERNARD, Yves wrote: From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "issues@omg.org" , "uml2-rtf@omg.org" Date: Wed, 7 Apr 2010 10:40:51 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXc0q4sKvmQgFSniEunizTJD41gAAilZg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o37EVO8A004475 Bran, > I think you are reading too much into the term "through" > here. I don't think the intent was to say that the behavior > sees what is beyond the port. Instead, I think the > complaint was , for actions in state machines transitions, > there is no way of specifying that a message to be sent is > directed to a particular port. For example, see figure > 15.44, which has two send operations specified. However, if > these messages are intended to be sent via specific ports, > there is no standard way to specify that. That's how I read the issue also. You can do with the onPort property of InvocationAction, see Section 9.3.9. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Wed, 7 Apr 2010 11:14:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQ From: "Ed Seidewitz" To: "Bran Selic" , "BERNARD, Yves" Cc: , Bran . You are right, this is a real issue. Now, the Composite Structure clause does add an .onPort. property to InvocationAction (see Subclause 9.3.9), which I had thought addressed this issue. However, this property is described as .An optional port of the receiver object on which the behavioral feature is invoked. (emphasis added). That is, what is specified is a port owned by the object receiving the message, rather than the port on the sending object .through. which the message is to be sent. The current concept of onPort is thus misguided, since the whole point of ports is that the receiving object is determined by the connection between the ports, not by the invoking action. Syntactically, I think Invocation::onPort is the right thing (and there is even a notation given for using it: one adds the phrase .via . to the invocation action label). But I think the semantics needs to be changed so that it means sending a message through a required interface of a .local. port. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, April 07, 2010 10:18 AM To: BERNARD, Yves Cc: issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Yves, I think you are reading too much into the term "through" here. I don't think the intent was to say that the behavior sees what is beyond the port. Instead, I think the complaint was , for actions in state machines transitions, there is no way of specifying that a message to be sent is directed to a particular port. For example, see figure 15.44, which has two send operations specified. However, if these messages are intended to be sent via specific ports, there is no standard way to specify that. In contrast, in Interactions you can be quite specific about which messages are going through which ports (see, for example, figure 14.21 in the spec). Cheers...Bran On Wed, Apr 7, 2010 at 9:58 AM, BERNARD, Yves wrote: From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: issue 15145 -- UML 2 RTF issue Date: Wed, 7 Apr 2010 17:25:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAAChbDA= From: "BERNARD, Yves" To: "Ed Seidewitz" , "Bran Selic" Cc: , X-OriginalArrivalTime: 07 Apr 2010 15:25:11.0822 (UTC) FILETIME=[83B5D2E0:01CAD666] SendSignalAction and SendObjectAction both have a .target. property to specify .The target object to which the object is sent.. Do you see anything preventing this target to be a port? Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 7 avril 2010 17:14 À: Bran Selic; BERNARD, Yves Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Bran . You are right, this is a real issue. Now, the Composite Structure clause does add an .onPort. property to InvocationAction (see Subclause 9.3.9), which I had thought addressed this issue. However, this property is described as .An optional port of the receiver object on which the behavioral feature is invoked. (emphasis added). That is, what is specified is a port owned by the object receiving the message, rather than the port on the sending object .through. which the message is to be sent. The current concept of onPort is thus misguided, since the whole point of ports is that the receiving object is determined by the connection between the ports, not by the invoking action. Syntactically, I think Invocation::onPort is the right thing (and there is even a notation given for using it: one adds the phrase .via . to the invocation action label). But I think the semantics needs to be changed so that it means sending a message through a required interface of a .local. port. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, April 07, 2010 10:18 AM To: BERNARD, Yves Cc: issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Yves, I think you are reading too much into the term "through" here. I don't think the intent was to say that the behavior sees what is beyond the port. Instead, I think the complaint was , for actions in state machines transitions, there is no way of specifying that a message to be sent is directed to a particular port. For example, see figure 15.44, which has two send operations specified. However, if these messages are intended to be sent via specific ports, there is no standard way to specify that. In contrast, in Interactions you can be quite specific about which messages are going through which ports (see, for example, figure 14.21 in the spec). Cheers...Bran On Wed, Apr 7, 2010 at 9:58 AM, BERNARD, Yves wrote: From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "issues@omg.org" , "uml2-rtf@omg.org" Date: Wed, 7 Apr 2010 11:30:57 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o37FMmxv025828 rEdoEsis added). I think this is just a wording issue. The description says: In addition to targeting an object, invocation actions can also invoke behavioral features on ports from where the invocation requests are routed onwards on links deriving from attached connectors. Invocation actions may also be sent to a target via a given port, either on the sending object or on another object. The action can send invoke behavior features of ports on the same runtime object as the action execution. This was the intention in any case. The description doesn't seem to limit the action to be taken in the same runtime object as the target, however. From: "Bock, Conrad" To: "issues@omg.org" , "uml2-rtf@omg.org" Date: Wed, 7 Apr 2010 11:30:57 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o37FMmxv025828 Ed, rsis added). I think this is just a wording issue. The description says: In addition to targeting an object, invocation actions can also invoke behavioral features on ports from where the invocation requests are routed onwards on links deriving from attached connectors. Invocation actions may also be sent to a target via a given port, either on the sending object or on another object. The action can send invoke behavior features of ports on the same runtime object as the action execution. This was the intention in any case. The description doesn't seem to limit the action to be taken in the same runtime object as the target, however. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Wed, 7 Apr 2010 11:40:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAAChbDAAAIJeEA== From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: , Yves . The problem is with the typing. The invoked behavior has to be a feature of the target object. However, if you are trying to send the message through a port of the sending object, the feature you want to invoke will be on a required interface of the port, not a provided interface. This means that the port type will have a usage dependency on the required interface, not a realization, and the features of the required interface will not be features of the port type. What is needed is new rules that say that, if an invocation action has an onPort value, then the target object type is on of the realized interfaces of the port, rather than the type of the port itself. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 07, 2010 11:25 AM To: Ed Seidewitz; Bran Selic Cc: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue SendSignalAction and SendObjectAction both have a .target. property to specify .The target object to which the object is sent.. Do you see anything preventing this target to be a port? Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 7 avril 2010 17:14 À: Bran Selic; BERNARD, Yves Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Bran . You are right, this is a real issue. Now, the Composite Structure clause does add an .onPort. property to InvocationAction (see Subclause 9.3.9), which I had thought addressed this issue. However, this property is described as .An optional port of the receiver object on which the behavioral feature is invoked. (emphasis added). That is, what is specified is a port owned by the object receiving the message, rather than the port on the sending object .through. which the message is to be sent. The current concept of onPort is thus misguided, since the whole point of ports is that the receiving object is determined by the connection between the ports, not by the invoking action. Syntactically, I think Invocation::onPort is the right thing (and there is even a notation given for using it: one adds the phrase .via . to the invocation action label). But I think the semantics needs to be changed so that it means sending a message through a required interface of a .local. port. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, April 07, 2010 10:18 AM To: BERNARD, Yves Cc: issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Yves, I think you are reading too much into the term "through" here. I don't think the intent was to say that the behavior sees what is beyond the port. Instead, I think the complaint was , for actions in state machines transitions, there is no way of specifying that a message to be sent is directed to a particular port. For example, see figure 15.44, which has two send operations specified. However, if these messages are intended to be sent via specific ports, there is no standard way to specify that. In contrast, in Interactions you can be quite specific about which messages are going through which ports (see, for example, figure 14.21 in the spec). Cheers...Bran On Wed, Apr 7, 2010 at 9:58 AM, BERNARD, Yves wrote: From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 7 Apr 2010 11:43:27 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAAChbDAAAKyF8A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o37FXx3q028158 Yves, you see anything preventing this target to be a > port? No, but some implementations do not have runtime port objects, ie, no values of the ports as properties (I think SDL execution is like this). The onPort association was added for these cases. The target is an instance of the class owning the port. The action execution can be inside the port-owning object, sending a message out, or outside the object sending a message in. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Wed, 7 Apr 2010 11:46:08 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AA== From: "Ed Seidewitz" To: "Bock, Conrad" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o37FaTX2028749 Conrad -- Description aside, there is an explicit constraint that says "[1] The onPort must be a port on the receiver object." The description may express what the intent was, but this is not supported by either the constraint or the semantic specification. And I am not sure how the same meta-property can be used to handle invocations through ports of either the sending or receiving object. The typing of the target object is going to be different. I guess the semantics could depend on which type you used on the target input pin. -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Wednesday, April 07, 2010 11:31 AM To: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, rsis added). I think this is just a wording issue. The description says: In addition to targeting an object, invocation actions can also invoke behavioral features on ports from where the invocation requests are routed onwards on links deriving from attached connectors. Invocation actions may also be sent to a target via a given port, either on the sending object or on another object. The action can send invoke behavior features of ports on the same runtime object as the action execution. This was the intention in any case. The description doesn't seem to limit the action to be taken in the same runtime object as the target, however. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Wed, 7 Apr 2010 12:04:32 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAAChbDAAAKyF8AAAakCw From: "Ed Seidewitz" To: "Bock, Conrad" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o37FswIi002856 Conrad -- I think one of the real problems here is that it is not at all clear how the addition of onPort to invocation action effects the detailed (and different) constraints given on the subclasses of InvocationAction in Clause 11 (Actions). For example, suppose the invocation action is a call operation action. Then the operation being called has to be an operation of the type of the target object of the call. Suppose that this action is inside a port-owning object and references a port of the type of that object. It would seem that the type of the target object of the action would have to be the very object that the action is inside, since this is the "receiving object" of the invocation. However, the invoked operation would then have to be on an operation of the object the action is inside, which is certainly not what is intended by "calling though" the required interface of a port! Another problem is that the semantics in 9.3.9 refers to "the object owning this port" and "port identity". However, in UML objects don't own ports, classifiers do. An ports don't have independent identity, they are properties of the classifiers of objects -- only the objects have identity. So, the intent may have been to allow SDL-like semantics, but 9.3.9 is in the Composite Structure clause, not the Component clause, and I don't think the semantics really works in that context. -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Wednesday, April 07, 2010 11:43 AM To: uml2-rtf@omg.org; issues@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Yves, you see anything preventing this target to be a > port? No, but some implementations do not have runtime port objects, ie, no values of the ports as properties (I think SDL execution is like this). The onPort association was added for these cases. The target is an instance of the class owning the port. The action execution can be inside the port-owning object, sending a message out, or outside the object sending a message in. Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=Ql2aH8IGAjIXtLabmO48FvE/Hf+BzgUwxE2B1zg1CBY=; b=h/bQ/ZdTz8b8kDa03+6/hafj31oOrKbvIQMUqBzTNI3j2r9cfylwoHZIpB8Tpp2Eww cCITkbFVNFH+Jk6C8fYXBM4jvVP6NMwysK3cN4DQ8L1cojo1YSQPkBowONbRilpgl8iz 4YwgSA/PHil6SgRvy84FKEIKQLb8kv6es8mFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=htJ3x6AizO8OoYd3g/f0ZP5HFOLmj7/ZwqlOfjlDzHQOfi4TBbVXAhE61mYu50pKNh piT9q7/bRRqhnVYZzwB5Ogv5r4TiPjvt+3EnHisUG5PI8YtROgED+V0SwmlK77JLJLA3 CfBHPj6mKKFZ+oLsRw1MNZXlUk9dQGBxNNOmc= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 8 Apr 2010 09:26:49 +0200 X-Google-Sender-Auth: 1ca5420e8ac0a6f2 Subject: Re: issue 15145 -- UML 2 RTF issue To: Ed Seidewitz Cc: "BERNARD, Yves" , issues@omg.org, uml2-rtf@omg.org Ed, Yves has a point. Remember that ports have two interpretations going back to their respective UML-RT versus SDL origins. In the UML-RT case, ports are actual objects whose type is NOT defined by either the required or provided interface supported by the port. Instead, it is a system defined type. This system-defined type is such that it provides the features of the required interface of the port (e.g., a reception). Consequently, sending a signal to the port would have the effect that Yves is talking about. (The spec does not go into this type of detail about the type because I didn't want to saddle the spec with too much UML-RT-specific stuff -- perhaps I should have. However, there is certainly room for this interpretation in there, and that is by design.) In the SDL case, ports are not objects, but merely routing identifies, and the type of a port is defined by its provided interface -- this is the case you are talking about. Cheers...Bran On Wed, Apr 7, 2010 at 5:40 PM, Ed Seidewitz wrote: Yves . The problem is with the typing. The invoked behavior has to be a feature of the target object. However, if you are trying to send the message through a port of the sending object, the feature you want to invoke will be on a required interface of the port, not a provided interface. This means that the port type will have a usage dependency on the required interface, not a realization, and the features of the required interface will not be features of the port type. What is needed is new rules that say that, if an invocation action has an onPort value, then the target object type is on of the realized interfaces of the port, rather than the type of the port itself. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 07, 2010 11:25 AM To: Ed Seidewitz; Bran Selic Cc: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue SendSignalAction and SendObjectAction both have a .target. property to specify .The target object to which the object is sent.. Do you see anything preventing this target to be a port? Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 7 avril 2010 17:14 À: Bran Selic; BERNARD, Yves Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Bran . You are right, this is a real issue. Now, the Composite Structure clause does add an .onPort. property to InvocationAction (see Subclause 9.3.9), which I had thought addressed this issue. However, this property is described as .An optional port of the receiver object on which the behavioral feature is invoked. (emphasis added). That is, what is specified is a port owned by the object receiving the message, rather than the port on the sending object .through. which the message is to be sent. The current concept of onPort is thus misguided, since the whole point of ports is that the receiving object is determined by the connection between the ports, not by the invoking action. Syntactically, I think Invocation::onPort is the right thing (and there is even a notation given for using it: one adds the phrase .via . to the invocation action label). But I think the semantics needs to be changed so that it means sending a message through a required interface of a .local. port. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, April 07, 2010 10:18 AM To: BERNARD, Yves Cc: issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Yves, I think you are reading too much into the term "through" here. I don't think the intent was to say that the behavior sees what is beyond the port. Instead, I think the complaint was , for actions in state machines transitions, there is no way of specifying that a message to be sent is directed to a particular port. For example, see figure 15.44, which has two send operations specified. However, if these messages are intended to be sent via specific ports, there is no standard way to specify that. In contrast, in Interactions you can be quite specific about which messages are going through which ports (see, for example, figure 14.21 in the spec). Cheers...Bran On Wed, Apr 7, 2010 at 9:58 AM, BERNARD, Yves wrote: From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=8JB3F6V1fGF6WiXIJr5+BJxejNymGZN7XGVxqZ/9HOU=; b=jj3BX6Q0LI3Rky01Wr+PJStUyHWdo8hNy/GGuiLtZv4yeVthfl8+7PsfTLAytxOBIT 0gOBLhxYLlO8Qklilae4mbBuTi/kEP++QwElcv6feu9i8VnMGvsBLXo4Yodp7n3ccsTf Ric+YIe7BI3URzH8OhdVpyqMfsl71FTiZIh+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=bfTopQaPyRykjdyKACsUKNTjQo+F5Ya/xVpXYas00vh91USbOs4e3n9MNNHH4XD/hJ DuaLR06Wplpqz+TMvVkypJJufAOESND1oOfzXdKIaQvkraj8utdGeZuIdb60qIEYGjm+ dt7ZNLSlTot2dOfVZFVWRyLvDsHZrkrrIEfbI= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 8 Apr 2010 09:27:44 +0200 X-Google-Sender-Auth: 4320877cf7bf095d Subject: Re: issue 15145 -- UML 2 RTF issue To: "Bock, Conrad" Cc: "uml2-rtf@omg.org" , "issues@omg.org" Exactly. This is what I meant in my last message....Bran On Wed, Apr 7, 2010 at 5:43 PM, Bock, Conrad wrote: Yves, > SendSignalAction and SendObjectAction both have a $(Cta (Brget $(D (B > property to specify $(CTh (Be target object to which the object > is sent $(D. (BDo you see anything preventing this target to be a > port? No, but some implementations do not have runtime port objects, ie, no values of the ports as properties (I think SDL execution is like this). The onPort association was added for these cases. The target is an instance of the class owning the port. The action execution can be inside the port-owning object, sending a message out, or outside the object sending a message in. Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=O3igXWvd9R9xufhnd/grcSFhOkS8yoZygNguXfoUWHA=; b=T+eKmiBUpx4c74JLNG7aEAUG9s7uMe0UEfc6Riqz52QfCdmI/AUFcS4Bt80MXtdusj fbT5z8bG6BeyeE0G0MUnqv68EOLKLZH9VZ/FT/Yu/Lmh4a+BiQD3IZ9INfFMcbkGFgfW dWOJEQWDKEzlJ/s8/JEMLM0hkVqbL57lY9YIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=gHbF3dP7w26hjx+5WXKl80ddyxzWBjsDKjuUKGx1hOWcOq1iSGDPOdykKhwa5AjRc3 8pJYHh6l21bu2WFh6inLOaZ1rCnclEJj36SWPQu3PXmgN5UuWCKOU3Kpi45tO7H38Drs EUA2+fcxycFB5Z+DF6MiKkL+r85uw5nZgZU08= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 8 Apr 2010 09:32:16 +0200 X-Google-Sender-Auth: d6f3b5081ce3097c Subject: Re: issue 15145 -- UML 2 RTF issue To: Ed Seidewitz Cc: "Bock, Conrad" , uml2-rtf@omg.org, issues@omg.org Ed, Please have a look at my previous e-mail about the two interpretations of port. However, I am mystified by your statement: On Wed, Apr 7, 2010 at 6:04 PM, Ed Seidewitz wrote: Conrad -- Another problem is that the semantics in 9.3.9 refers to "the object owning this port" and "port identity". However, in UML objects don't own ports, classifiers do. Huh? Of course UML objects own ports, see figure 9.4. An ports don't have independent identity, they are properties of the classifiers of objects -- only the objects have identity. In the UML-RT interpretation, ports are objects and, therefore, do have an identity. I don't see anything in the spec that prevents that interpretation -- which, as I said, is by design. Cheers...Bran Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 05:14:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrW7PZcNysEbA97QzW8rFTkmuSuOwAC9HTw From: "Ed Seidewitz" To: "Bran Selic" Cc: "BERNARD, Yves" , , Bran . Once again, we have a problem of what, perhaps, was intended for UML 2.0 five years ago as opposed to what UML 2 is today, as best can be determined by reading the current spec. While it is useful to understand the intent in order to understand how we got where we are today, it is high time we took the UML spec seriously and expect it to stand consistently on its own. And, in this area, I really don.t think it stands up to detailed scrutiny. When you put Subclause 9.3.9 on Invocation Action together with the base definition for it and its subclasses in Subclause 11, I cannot see any way to come up with a consistent interpretation for sending a message to a port as a target object. (This would be a lot clearer to understand . and fix -- if things were not spread over multiple merge increments of InvocationAction, which is just another reason why the UML 2.5 spec simplification is so important.) In order to get a target object to feed into a send signal action or call operation action, one would need to read the port as a structural feature. And doing this using read structural feature action would treat the port as an attribute, giving an object of the port type. And one thing that is clear from the definition of Port in Subclause 9.3.11 is that the type of a port realizes the provided interfaces of the port. Hence, the available behavioral features of an object obtained from a port (receptions or operations) will be those from the provided interfaces, not the required interfaces. I would be very interested to hear of you can come up with a different interpretation of how this would work, based only on what is in the UML spec, without reference to any intended or past practices with UML-RT, SDL or anything else. I certainly have not been able to. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, April 08, 2010 3:27 AM To: Ed Seidewitz Cc: BERNARD, Yves; issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Ed, Yves has a point. Remember that ports have two interpretations going back to their respective UML-RT versus SDL origins. In the UML-RT case, ports are actual objects whose type is NOT defined by either the required or provided interface supported by the port. Instead, it is a system defined type. This system-defined type is such that it provides the features of the required interface of the port (e.g., a reception). Consequently, sending a signal to the port would have the effect that Yves is talking about. (The spec does not go into this type of detail about the type because I didn't want to saddle the spec with too much UML-RT-specific stuff -- perhaps I should have. However, there is certainly room for this interpretation in there, and that is by design.) In the SDL case, ports are not objects, but merely routing identifies, and the type of a port is defined by its provided interface -- this is the case you are talking about. Cheers...Bran On Wed, Apr 7, 2010 at 5:40 PM, Ed Seidewitz wrote: Yves . The problem is with the typing. The invoked behavior has to be a feature of the target object. However, if you are trying to send the message through a port of the sending object, the feature you want to invoke will be on a required interface of the port, not a provided interface. This means that the port type will have a usage dependency on the required interface, not a realization, and the features of the required interface will not be features of the port type. What is needed is new rules that say that, if an invocation action has an onPort value, then the target object type is on of the realized interfaces of the port, rather than the type of the port itself. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 07, 2010 11:25 AM To: Ed Seidewitz; Bran Selic Cc: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue SendSignalAction and SendObjectAction both have a .target. property to specify .The target object to which the object is sent.. Do you see anything preventing this target to be a port? Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 7 avril 2010 17:14 À: Bran Selic; BERNARD, Yves Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Bran . You are right, this is a real issue. Now, the Composite Structure clause does add an .onPort. property to InvocationAction (see Subclause 9.3.9), which I had thought addressed this issue. However, this property is described as .An optional port of the receiver object on which the behavioral feature is invoked. (emphasis added). That is, what is specified is a port owned by the object receiving the message, rather than the port on the sending object .through. which the message is to be sent. The current concept of onPort is thus misguided, since the whole point of ports is that the receiving object is determined by the connection between the ports, not by the invoking action. Syntactically, I think Invocation::onPort is the right thing (and there is even a notation given for using it: one adds the phrase .via . to the invocation action label). But I think the semantics needs to be changed so that it means sending a message through a required interface of a .local. port. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, April 07, 2010 10:18 AM To: BERNARD, Yves Cc: issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Yves, I think you are reading too much into the term "through" here. I don't think the intent was to say that the behavior sees what is beyond the port. Instead, I think the complaint was , for actions in state machines transitions, there is no way of specifying that a message to be sent is directed to a particular port. For example, see figure 15.44, which has two send operations specified. However, if these messages are intended to be sent via specific ports, there is no standard way to specify that. In contrast, in Interactions you can be quite specific about which messages are going through which ports (see, for example, figure 14.21 in the spec). Cheers...Bran On Wed, Apr 7, 2010 at 9:58 AM, BERNARD, Yves wrote: From my point of view, according to the encapsulation principle, one doesn.t send a message .through. a port but .to. a port the final destination of the message is not decided at the level of the .send. action but according to the connectors that are linked to the port. Proposed resolution: close, no change. Yves De : Juergen Boldt [mailto:juergen@omg.org] Envoyé mercredi 7 avril 2010 14:53 À: issues@omg.org; uml2-rtf@omg.org Objet : issue 15145 -- UML 2 RTF issue From: webmaster@omg.org Date: 24 Mar 2010 03:25:24 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adrian Noguero Company: European Software Institute mailFrom: adrian.noguero@esi.es Notification: Yes Specification: UML Section: 15 FormalNumber: ptc/2009-09-09 Version: 2.3 RevisionDate: 09/09/2009 Page: 525 and following Title: Modeling sent messages in State Machines Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port. I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. 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 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=cG4zn2S4RfkVr+okSdGEaC+HXXZNgdPH+qF1aIOyHOw=; b=th/5AZSTNAr/tU9zj7x5e5FDsiBpHdl9OgRrcUDjtCxlljdeoVG0zkAhje/33prkcd 7QwYfdqlXMNGfvhr2XAr/vNK8ZCiVNRButWedTLClSIAC+hAiDdGn7DKqfrQrvuzxsla +ZXqOr9x01F4tYDN2tzmLlqPxSxB0lH0z5ba0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=dTf85wdIy0QMgC/zfC5A1WgMWhO4vkiRIbwQoQEbdM+zA+gI0wSS8v6fYGH6f1YfWh ztSn0xwJh3Y0Uyngs6ya0uphR1ZOtKjq7CBd+Wek/vthUYQiurgu0upiZYOvE7C8ybqr +7FxdBJIEKSGWkPpPqTJfvyWzbP4ThDqHr42I= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 8 Apr 2010 11:41:40 +0200 X-Google-Sender-Auth: edec0e6b08b99632 Subject: Re: issue 15145 -- UML 2 RTF issue To: Ed Seidewitz Cc: "BERNARD, Yves" , issues@omg.org, uml2-rtf@omg.org It is true that the spec has undergone some changes in the interval since we put this thing together and that it needs cleaning up. However, as I said, I really did not want to clutter the spec with the specifics of UML-RT, but wanted to make sure that there was adequate room to retain those semantics through a profile. Some explanations below: On Thu, Apr 8, 2010 at 11:14 AM, Ed Seidewitz wrote: Bran . Once again, we have a problem of what, perhaps, was intended for UML 2.0 five years ago as opposed to what UML 2 is today, as best can be determined by reading the current spec. While it is useful to understand the intent in order to understand how we got where we are today, it is high time we took the UML spec seriously and expect it to stand consistently on its own. [bvs] The implication is that we did not take it seriously at the time. I assure you that we did, but, undeniably, we made mistakes. Hindisght is 20/20. And, in this area, I really don.t think it stands up to detailed scrutiny. When you put Subclause 9.3.9 on Invocation Action together with the base definition for it and its subclasses in Subclause 11, I cannot see any way to come up with a consistent interpretation for sending a message to a port as a target object. (This would be a lot clearer to understand . and fix -- if things were not spread over multiple merge increments of InvocationAction, which is just another reason why the UML 2.5 spec simplification is so important.) [bvs] Sublcause 9.3.9 was put in by Thomas Weigert, who was somewhat more aggressive in putting in SDL semantics into this than I was. I do agree that thi section is flawed. But, read on... In order to get a target object to feed into a send signal action or call operation action, one would need to read the port as a structural feature. And doing this using read structural feature action would treat the port as an attribute, giving an object of the port type. And one thing that is clear from the definition of Port in Subclause 9.3.11 is that the type of a port realizes the provided interfaces of the port. Hence, the available behavioral features of an object obtained from a port (receptions or operations) will be those from the provided interfaces, not the required interfaces. [bvs] Actually, the way you achieve message sending in UML-RT is by invoking the appropriate send operation on the port object -- which is a feature of the system-defined type. (There are a number of ways of realizing this, but one is to provide such a feature for each behavioural feature of the required interface of the port.) So, in this case, we do not even use a SendSignalAction for this purpose (I did not want to go into such detail in my previous message, but now it is necessary.) Instead, we use a CallOperationAction (or some such equivalent). [bvs] Note that such a port can still declare that it realizes its provided interface. However, UML does not specify how "realize" is realized. As we know, it can be done by delegation or by some behaviour that exists outside the port itself. [bvs] In a sense, UML-RT behaviour ports always have two sides. The outward-facing side is what you see when you declare the port as having a provided and required interface. The inward-facing side has additional features, corresponding to the required interface. The result, as you can see, is a system-defined type that is a composite of the required and provided interfaces of the port (as well as some other system-defined features, such as operations that defer a message arriving on a port). It is actually quite simple, but, I hope you see why I thought it too specific to include in the general UML 2 spec. I would be very interested to hear of you can come up with a different interpretation of how this would work, based only on what is in the UML spec, without reference to any intended or past practices with UML-RT, SDL or anything else. I certainly have not been able to. [bvs] I hope the above explanation is clear. To repeat, I do not think it appropriate to include this type of detail in the UML 2 spec, but I do think that it is fundamental that, whatever changes are made, this type of refinement is not somehow eliminated. As things currently stand, I do not see that there is anything in UML 2 that precludes it. Which is how it should be. Cheers...Bran Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 05:56:57 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrW7bFD+3wu0UCLR2G9lxYD6t6zwQADkXnw From: "Ed Seidewitz" To: "Bran Selic" Cc: "Bock, Conrad" , , Bran . Figure 9.4 shows EncapsulatedClassifier having an ownedPort association with Port. What said was .However, in UML objects don.t own ports, classifiers do.. That is exactly what Figure 9.4 shows . classifiers owning ports. An object in UML no more .owns. its ports than it .owns. its attributes . since ports in UML 2 are attributes (EncapsulatedClassifier::ownedPort subsets EncapsulatedClassifier::ownedAttribute). Every instance of an encapsulated classifier shares the same set of port definitions. According to Subclause 9.3.11, .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. These instances are referred to as .interaction points. and provide unique references.. Thus, an .interaction point. object held in the port slot of an instance of an encapsulated classifier has an identity, not the port itself. This may seem like a pedantic distinction, but it is important. It is not enough to point just to the port, as is done with InvocationAction::onPort, and expect there to be some sort of .port identity.. One has to get a reference to the interaction point object held in a specific port slot in order to have any concept of .port identity.. And, to do this, you have to first identify both the relevant encapsulated classifier instance and the desired port on this instance, just you would to get the value of any object attribute (since ports are just attributes). The problem with 9.3.9 is that it seems to indicate that the .object that owns this port. can be identified by a reference to the port alone. But this is just not the case, at least as far as the semantics of 9.3.11 is concerned. So, for send signal and call operation actions, one has to presume that you either need to provide the encapsulated class instance or the interaction port object as the target object. Neither of these support the ability to send a message .through. an outgoing port. (And I really have know idea what the semantics are supposed to be for a call behavior action with onPort set.) Now, 9.3.11 also says that .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port.. I just don.t see how to really do this with the action metamodel as currently defined. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, April 08, 2010 3:32 AM To: Ed Seidewitz Cc: Bock, Conrad; uml2-rtf@omg.org; issues@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Ed, Please have a look at my previous e-mail about the two interpretations of port. However, I am mystified by your statement: On Wed, Apr 7, 2010 at 6:04 PM, Ed Seidewitz wrote: Conrad -- Another problem is that the semantics in 9.3.9 refers to "the object owning this port" and "port identity". However, in UML objects don't own ports, classifiers do. Huh? Of course UML objects own ports, see figure 9.4. An ports don't have independent identity, they are properties of the classifiers of objects -- only the objects have identity. In the UML-RT interpretation, ports are objects and, therefore, do have an identity. I don't see anything in the spec that prevents that interpretation -- which, as I said, is by design. Cheers...Bran Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 06:51:02 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrW/8zt2CN40Y+QRTGSyNHY2M1RMgABVmLw From: "Ed Seidewitz" To: "Bran Selic" Cc: "BERNARD, Yves" , , Bran . OK, so now you have described in even more detail what you did in UML RT. Then you end with the statement that .I do not see that there is anything in UML 2 that precludes. doing something similar in UML 2. But what I really wanted was for you to show me how this would be done using a completely valid UML model per the current spec, not just assert that the spec allows it. I understand . and appreciate . the idea of a port having inward and outward sides. But, as you also imply, this is a UML RT concept that is not in the UML 2 spec. If understand you correctly, what needs to happen is that the .system defined type. of a port has to include all the operations from the required interfaces of the port as well as all the operations from the provided interfaces (the latter is required by 9.3.11). Note, of course, that the port type can.t realize the required interfaces to indicate that it is implementing the required interface operations . because that would make the required interfaces into provided interfaces! A tool using this approach would simply have to automatically update the port type whenever any of the required interfaces changed . or a modeler would have to do it by hand. I suppose that this is approach is not actually precluded in UML 2. But the current UML 2 spec certainly makes it clumsy to model. And, in any case, since the spec does not specifically mention the approach, it is just one non-standard interpretation. Subclause 9.3.11 says .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port.. But I still claim that the current spec actually provides no standard way in which this is really .possible.! Personally, I don.t find this acceptable. If we all we want is to have UML 2 encapsulated classifier models be able to syntactically represent UML RT type components or SDL components or whatever, then we should leave any semantics for them out of the UML spec and let UML RT modelers given them one semantics and SDL models another. Trying to give just enough semantics to cover both, but really neither, as currently seems to be the case, is just a mess. With Foundational UML, we now have precise execution semantics for basic class models and activities. This does not preclude using UML class models to basically be design pictures for, say, Java code, to be interpreted as Java classes with Java semantics. But it does mean that if you want to actually execute an fUML model itself, you know that means. Similarly, one of the things I would like to see use build on top of fUML is precise execution semantics for encapsulated classifiers and ports. Again, this would not preclude the using of UML models syntactically to represent composite structures with UML RT or SDL execution semantics. But it would also allow those of us who want to execute UML models directly some idea of what the standard semantics for this is. As in the case when we did fUML, once you try to make the semantic statements in the UML spec precise, you find some real problems . not just with ambiguous and imprecise statements, but with cases in which it just was not even clear in principle how to make precise the statements made in the spec. And, as we did with in a number of cases relative to fUML (problems with decision nodes and starting object behaviors come to mind as examples), we are going to need to fix such cases in the spec, even if (as with fUML) the fully precise semantics is a separate standard. I believe that what we have with Issue 15145 and the related problems that have come up in discussion of it are such cases. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, April 08, 2010 5:42 AM To: Ed Seidewitz Cc: BERNARD, Yves; issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue It is true that the spec has undergone some changes in the interval since we put this thing together and that it needs cleaning up. However, as I said, I really did not want to clutter the spec with the specifics of UML-RT, but wanted to make sure that there was adequate room to retain those semantics through a profile. Some explanations below: On Thu, Apr 8, 2010 at 11:14 AM, Ed Seidewitz wrote: Bran . Once again, we have a problem of what, perhaps, was intended for UML 2.0 five years ago as opposed to what UML 2 is today, as best can be determined by reading the current spec. While it is useful to understand the intent in order to understand how we got where we are today, it is high time we took the UML spec seriously and expect it to stand consistently on its own. [bvs] The implication is that we did not take it seriously at the time. I assure you that we did, but, undeniably, we made mistakes. Hindisght is 20/20. And, in this area, I really don.t think it stands up to detailed scrutiny. When you put Subclause 9.3.9 on Invocation Action together with the base definition for it and its subclasses in Subclause 11, I cannot see any way to come up with a consistent interpretation for sending a message to a port as a target object. (This would be a lot clearer to understand . and fix -- if things were not spread over multiple merge increments of InvocationAction, which is just another reason why the UML 2.5 spec simplification is so important.) [bvs] Sublcause 9.3.9 was put in by Thomas Weigert, who was somewhat more aggressive in putting in SDL semantics into this than I was. I do agree that thi section is flawed. But, read on... In order to get a target object to feed into a send signal action or call operation action, one would need to read the port as a structural feature. And doing this using read structural feature action would treat the port as an attribute, giving an object of the port type. And one thing that is clear from the definition of Port in Subclause 9.3.11 is that the type of a port realizes the provided interfaces of the port. Hence, the available behavioral features of an object obtained from a port (receptions or operations) will be those from the provided interfaces, not the required interfaces. [bvs] Actually, the way you achieve message sending in UML-RT is by invoking the appropriate send operation on the port object -- which is a feature of the system-defined type. (There are a number of ways of realizing this, but one is to provide such a feature for each behavioural feature of the required interface of the port.) So, in this case, we do not even use a SendSignalAction for this purpose (I did not want to go into such detail in my previous message, but now it is necessary.) Instead, we use a CallOperationAction (or some such equivalent). [bvs] Note that such a port can still declare that it realizes its provided interface. However, UML does not specify how "realize" is realized. As we know, it can be done by delegation or by some behaviour that exists outside the port itself. [bvs] In a sense, UML-RT behaviour ports always have two sides. The outward-facing side is what you see when you declare the port as having a provided and required interface. The inward-facing side has additional features, corresponding to the required interface. The result, as you can see, is a system-defined type that is a composite of the required and provided interfaces of the port (as well as some other system-defined features, such as operations that defer a message arriving on a port). It is actually quite simple, but, I hope you see why I thought it too specific to include in the general UML 2 spec. I would be very interested to hear of you can come up with a different interpretation of how this would work, based only on what is in the UML spec, without reference to any intended or past practices with UML-RT, SDL or anything else. I certainly have not been able to. [bvs] I hope the above explanation is clear. To repeat, I do not think it appropriate to include this type of detail in the UML 2 spec, but I do think that it is fundamental that, whatever changes are made, this type of refinement is not somehow eliminated. As things currently stand, I do not see that there is anything in UML 2 that precludes it. Which is how it should be. Cheers...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=GGe7yyQBzCwIv8E/02mtdIBfQjEsp+Hf7Yhsr/+NzU0=; b=Dq0wR+jYId52MM4SQEZEp8sA0iDKs8tXTwZtCdRv8JLERKcoUUU9aR+Vmi8U9PCheE pIs8IDE/9bivPHFkJx1w7pjRJAW21pzGmncvceasLm6CnnSAqgOSq2EdyvGPVPWFbUar T0OQarQdJ4NFVymjPBMOVXqn1TBY+HyqW1cZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=O2Xr215RA4xTg8Iv1JMs0sQRW7XY0GyFf6e2zaqXBxboWS8nGiAWSBVWXyVu+zd262 e10kA7hGP3EwNfvJ+mIck4zhwW/mchL/LNAuF4odp2p0VmBzUaTMpYxwsxngEeFYJi3C OyjevWRNTnpd0uhHzPHhdEfUNSZ96GzMw+wqE= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 8 Apr 2010 13:35:21 +0200 X-Google-Sender-Auth: ceab929b8734568d Subject: Re: issue 15145 -- UML 2 RTF issue To: Ed Seidewitz Cc: "BERNARD, Yves" , issues@omg.org, uml2-rtf@omg.org Thanks, Ed. A few more remarks below: On Thu, Apr 8, 2010 at 12:51 PM, Ed Seidewitz wrote: OK, so now you have described in even more detail what you did in UML RT. Then you end with the statement that .I do not see that there is anything in UML 2 that precludes. doing something similar in UML 2. [bvs] Sorry for the poor wording. I should have reread my e-mail before sending. But what I really wanted was for you to show me how this would be done using a completely valid UML model per the current spec, not just assert that the spec allows it. [bvs] I am not sure how you define a "completely valid" UML model, but to me that is any model that conforms to the abstract syntax, well-formedness rules and semantics of UML and does not violate any of them. From what I can tell, a UML-RT model fits this category. Demonstrating this is not something I can do in an e-mail, but you can see an existence proof in IBM's RSA-RT tool (I am not sure that is its formal product name), which is based on the standard UML metamodel and a profile defined using standard profiling concepts from UML. Hence, my assertion. I suppose that this is approach is not actually precluded in UML 2. But the current UML 2 spec certainly makes it clumsy to model. [bvs] I am not sure why you call it clumsy. It is simply filling in a few details about which the spec is silent. [bvs] Perhaps you are thinking of fUML? I fully agree that implementing UML-RT directly in fUML would likely be cumbersome, but fUML is, in effect, just a UML profile. By that I mean that I believe that standard UML tolerates interpretations that are outside of fUML. (BTW, as far as I can tell, UML-RT does conform to fUML, clumsy as that may be. Naturally, an implementation does not have to actually use fUML.) And, in any case, since the spec does not specifically mention the approach, it is just one non-standard interpretation. [bvs] I don't believe that it is "non standard", based on my definition of a "completely valid" UML model. However, if there are points where it does violate the standard, the standard should be fixed Subclause 9.3.11 says .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port.. But I still claim that the current spec actually provides no standard way in which this is really .possible.! [bvs] That is the issue that started this discussion and I agree that it is an issue. No disagreement there. Personally, I don.t find this acceptable. If we all we want is to have UML 2 encapsulated classifier models be able to syntactically represent UML RT type components or SDL components or whatever, then we should leave any semantics for them out of the UML spec and let UML RT modelers given them one semantics and SDL models another. Trying to give just enough semantics to cover both, but really neither, as currently seems to be the case, is just a mess. [bvs] Now we are getting into deeper issues. Are you, in effect, arguing against the "family of languages" idea behind UML? Defining just enough semantics to cover multiple choices is the core mechanims behind this. Changing that would be a rather radical step, with major consequences for practically all UML users (e.g., all currently adopted profiles would lose their connection to UML and just become independent domain-specific langauges). I will not argue for or against the "family of langauges" idea (although I believe that it is a good idea -- perhaps poorly realized), but I do not think it realistic to change this now. With Foundational UML, we now have precise execution semantics for basic class models and activities. This does not preclude using UML class models to basically be design pictures for, say, Java code, to be interpreted as Java classes with Java semantics. But it does mean that if you want to actually execute an fUML model itself, you know that means. [bvs] I think that this is a core question that needs to be addressed by the OMG as a whole. Should Foundational UML be deemed as the sole valid interpretation of UML semantics? At present, as I said, I see it as just one possible interpretation -- an important one, mind you, which has the major benefit of being quite precise. Similarly, one of the things I would like to see use build on top of fUML is precise execution semantics for encapsulated classifiers and ports. Again, this would not preclude the using of UML models syntactically to represent composite structures with UML RT or SDL execution semantics. But it would also allow those of us who want to execute UML models directly some idea of what the standard semantics for this is. [bvs] Actually, I am in favour of that as well, which is why I supported and worked on fUML. (Note, BTW, that UML-RT is precise, in fact, more precise than fUML, since it produces fully executable models, which fUML does not, due to its semantic variation points.) Furthermore, there is nothing stopping any of us from doing that. The only important question that must be answered is whether or not that would be the one and only valid interpretation of UML. It seems to me that your position on this point is a bit ambivalent. Can you clarify? As in the case when we did fUML, once you try to make the semantic statements in the UML spec precise, you find some real problems . not just with ambiguous and imprecise statements, but with cases in which it just was not even clear in principle how to make precise the statements made in the spec. And, as we did with in a number of cases relative to fUML (problems with decision nodes and starting object behaviors come to mind as examples), we are going to need to fix such cases in the spec, even if (as with fUML) the fully precise semantics is a separate standard. [bvs] I believe that there is an important distinction between precision and detail. I think that what we need to do is make UML precise, but not by closing off its semantic variation points, but by defining them precisely. We failed to do this so far. Actually, fUML is a good example of how it can be done. Cheers...Bran From: "Bock, Conrad" To: "issues@omg.org" , "uml2-rtf@omg.org" Date: Thu, 8 Apr 2010 09:24:01 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o38DEm7V031833 Ed, > Description aside, there is an explicit constraint that says "[1] > The onPort must be a port on the receiver object." The description > may express what the intent was, but this is not supported by either > the constraint or the semantic specification. The term "receiver" means the target of the invocation. The target can be the runtime object owning the action execution, or it can be another object. (BTW, you can't set aside the descriptions, they are part of the spec) > And I am not sure how the same meta-property can be used to handle > invocations through ports of either the sending or receiving > object. The typing of the target object is going to be different. I > guess the semantics could depend on which type you used on the > target input pin. It's always the port on the receiver (target). The action might be in the runtime object sending the message or outside of it. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 10:02:46 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrXD6fDeaEeoR3DTEiwo19RhehXrgAD0Rrw From: "Ed Seidewitz" To: "Bran Selic" Cc: "BERNARD, Yves" , , Bran . I think you already clarified a key point of mine for me: if UML constructs are to be defined with .just enough. semantics and semantic variation points, then the semantics that are defined should be precise and the semantic variation points should be clear. There is also a difference between lack of detail and lack of clarity! Right now, the semantic description of InvocationAction::onPort in Subclause 9.3.9 is, I believe, both unclear (especially on how it relates to the semantics of each of the kinds of invocation actions defined in Clause 11) and worded inconsistently with the syntax and semantics for ports in Subclause 9.3.11. I don.t think this is acceptable. And, when it says in Subclause 9.3.11 that .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port., this sets up a reasonable expectation that, somewhere, the spec will describe how to do this. But it doesn.t. Technically, it is .possible. to do it, in the sense that if you come up with a specific methodological approach like UML-RT and have appropriate tool support for it, then there is a way to model it that (perhaps) does not violate any of the constraints of the standard. But, when I said this is .non-standard., I really meant that it is .not standardized.. As you said the standard is silent on this. Which makes it really difficult for someone who is just trying to do precise encapsulated class and port modeling using a general UML tool without some additional add-on like UML RT. (Actually, SoaML does effectively provide a standard way to do this, and perhaps SysML, too, but they are different from UML-RT and from each other, and only apply if you are using one of those profiles. And, at least in the case of SoaML, it took a lot of stretching of what was written in the spec about ports to come up with a reasonable interpretation.) To be honest, I am coming to think that the whole .family of languages. idea is mostly a lost cause with UML 2. The level of detail and precision of the semantics defined in the spec vary wildly across different areas of the spec. It is impossible in any practical sense to tease apart semantic commitments made in one area from those made in another area merged into or dependent on the first. And the semantic variation points that are defined are often not very clearly described and no one really knows how all the various possible variations interact. There is, in fact, a real sense in which fUML is .the. semantics for UML, at least the subset included in fUML. Conrad argued very strongly that the semantics of fUML must be just a more precise statement of the semantics as described in the spec document, and the submission team accepted his argument. So, conforming to fUML doesn.t mean conforming to .different. semantics than are in the UML spec. It simply means that a tool has made a commitment to conform more precisely, formally and testably to the semantics that were already intended by the UML superstructure spec. The other thing we did was to define a default for each of the few semantic variation points that are left in the fUML subset. So a fUML model, is completely executable per this default, which is what you get from the fUML spec .out of the box.. Any tool that wishes to provide a variant on one of these points is obligated to provide a semantic definition for that variant as precise as that given for the default, so a user of the tool then knows exactly what he or she is getting. I think we would be better served to take a similar approach to all of UML. Treat it as a real language with real semantics. Allow semantic variation points where appropriate, but provide a default for each one and require precise definition for any variants. And make this the standard semantics for UML, so we at least know what any UML model means as a UML model. Then make conformance to this standard semantics a separate conformance point, just as concrete and abstract syntax conformance points now. (By the way, the UML Superstructure spec actually provides no compliance points for semantics right now . per Subclause 2.3.) In my opinion UML 2 has largely missed the boat on the .family of languages. concept, and saying otherwise is just making UML harder, not easier, to use. I say, let.s make UML just one, real language, and then try again to do a .family of languages. right as part of the new architecture ecosystem effort. (But, then again, I got up early this morning and I am generally grumpy today.) -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, April 08, 2010 7:35 AM To: Ed Seidewitz Cc: BERNARD, Yves; issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Thanks, Ed. A few more remarks below: On Thu, Apr 8, 2010 at 12:51 PM, Ed Seidewitz wrote: OK, so now you have described in even more detail what you did in UML RT. Then you end with the statement that .I do not see that there is anything in UML 2 that precludes. doing something similar in UML 2. [bvs] Sorry for the poor wording. I should have reread my e-mail before sending. But what I really wanted was for you to show me how this would be done using a completely valid UML model per the current spec, not just assert that the spec allows it. [bvs] I am not sure how you define a "completely valid" UML model, but to me that is any model that conforms to the abstract syntax, well-formedness rules and semantics of UML and does not violate any of them. From what I can tell, a UML-RT model fits this category. Demonstrating this is not something I can do in an e-mail, but you can see an existence proof in IBM's RSA-RT tool (I am not sure that is its formal product name), which is based on the standard UML metamodel and a profile defined using standard profiling concepts from UML. Hence, my assertion. I suppose that this is approach is not actually precluded in UML 2. But the current UML 2 spec certainly makes it clumsy to model. [bvs] I am not sure why you call it clumsy. It is simply filling in a few details about which the spec is silent. [bvs] Perhaps you are thinking of fUML? I fully agree that implementing UML-RT directly in fUML would likely be cumbersome, but fUML is, in effect, just a UML profile. By that I mean that I believe that standard UML tolerates interpretations that are outside of fUML. (BTW, as far as I can tell, UML-RT does conform to fUML, clumsy as that may be. Naturally, an implementation does not have to actually use fUML.) And, in any case, since the spec does not specifically mention the approach, it is just one non-standard interpretation. [bvs] I don't believe that it is "non standard", based on my definition of a "completely valid" UML model. However, if there are points where it does violate the standard, the standard should be fixed Subclause 9.3.11 says .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port.. But I still claim that the current spec actually provides no standard way in which this is really .possible.! [bvs] That is the issue that started this discussion and I agree that it is an issue. No disagreement there. Personally, I don.t find this acceptable. If we all we want is to have UML 2 encapsulated classifier models be able to syntactically represent UML RT type components or SDL components or whatever, then we should leave any semantics for them out of the UML spec and let UML RT modelers given them one semantics and SDL models another. Trying to give just enough semantics to cover both, but really neither, as currently seems to be the case, is just a mess. [bvs] Now we are getting into deeper issues. Are you, in effect, arguing against the "family of languages" idea behind UML? Defining just enough semantics to cover multiple choices is the core mechanims behind this. Changing that would be a rather radical step, with major consequences for practically all UML users (e.g., all currently adopted profiles would lose their connection to UML and just become independent domain-specific langauges). I will not argue for or against the "family of langauges" idea (although I believe that it is a good idea -- perhaps poorly realized), but I do not think it realistic to change this now. With Foundational UML, we now have precise execution semantics for basic class models and activities. This does not preclude using UML class models to basically be design pictures for, say, Java code, to be interpreted as Java classes with Java semantics. But it does mean that if you want to actually execute an fUML model itself, you know that means. [bvs] I think that this is a core question that needs to be addressed by the OMG as a whole. Should Foundational UML be deemed as the sole valid interpretation of UML semantics? At present, as I said, I see it as just one possible interpretation -- an important one, mind you, which has the major benefit of being quite precise. Similarly, one of the things I would like to see use build on top of fUML is precise execution semantics for encapsulated classifiers and ports. Again, this would not preclude the using of UML models syntactically to represent composite structures with UML RT or SDL execution semantics. But it would also allow those of us who want to execute UML models directly some idea of what the standard semantics for this is. [bvs] Actually, I am in favour of that as well, which is why I supported and worked on fUML. (Note, BTW, that UML-RT is precise, in fact, more precise than fUML, since it produces fully executable models, which fUML does not, due to its semantic variation points.) Furthermore, there is nothing stopping any of us from doing that. The only important question that must be answered is whether or not that would be the one and only valid interpretation of UML. It seems to me that your position on this point is a bit ambivalent. Can you clarify? As in the case when we did fUML, once you try to make the semantic statements in the UML spec precise, you find some real problems . not just with ambiguous and imprecise statements, but with cases in which it just was not even clear in principle how to make precise the statements made in the spec. And, as we did with in a number of cases relative to fUML (problems with decision nodes and starting object behaviors come to mind as examples), we are going to need to fix such cases in the spec, even if (as with fUML) the fully precise semantics is a separate standard. [bvs] I believe that there is an important distinction between precision and detail. I think that what we need to do is make UML precise, but not by closing off its semantic variation points, but by defining them precisely. We failed to do this so far. Actually, fUML is a good example of how it can be done. Cheers...Bran Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 10:14:25 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfA= From: "Ed Seidewitz" To: "Bock, Conrad" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o38E4oJp005662 Conrad -- First of all, not all invocations have targets. What is the "target object" of a call behavior action? As I have noted previously, you can't determine the target object at run-time from just a static reference to a port -- you have to either get an explicit reference to the run-time "interaction point" object in the port slot or to a run-time instance of the encapsulated classifier owning the port. Second, if the run-time object is the object owning the action execution, then the object will be sending a message to itself. For invocation actions that have target objects (send signal action and call object action), that is what they do -- send a message to the target object. But the desired behavior under discussion was sending a message _out_ through a required interface of a port of the sending object, not invoking a behavior on the sending object itself. In that case the target is the object at the other end of a connector from the local port, and it is that object that would have to be the "target" of the invocation action. Finally, I don't understand what you mean by your final sentence "The action might be in the runtime object sending the message or outside of it." Isn't it the very fact that the action is inside "the runtime object sending the message" that makes it "the runtime object sending the message"?? Or did you mean "The action might be in the runtime object _receiving_ the message or outside of it"? -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, April 08, 2010 9:24 AM To: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, > Description aside, there is an explicit constraint that says "[1] > The onPort must be a port on the receiver object." The description > may express what the intent was, but this is not supported by either > the constraint or the semantic specification. The term "receiver" means the target of the invocation. The target can be the runtime object owning the action execution, or it can be another object. (BTW, you can't set aside the descriptions, they are part of the spec) > And I am not sure how the same meta-property can be used to handle > invocations through ports of either the sending or receiving > object. The typing of the target object is going to be different. I > guess the semantics could depend on which type you used on the > target input pin. It's always the port on the receiver (target). The action might be in the runtime object sending the message or outside of it. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 17:07:32 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAAANbQ4A== From: "BERNARD, Yves" To: X-OriginalArrivalTime: 08 Apr 2010 15:07:33.0101 (UTC) FILETIME=[371391D0:01CAD72D] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o38EwUEt011776 The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). Yves ----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 8 avril 2010 16:14 À: Bock, Conrad Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Conrad -- First of all, not all invocations have targets. What is the "target object" of a call behavior action? As I have noted previously, you can't determine the target object at run-time from just a static reference to a port -- you have to either get an explicit reference to the run-time "interaction point" object in the port slot or to a run-time instance of the encapsulated classifier owning the port. Second, if the run-time object is the object owning the action execution, then the object will be sending a message to itself. For invocation actions that have target objects (send signal action and call object action), that is what they do -- send a message to the target object. But the desired behavior under discussion was sending a message _out_ through a required interface of a port of the sending object, not invoking a behavior on the sending object itself. In that case the target is the object at the other end of a connector from the local port, and it is that object that would have to be the "target" of the invocation action. Finally, I don't understand what you mean by your final sentence "The action might be in the runtime object sending the message or outside of it." Isn't it the very fact that the action is inside "the runtime object sending the message" that makes it "the runtime object sending the message"?? Or did you mean "The action might be in the runtime object _receiving_ the message or outside of it"? -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, April 08, 2010 9:24 AM To: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, > Description aside, there is an explicit constraint that says "[1] > The onPort must be a port on the receiver object." The description > may express what the intent was, but this is not supported by either > the constraint or the semantic specification. The term "receiver" means the target of the invocation. The target can be the runtime object owning the action execution, or it can be another object. (BTW, you can't set aside the descriptions, they are part of the spec) > And I am not sure how the same meta-property can be used to handle > invocations through ports of either the sending or receiving > object. The typing of the target object is going to be different. I > guess the semantics could depend on which type you used on the > target input pin. It's always the port on the receiver (target). The action might be in the runtime object sending the message or outside of it. Conrad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz CC: Bran Selic , "BERNARD, Yves" , "issues@omg.org" , "uml2-rtf@omg.org" Date: Thu, 8 Apr 2010 08:15:17 -0700 Subject: Re: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrXLkyiZMkFw0QXSeuuL/k4Yj3wJQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized This issue started from a simple question, which I understood as how to define formally in a state machine that a behavior linked to a transition or state results in a message sent through a port defined in the behaviored classifier context of that state machine. Resolving this issue without fUML amounts to a short-term fix that effectively postpones clarifying the runtime semantics of encapsulated classifiers. Resolving this issue via an extension of fUML for encapsulated classifiers is the right thing to do for improving and strengthening the architecture of the UML as a competitive modeling language. I think that we may need to do both: the short-term fix is needed to make the specification document linguistically consistent and the long-term fix is needed to make the UML itself coherent and usable, that is making sure that the intended semantics of the concepts and their actual semantics per the specification document and the metamodel are logically consistent with one another. By this, I mean that if a user creates a state machine in which a behavior linked to a transition or state is intended to result in a message sent through a port defined in the state machine's context, then this is also what the semantics of that state machine should have in any tool that conforms to the UML spec. - Nicolas. On Apr 8, 2010, at 7:02 AM, Ed Seidewitz wrote: Bran . I think you already clarified a key point of mine for me: if UML constructs are to be defined with .just enough. semantics and semantic variation points, then the semantics that are defined should be precise and the semantic variation points should be clear. There is also a difference between lack of detail and lack of clarity! Right now, the semantic description of InvocationAction::onPort in Subclause 9.3.9 is, I believe, both unclear (especially on how it relates to the semantics of each of the kinds of invocation actions defined in Clause 11) and worded inconsistently with the syntax and semantics for ports in Subclause 9.3.11. I don.t think this is acceptable. And, when it says in Subclause 9.3.11 that .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port., this sets up a reasonable expectation that, somewhere, the spec will describe how to do this. But it doesn.t. Technically, it is .possible. to do it, in the sense that if you come up with a specific methodological approach like UML-RT and have appropriate tool support for it, then there is a way to model it that (perhaps) does not violate any of the constraints of the standard. But, when I said this is .non-standard., I really meant that it is .not standardized.. As you said the standard is silent on this. Which makes it really difficult for someone who is just trying to do precise encapsulated class and port modeling using a general UML tool without some additional add-on like UML RT. (Actually, SoaML does effectively provide a standard way to do this, and perhaps SysML, too, but they are different from UML-RT and from each other, and only apply if you are using one of those profiles. And, at least in the case of SoaML, it took a lot of stretching of what was written in the spec about ports to come up with a reasonable interpretation.) To be honest, I am coming to think that the whole .family of languages. idea is mostly a lost cause with UML 2. The level of detail and precision of the semantics defined in the spec vary wildly across different areas of the spec. It is impossible in any practical sense to tease apart semantic commitments made in one area from those made in another area merged into or dependent on the first. And the semantic variation points that are defined are often not very clearly described and no one really knows how all the various possible variations interact. There is, in fact, a real sense in which fUML is .the. semantics for UML, at least the subset included in fUML. Conrad argued very strongly that the semantics of fUML must be just a more precise statement of the semantics as described in the spec document, and the submission team accepted his argument. So, conforming to fUML doesn.t mean conforming to .different. semantics than are in the UML spec. It simply means that a tool has made a commitment to conform more precisely, formally and testably to the semantics that were already intended by the UML superstructure spec. The other thing we did was to define a default for each of the few semantic variation points that are left in the fUML subset. So a fUML model, is completely executable per this default, which is what you get from the fUML spec .out of the box.. Any tool that wishes to provide a variant on one of these points is obligated to provide a semantic definition for that variant as precise as that given for the default, so a user of the tool then knows exactly what he or she is getting. I think we would be better served to take a similar approach to all of UML. Treat it as a real language with real semantics. Allow semantic variation points where appropriate, but provide a default for each one and require precise definition for any variants. And make this the standard semantics for UML, so we at least know what any UML model means as a UML model. Then make conformance to this standard semantics a separate conformance point, just as concrete and abstract syntax conformance points now. (By the way, the UML Superstructure spec actually provides no compliance points for semantics right now . per Subclause 2.3.) In my opinion UML 2 has largely missed the boat on the .family of languages. concept, and saying otherwise is just making UML harder, not easier, to use. I say, let.s make UML just one, real language, and then try again to do a .family of languages. right as part of the new architecture ecosystem effort. (But, then again, I got up early this morning and I am generally grumpy today.) -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, April 08, 2010 7:35 AM To: Ed Seidewitz Cc: BERNARD, Yves; issues@omg.org; uml2-rtf@omg.org Subject: Re: issue 15145 -- UML 2 RTF issue Thanks, Ed. A few more remarks below: On Thu, Apr 8, 2010 at 12:51 PM, Ed Seidewitz wrote: OK, so now you have described in even more detail what you did in UML RT. Then you end with the statement that .I do not see that there is anything in UML 2 that precludes. doing something similar in UML 2. [bvs] Sorry for the poor wording. I should have reread my e-mail before sending. But what I really wanted was for you to show me how this would be done using a completely valid UML model per the current spec, not just assert that the spec allows it. [bvs] I am not sure how you define a "completely valid" UML model, but to me that is any model that conforms to the abstract syntax, well-formedness rules and semantics of UML and does not violate any of them. From what I can tell, a UML-RT model fits this category. Demonstrating this is not something I can do in an e-mail, but you can see an existence proof in IBM's RSA-RT tool (I am not sure that is its formal product name), which is based on the standard UML metamodel and a profile defined using standard profiling concepts from UML. Hence, my assertion. I suppose that this is approach is not actually precluded in UML 2. But the current UML 2 spec certainly makes it clumsy to model. [bvs] I am not sure why you call it clumsy. It is simply filling in a few details about which the spec is silent. [bvs] Perhaps you are thinking of fUML? I fully agree that implementing UML-RT directly in fUML would likely be cumbersome, but fUML is, in effect, just a UML profile. By that I mean that I believe that standard UML tolerates interpretations that are outside of fUML. (BTW, as far as I can tell, UML-RT does conform to fUML, clumsy as that may be. Naturally, an implementation does not have to actually use fUML.) And, in any case, since the spec does not specifically mention the approach, it is just one non-standard interpretation. [bvs] I don't believe that it is "non standard", based on my definition of a "completely valid" UML model. However, if there are points where it does violate the standard, the standard should be fixed Subclause 9.3.11 says .it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port.. But I still claim that the current spec actually provides nostandard way in which this is really .possible.! [bvs] That is the issue that started this discussion and I agree that it is an issue. No disagreement there. Personally, I don.t find this acceptable. If we all we want is to have UML 2 encapsulated classifier models be able to syntactically represent UML RT type components or SDL components or whatever, then we should leave any semantics for them out of the UML spec and let UML RT modelers given them one semantics and SDL models another. Trying to give just enough semantics to cover both, but really neither, as currently seems to be the case, is just a mess. [bvs] Now we are getting into deeper issues. Are you, in effect, arguing against the "family of languages" idea behind UML? Defining just enough semantics to cover multiple choices is the core mechanims behind this. Changing that would be a rather radical step, with major consequences for practically all UML users (e.g., all currently adopted profiles would lose their connection to UML and just become independent domain-specific langauges). I will not argue for or against the "family of langauges" idea (although I believe that it is a good idea -- perhaps poorly realized), but I do not think it realistic to change this now. With Foundational UML, we now have precise execution semantics for basic class models and activities. This does not preclude using UML class models to basically be design pictures for, say, Java code, to be interpreted as Java classes with Java semantics. But it does mean that if you want to actually execute an fUML model itself, you know that means. [bvs] I think that this is a core question that needs to be addressed by the OMG as a whole. Should Foundational UML be deemed as the sole valid interpretation of UML semantics? At present, as I said, I see it as just one possible interpretation -- an important one, mind you, which has the major benefit of being quite precise. Similarly, one of the things I would like to see use build on top of fUML is precise execution semantics for encapsulated classifiers and ports. Again, this would not preclude the using of UML models syntactically to represent composite structures with UML RT or SDL execution semantics. But it would also allow those of us who want to execute UML models directly some idea of what the standard semantics for this is. [bvs] Actually, I am in favour of that as well, which is why I supported and worked on fUML. (Note, BTW, that UML-RT is precise, in fact, more precise than fUML, since it produces fully executable models, which fUML does not, due to its semantic variation points.) Furthermore, there is nothing stopping any of us from doing that. The only important question that must be answered is whether or not that would be the one and only valid interpretation of UML. It seems to me that your position on this point is a bit ambivalent. Can you clarify? As in the case when we did fUML, once you try to make the semantic statements in the UML spec precise, you find some real problems . not just with ambiguous and imprecise statements, but with cases in which it just was not even clear in principle how to make precise the statements made in the spec. And, as we did with in a number of cases relative to fUML (problems with decision nodes and starting object behaviors come to mind as examples), we are going to need to fix such cases in the spec, even if (as with fUML) the fully precise semantics is a separate standard. [bvs] I believe that there is an important distinction between precision and detail. I think that what we need to do is make UML precise, but not by closing off its semantic variation points, but by defining them precisely. We failed to do this so far. Actually, fUML is a good example of how it can be done. Cheers...Bran Subject: RE: issue 15145 -- UML 2 RTF issue Date: Thu, 8 Apr 2010 17:32:47 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAAANbQ4AAOnP5Q From: "Ed Seidewitz" To: "BERNARD, Yves" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o38LNF2Y012280 Bernard -- You are right that the target doesn't have to have a reception to receive a signal. But that doesn't really affect the point that I was making. The fact remains that, in order to send a signal, you need to identify a target, and you can't do that just by pointing to a port. It is worth noting, though, that the primary reason to use a port is so that you can define the interfaces on that port. And the only way to indicate the provision or requirement of a signal through an interface is to put a reception on the interface. As to what an interaction point "should" be, that isn't the point, either. Subclause 9.3.11 defines an "interaction point" as the run-time instance in a port slot and therefore specifies what that "is" in UML, to the extent that it is well defined at all. -- Ed -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, April 08, 2010 11:08 AM To: uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). Yves ----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 8 avril 2010 16:14 À: Bock, Conrad Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Conrad -- First of all, not all invocations have targets. What is the "target object" of a call behavior action? As I have noted previously, you can't determine the target object at run-time from just a static reference to a port -- you have to either get an explicit reference to the run-time "interaction point" object in the port slot or to a run-time instance of the encapsulated classifier owning the port. Second, if the run-time object is the object owning the action execution, then the object will be sending a message to itself. For invocation actions that have target objects (send signal action and call object action), that is what they do -- send a message to the target object. But the desired behavior under discussion was sending a message _out_ through a required interface of a port of the sending object, not invoking a behavior on the sending object itself. In that case the target is the object at the other end of a connector from the local port, and it is that object that would have to be the "target" of the invocation action. Finally, I don't understand what you mean by your final sentence "The action might be in the runtime object sending the message or outside of it." Isn't it the very fact that the action is inside "the runtime object sending the message" that makes it "the runtime object sending the message"?? Or did you mean "The action might be in the runtime object _receiving_ the message or outside of it"? -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, April 08, 2010 9:24 AM To: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, > Description aside, there is an explicit constraint that says "[1] > The onPort must be a port on the receiver object." The description > may express what the intent was, but this is not supported by either > the constraint or the semantic specification. The term "receiver" means the target of the invocation. The target can be the runtime object owning the action execution, or it can be another object. (BTW, you can't set aside the descriptions, they are part of the spec) > And I am not sure how the same meta-property can be used to handle > invocations through ports of either the sending or receiving > object. The typing of the target object is going to be different. I > guess the semantics could depend on which type you used on the > target input pin. It's always the port on the receiver (target). The action might be in the runtime object sending the message or outside of it. Conrad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: issue 15145 -- UML 2 RTF issue Date: Fri, 9 Apr 2010 12:18:32 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAAANbQ4AAOnP5QABF0ItA= From: "BERNARD, Yves" To: "Ed Seidewitz" , X-OriginalArrivalTime: 09 Apr 2010 10:18:32.0748 (UTC) FILETIME=[01D56EC0:01CAD7CE] Ed, I believe you can send a signal (or an object) to an interaction point. If you can specify an object, you can also specify the slot corresponding to the feature of that object, including those described by ports in its classifier. Then according to what the UML specification currently "is", it is perfectly allowed to specify an interaction point as the target of a send action. From my point of view, the primary reason to use a port is NOT to define interface, because you don't need ports do specify provided and required interfaces on a classifier, but to define distinct interaction points for those interfaces. Section 9.3.11 is very clear about that: · .The required interfaces of a port characterize the requests that may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port. · .A port has the ability to specify that any requests arriving at this port are handled by the behavior of the instance of the owning classifier, rather than being forwarded to any contained instances, if any. · .A port represents an interaction point between a classifier instance and its environment or between a classifier instance and instances it may contain. · .The required interfaces characterize services that the owning classifier expects from its environment and that it may access through this interaction point: Instances of this classifier expect that the features owned by its required interfaces will be offered by one or more instances in its environment. · .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.. · .The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port. · .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. These instances are referred to as .interaction points. and provide unique references. A link from that instance to the instance of the owning classifier is created through which communication is forwarded to the instance of the owning classifier or through which the owning classifier communicates with its environment. It is, therefore, possible for an instance to differentiate between requests for the invocation of a behavioral feature targeted at its different ports. · .Similarly, it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port. (In the following, .requests arriving at a port. shall mean .request occurrences arriving at the interaction point of this instance corresponding to this port..). ðt is very clear that interactions are between the object and its environment and NOT between the object and the interaction point one side and between the interaction point and the environment on the other side ðt is then very clear also that this semantic does not authorize any kind of modification on the request going through a port. The only operation that a port performs on a request is routing. ðhus, any capability offered to a port thanks to the kind of classifier it has for type results from unexpected inheritance and should be explicitly restricted with appropriate constraints (RTF scope) ðote also the last sentence in the list above, which allows the usage of the word .port. as an official shortcut to refer to the corresponding interaction point... By the way, my understanding of the .UML compliant. concept of port is very similar to the IP concept of port: a kind of communication channel that exists at run-time even if it remains purely virtual, with no inward or outward aspects. In conclusion, and to come back to the posted issue, a send action targeting a .port. (i.e. an interaction point) is possible with the current specification can be seen as a kind of .channel restricted. broadcast, what make sense to me. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 8 avril 2010 23:33 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Bernard -- You are right that the target doesn't have to have a reception to receive a signal. But that doesn't really affect the point that I was making. The fact remains that, in order to send a signal, you need to identify a target, and you can't do that just by pointing to a port. It is worth noting, though, that the primary reason to use a port is so that you can define the interfaces on that port. And the only way to indicate the provision or requirement of a signal through an interface is to put a reception on the interface. As to what an interaction point "should" be, that isn't the point, either. Subclause 9.3.11 defines an "interaction point" as the run-time instance in a port slot and therefore specifies what that "is" in UML, to the extent that it is well defined at all. -- Ed -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, April 08, 2010 11:08 AM To: uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). Yves ----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 8 avril 2010 16:14 À: Bock, Conrad Cc : issues@omg.org; uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Conrad -- First of all, not all invocations have targets. What is the "target object" of a call behavior action? As I have noted previously, you can't determine the target object at run-time from just a static reference to a port -- you have to either get an explicit reference to the run-time "interaction point" object in the port slot or to a run-time instance of the encapsulated classifier owning the port. Second, if the run-time object is the object owning the action execution, then the object will be sending a message to itself. For invocation actions that have target objects (send signal action and call object action), that is what they do -- send a message to the target object. But the desired behavior under discussion was sending a message _out_ through a required interface of a port of the sending object, not invoking a behavior on the sending object itself. In that case the target is the object at the other end of a connector from the local port, and it is that object that would have to be the "target" of the invocation action. Finally, I don't understand what you mean by your final sentence "The action might be in the runtime object sending the message or outside of it." Isn't it the very fact that the action is inside "the runtime object sending the message" that makes it "the runtime object sending the message"?? Or did you mean "The action might be in the runtime object _receiving_ the message or outside of it"? -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, April 08, 2010 9:24 AM To: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, > Description aside, there is an explicit constraint that says "[1] > The onPort must be a port on the receiver object." The description > may express what the intent was, but this is not supported by either > the constraint or the semantic specification. The term "receiver" means the target of the invocation. The target can be the runtime object owning the action execution, or it can be another object. (BTW, you can't set aside the descriptions, they are part of the spec) > And I am not sure how the same meta-property can be used to handle > invocations through ports of either the sending or receiving > object. The typing of the target object is going to be different. I > guess the semantics could depend on which type you used on the > target input pin. It's always the port on the receiver (target). The action might be in the runtime object sending the message or outside of it. Conrad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: issue 15145 -- UML 2 RTF issue Date: Fri, 9 Apr 2010 09:34:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrXqxHZItTs6DdNT+ikWlRDISnuOwAPUo2A From: "Ed Seidewitz" To: Birger Mø-Pedersen Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o39DOqcm021930 Birger -- My point (or one of them, at least) is exactly that you need to specify "r" (the object) in addition to "i" (the port). Subclause 9.3.9 adds the onPort property to InvocationAction, which is "i". But it doesn't explicitly state how "r" is to be specified. Now, 9.3.9 does say that the specified port is on the "receiving object" of the message. However, some invocation actions (e.g., CallBehaviorAction and BroadcastSignalAction) do not provide for the input of any "receiving object", so it is not clear what "r" would be for them. And those that do provide for the input of a "target object" (e.g., CallOperationAction, SendSignalAction and SendObjectAction) clearly have the semantics that the given object is the end object handling the message. That, indeed, seems to be the intended semantics of InvocationAction with onPort, but it does not correspond to the semantics of sending a message out through a "local" port of the object owning the invocation action. -- Ed -----Original Message----- From: Birger Mø-Pedersen [mailto:birger@ifi.uio.no] Sent: Friday, April 09, 2010 1:53 AM To: Ed Seidewitz Subject: Re: issue 15145 -- UML 2 RTF issue However, it cannot be so that the specification of an action has to contain an identification of the 'interaction point' by other means than by a port, in the same way as there is no need to identify a specific slot in order to specify an assignment to an attribute. In Java speak the remote identifier 'r.i' is enough to identify (in UML speak) the slot corresponding to 'i' in the object currently denoted by the slot identified by 'r'. /birger On 4/8/10 11:32 PM, Ed Seidewitz wrote: > Bernard -- > > You are right that the target doesn't have to have a reception to receive a signal. But that doesn't really affect the point that I was making. The fact remains that, in order to send a signal, you need to identify a target, and you can't do that just by pointing to a port. > > It is worth noting, though, that the primary reason to use a port is so that you can define the interfaces on that port. And the only way to indicate the provision or requirement of a signal through an interface is to put a reception on the interface. > > As to what an interaction point "should" be, that isn't the point, either. Subclause 9.3.11 defines an "interaction point" as the run-time instance in a port slot and therefore specifies what that "is" in UML, to the extent that it is well defined at all. > > -- Ed > > -----Original Message----- > From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] > Sent: Thursday, April 08, 2010 11:08 AM > To: uml2-rtf@omg.org > Subject: RE: issue 15145 -- UML 2 RTF issue > > > The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform > its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. > > There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. > > Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). > > Yves > > ----Message d'origine----- > De : Ed Seidewitz [mailto:ed-s@modeldriven.com] > Envoyé jeudi 8 avril 2010 16:14 > À: Bock, Conrad > Cc : issues@omg.org; uml2-rtf@omg.org > Objet : RE: issue 15145 -- UML 2 RTF issue > > Conrad -- > > First of all, not all invocations have targets. What is the "target > object" of a call behavior action? As I have noted previously, you can't > determine the target object at run-time from just a static reference to > a port -- you have to either get an explicit reference to the run-time > "interaction point" object in the port slot or to a run-time instance of > the encapsulated classifier owning the port. > > Second, if the run-time object is the object owning the action > execution, then the object will be sending a message to itself. For > invocation actions that have target objects (send signal action and call > object action), that is what they do -- send a message to the target > object. But the desired behavior under discussion was sending a message > _out_ through a required interface of a port of the sending object, not > invoking a behavior on the sending object itself. In that case the > target is the object at the other end of a connector from the local > port, and it is that object that would have to be the "target" of the > invocation action. > > Finally, I don't understand what you mean by your final sentence "The > action might be in the runtime object sending the message or outside of > it." Isn't it the very fact that the action is inside "the runtime > object sending the message" that makes it "the runtime object sending > the message"?? Or did you mean "The action might be in the runtime > object _receiving_ the message or outside of it"? > > -- Ed > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Thursday, April 08, 2010 9:24 AM > To: issues@omg.org; uml2-rtf@omg.org > Subject: RE: issue 15145 -- UML 2 RTF issue > > Ed, > > > Description aside, there is an explicit constraint that says "[1] > > The onPort must be a port on the receiver object." The description > > may express what the intent was, but this is not supported by either > > the constraint or the semantic specification. > > The term "receiver" means the target of the invocation. The target can > be the runtime object owning the action execution, or it can be another > object. (BTW, you can't set aside the descriptions, they are part of > the spec) > > > And I am not sure how the same meta-property can be used to handle > > invocations through ports of either the sending or receiving > > object. The typing of the target object is going to be different. I > > guess the semantics could depend on which type you used on the > > target input pin. > > It's always the port on the receiver (target). The action might be in > the runtime object sending the message or outside of it. > > Conrad > > > This mail has originated outside your organization, either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > > > The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. > > > Subject: RE: issue 15145 -- UML 2 RTF issue Date: Fri, 9 Apr 2010 16:26:02 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrXqxHZItTs6DdNT+ikWlRDISnuOwAPUo2AAAHVY7A= From: "BERNARD, Yves" To: "Ed Seidewitz" , Birger Mø-Pedersen Cc: X-OriginalArrivalTime: 09 Apr 2010 14:26:02.0585 (UTC) FILETIME=[9506BC90:01CAD7F0] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o39EGrLV031585 Ed, I think you demonstrate clearly that the specification is inconsistent there, and then shall be fixed. According to what I said in my previous message my feeling is that if we simply remove the constraint [1] of §9.3.9, that is clearly in contradiction with the description sub-clause of the same paragraph, most of the inconsistency is removed also... Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé vendredi 9 avril 2010 15:34 À: Birger Mø-Pedersen Cc : uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Birger -- My point (or one of them, at least) is exactly that you need to specify "r" (the object) in addition to "i" (the port). Subclause 9.3.9 adds the onPort property to InvocationAction, which is "i". But it doesn't explicitly state how "r" is to be specified. Now, 9.3.9 does say that the specified port is on the "receiving object" of the message. However, some invocation actions (e.g., CallBehaviorAction and BroadcastSignalAction) do not provide for the input of any "receiving object", so it is not clear what "r" would be for them. And those that do provide for the input of a "target object" (e.g., CallOperationAction, SendSignalAction and SendObjectAction) clearly have the semantics that the given object is the end object handling the message. That, indeed, seems to be the intended semantics of InvocationAction with onPort, but it does not correspond to the semantics of sending a message out through a "local" port of the object owning the invocation action. -- Ed -----Original Message----- From: Birger Mø-Pedersen [mailto:birger@ifi.uio.no] Sent: Friday, April 09, 2010 1:53 AM To: Ed Seidewitz Subject: Re: issue 15145 -- UML 2 RTF issue However, it cannot be so that the specification of an action has to contain an identification of the 'interaction point' by other means than by a port, in the same way as there is no need to identify a specific slot in order to specify an assignment to an attribute. In Java speak the remote identifier 'r.i' is enough to identify (in UML speak) the slot corresponding to 'i' in the object currently denoted by the slot identified by 'r'. /birger On 4/8/10 11:32 PM, Ed Seidewitz wrote: > Bernard -- > > You are right that the target doesn't have to have a reception to receive a signal. But that doesn't really affect the point that I was making. The fact remains that, in order to send a signal, you need to identify a target, and you can't do that just by pointing to a port. > > It is worth noting, though, that the primary reason to use a port is so that you can define the interfaces on that port. And the only way to indicate the provision or requirement of a signal through an interface is to put a reception on the interface. > > As to what an interaction point "should" be, that isn't the point, either. Subclause 9.3.11 defines an "interaction point" as the run-time instance in a port slot and therefore specifies what that "is" in UML, to the extent that it is well defined at all. > > -- Ed > > -----Original Message----- > From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] > Sent: Thursday, April 08, 2010 11:08 AM > To: uml2-rtf@omg.org > Subject: RE: issue 15145 -- UML 2 RTF issue > > > The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform > its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. > > There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. > > Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). > > Yves > > ----Message d'origine----- > De : Ed Seidewitz [mailto:ed-s@modeldriven.com] > Envoyé jeudi 8 avril 2010 16:14 > À: Bock, Conrad > Cc : issues@omg.org; uml2-rtf@omg.org > Objet : RE: issue 15145 -- UML 2 RTF issue > > Conrad -- > > First of all, not all invocations have targets. What is the "target > object" of a call behavior action? As I have noted previously, you can't > determine the target object at run-time from just a static reference to > a port -- you have to either get an explicit reference to the run-time > "interaction point" object in the port slot or to a run-time instance of > the encapsulated classifier owning the port. > > Second, if the run-time object is the object owning the action > execution, then the object will be sending a message to itself. For > invocation actions that have target objects (send signal action and call > object action), that is what they do -- send a message to the target > object. But the desired behavior under discussion was sending a message > _out_ through a required interface of a port of the sending object, not > invoking a behavior on the sending object itself. In that case the > target is the object at the other end of a connector from the local > port, and it is that object that would have to be the "target" of the > invocation action. > > Finally, I don't understand what you mean by your final sentence "The > action might be in the runtime object sending the message or outside of > it." Isn't it the very fact that the action is inside "the runtime > object sending the message" that makes it "the runtime object sending > the message"?? Or did you mean "The action might be in the runtime > object _receiving_ the message or outside of it"? > > -- Ed > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Thursday, April 08, 2010 9:24 AM > To: issues@omg.org; uml2-rtf@omg.org > Subject: RE: issue 15145 -- UML 2 RTF issue > > Ed, > > > Description aside, there is an explicit constraint that says "[1] > > The onPort must be a port on the receiver object." The description > > may express what the intent was, but this is not supported by either > > the constraint or the semantic specification. > > The term "receiver" means the target of the invocation. The target can > be the runtime object owning the action execution, or it can be another > object. (BTW, you can't set aside the descriptions, they are part of > the spec) > > > And I am not sure how the same meta-property can be used to handle > > invocations through ports of either the sending or receiving > > object. The typing of the target object is going to be different. I > > guess the semantics could depend on which type you used on the > > target input pin. > > It's always the port on the receiver (target). The action might be in > the runtime object sending the message or outside of it. > > Conrad > > > This mail has originated outside your organization, either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > > > The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. > > > This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: issue 15145 -- UML 2 RTF issue Date: Fri, 9 Apr 2010 10:31:01 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrXqxHZItTs6DdNT+ikWlRDISnuOwAPUo2AAAHVY7AAAE9UUA== From: "Ed Seidewitz" To: "BERNARD, Yves" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o39ELNZ1032633 Yves -- Yes, I think the specification in this overall area is inconsistent (overspecified) in some ways and underspecified in others (though Bran indicates that, to some extent, this underspecification was intentional). When we start work on UML 2.5, various merge increments, like the addition of onPort to InvocationAction in Clause 9.3.9, will be pulled together, so we can (finally) solve the semantic inconsistencies they have caused in a unified way. -- Ed -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 09, 2010 10:26 AM To: Ed Seidewitz; Birger Mø-Pedersen Cc: uml2-rtf@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, I think you demonstrate clearly that the specification is inconsistent there, and then shall be fixed. According to what I said in my previous message my feeling is that if we simply remove the constraint [1] of §9.3.9, that is clearly in contradiction with the description sub-clause of the same paragraph, most of the inconsistency is removed also... Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé vendredi 9 avril 2010 15:34 À: Birger Mø-Pedersen Cc : uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Birger -- My point (or one of them, at least) is exactly that you need to specify "r" (the object) in addition to "i" (the port). Subclause 9.3.9 adds the onPort property to InvocationAction, which is "i". But it doesn't explicitly state how "r" is to be specified. Now, 9.3.9 does say that the specified port is on the "receiving object" of the message. However, some invocation actions (e.g., CallBehaviorAction and BroadcastSignalAction) do not provide for the input of any "receiving object", so it is not clear what "r" would be for them. And those that do provide for the input of a "target object" (e.g., CallOperationAction, SendSignalAction and SendObjectAction) clearly have the semantics that the given object is the end object handling the message. That, indeed, seems to be the intended semantics of InvocationAction with onPort, but it does not correspond to the semantics of sending a message out through a "local" port of the object owning the invocation action. -- Ed -----Original Message----- From: Birger Mø-Pedersen [mailto:birger@ifi.uio.no] Sent: Friday, April 09, 2010 1:53 AM To: Ed Seidewitz Subject: Re: issue 15145 -- UML 2 RTF issue However, it cannot be so that the specification of an action has to contain an identification of the 'interaction point' by other means than by a port, in the same way as there is no need to identify a specific slot in order to specify an assignment to an attribute. In Java speak the remote identifier 'r.i' is enough to identify (in UML speak) the slot corresponding to 'i' in the object currently denoted by the slot identified by 'r'. /birger On 4/8/10 11:32 PM, Ed Seidewitz wrote: > Bernard -- > > You are right that the target doesn't have to have a reception to receive a signal. But that doesn't really affect the point that I was making. The fact remains that, in order to send a signal, you need to identify a target, and you can't do that just by pointing to a port. > > It is worth noting, though, that the primary reason to use a port is so that you can define the interfaces on that port. And the only way to indicate the provision or requirement of a signal through an interface is to put a reception on the interface. > > As to what an interaction point "should" be, that isn't the point, either. Subclause 9.3.11 defines an "interaction point" as the run-time instance in a port slot and therefore specifies what that "is" in UML, to the extent that it is well defined at all. > > -- Ed > > -----Original Message----- > From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] > Sent: Thursday, April 08, 2010 11:08 AM > To: uml2-rtf@omg.org > Subject: RE: issue 15145 -- UML 2 RTF issue > > > The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform > its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. > > There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. > > Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). > > Yves > > ----Message d'origine----- > De : Ed Seidewitz [mailto:ed-s@modeldriven.com] > Envoyé jeudi 8 avril 2010 16:14 > À: Bock, Conrad > Cc : issues@omg.org; uml2-rtf@omg.org > Objet : RE: issue 15145 -- UML 2 RTF issue > > Conrad -- > > First of all, not all invocations have targets. What is the "target > object" of a call behavior action? As I have noted previously, you can't > determine the target object at run-time from just a static reference to > a port -- you have to either get an explicit reference to the run-time > "interaction point" object in the port slot or to a run-time instance of > the encapsulated classifier owning the port. > > Second, if the run-time object is the object owning the action > execution, then the object will be sending a message to itself. For > invocation actions that have target objects (send signal action and call > object action), that is what they do -- send a message to the target > object. But the desired behavior under discussion was sending a message > _out_ through a required interface of a port of the sending object, not > invoking a behavior on the sending object itself. In that case the > target is the object at the other end of a connector from the local > port, and it is that object that would have to be the "target" of the > invocation action. > > Finally, I don't understand what you mean by your final sentence "The > action might be in the runtime object sending the message or outside of > it." Isn't it the very fact that the action is inside "the runtime > object sending the message" that makes it "the runtime object sending > the message"?? Or did you mean "The action might be in the runtime > object _receiving_ the message or outside of it"? > > -- Ed > > -----Original Message----- > From: Bock, Conrad [mailto:conrad.bock@nist.gov] > Sent: Thursday, April 08, 2010 9:24 AM > To: issues@omg.org; uml2-rtf@omg.org > Subject: RE: issue 15145 -- UML 2 RTF issue > > Ed, > > > Description aside, there is an explicit constraint that says "[1] > > The onPort must be a port on the receiver object." The description > > may express what the intent was, but this is not supported by either > > the constraint or the semantic specification. > > The term "receiver" means the target of the invocation. The target can > be the runtime object owning the action execution, or it can be another > object. (BTW, you can't set aside the descriptions, they are part of > the spec) > > > And I am not sure how the same meta-property can be used to handle > > invocations through ports of either the sending or receiving > > object. The typing of the target object is going to be different. I > > guess the semantics could depend on which type you used on the > > target input pin. > > It's always the port on the receiver (target). The action might be in > the runtime object sending the message or outside of it. > > Conrad > > > This mail has originated outside your organization, either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > > > The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. > > > This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz CC: Birger Mø-Pedersen , "uml2-rtf@omg.org" Date: Fri, 9 Apr 2010 17:40:42 -0700 Subject: Re: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrYRnOeAfHqQhvKQBCDgPuqPoKgaQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3A0X1vm003739 This example shows a confusion between concrete vs. abstract syntax. "r.i" is a concrete syntax expression in some language, perhaps Alf. If this expression is part of the concrete syntax form of an InvocationAction, then the result of parsing this concrete syntax and resolving the variables & identifiers would be a port object -- i.e., there is no change needed to 9.3.1 If you changed 9.3.1 so the InvocationAction would have an additional property to identify the object, then what would be the relationship between that object and the onPort : Port property? Wouldn't onPort have to become then the identifier of the port on the specified object rather than the port itself? If you were to force InvocationAction to use port identifiers, then I think that this would be a significant change to the UML. - Nicolas. On Apr 9, 2010, at 6:34 AM, Ed Seidewitz wrote: > Birger -- > > My point (or one of them, at least) is exactly that you need to specify "r" (the object) in addition to "i" (the port). Subclause 9.3.9 adds the onPort property to InvocationAction, which is "i". But it doesn't explicitly state how "r" is to be specified. > > Now, 9.3.9 does say that the specified port is on the "receiving object" of the message. However, some invocation actions (e.g., CallBehaviorAction and BroadcastSignalAction) do not provide for the input of any "receiving object", so it is not clear what "r" would be for them. And those that do provide for the input of a "target object" (e.g., CallOperationAction, SendSignalAction and SendObjectAction) clearly have the semantics that the given object is the end object handling the message. That, indeed, seems to be the intended semantics of InvocationAction with onPort, but it does not correspond to the semantics of sending a message out through a "local" port of the object owning the invocation action. > > -- Ed > > -----Original Message----- > From: Birger Mø-Pedersen [mailto:birger@ifi.uio.no] > Sent: Friday, April 09, 2010 1:53 AM > To: Ed Seidewitz > Subject: Re: issue 15145 -- UML 2 RTF issue > > However, it cannot be so that the specification of an action has to > contain an identification of the 'interaction point' by other means than > by a port, in the same way as there is no need to identify a specific > slot in order to specify an assignment to an attribute. In Java speak > the remote identifier 'r.i' is enough to identify (in UML speak) the > slot corresponding to 'i' in the object currently denoted by the slot > identified by 'r'. > > /birger > > On 4/8/10 11:32 PM, Ed Seidewitz wrote: >> Bernard -- >> >> You are right that the target doesn't have to have a reception to receive a signal. But that doesn't really affect the point that I was making. The fact remains that, in order to send a signal, you need to identify a target, and you can't do that just by pointing to a port. >> >> It is worth noting, though, that the primary reason to use a port is so that you can define the interfaces on that port. And the only way to indicate the provision or requirement of a signal through an interface is to put a reception on the interface. >> >> As to what an interaction point "should" be, that isn't the point, either. Subclause 9.3.11 defines an "interaction point" as the run-time instance in a port slot and therefore specifies what that "is" in UML, to the extent that it is well defined at all. >> >> -- Ed >> >> -----Original Message----- >> From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] >> Sent: Thursday, April 08, 2010 11:08 AM >> To: uml2-rtf@omg.org >> Subject: RE: issue 15145 -- UML 2 RTF issue >> >> >> The UML specification states that: "Required interfaces specify services that a classifier needs in order to perform >> its function and fulfill its own obligations to its clients". May be I miss something but I see nothing there that forbids to send a signal without an explicit reception on the target. >> >> There are many examples in the real life where systems broadcast a signal and it's not require this signal is used by something for them to work according to their specifications (a radio beacon, a speaker, a LED, ...). In such cases it would not be convenient to specify that those objects *require* a reception of the signal they sent because it is simply not true. >> >> Note also that if a port instance is actually an interaction *point* (and not a facade) it should have neither "inward" nor "outward" aspects but just provide a means to distinguish between two identical messages going out (or in) an object (when such a distinction is required). >> >> Yves >> >> ----Message d'origine----- >> De : Ed Seidewitz [mailto:ed-s@modeldriven.com] >> Envoyé jeudi 8 avril 2010 16:14 >> À: Bock, Conrad >> Cc : issues@omg.org; uml2-rtf@omg.org >> Objet : RE: issue 15145 -- UML 2 RTF issue >> >> Conrad -- >> >> First of all, not all invocations have targets. What is the "target >> object" of a call behavior action? As I have noted previously, you can't >> determine the target object at run-time from just a static reference to >> a port -- you have to either get an explicit reference to the run-time >> "interaction point" object in the port slot or to a run-time instance of >> the encapsulated classifier owning the port. >> >> Second, if the run-time object is the object owning the action >> execution, then the object will be sending a message to itself. For >> invocation actions that have target objects (send signal action and call >> object action), that is what they do -- send a message to the target >> object. But the desired behavior under discussion was sending a message >> _out_ through a required interface of a port of the sending object, not >> invoking a behavior on the sending object itself. In that case the >> target is the object at the other end of a connector from the local >> port, and it is that object that would have to be the "target" of the >> invocation action. >> >> Finally, I don't understand what you mean by your final sentence "The >> action might be in the runtime object sending the message or outside of >> it." Isn't it the very fact that the action is inside "the runtime >> object sending the message" that makes it "the runtime object sending >> the message"?? Or did you mean "The action might be in the runtime >> object _receiving_ the message or outside of it"? >> >> -- Ed >> >> -----Original Message----- >> From: Bock, Conrad [mailto:conrad.bock@nist.gov] >> Sent: Thursday, April 08, 2010 9:24 AM >> To: issues@omg.org; uml2-rtf@omg.org >> Subject: RE: issue 15145 -- UML 2 RTF issue >> >> Ed, >> >>> Description aside, there is an explicit constraint that says "[1] >>> The onPort must be a port on the receiver object." The description >>> may express what the intent was, but this is not supported by either >>> the constraint or the semantic specification. >> >> The term "receiver" means the target of the invocation. The target can >> be the runtime object owning the action execution, or it can be another >> object. (BTW, you can't set aside the descriptions, they are part of >> the spec) >> >>> And I am not sure how the same meta-property can be used to handle >>> invocations through ports of either the sending or receiving >>> object. The typing of the target object is going to be different. I >>> guess the semantics could depend on which type you used on the >>> target input pin. >> >> It's always the port on the receiver (target). The action might be in >> the runtime object sending the message or outside of it. >> >> Conrad >> >> >> This mail has originated outside your organization, either from an external partner or the Global Internet. >> Keep this in mind if you answer this message. >> >> >> >> >> The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. >> If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. >> Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. >> All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. >> >> >> > > From: "Bock, Conrad" To: "issues@omg.org" , "uml2-rtf@omg.org" Date: Fri, 23 Apr 2010 13:57:07 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAC+i5JEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Ed, > Second, if the run-time object is the object owning the action > execution, then the object will be sending a message to itself. For > invocation actions that have target objects (send signal action and > call object action), that is what they do -- send a message to the > target object. But the desired behavior under discussion was sending > a message _out_ through a required interface of a port of the > sending object, not invoking a behavior on the sending object > itself. In that case the target is the object at the other end of a > connector from the local port, and it is that object that would have > to be the "target" of the invocation action. That's where the message is forwarded, not the target. If the action is inside the object (the runtime object is executing the action), then when using onPort the target is the that runtime object. The semantics is that the message is forwarded out through the port. > Finally, I don't understand what you mean by your final sentence > "The action might be in the runtime object sending the message or > outside of it." Isn't it the very fact that the action is inside > "the runtime object sending the message" that makes it "the runtime > object sending the message"?? Or did you mean "The action might be > in the runtime object _receiving_ the message or outside of it"? If the action is outside the ported object (another runtime object is executing the action), then when using onPort, the target object is the instance of the class owning the port. The semantics is that the message is forwarded in through the port. > As I have noted previously, you can't determine the target object at > run-time from just a static reference to a port -- you have to > either get an explicit reference to the run-time "interaction point" > object in the port slot or to a run-time instance of the > encapsulated classifier owning the port. Right, but no one's saying you don't have a runtime target. > First of all, not all invocations have targets. What is the "target > object" of a call behavior action? Life goes on. :) We can go into behaviors being their own context object, but it doesn't matter to this case. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" , "issues@omg.org" Date: Fri, 23 Apr 2010 14:13:58 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAAChbDAAAKyF8AAAakCwAyk0vgA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Ed, > For example, suppose the invocation action is a call operation > action. Then the operation being called has to be an operation of > the type of the target object of the call. Suppose that this action > is inside a port-owning object and references a port of the type of > that object. It would seem that the type of the target object of the > action would have to be the very object that the action is inside, > since this is the "receiving object" of the invocation. However, the > invoked operation would then have to be on an operation of the > object the action is inside, which is certainly not what is intended > by "calling though" the required interface of a port! Yes, that's something onPort is working around. I think the SDL-like implementations treat the interfaces on the ports as if they were on the owning class. You can see this in the original U2P submission wording in the semantics of ports: When an instance of a classifier with a port is created, that instance is identifiable not just through its object identity, but also through a unique reference corresponding to each port (this reference is referred to as an interaction point). It is, therefore, possible for an instance to differentiate between requests for the invocation of a behavioral feature targeted at its different ports. The above was replaced at some point with the current text about runtime port objects as values of port properties. > Another problem is that the semantics in 9.3.9 refers to "the object > owning this port" and "port identity". However, in UML objects don't > own ports, classifiers do. An ports don't have independent identity, > they are properties of the classifiers of objects -- only the > objects have identity. This is just the usual shorthands in UML text that mix levels. I'd say it's more of a problem that it's using the terminology of the earlier U2P submission, rather than the updated port semantics. > So, the intent may have been to allow SDL-like semantics, but 9.3.9 > is in the Composite Structure clause, not the Component clause, and > I don't think the semantics really works in that context. Not sure why what difference the Clause makes. The general problem is how to accomodate the SDL optimization that eliminates runtime port objects and the current port semantics that written assuming runtime port objects. UML doesn't usually specify optimizations, but this one is so prevalent that it should be called out. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" CC: "issues@omg.org" Date: Fri, 23 Apr 2010 14:27:00 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrW7PZcNysEbA97QzW8rFTkmuSuOwAC9HTwAwYyKvA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Ed, > The problem is with the typing. The invoked behavior has to be a > feature of the target object. However, if you are trying to send the > message through a port of the sending object, the feature you want to > invoke will be on a required interface of the port, not a provided > interface. This means that the port type will have a usage dependency > on the required interface, not a realization, and the features of the > required interface will not be features of the port type. > In order to get a target object to feed into a send signal action or > call operation action, one would need to read the port as a > structural feature. And doing this using read structural feature > action would treat the port as an attribute, giving an object of the > port type. And one thing that is clear from the definition of Port in > Subclause 9.3.11 is that the type of a port realizes the provided > interfaces of the port. Hence, the available behavioral features of > an object obtained from a port (receptions or operations) will be > those from the provided interfaces, not the required interfaces. This is an central thing to address, but again, life doesn't come to end. It's one of the nice things about not being a theorem prover. :) If we need to build in special semantics for sending message to ports (and objects in general) from the inside versus the outside, let's get to the cleanup RFP and do it. Conrad Subject: RE: issue 15145 -- UML 2 RTF issue Date: Sat, 24 Apr 2010 09:44:25 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue thread-index: AcrW7PZcNysEbA97QzW8rFTkmuSuOwAC9HTwAwYyKvAAKGCFgA== From: "Ed Seidewitz" To: "Bock, Conrad" , Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3ODZ0bi000993 Conrad -- Catching up on old email threads, huh! In order to decide what to fix, we first have to agree on what is broken. I believe the description of the semantics of InvocationAction::onPort in the Composite Structure clause is broken and that the possibility of invocation actions having an onPort property is not properly accounted for in the general semantics for those actions given in the Actions clause. The whole point of the thread was to convince people that there really is an issue here that should be resolved. And, as I think I mentioned at some point in the original thread, I believe that this will be easier to resolve after (or even as part of) the spec simplification that will eliminate the separate merge increments for InvocationAction and allow us to describe all its semantics in one place. -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, April 23, 2010 2:27 PM To: uml2-rtf@omg.org Cc: issues@omg.org Subject: RE: issue 15145 -- UML 2 RTF issue Ed, > The problem is with the typing. The invoked behavior has to be a > feature of the target object. However, if you are trying to send the > message through a port of the sending object, the feature you want to > invoke will be on a required interface of the port, not a provided > interface. This means that the port type will have a usage dependency > on the required interface, not a realization, and the features of the > required interface will not be features of the port type. > In order to get a target object to feed into a send signal action or > call operation action, one would need to read the port as a > structural feature. And doing this using read structural feature > action would treat the port as an attribute, giving an object of the > port type. And one thing that is clear from the definition of Port in > Subclause 9.3.11 is that the type of a port realizes the provided > interfaces of the port. Hence, the available behavioral features of > an object obtained from a port (receptions or operations) will be > those from the provided interfaces, not the required interfaces. This is an central thing to address, but again, life doesn't come to end. It's one of the nice things about not being a theorem prover. :) If we need to build in special semantics for sending message to ports (and objects in general) from the inside versus the outside, let's get to the cleanup RFP and do it. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" CC: "issues@omg.org" Date: Mon, 26 Apr 2010 10:49:44 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrW7PZcNysEbA97QzW8rFTkmuSuOwAC9HTwAwYyKvAAKGCFgABnI8OQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Ed, > Catching up on old email threads, huh! This one is timeless. :) > In order to decide what to fix, we first have to agree on what is > broken. I believe the description of the semantics of > InvocationAction::onPort in the Composite Structure clause is broken > and that the possibility of invocation actions having an onPort > property is not properly accounted for in the general semantics for > those actions given in the Actions clause. Agreed, though I wouldn't use the term "broken" for something as unmechanical as the UML spec. Some major UML implementations work fine with the SDL-like optimization they see in the spec. From a standards point of view, however, it needs to be fixed so everyone can see it. > The whole point of the thread was to convince people that there > really is an issue here that should be resolved. And, as I think I > mentioned at some point in the original thread, I believe that this > will be easier to resolve after (or even as part of) the spec > simplification that will eliminate the separate merge increments for > InvocationAction and allow us to describe all its semantics in one > place. Thx for adding this to the subproblems on the port topic. The other you mentioned in the emails was sending messages from inside/outside to runtime port objects doesn't fit well with the semantics of interfaces currently. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Mon, 3 May 2010 13:59:15 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAAANbQ4AAOnP5QABF0ItAEz/ZY8A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o43Hp63Y016416 Yves, I numbered your spec quotes below for reference. > ðt is very clear that interactions are between the > object and its environment and NOT between the object and > the interaction point one side and between the interaction > point and the environment on the other side This isn't true for quote 8, and can't be true in general, since the purpose of ports is to allow the internals of object the be specified independently of the externals. The runtime interaction point (quote 7) is not an environmental object. In the other quotes the internals of an object are sometimes called "the object," but the request comes from inside the object, through the port, then to the environment. > ðt is then very clear also that this semantic does not > authorize any kind of modification on the request going > through a port. The only operation that a port performs on > a request is routing. Couldn't find anything about this in the quotes. Forwarding doesn't restrict modifications of the forwarded object. an official shortcut > to refer to the corresponding interaction point... And quote 7 says interaction points are the runtime values of ports (ports are properties and can have values like any other odcast, what make sense to me. Yes, where interaction points are runtime values of ports (as properties). Conrad 1) The required interfaces of a port characterize the requests that may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port 2) A port has the ability to specify that any requests arriving at this port are handled by the behavior of the instance of the owning classifier, rather than being forwarded to any contained instances, if any 3) A port represents an interaction point between a classifier instance and its environment or between a classifier instance and instances it may contain 4) The required interfaces characterize services that the owning classifier expects from its environment and that it may access through this interaction point: Instances of this classifier expect that the features owned by its required interfaces will be offered by one or more instances in its environment 5) 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. 6) The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port 7) When an instance of a classifier is created, instances de unique references. A link from that instance to the instance of the owning classifier is created through which communication is forwarded to the instance of the owning classifier or through which the owning classifier communicates with its environment. It is, therefore, possible for an instance to differentiate between requests for the invocation of a behavioral feature targeted at its different ports lt occurrences arriving at the interaction point of this instance corresponding to this port. 8) Similarly, it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this ports arriving at a port. corresponding to each of its ports are created and held in the slots specified by the ports, in accordance with its multiplicity. pointsin shorthand in quote 8 is the usual kind in UML that confuses the user model with .nnel > restrictede. > with the current specification can be seen as a kind of runtime. ncept > of port is very similar to the IP concept of port: a kind > of communication channel that exists at run-time even if it > remains purely virtual, with no inward or outward aspects. po > targeting a > ant ðhus, any capability offered to a port thanks to the > kind of classifier it has for type results from unexpected > inheritance and should be explicitly restricted with > appropriate constraints (RTF scope) po ubject: RE: issue 15145 -- UML 2 RTF issue Date: Tue, 4 May 2010 09:51:21 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAAANbQ4AAOnP5QABF0ItAEz/ZY8AAcJr4w From: "BERNARD, Yves" To: "Bock, Conrad" Cc: X-OriginalArrivalTime: 04 May 2010 07:51:21.0609 (UTC) FILETIME=[96644F90:01CAEB5E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o447g3h3006206 Conrad, See my answers below. Yves -----Message d'origine----- De : Bock, Conrad [mailto:conrad.bock@nist.gov] Envoyé lundi 3 mai 2010 19:59 À: uml2-rtf@omg.org Objet : RE: issue 15145 -- UML 2 RTF issue Yves, I numbered your spec quotes below for reference. > ðt is very clear that interactions are between the > object and its environment and NOT between the object and > the interaction point one side and between the interaction > point and the environment on the other side This isn't true for quote 8, and can't be true in general, since the purpose of ports is to allow the internals of object the be specified independently of the externals. The runtime interaction point (quote 7) is not an environmental object. In the other quotes the internals of an object are sometimes called "the object," but the request comes from inside the object, through the port, then to the environment. [BERNARD, Yves] Any object that requires anything from its environment cannot be specified independently from the externals, only from the way that "externals" is organized. Cf. §9.3.11, Association sub clause, p181: "/required: Interface [*] References the interfaces specifying the set of operations and receptions that the classifier expects its environment to handle via this port." My understanding is that a port shall not be considered as an element from inside or from outside an object but as something on the boundary between an object and its environment. From inside the object it is an abstraction of the external, from the externals, it is an abstraction of the object. > ðt is then very clear also that this semantic does not > authorize any kind of modification on the request going > through a port. The only operation that a port performs on > a request is routing. Couldn't find anything about this in the quotes. Forwarding doesn't restrict modifications of the forwarded object. [BERNARD, Yves] If a data or a request is modified it's no more the same data or the same request. Cf. the spec quotted above where it is the environment and not the port is expected to process the request. See also the corresponding for the provided interfaces, same subclause, same page: "References the interfaces specifying the set of operations and receptions that the classifier offers to its environment via this port, and which it will handle either directly or by forwarding it to a part of its internal structure" > ðhus, any capability offered to a port thanks to the > kind of classifier it has for type results from unexpected > inheritance and should be explicitly restricted with > appropriate constraints (RTF scope) Again not following, which quote supports this? an official shortcut > to refer to the corresponding interaction point... And quote 7 says interaction points are the runtime values of ports (ports are properties and can have values like any other property). The shorthand in quote 8 is the usual kind in UML that confuses the user model with runtime. [BERNARD, Yves] Ok, thus you should raise an issue on that point. ncept > of port is very similar to the IP concept of port: a kind > of communication channel that exists at run-time even if it > remains purely virtual, with no inward or outward aspects. This isn't true for quote 8. dcast, what make sense to me. Yes, where interaction points are runtime values of ports (as properties). Conrad 1) The required interfaces of a port characterize the requests that may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port 2) A port has the ability to specify that any requests arriving at this port are handled by the behavior of the instance of the owning classifier, rather than being forwarded to any contained instances, if any 3) A port represents an interaction point between a classifier instance and its environment or between a classifier instance and instances it may contain 4) The required interfaces characterize services that the owning classifier expects from its environment and that it may access through this interaction point: Instances of this classifier expect that the features owned by its required interfaces will be offered by one or more instances in its environment 5) 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. 6) The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port 7) When an instance of a classifier is created, instances de unique references. A link from that instance to the instance of the owning classifier is created through which communication is forwarded to the instance of the owning classifier or through which the owning classifier communicates with its environment. It is, therefore, possible for an instance to differentiate between requests for the invocation of a behavioral feature targeted at its different ports 8) Similarly, it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port. (In the following, "requests arriving at a port "shall mean "request occurrences arriving at the interaction point of this instance corresponding to this port")" This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. corresponding to each of its ports are created and held in the slots specified by the ports, in accordance with its on pointsiplicity. .nnel > restrictede. > with the current specification can be seen as a kind of [BERNARD, Yves] I do not see what point in quote 8 does not match. Please explain. po > targeting a [BERNARD, Yves] None. From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Tue, 4 May 2010 09:55:41 -0400 Subject: RE: issue 15145 -- UML 2 RTF issue Thread-Topic: issue 15145 -- UML 2 RTF issue Thread-Index: AcrWXcuyAEApj/WHQRiXqixt8txaWQABYeRQAADLUJAAAJR7AAAtU8iQAAGNhfAAANbQ4AAOnP5QABF0ItAEz/ZY8AAcJr4wAA2IilA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o44Djd6O031612 Yves, > This isn't true for quote 8, and can't be true in general, since the > purpose of ports is to allow the internals of object the be > specified independently of the externals. The runtime interaction > point (quote 7) is not an environmental object. In the other quotes > the internals of an object are sometimes called "the object," but > the request comes from inside the object, through the port, then to > the environment. > [BERNARD, Yves] Any object that requires anything from its > environment cannot be specified independently from the externals, > only from the way that "externals" is organized. Cf. §9.3.11, > Association sub clause, p181: "/required: Interface [*] References > the interfaces specifying the set of operations and receptions that > the classifier expects its environment to handle via this port." Sure, but the object is still specified separately and independently of the environment. A class might be defined before, after, or during the specification of its environment, by different or the same people. This is the pupose of interfaces and ports. This means sending to a port from the inside is not the same as sending to the environment, see your quotes 8 and 7. > My understanding is that a port shall not be considered as > an element from inside or from outside an object but as > something on the boundary between an object and its > environment. From inside the object it is an abstraction of > the external, from the externals, it is an abstraction of > the object. Make sense, but the symmetry isn't total. A port is owned by a class, not the environment of the class, so the port isn't "in between" a class and its environment, it's in the class. Same for the runtime values of ports (interaction points), which are owned by the runtime instance of the class. > > ðt is then very clear also that this semantic does not > > authorize any kind of modification on the request going > > through a port. The only operation that a port performs on > > a request is routing. > > Couldn't find anything about this in the quotes. Forwarding doesn't > restrict modifications of the forwarded object. > > [BERNARD, Yves] If a data or a request is modified it's no > more the same data or the same request. Not exactly the same, but it has the same identity. For example in SysML, water flowing through a port might be heated as it goes through. It's the same water, with different property values. > Cf. the spec quotted above where it is the environment and not the > port is expected to process the request. See also the corresponding > for the provided interfaces, same subclause, same page: "References > the interfaces specifying the set of operations and receptions that > the classifier offers to its environment via this port, and which it > will handle either directly or by forwarding it to a part of its > internal structure" Yes, the environment can handle the request, but this doesn't prevent a port from modifying properties of the request. Modifying the flowing item's properties doesn't handle anything. > > ðhus, any capability offered to a port thanks to the > > kind of classifier it has for type results from unexpected > > inheritance and should be explicitly restricted with > > appropriate constraints (RTF scope) > > Again not following, which quote supports this? > > [BERNARD, Yves] None. It's my analysis according to the > previous points. Sorry, I still can't follow this or see it suggested anywhere else. The runtime value of a port (the interation point) is classified by the type of the port and "inherits" its characteristics. There's nothing unintended. > And quote 7 says interaction points are the runtime values of ports > (ports are properties and can have values like any other property). > The shorthand in quote 8 is the usual kind in UML that confuses the > user model with runtime. > [BERNARD, Yves] Ok, thus you should raise an issue on that point. At least in this case the spec defines the shortcut. :) ncept of port is very similar to the IP concept of port: a > > kind of communication channel that exists at run-time even if it > > remains purely virtual, with no inward or outward aspects. > This isn't true for quote 8. > > [BERNARD, Yves] I do not see what point in quote 8 does not > match. Please explain. Each request you make on the Net is directed > to an IP port, even if you don't specify it explicitly most of the > time. I guess you're right about lack of inward/outward, since quote 8 doesn't say anything about the direction of routing, but ports are still have an owning class, as do connectors, so the inside/outside aspects are inherent in the metamodel. This causes the problem Eran and Eldad have pointed out that the interfaces on the port only "work" in one direction, if you follow the letter of the spec. But there might be wording that deals with this somewhere. If not, we can add it. Conrad