Issue 15239: Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications (uml2-rtf) Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org) Nature: Uncategorized Issue Severity: Summary: Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications. This is because in the metamodel the start and finish of an ExecutionSpecification are OccurrenceSpecifications, not ExecutionOccurrenceSpecifications. This means that it appears to be valid for the MessageOccurrenceSpecification that is a Message's receiveEvent to also be the start of an ExecutionSpecification. The text is equally ambiguous. The 14.3.10 paragraph "An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification" appears to say unambiguously that the start and finish must be ExecutionOccurrenceSpecifications. However the later sentence "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)" both introduces ambiguity through the use of the word "typically", and then proceeds to blatantly contradict the earlier paragraph. This causes tool interoperability problems. I suggest targeting ExecutionSpecification::start and finish onto ExecutionOccurrenceSpecification, and rewriting the contradictory semantics accordingly. Resolution: Revised Text: Actions taken: May 4, 2010: received issue Discussion: End of Annotations:===== m: Steve Cook To: "issues@omg.org" , "juergen@omg.org" CC: Østein Haugen , "uml2-rtf@omg.org" , Bran Selic , "Ed Seidewitz" , Maged Elaasar , "Dave Hawkins" Subject: RE: Ballot 8 Draft: A draft resolution on Events in Interactions Thread-Topic: Ballot 8 Draft: A draft resolution on Events in Interactions Thread-Index: AcrlY3Lg1lSwrlE5Q6CBQe8X6aZ2oQAIXM/gABZ3yrAABJbUgAABQKyAAAV+XEAAM7iXgAA39mwAACSs/+AAyJJ/gAADA/eA Date: Tue, 4 May 2010 11:34:17 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o44BNrDs013844 Juergen, please raise an issue against UML 2: *** Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications. This is because in the metamodel the start and finish of an ExecutionSpecification are OccurrenceSpecifications, not ExecutionOccurrenceSpecifications. This means that it appears to be valid for the MessageOccurrenceSpecification that is a Message's receiveEvent to also be the start of an ExecutionSpecification. The text is equally ambiguous. The 14.3.10 paragraph "An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification" appears to say unambiguously that the start and finish must be ExecutionOccurrenceSpecifications. However the later sentence "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)" both introduces ambiguity through the use of the word "typically", and then proceeds to blatantly contradict the earlier paragraph. This causes tool interoperability problems. I suggest targeting ExecutionSpecification::start and finish onto ExecutionOccurrenceSpecification, and rewriting the contradictory semantics accordingly. *** Thanks -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 04 May 2010 11:55 To: Steve Cook Cc: Østein Haugen; uml2-rtf@omg.org; Bran Selic; Ed Seidewitz; Maged Elaasar Subject: Re: Ballot 8 Draft: A draft resolution on Events in Interactions I strongly agree with Steve's view that this freedom is not actually helpful to implementors. My request for instance diagrams was to try to eliminate just this kind of ambiguity. We've had real trouble understanding precisely how the interaction notation maps to the underlying model with respect to occurrence specifications. The specification just isn't terribly clear. Cheers, Dave Steve Cook wrote: > Oystein > > Your new constraint[8] surely does not apply to all Messages? Insofar as I understand the way you have formulated it, it does. > > You say >> The tools are free to apply only one OccurrenceSpecification representing the start of an ExecutionSpecification and the end of a synchronous message (i.e. an Operation call). > > It is exactly this kind of freedom that imposes unnecessary costs on implementers and causes failures of interoperability. If one vendor chooses to create separate OccurrenceSpecifications, and builds a model-diagram mapping based on it, while another vendor chooses to merge them, then interoperability will fail. Our developers get very frustrated with this kind of ambiguity in the spec. > > -- Steve > > -----Original Message----- > From: Østein Haugen [mailto:Oystein.Haugen@sintef.no] > Sent: 29 April 2010 18:42 > To: uml2-rtf@omg.org > Cc: Steve Cook; Bran Selic; Ed Seidewitz; Maged Elaasar; Dave Hawkins; > Østein Haugen > Subject: RE: Ballot 8 Draft: A draft resolution on Events in > Interactions > > I have made an update to the Draft Resolution of Issue 14629. > > I have tried to take the comments into account and I have walked through in greater detail the classes that I suggest to delete. The main statement still remains true, namely that the Events that were produced in the repository for Interactions are never used anywhere else and they contain close to no useful information. Everybody seems to agree to that. I have according to Steve's findings removed the desire to remove also "MessageEvent" since it is used in StateMachines, but none of its concrete subclasses there overlap with those originally in Interactions. As Steve points out, the name MessageEvent is meaningless in State Machines, and the class contains no information, so it could in fact be removed there, too (and its subclasses inheriting directly from Event), but that is not my concern. > > It is true that I have changed a multiplicity that strictly speaking > did not fall under the issue, but it did fall into the scope of my > other changes, so I chose to include it. I changed it now to the more > restricted 0..2 (rather than * in my first version) because there can > never be more than 2 ExecutionOccurrenceSpecifications referring to > the same ExecutionSpecification. (Please note that > ExecutionSpecifications need not be bounded only by > ExecutionOccurrenceSpecifications. The tools are free to apply only > one OccurrenceSpecification representing the start of an > ExecutionSpecification and the end of a synchronous message (i.e. an > Operation call). In principle also other OccurrenceSpecifications can > be "reused". Typically a finish of an ExecutionSpecification can > coincide with the sending of a reply message. This is not affected by > my resolution proposal, but has been this way always in UML2.) > > Dave asked for instance diagrams. If you mean illustrations of how the repository should be for some examples, that may certainly be useful, but you do not find those anywhere else in the standard? If you mean figures and examples, there are not that few examples in Interaction chapter, but I do agree that there could be even more. > > Regards, > Oystein > > > ---- > Dr. Oystein Haugen > Senior Researcher > SINTEF > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: 28. april 2010 16:59 > To: Østein Haugen > Cc: Steve Cook; Bran Selic; Ed Seidewitz; Maged Elaasar; > uml2-rtf@omg.org > Subject: Re: Ballot 8 Draft: A draft resolution on Events in > Interactions > > Oystein, > > This resolution seems to be including fixes for a number of things > that aren't related to the issue Steve logged. Specifically, changing > the multiplicty of the > ExecutionSpecification-ExecutionOccurrenceSpecification > association and updating some typos. The first of those is actually a serious issue in its own right and I'm a little uncomfortable that it's being tacked onto this resolution as OMG members might not vote in favour of the full resolution. > > Interaction events have caused us a bit of a headache in our implementation, although that is primarily because they can only be owned by packages. (As Maged and I'm fairly certain Nerijus previously have suggested, events owned by BehaviouredClassifiers would make managing them much easier.) Eliminating events from interactions would certainly resolve that, however I remain concerned about those areas of the specification that use events in general. > For example, a trigger can reference an event. There's nothing to say that it couldn't be referencing one of the events proposed for removal and this is a mandatory property. > > The resolution isn't clear how a DestructionSpecification would actually be used. (This is a general problem with the Interactions specification, it lacks instance diagrams and is overly open to vendor interpretation.) Does it replace the MessageOccurrenceSpecification at the end of a deleteMessage? > Does it follow it? And why isn't it called DestructionOcurrenceSpecification? > > Cheers, > > Dave > > Steve Cook wrote: >> Oystein >> >> >> >> In general, your resolution talks about deleting and modifying >> associations, but does not identify the consequential specific >> textual changes - the one Bran identified was one case of this. >> We're very pushed in this RTF, so getting the textual changes >> complete is a pre-requisite for making the resolution acceptable. >> >> >> >> Deleting CreationEvent takes along with it the following constraint: >> [1] No other OccurrenceSpecification may appear above an >> OccurrenceSpecification which references a CreationEvent on a given >> Lifeline in an InteractionOperand. >> >> Should there not be a semantically equivalent constraint >> re-introduced elsewhere, e.g. on Message or on OccurrenceSpecification? >> >> >> >> The following are subtypes of MessageEvent: AnyReceiveEvent, >> SignalEvent, CallEvent (fig 13.12). Your resolution doesn't mention >> them. They are used in Actions, State Machines, etc. So I don't >> believe you can delete MessageEvent. If you don't delete >> MessageEvent, since it will now not be used in interactions, what is >> the significance of "Message" in its name? >> >> >> >> You say 'Replace "EventOccurrences" by "OccurrenceSpecification"'. >> This should read 'Replace "EventOccurrences" by "OccurrenceSpecification*s*"' >> >> >> >> I am not wholly opposed to trying to shoehorn this in, but it needs >> to be significantly improved. >> >> -- Steve >> >> >> >> >> >> *From:* Østein Haugen [mailto:Oystein.Haugen@sintef.no] >> *Sent:* 27 April 2010 12:41 >> *To:* Bran Selic >> *Cc:* Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org; Østein Haugen >> *Subject:* RE: Ballot 8 Draft: A draft resolution on Events in >> Interactions >> >> >> >> Bran >> >> You are right about the mentioned association. In the model itself it >> would follow from the elimination of ExecutionEvent, but in the text >> it would not follow automatically (unfortunately). I had it in my >> handwritten notes, but failed to transfer it to the incremental >> resolution. I consider this a normal effect of the fact that this is >> a draft and it is reasonable that such minor mistakes are discovered. >> I had intended to show the final metamodel diagrams, but the RSM >> models do not have all the diagrams available. >> >> >> >> I agree that I should have done this long time ago and not in the >> last ballot. I apologize. However, I found that it has gradually >> become more broken than I had thought and found that the model >> actually does not at all reflect what the user defines in an >> Interaction. This really needs simplification again. As far as I can >> see you do not have a real technical argument against the change, but >> you fear that there may be something hidden down there some place? >> Continuing to make the current approach more elaborate, is going the >> wrong direction. I wanted to point that out, for now or later. >> >> >> >> What to do with the existing models? I have understood that the >> models of Interaction are not all that interoperable and I have also >> indirectly understood that different vendors jump to the wrong >> conclusions about the layout of the Interaction models. Therefore it >> is hard to say what should be done with the old models. If the models >> keep explicitly the "signature" association, however, there should be >> only removing the Event objects, plus redefining the DestructionEvent >> to DestructionOccurrence when applicable. If the 'signature' >> association is not expicit in the model, then that association must >> be derived from the old model. >> >> >> >> The UML users will not experience this change at all. They have never >> known anything about Events. Events represent a lot of unnecessary >> plumbing in my opinion. The Message (and thereby its signature) is >> what the user sees and manipulates, but in the current version this >> is "derived" in a rather cryptic way. This is in my opinion the problem. >> >> >> >> /Oystein >> >> >> >> ---- >> >> Dr. Oystein Haugen >> >> Senior Researcher >> >> SINTEF >> >> >> >> >> >> --------------------------------------------------------------------- >> - >> -- >> >> *From:* bran.selic@gmail.com [mailto:bran.selic@gmail.com] *On Behalf >> Of *Bran Selic >> *Sent:* 27. april 2010 13:05 >> *To:* Østein Haugen >> *Cc:* Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org >> *Subject:* Re: Ballot 8 Draft: A draft resolution on Events in >> Interactions >> >> Oystein, >> >> I notice that your resolution is incomplete, since it does not remove >> the appropriate text in the metaclass >> *ExecutionOccurrenceSpecification*; i.e.,: >> >> *Associations* >> * event : ExecutionEvent [1] Redefines the event referenced to be >> restricted to an execution event. >> >> >> I did not check in other places, but it is a sign that this kind of >> change can be tricky and may even have repercussions. Based on that, >> I tend to agree with folks who are nervous about this type of change >> at this stage (last ballot). My experience in the past is that the >> last ballot should be reserved for less extensive fixes. >> >> Furthermore, I do think that /any fix that modifies the metamodel >> should include a recommendation on how existing models should deal >> with the change /(e.g., do they simply delete things in the models or >> do they do some kind of transformation to conform the new metamodel? >> etc.). Since Interactions is one of the most widely used features of >> UML, the impact of this change on existing metamodels and, hence, UML >> users, could be quite significant. >> >> Cheers...Bran >> >> 2010/4/27 Østein Haugen > > >> >> Dear Ed and Maged >> >> You have both expressed concern about my resolution to 14629. Your >> concern is that this is such a big change. I am not so sure it is. >> >> >> >> I put time into this and suggested the resolution because I was under >> the impression that this was the time for changing the metamodel. In >> 2.5 that cannot be done. Therefore it is necessary to do it now. >> Since the metamodel is changed, all tools must change accordingly and >> interoperability must be tried again. >> >> >> >> Is the change drastic? In a way it is since it eliminates the use of >> Events and its subclasses in Interactions. In another way it is not. >> The Interaction users never sees Events and they never explicitly >> model them. In fact I am quite sure that no Event objects created >> implicitly by the tool in an Interaction diagram are used anywhere >> else. This latter statement is the heart of the issue. Events were >> originally invented during UML 2.0 very late and it was intended to >> form a bridge between different kinds of behavioral descriptions. But >> it does not function that way - at least not for Interactions. >> Therefore the Event objects are merely there to describe something >> which is easier done directly and the way it was originally designed (by me in early UML 2.0). >> >> >> >> The user defines the kind, sort and name of the Message. There is >> concrete syntax for that. The name of the Message (and its arguments) >> correspond to a 'signature' which is either an Operation (if it is >> synchronous) or a Signal (if it is asynchronous). This is the >> significant information and the information any analysis tool will >> use when comparing (say) state machines and Interactions. The >> signature objects _are shared_ between different behavioral and >> structural descriptions in the same UML model. In the 2.3 version the >> signature is derived and this is very backward since the signature is >> exactly what the interaction modeler defines directly. >> >> >> >> Two points that also may be relevant: >> >> 1) Interactions do not define any implicit Actions on the Message ends. >> This misunderstanding has come from somewhere, probably from the fact >> that at runtime there must exist some action execution for a message >> to be sent and received, but this is not something that the >> Interactions define in detail. The metamodel should only represent >> the information that the modeler actually conveys. Actions may >> explicitly be defined through ExecutionSpecifications. >> >> 2) The term "event" is used also in connection with the semantics of >> Interactions (as pointed out by Maged), but this is because the term >> "event" was earlier used for what is now termed >> "occurrencespecification". This term changed when Event was introduced. >> Thus there is still some term confusion, but we can live with that. >> The Event concept is not at all used for the tracebased semantics of >> Interactions. The information of the "event" in the traces come from >> the occurrence specification and its associated message signature. >> >> >> >> It is still my opinion that eliminating the Events will simplify the >> Interactions metamodel. It will of course have effect on the tools, >> but all metamodel changes do. >> >> >> >> Regards, >> >> Oystein >> >> >> >> ---- >> >> Dr. Oystein Haugen >> >> Senior Researcher >> >> SINTEF >> >> >> >> >> >> --------------------------------------------------------------------- >> - >> -- >> >> *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com >> ] >> *Sent:* 26. april 2010 23:18 >> *To:* Østein Haugen >> *Cc:* uml2-rtf@omg.org >> *Subject:* RE: Ballot 8 Draft: A draft resolution on Events in >> Interactions >> >> Oystein - >> >> >> >> Sorry I have not had time to engage in the discussion of this issue. >> However, regardless of the technical merits of your resolution, this >> seems to be a very large and significant change to be introducing in >> UML >> 2.4 at all, let alone at the last minute before the last ballot. >> While I was never a fan of the special set of events defined in the >> Interactions clause, it always worries me change like this one, which >> seems to hit at a fundamental way in which interactions were >> previously structured, can end up introducing more unexpected issues than the issue they resolve. >> >> >> >> You also state this resolution will have "cascading effects" on the >> resolution of other issues. But, if this is so, it again seems like >> there was a fundamental problem in the way that interactions were >> constructed before, and I wonder if we are missing something in >> simply ripping out a part of the metamodel in seeking resolution to these problems. >> >> >> >> Finally, before we do something this drastic, I would like to make >> sure that we are really resolving the problems that Nerijus and >> others brought up in the MIWG. To my mind, Issue 14629 may identify >> an annoyance but it is not a "showstopper". However, the issues that >> Nerijus brought up, if valid, would, indeed, be showstoppers for >> which drastic measures could be considered in this RTF. >> >> >> >> -- Ed >> >> >> >> --------------------------------------------------------------------- >> - >> -- >> >> *From:* Østein Haugen [mailto:Oystein.Haugen@sintef.no >> ] >> *Sent:* Monday, April 26, 2010 1:11 PM >> *To:* uml2-rtf@omg.org >> *Cc:* Østein Haugen >> *Subject:* Ballot 8 Draft: A draft resolution on Events in >> Interactions >> >> >> >> UML 2.4 RTF >> >> I have put in a resolution to fixing Events in Interactions which in >> practice means eliminating them from Interactions (but not from >> anywhere else). This will change and simplify the metamodel. >> >> >> >> Please review. I am sure there might be reactions. >> >> >> >> Even though this is a resolution to only one Issue, there will be >> cascading effects to solving a number of the other outstanding >> Interaction issues. >> >> >> >> Regards, >> >> Oystein >> >> >> >> ---- >> >> Dr. Oystein Haugen >> >> Senior Researcher >> >> SINTEF >> >> >> >> >> > > -- > 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. > -- 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.