Issue 7392: Interactions model sequences of events (uml2-rtf) Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu) Nature: Clarification Severity: Minor Summary: Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event. Resolution: Discussion: This was fixed in UML 2.1 Revised Text: N/A Disposition: Closed, no change Revised Text: Actions taken: May 29, 2004: received issue October 27, 2008: closed issue Discussion: Resolution deferred for the next RTF End of Annotations:===== m: webmaster@omg.org Date: 29 May 2004 22:45:08 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Thomas Weigert Company: Motorola mailFrom: thomas.weigert@motorola.com Notification: No Specification: UML Section: 14.3.3 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: 02/08/2003 Page: 4.1.6 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event. From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Ballot 24 draft Date: Thu, 19 Aug 2004 23:35:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Comments: 6171: Delete last sentence of replacement text. It is not at all clear whether the mentioned rules are in scope of UML or not. Certainly we have declared those to be a semantic variation point in other places. I would suggest to move the text into the semantic variation point section and replace the last sentence by "Such rules constitute semantic variation points." 6988: Please make sure you use the new terminology introduced by Jim R. 7392: This would be resolved by the resolution to the Nick's event issue I sent in tonight. I would suggest to combine those. 7417: Just FYI. The text that the submitter complains about was a note that I had written to myself using the Frame conditional text feature. Somehow it ended up in the spec but was later removed, as it should have been. The resolution is correct. 7431: This resolution should be deleted. The issue references an outdated version of the spec. If the adopted resolution to issue 7122 were considered, much of the tension is gone: Constraint [2], as it is in place due to issue 7122, states that "The connectable elements attached to the ends of a connector must be compatible." Constraint [1], for a subtype of connector, states that the connectable elements must have the same or compatible interfaces. So the only conflict is that the phrasing in Components has not been updated to move the compatibility relation to the connectable elements and it still speaks of compatible interfaces. I think the bigger issue is that the constraint [1] mentions a connector between interfaces, which is nonsense. So what we should do is bring the constraint [1] in line with constraint [2] terminology, as compatibility between interfaces is not any more defined. 7434: There are two presentation options discussed under collaboration occurrence. The option quoted "point at the owning classifier" is not relevant to the problem; it refers to the situation where a collaboration represents an operation. But actually, the text of the presentation option has become so confusing due to the repeated changes to the keywords that it makes little sense. A clearer wording is required. In addition, it should be made clear which direction the arrow points. I would defer this issue, as the proposed solution does not really address the problem. 7438: The choice of word "connector" in this resolution is not good, as "Connector" is the name of a model element. 7575: Make sure that the bookmark references are correct in the final version. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran