Issue 18131: 17 Semantics of interactions (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Consider Figure 17.2 (in the UML2.5 Revised August draft): Clearly we expect that: "oper1()" is a Message whose Message::signature refers to A::oper1() "callback()" is a Message whose Message::signature refers to C::callback() However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message. In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3) The spec does not currently specify any kind of bound on this resolution process — that is, Behaviors could be found potentially anywhere in the model. This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B. Resolution: Revised Text: Actions taken: October 2, 2012: received issue Discussion: From: <Wendland>, Marc-Florian <marc-florian.wendland@fokus.fraunhofer.de> Date: Tuesday, October 2, 2012 12:02 AM To: JPL <nicolas.f.rouquette@jpl.nasa.gov>, "uml-spec-simplification@omg.org" <uml-spec-simplification@omg.org> Subject: AW: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Hi Nicolas, I don’t think that this has been filed yet. I flicked briefly through the Interaction-related issues in preparation for my contribution to FTF. However, I might have overlooked something, of course. Anyway, I agree that there is a need for more clarification on this, however, I don’t think that this is a trivial thing due to the very flexible concepts of Messages etc. There are several possibilities where those Operations can be located, respectively what Operations are actually invokable via that Message. Possible locations for any invoked BehavioralFeatures <!--[if !supportLists]-->1. <!--[endif]-->Directly owned or inherited by the Type of the ConnectableElement the Lifeline represents (simplest possibility) <!--[if !supportLists]-->2. <!--[endif]-->Directly owned or inherited by the Type of a Port of the ConnectableElement the Lifeline represents <!--[if !supportLists]-->3. <!--[endif]-->Directly owned or inherited by a realized (via InterfaceRealization) Interface of the Type of a Port of the ConnectableElement the Lifeline represents – we are using this kind of BehavioralFeature offering a lot when modeling test architectures with UTP Offered BehavioralFeatures for a Message sent via Connector <!--[if !supportLists]-->4. <!--[endif]-->If the Message is send via a specific Connector that is connected to a Port (e.g., owned by C), only those BehavioralFeatures are allowed to be invoked by the Message which are offered by the Type of the Port that is connected by the Connector over which the Message is sent – we are using this kind of Message sending when modeling test cases with UTP that can be executed via TTCN-3 or JUnit etc. These are just four possible ways on how to determine the offered BehavioralFeature of a called Lifeline. I guess there are even more. In any case, your statement “This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B.” Is not absurd, but for what we doing a normal matter of fact. In that case B would be a (I call them InterfaceComponent, simply a Type of a Port that realizes Interfaces) Type of a Port that is connected with a Connector over which the Message is sent. But I agree: There is a need to identify and clarify all possibilities for invoking a Behavior. Regards, Marc-Florian End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Oct 2012 14:23:09 -0400 To: issues@omg.org, uml25-ftf@omg.org From: Juergen Boldt Subject: issue 18131 -- UML 2.5 FTF issue From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "Wendland, Marc-Florian" , Steve Cook Subject: UML2.5 issue in clause 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Thread-Topic: UML2.5 issue in clause 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Thread-Index: AQHNnaULudE+Xe1KdUyBbtebIrdf0Zelk3zggADC1AA= Date: Tue, 2 Oct 2012 18:07:43 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Juergen, Please file the last message as an issue for UML 2.5 and attach Marc's reply to the discussion of that issue. - Nicolas. From: , Marc-Florian < marc-florian.wendland@fokus.fraunhofer.de> Date: Tuesday, October 2, 2012 12:02 AM To: JPL < nicolas.f.rouquette@jpl.nasa.gov>, " uml-spec-simplification@omg.org" < uml-spec-simplification@omg.org> Subject: AW: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Hi Nicolas, I don.t think that this has been filed yet. I flicked briefly through the Interaction-related issues in preparation for my contribution to FTF. However, I might have overlooked something, of course. Anyway, I agree that there is a need for more clarification on this, however, I don.t think that this is a trivial thing due to the very flexible concepts of Messages etc. There are several possibilities where those Operations can be located, respectively what Operations are actually invokable via that Message. Possible locations for any invoked BehavioralFeatures 1. Directly owned or inherited by the Type of the ConnectableElement the Lifeline represents (simplest possibility) 2. Directly owned or inherited by the Type of a Port of the ConnectableElement the Lifeline represents 3. Directly owned or inherited by a realized (via InterfaceRealization) Interface of the Type of a Port of the ConnectableElement the Lifeline represents . we are using this kind of BehavioralFeature offering a lot when modeling test architectures with UTP Offered BehavioralFeatures for a Message sent via Connector 4. If the Message is send via a specific Connector that is connected to a Port (e.g., owned by C), only those BehavioralFeatures are allowed to be invoked by the Message which are offered by the Type of the Port that is connected by the Connector over which the Message is sent . we are using this kind of Message sending when modeling test cases with UTP that can be executed via TTCN-3 or JUnit etc. These are just four possible ways on how to determine the offered BehavioralFeature of a called Lifeline. I guess there are even more. In any case, your statement .This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B.. Is not absurd, but for what we doing a normal matter of fact. In that case B would be a (I call them InterfaceComponent, simply a Type of a Port that realizes Interfaces) Type of a Port that is connected with a Connector over which the Message is sent. But I agree: There is a need to identify and clarify all possibilities for invoking a Behavior. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [ mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Freitag, 28. September 2012 20:14 An: uml-spec-simplification@omg.org Betreff: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) This question came up in a forum at NASA's Systems Engineering "early adopters" group (folks from several NASA centers) Consider Figure 17.2 (in the UML2.5 Revised August draft): Clearly we expect that: "oper1()" is a Message whose Message::signature refers to A::oper1() "callback()" is a Message whose Message::signature refers to C::callback() However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message. In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3) The spec does not currently specify any kind of bound on this resolution process . that is, Behaviors could be found potentially anywhere in the model. This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B. Has this issue already been filed? - Nicolas. image00131.png Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org From: "Wendland, Marc-Florian" To: "Rouquette, Nicolas F (313K)" , "Manfred R. Koethe" , "" Subject: Issue 18131 Thread-Topic: Issue 18131 Thread-Index: Ac5tg/2stAKEh8I2RYyxfYZV/qBH8A== Date: Thu, 20 Jun 2013 07:01:44 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.37.77.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml25-ftf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate02-dus with A7B733880034 X-cloud-security: scantime:.2574 X-Virus-Scanned: amavisd-new at omg.org Guys, I agree that the situation resulting from 18131 is not very good, however, as long as we are not able to substantially change the metamodel, we do not have chance to make real progress on Interactions. Everything we do in 2.5 for Interactions is clarification, where some things would need a substantial revision and not an editorial clarification. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Mittwoch, 19. Juni 2013 23:29 An: Manfred R. Koethe; Betreff: Re: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Manfred, NASA votes yes on all resolutions in ballot 6 except for 18131 for which it votes no. Closing this issue no-change means that UML 2.5 will provide no practical utility to UML interactions. Without being able to determine, according to the UML spec, what a particular MessageOccurenceSpecification or ExecutionOccurenceSpecification actually refers to in terms of a particular Operation, Signal or Action means that the meaning of UML interaction diagrams will be left unspecified in UML 2.5. Anyone claiming to "understand" UML 2.5 interaction diagrams will be basically doing so on the basis of a semantics that is not defined in the UML 2.5 spec . I.e., it's someone's semantics, some tool's semantics, something invented, ... I am not sure how to fix this issue . the discussion raises a valid point about avoiding over-constraining UML 2.5; however, we cannot leave the situation as-is . I.e., completely unconstrained . because doing so leaves the meaning of UML interactions semantically vacuous. Nicolas. From: Manfred Koethe Date: Wednesday, June 19, 2013 2:02 PM To: "uml25-ftf@omg.org" Subject: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Dear Colleagues, Nerijus pointed out that the reasoning texts for issues 18131 and 18699 had been flipped. This is corrected in Revision 2 of Ballot 6 for the UML 2.5 FTF. Since both issues have a disposition of "Close - No Change", the net effect of the ballot has not changed. (Nerijus, you may reconsider your vote now...) The ballot period remains unchanged, it was and is: ==> Poll start date: Saturday, 15 June 2013 (01:00 AM EDT - 06:00 GMT) ==> Poll closing date: Sunday, 23 June 2013 (7:00 PM EDT - 24:00 GMT) All votes I received so far will be carried over, you have however the right to change your vote as often as you like during the voting period... Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Steve Cook To: "Wendland, Marc-Florian" , "Rouquette, Nicolas F (313K)" , "Manfred R. Koethe" , "" Subject: RE: Issue 18131 Thread-Topic: Issue 18131 Thread-Index: Ac5tg/2stAKEh8I2RYyxfYZV/qBH8AAA9LsQ Date: Thu, 20 Jun 2013 07:29:50 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(71364002)(189002)(5403001)(377454003)(76796001)(74366001)(16406001)(47446002)(63696002)(31966008)(47736001)(46102001)(80022001)(16236675002)(76482001)(65816001)(4396001)(71186001)(81342001)(74876001)(6806003)(74502001)(47976001)(74662001)(76786001)(79102001)(54316002)(50986001)(56816003)(55846006)(54356001)(53806001)(20776003)(15202345003)(33656001)(77982001)(49866001)(16601075003)(69226001)(74706001)(51856001)(81542001)(59766001)(77096001)(44976003)(512954002)(56776001)(19300405003)(491001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB032;H:TK5EX14MLTC103.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08831F51DC X-Virus-Scanned: amavisd-new at omg.org Perhaps then the issue should be classified as an Enhancement, in which case it should be deferred and not closed. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 20 June 2013 08:02 To: Rouquette, Nicolas F (313K); Manfred R. Koethe; Subject: Issue 18131 Guys, I agree that the situation resulting from 18131 is not very good, however, as long as we are not able to substantially change the metamodel, we do not have chance to make real progress on Interactions. Everything we do in 2.5 for Interactions is clarification, where some things would need a substantial revision and not an editorial clarification. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Mittwoch, 19. Juni 2013 23:29 An: Manfred R. Koethe; Betreff: Re: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Manfred, NASA votes yes on all resolutions in ballot 6 except for 18131 for which it votes no. Closing this issue no-change means that UML 2.5 will provide no practical utility to UML interactions. Without being able to determine, according to the UML spec, what a particular MessageOccurenceSpecification or ExecutionOccurenceSpecification actually refers to in terms of a particular Operation, Signal or Action means that the meaning of UML interaction diagrams will be left unspecified in UML 2.5. Anyone claiming to "understand" UML 2.5 interaction diagrams will be basically doing so on the basis of a semantics that is not defined in the UML 2.5 spec . I.e., it's someone's semantics, some tool's semantics, something invented, ... I am not sure how to fix this issue . the discussion raises a valid point about avoiding over-constraining UML 2.5; however, we cannot leave the situation as-is . I.e., completely unconstrained . because doing so leaves the meaning of UML interactions semantically vacuous. Nicolas. From: Manfred Koethe Date: Wednesday, June 19, 2013 2:02 PM To: "uml25-ftf@omg.org" Subject: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Dear Colleagues, Nerijus pointed out that the reasoning texts for issues 18131 and 18699 had been flipped. This is corrected in Revision 2 of Ballot 6 for the UML 2.5 FTF. Since both issues have a disposition of "Close - No Change", the net effect of the ballot has not changed. (Nerijus, you may reconsider your vote now...) The ballot period remains unchanged, it was and is: ==> Poll start date: Saturday, 15 June 2013 (01:00 AM EDT - 06:00 GMT) ==> Poll closing date: Sunday, 23 June 2013 (7:00 PM EDT - 24:00 GMT) All votes I received so far will be carried over, you have however the right to change your vote as often as you like during the voting period... Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- Subject: Re: Issue 18131 From: "Manfred R. Koethe" Date: Thu, 20 Jun 2013 08:07:14 -0700 Cc: "Wendland, Marc-Florian" , "Rouquette, Nicolas F (313K)" , "" To: Steve Cook X-Mailer: Apple Mail (2.1508) X-Provags-ID: V02:K0:HalklU9RjkcVmUpHkpmITC9BJ87CFt9LG/rtbydCyRv lXbbZcK1dHcGMF3/IpO6zKpg14vEbXB4p420MjKggADJo1ty6U maAZE2y3ULYF1SE8NP1npmYUmzgIit6jvwVAbOe5FcMDlCCiDx DV350hYV3UFARGnBsremvMbVuMcitdEY1LqK6xQn8kdnugA1Yh vqlCFfX3u9jHy3aGZr8gFrDTDDxyjGzWwS3OiW5TAPjt3ViEEQ EoX+E7y37beIxCnLm5qibgyYvYw5a95ugsiP2la86x4uI1pHMY QakwS5VYtgXEyjGsDAy6fJeHKMrQ2kh14JmBdhgamxJ+8HbBGE dc4JENitkFhFbYFVhSQEGIrpYWKGFWoD/Y2qyatmzV0rM8wkc6 ZfWqZcUuMBT6w== X-Virus-Scanned: amavisd-new at omg.org So then I suggest we pull 18131 from Ballot 6 and feed it into Ballot 7 with disposition "Deferred". If this is ok, with the rest of you, I will remove 18131 from Ballot 6. Let me know quickly. Manfred On Jun 20, 2013, at 0:29 , Steve Cook wrote: Perhaps then the issue should be classified as an Enhancement, in which case it should be deferred and not closed. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 20 June 2013 08:02 To: Rouquette, Nicolas F (313K); Manfred R. Koethe; Subject: Issue 18131 Guys, I agree that the situation resulting from 18131 is not very good, however, as long as we are not able to substantially change the metamodel, we do not have chance to make real progress on Interactions. Everything we do in 2.5 for Interactions is clarification, where some things would need a substantial revision and not an editorial clarification. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Mittwoch, 19. Juni 2013 23:29 An: Manfred R. Koethe; Betreff: Re: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Manfred, NASA votes yes on all resolutions in ballot 6 except for 18131 for which it votes no. Closing this issue no-change means that UML 2.5 will provide no practical utility to UML interactions. Without being able to determine, according to the UML spec, what a particular MessageOccurenceSpecification or ExecutionOccurenceSpecification actually refers to in terms of a particular Operation, Signal or Action means that the meaning of UML interaction diagrams will be left unspecified in UML 2.5. Anyone claiming to "understand" UML 2.5 interaction diagrams will be basically doing so on the basis of a semantics that is not defined in the UML 2.5 spec . I.e., it's someone's semantics, some tool's semantics, something invented, ... I am not sure how to fix this issue . the discussion raises a valid point about avoiding over-constraining UML 2.5; however, we cannot leave the situation as-is . I.e., completely unconstrained . because doing so leaves the meaning of UML interactions semantically vacuous. Nicolas. From: Manfred Koethe Date: Wednesday, June 19, 2013 2:02 PM To: "uml25-ftf@omg.org" Subject: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Dear Colleagues, Nerijus pointed out that the reasoning texts for issues 18131 and 18699 had been flipped. This is corrected in Revision 2 of Ballot 6 for the UML 2.5 FTF. Since both issues have a disposition of "Close - No Change", the net effect of the ballot has not changed. (Nerijus, you may reconsider your vote now...) The ballot period remains unchanged, it was and is: ==> Poll start date: Saturday, 15 June 2013 (01:00 AM EDT - 06:00 GMT) ==> Poll closing date: Sunday, 23 June 2013 (7:00 PM EDT - 24:00 GMT) All votes I received so far will be carried over, you have however the right to change your vote as often as you like during the voting period... Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- signature26.asc signature26.asc From: Steve Cook To: "Manfred R. Koethe" CC: "Wendland, Marc-Florian" , "Rouquette, Nicolas F (313K)" , "" Subject: RE: Issue 18131 Thread-Topic: Issue 18131 Thread-Index: Ac5tg/2stAKEh8I2RYyxfYZV/qBH8AAA9LsQABAB/wAAIGQyUA== Date: Fri, 21 Jun 2013 06:35:30 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454002)(377454003)(71364002)(5403001)(189002)(199002)(63696002)(53806001)(16406001)(74706001)(65816001)(47446002)(47736001)(33656001)(4396001)(16236675002)(55846006)(56776001)(74662001)(47976001)(74876001)(59766001)(49866001)(51856001)(15202345003)(77096001)(77982001)(50986001)(74502001)(79102001)(74366001)(19300405004)(54316002)(31966008)(76786001)(81542001)(16601075003)(44976004)(6806003)(71186001)(69226001)(81342001)(20776003)(56816003)(512954002)(46102001)(80022001)(76482001)(54356001)(76796001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB011;H:TK5EX14HUBC103.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0884AAA693 X-Virus-Scanned: amavisd-new at omg.org Manfred . sorry I didn.t reply, time zone and connectivity issues. I fully agree with what you did. From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: 20 June 2013 16:07 To: Steve Cook Cc: Wendland, Marc-Florian; Rouquette, Nicolas F (313K); Subject: Re: Issue 18131 So then I suggest we pull 18131 from Ballot 6 and feed it into Ballot 7 with disposition "Deferred". If this is ok, with the rest of you, I will remove 18131 from Ballot 6. Let me know quickly. Manfred On Jun 20, 2013, at 0:29 , Steve Cook wrote: Perhaps then the issue should be classified as an Enhancement, in which case it should be deferred and not closed. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 20 June 2013 08:02 To: Rouquette, Nicolas F (313K); Manfred R. Koethe; Subject: Issue 18131 Guys, I agree that the situation resulting from 18131 is not very good, however, as long as we are not able to substantially change the metamodel, we do not have chance to make real progress on Interactions. Everything we do in 2.5 for Interactions is clarification, where some things would need a substantial revision and not an editorial clarification. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Mittwoch, 19. Juni 2013 23:29 An: Manfred R. Koethe; Betreff: Re: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Manfred, NASA votes yes on all resolutions in ballot 6 except for 18131 for which it votes no. Closing this issue no-change means that UML 2.5 will provide no practical utility to UML interactions. Without being able to determine, according to the UML spec, what a particular MessageOccurenceSpecification or ExecutionOccurenceSpecification actually refers to in terms of a particular Operation, Signal or Action means that the meaning of UML interaction diagrams will be left unspecified in UML 2.5. Anyone claiming to "understand" UML 2.5 interaction diagrams will be basically doing so on the basis of a semantics that is not defined in the UML 2.5 spec . I.e., it's someone's semantics, some tool's semantics, something invented, ... I am not sure how to fix this issue . the discussion raises a valid point about avoiding over-constraining UML 2.5; however, we cannot leave the situation as-is . I.e., completely unconstrained . because doing so leaves the meaning of UML interactions semantically vacuous. Nicolas. From: Manfred Koethe Date: Wednesday, June 19, 2013 2:02 PM To: "uml25-ftf@omg.org" Subject: {UML 2.5 FTF] Ballot 6 - Revision 2 --- PLEASE VOTE (if you have not done so already) Dear Colleagues, Nerijus pointed out that the reasoning texts for issues 18131 and 18699 had been flipped. This is corrected in Revision 2 of Ballot 6 for the UML 2.5 FTF. Since both issues have a disposition of "Close - No Change", the net effect of the ballot has not changed. (Nerijus, you may reconsider your vote now...) The ballot period remains unchanged, it was and is: ==> Poll start date: Saturday, 15 June 2013 (01:00 AM EDT - 06:00 GMT) ==> Poll closing date: Sunday, 23 June 2013 (7:00 PM EDT - 24:00 GMT) All votes I received so far will be carried over, you have however the right to change your vote as often as you like during the voting period... Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)--------