Issue 12167: inability to specify ordering of messages connected to gates is problematic (uml2-rtf) Source: International Business Machines (Mr. James Bruck, nobody) Nature: Uncategorized Issue Severity: Summary: In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Resolution: Revised Text: Actions taken: January 8, 2008: receive dissue Discussion: End of Annotations:===== c: Dusko Misic , Anthony Hunter Subject: Issue with the UML superstructure spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Tue, 8 Jan 2008 15:48:52 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/08/2008 15:48:53, Serialize complete at 01/08/2008 15:48:53 Hi Juergen, I would like to raise the following issue with the spec. --------------------------------------------------- In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Cheers, - James. X-Ninja-PIM: Scanned by Ninja Subject: RE: issue 12167 -- UML 2 RTF issue Date: Thu, 10 Jan 2008 11:22:54 +0100 Thread-Topic: issue 12167 -- UML 2 RTF issue Thread-Index: AchS/+cDEOCZI3xHSn6dBHdHCXNfZgAcHYZw From: Haugen Øystein To: Juergen Boldt , issues@omg.org, uml2-rtf@omg.org, jbruck@ca.ibm.com Cc: Haugen Øystein X-OriginalArrivalTime: 10 Jan 2008 10:24:51.0014 (UTC) FILETIME=[08913E60:01C85373] James Bruck etc. I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: 1. Nothing happens at a gate. There is no output or input that happens there. A gate is a point of connection that logically combines message pieces from within a referenced diagram with message pieces outside the reference to said diagram. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. 5. If your desire is to order events on an interface, I would suggest to use ports as interface descriptions on a composite structure. Ports are ConnectableElements and can be represented by Lifelines and then occurrence specifications can be ordered on those Lifelines. Regards, Oystein Haugen ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 9. januar 2008 21:29 To: issues@omg.org; uml2-rtf@omg.org Subject: issue 12167 -- UML 2 RTF issue To: juergen@omg.org Cc: Dusko Misic , Anthony Hunter Subject: Issue with the UML superstructure spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Tue, 8 Jan 2008 15:48:52 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/08/2008 15:48:53, Serialize complete at 01/08/2008 15:48:53 Hi Juergen, I would like to raise the following issue with the spec. --------------------------------------------------- In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Cheers, - James. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org To: Haugen Øystein Cc: issues@omg.org, Juergen Boldt , Haugen Øystein , uml2-rtf@omg.org Subject: RE: issue 12167 -- UML 2 RTF issue X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Thu, 10 Jan 2008 10:46:36 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/10/2008 10:46:40, Serialize complete at 01/10/2008 10:46:40 Thanks for the reply. Some responses below... I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: The problem of ordering happens when we have gates on both end of the message. Say we have two gates on an interaction 'connected' to two corresponding gates on some InteractionUse (in the interior) (see the picture below). In this scenario, we cannot say that one message occurs before the other. Semantically, there would be no way to determine which message occurrs first, or am I missing something obvious. We can also come up with more difficult examples of messages between gates that are on InteractionUse. Without knowing about the contents of the InteractionUse (which may not be possible in practical modeling scenarios) we do not know the order. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. Yes. The order of messages can be inferred from the (ordered) MessageOccurrenceSpecifications at the ends of the Message can they not? 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. The 'in general' part has me a bit concerned. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. Should the spec. clarify the following case: In such a case, could M2 happen before M1? Regards, - James. Haugen Øystein 01/10/2008 05:22 AM To Juergen Boldt , issues@omg.org, uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA cc Haugen Øystein Subject RE: issue 12167 -- UML 2 RTF issue James Bruck etc. I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: 1. Nothing happens at a gate. There is no output or input that happens there. A gate is a point of connection that logically combines message pieces from within a referenced diagram with message pieces outside the reference to said diagram. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. 5. If your desire is to order events on an interface, I would suggest to use ports as interface descriptions on a composite structure. Ports are ConnectableElements and can be represented by Lifelines and then occurrence specifications can be ordered on those Lifelines. Regards, Oystein Haugen ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 9. januar 2008 21:29 To: issues@omg.org; uml2-rtf@omg.org Subject: issue 12167 -- UML 2 RTF issue To: juergen@omg.org Cc: Dusko Misic , Anthony Hunter Subject: Issue with the UML superstructure spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Tue, 8 Jan 2008 15:48:52 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/08/2008 15:48:53, Serialize complete at 01/08/2008 15:48:53 Hi Juergen, I would like to raise the following issue with the spec. --------------------------------------------------- In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Cheers, - James. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Nerijus Jankevicius" To: Haugen Øystein , "James Bruck" Cc: , "Juergen Boldt" , Haugen Øystein , Subject: Re: issue 12167 -- UML 2 RTF issue Date: Mon, 14 Jan 2008 16:43:42 +0200 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 James, Your example illustrates even more problems. In case both message ends are Gates, it's not possible to use events (CallEvent, SendEvent, DestroyEvent etc), because event could be used on MessageOccurenceSpecification (Gate is simple MessageEnd) only, so it's not possible to draw call message between Diagram Frame and Interaction Use. Nerijus ----- Original Message ----- From: James Bruck To: Haugen Øystein Cc: issues@omg.org ; Juergen Boldt ; Haugen Øystein ; uml2-rtf@omg.org Sent: Thursday, January 10, 2008 5:46 PM Subject: RE: issue 12167 -- UML 2 RTF issue Thanks for the reply. Some responses below... I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: The problem of ordering happens when we have gates on both end of the message. Say we have two gates on an interaction 'connected' to two corresponding gates on some InteractionUse (in the interior) (see the picture below). In this scenario, we cannot say that one message occurs before the other. Semantically, there would be no way to determine which message occurrs first, or am I missing something obvious. We can also come up with more difficult examples of messages between gates that are on InteractionUse. Without knowing about the contents of the InteractionUse (which may not be possible in practical modeling scenarios) we do not know the order. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. Yes. The order of messages can be inferred from the (ordered) MessageOccurrenceSpecifications at the ends of the Message can they not? 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. The 'in general' part has me a bit concerned. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. Should the spec. clarify the following case: In such a case, could M2 happen before M1? Regards, - James. Haugen Øystein 01/10/2008 05:22 AM To Juergen Boldt , issues@omg.org, uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA cc Haugen Øystein Subject RE: issue 12167 -- UML 2 RTF issue James Bruck etc. I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: 1. Nothing happens at a gate. There is no output or input that happens there. A gate is a point of connection that logically combines message pieces from within a referenced diagram with message pieces outside the reference to said diagram. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. 5. If your desire is to order events on an interface, I would suggest to use ports as interface descriptions on a composite structure. Ports are ConnectableElements and can be represented by Lifelines and then occurrence specifications can be ordered on those Lifelines. Regards, Oystein Haugen ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 9. januar 2008 21:29 To: issues@omg.org; uml2-rtf@omg.org Subject: issue 12167 -- UML 2 RTF issue To: juergen@omg.org Cc: Dusko Misic , Anthony Hunter Subject: Issue with the UML superstructure spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Tue, 8 Jan 2008 15:48:52 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/08/2008 15:48:53, Serialize complete at 01/08/2008 15:48:53 Hi Juergen, I would like to raise the following issue with the spec. --------------------------------------------------- In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Cheers, - James. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-Ninja-PIM: Scanned by Ninja Subject: RE: issue 12167 -- UML 2 RTF issue Date: Mon, 14 Jan 2008 16:36:50 +0100 X-MS-Has-Attach: yes Thread-Topic: issue 12167 -- UML 2 RTF issue Thread-Index: AchToBGopR5zY7KCSWGC5TCfdEe+mQALAnLQ From: Haugen Øystein To: James Bruck Cc: issues@omg.org, Juergen Boldt , uml2-rtf@omg.org, Haugen Øystein X-OriginalArrivalTime: 14 Jan 2008 15:38:58.0275 (UTC) FILETIME=[94100B30:01C856C3] James Please see my responses interleaved below. /Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: 10. januar 2008 16:47 To: Haugen Øystein Cc: issues@omg.org; Juergen Boldt; Haugen Øystein; uml2-rtf@omg.org Subject: RE: issue 12167 -- UML 2 RTF issue Thanks for the reply. Some responses below... I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: The problem of ordering happens when we have gates on both end of the message. Say we have two gates on an interaction 'connected' to two corresponding gates on some InteractionUse (in the interior) (see the picture below). In this scenario, we cannot say that one message occurs before the other. Semantically, there would be no way to determine which message occurrs first, or am I missing something obvious. We can also come up with more difficult examples of messages between gates that are on InteractionUse. Without knowing about the contents of the InteractionUse (which may not be possible in practical modeling scenarios) we do not know the order. You are completely right. In your illustration "Interaction1" nothing can be said about the order between M1 and M2. Furthermore in Interaction1 there is absolutely nothing happening in M1 and M2. They are merely binding lines between the actual gates on Interaction2 and the formal gates of Interaction1. This does not pose any problem. (By the way the diagram is wrong since all messages need to have a direction and neither M1 nor M2 seem to have any arrow head). If you enhanced the notation to include general ordering between gates (say) then that would mean that you define requirements on occurrence specifications that are beyond the diagram itself. This is of course possible to do, but it would be a very 2. Sequence diagrams defines ordering of occurrence specifications, not messages. Yes. The order of messages can be inferred from the (ordered) MessageOccurrenceSpecifications at the ends of the Message can they not? No, message orders cannot in general be inferred from the message ends because we may describe asynchronous signaling and that can mean message overtaking (what is sent first, is received last) or just the fact that events on independent parts of the diagram may come in any order. Any formal semantics of asynchronous messages splits the messages into their two message ends. 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. The 'in general' part has me a bit concerned. "In general" could be removed. A message cannot go upwards. This is specified in the Notation section of Message. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. Should the spec. clarify the following case: In such a case, could M2 happen before M1? M2 and M1 does not happen. M2 and M1 are just connection lines. (see point #1). Regards, - James. Haugen Øystein 01/10/2008 05:22 AM To Juergen Boldt , issues@omg.org, uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA cc Haugen Øystein Subject RE: issue 12167 -- UML 2 RTF issue James Bruck etc. I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: 1. Nothing happens at a gate. There is no output or input that happens there. A gate is a point of connection that logically combines message pieces from within a referenced diagram with message pieces outside the reference to said diagram. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. 5. If your desire is to order events on an interface, I would suggest to use ports as interface descriptions on a composite structure. Ports are ConnectableElements and can be represented by Lifelines and then occurrence specifications can be ordered on those Lifelines. Regards, Oystein Haugen ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 9. januar 2008 21:29 To: issues@omg.org; uml2-rtf@omg.org Subject: issue 12167 -- UML 2 RTF issue To: juergen@omg.org Cc: Dusko Misic , Anthony Hunter Subject: Issue with the UML superstructure spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Tue, 8 Jan 2008 15:48:52 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/08/2008 15:48:53, Serialize complete at 01/08/2008 15:48:53 Hi Juergen, I would like to raise the following issue with the spec. --------------------------------------------------- In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Cheers, - James. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org To: "Nerijus Jankevicius" Cc: issues@omg.org, "Juergen Boldt" , Haugen Øystein , uml2-rtf@omg.org Subject: Re: issue 12167 -- UML 2 RTF issue X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Mon, 14 Jan 2008 11:05:03 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/14/2008 11:05:05, Serialize complete at 01/14/2008 11:05:05 Hi Nerijus, Thanks for pointing that out. Actually after investigating a bit further my example might be bogus. There seems to be an implicit interpretation of the spec that would exclude messages going between two gates. From the spec: A Message reflects either an Operation call and start of execution or a sending and reception of a Signal. When a Message represents an Operation invocation, the arguments of the Message are the arguments of the CallOperationAction on the sending Lifeline as well as the arguments of the CallEvent occurrence on the receiving Lifeline. When a Message represents a Signal, the arguments of the Message are the arguments of the SendAction on the sending Lifeline and on the receiving Lifeline the arguments are available in the SignalEvent. IMHO a possible resolution would be to introduce an explicit constraint specifying this. Having multiple gates with incoming messages might also be a menaingless scenario. If we are modeling an operation foo() with some sequence diagram then having a gate on the interaction with a message would imply that we are invoking foo() itself (please correct any of this if I'm wrong). It would be as if we had an initial lifeline at the beginning of the sequence diagram that represented the lifetime of foo(). The message from the gate would connect to that lifeline. We could then have another message connected to a gate on an interaction use. Also, after executing foo() we could have a message (going from the interior to a gate on the frame) with the return parameters. So perhaps we should also add constraints dealing with the number of gates on an interaction and how they are to be used in addition to mentioning that we can have a gate only at one end of a message. Regards, - James. "Nerijus Jankevicius" 01/14/2008 09:43 AM To Haugen Øystein , James Bruck/Ottawa/IBM@IBMCA cc , "Juergen Boldt" , Haugen Øystein , Subject Re: issue 12167 -- UML 2 RTF issue James, Your example illustrates even more problems. In case both message ends are Gates, it's not possible to use events (CallEvent, SendEvent, DestroyEvent etc), because event could be used on MessageOccurenceSpecification (Gate is simple MessageEnd) only, so it's not possible to draw call message between Diagram Frame and Interaction Use. Nerijus ----- Original Message ----- From: James Bruck To: Haugen Øystein Cc: issues@omg.org ; Juergen Boldt ; Haugen Øystein ; uml2-rtf@omg.org Sent: Thursday, January 10, 2008 5:46 PM Subject: RE: issue 12167 -- UML 2 RTF issue Thanks for the reply. Some responses below... I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: The problem of ordering happens when we have gates on both end of the message. Say we have two gates on an interaction 'connected' to two corresponding gates on some InteractionUse (in the interior) (see the picture below). In this scenario, we cannot say that one message occurs before the other. Semantically, there would be no way to determine which message occurrs first, or am I missing something obvious. We can also come up with more difficult examples of messages between gates that are on InteractionUse. Without knowing about the contents of the InteractionUse (which may not be possible in practical modeling scenarios) we do not know the order. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. Yes. The order of messages can be inferred from the (ordered) MessageOccurrenceSpecifications at the ends of the Message can they not? 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. The 'in general' part has me a bit concerned. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. Should the spec. clarify the following case: In such a case, could M2 happen before M1? Regards, - James. Haugen Øystein 01/10/2008 05:22 AM To Juergen Boldt , issues@omg.org, uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA cc Haugen Øystein Subject RE: issue 12167 -- UML 2 RTF issue James Bruck etc. I am not entirely sure what your problem may be, but I will try and give a few statements that may clarify your problems: 1. Nothing happens at a gate. There is no output or input that happens there. A gate is a point of connection that logically combines message pieces from within a referenced diagram with message pieces outside the reference to said diagram. 2. Sequence diagrams defines ordering of occurrence specifications, not messages. 3. If the order of the formal gates are preserved in the order of the actual gates, the InteractionUse will not easily be able to define an inconsistent trace where an occurrence specification is defined to occur before itself (through transitivity). This is because messages in general are not allowed to slope upwards. 4. You can specify explicitly the order of any two occurrence specifications through the GeneralOrdering mechanisms, but you are right that you cannot order gates. 5. If your desire is to order events on an interface, I would suggest to use ports as interface descriptions on a composite structure. Ports are ConnectableElements and can be represented by Lifelines and then occurrence specifications can be ordered on those Lifelines. Regards, Oystein Haugen ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 9. januar 2008 21:29 To: issues@omg.org; uml2-rtf@omg.org Subject: issue 12167 -- UML 2 RTF issue To: juergen@omg.org Cc: Dusko Misic , Anthony Hunter Subject: Issue with the UML superstructure spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Tue, 8 Jan 2008 15:48:52 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/08/2008 15:48:53, Serialize complete at 01/08/2008 15:48:53 Hi Juergen, I would like to raise the following issue with the spec. --------------------------------------------------- In the 2.1.1 specification (070205): Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible. In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering. The inability to specify ordering of messages connected to gates is problematic. __________________________________ Cheers, - James. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Rouquette, Nicolas F (313K)" To: "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: 12167 -- Re: [UML 2.5 FTF] Ballot 2 - PREVIEW -- PLEASE, PLEASE READ!! -- Thank you. Thread-Topic: 12167 -- Re: [UML 2.5 FTF] Ballot 2 - PREVIEW -- PLEASE, PLEASE READ!! -- Thank you. Thread-Index: AQHOCg6N8L/KANPDVUWLnaqW6WcVKJh4+RCA Date: Thu, 14 Feb 2013 07:40:43 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Manfred, Great work putting this back-to-back ballot together! .Gates areMessageEnds which are partially ordered by theMessageOccuranceSpecifications at the opposite end of the two Message instances linked by a paired set of gates.. Huh? I have 2 problems with this resolution: 1) it is out-of-place. This resolution refers to the partial ordering of MessageOccurenceSpecifications which is only discussed in section 17.5, not 17.4.3. 2) it's too concise and too convoluted to be understandable by a reasonable person. - Nicolas. From: "Manfred R. Koethe" Date: Wednesday, February 13, 2013 9:19 AM To: "uml25-ftf@omg.org" Cc: "Manfred R. Koethe" Subject: [UML 2.5 FTF] Ballot 2 - PREVIEW -- PLEASE, PLEASE READ!! -- Thank you. Dear Colleagues, Ballot 2 of the UML 2.5 FTF is now available for PREVIEW. Please, please, please read and if necessary, send me your comments while this ballot is still in preview. Please lat us not go into multiple revision cycles again, as it was with Ballot 1. Thank you very much in advance for your cooperation. Ballot 2 has three sections: (1) Disposition Resolved (2) Disposition Closed-No Change (3) Disposition Duplicate / Merged The resolutions in the attached document are grouped accordingly. Voting on the Ballot 2 will open On Monday 18-February-2013 and close on Monday 25-February-2013. Please see page 2 of the attached document for further details. And this is an advanced warning to Roger and Jishnu: You missed Ballot 1, please make sure to vote on Ballot 2 to stay on board of the FTF. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- Date: Tue, 19 Feb 2013 14:05:21 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "Rouquette, Nicolas F (313K)" CC: "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: Re: 12167 -- Re: [UML 2.5 FTF] Ballot 2 - PREVIEW -- PLEASE, PLEASE READ!! -- Thank you. X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== I second that Huh? It's really not clear to me from that sentence which messages are involved. Dave On 14/02/13 07:40, Rouquette, Nicolas F (313K) wrote: Manfred, Great work putting this back-to-back ballot together! .Gates areMessageEnds which are partially ordered by theMessageOccuranceSpecifications at the opposite end of the two Message instances linked by a paired set of gates.. Huh? I have 2 problems with this resolution: 1) it is out-of-place. This resolution refers to the partial ordering of MessageOccurenceSpecifications which is only discussed in section 17.5, not 17.4.3. 2) it's too concise and too convoluted to be understandable by a reasonable person. - Nicolas. From: "Manfred R. Koethe" > Date: Wednesday, February 13, 2013 9:19 AM To: "uml25-ftf@omg.org " > Cc: "Manfred R. Koethe" > Subject: [UML 2.5 FTF] Ballot 2 - PREVIEW -- PLEASE, PLEASE READ!! -- Thank you. Dear Colleagues, Ballot 2 of the UML 2.5 FTF is now available for PREVIEW. Please, please, please read and if necessary, send me your comments while this ballot is still in preview. Please lat us not go into multiple revision cycles again, as it was with Ballot 1. Thank you very much in advance for your cooperation. Ballot 2 has three sections: (1) Disposition Resolved (2) Disposition Closed-No Change (3) Disposition Duplicate / Merged The resolutions in the attached document are grouped accordingly. Voting on the Ballot 2 will open On Monday 18-February-2013 and close on Monday 25-February-2013. Please see page 2 of the attached document for further details. And this is an advanced warning to Roger and Jishnu: You missed Ballot 1, please make sure to vote on Ballot 2 to stay on board of the FTF. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.