Issue 4263: Events, signals, stimuli, etc. (uml2-superstructure-ftf) Source: Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall, nobody) Nature: Clarification Severity: Summary: Here is my understanding of communication between instances on an example (all quotes are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction, according to the spec: "A send action is an action that results in the (asynchronous) sending of a signal". Then, the signal is delivered to say instance i2, and as a consequence of the receipt, a SignalEvent is generated (according to the spec, "A signal event represents the RECEPTION of a particular (asynchronous) signal") Now the problems: 1) the spec goes on further to say about the signal event that "A signal event instance should not be confused with the action (e.g., send action) that generated it". The problem I have with my above understanding is that the send action should not be the one generating the send event but rather the reception of the signal should be the one generating it. 2)According to the spec: "A signal is a specification of an asynchronous stimulus communicated between instances" where a stimulus is more general "In the metamodel Stimulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an Operation". Thus, I conclude that the things sent between instances are stimuli. However, I'm a little confused of the relationship between events and stimuli with the following sentence taken from the spec "Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target,..." Furthermore, how are stimuli and signals related in the metamodel? Resolution: Revised Text: This issue refers to the event model of UML 1.x. UML 2.0 has largely revised this model and the issue is no longer applicable. A further reformulation of the event model is forthcoming in the resolution to issue 4456. Actions taken: April 10, 2001: received issue March 9, 2005: closed issue Discussion: This is a complex area that is expected to be rationalized by the 2.0 submissions. End of Annotations:===== Date: Tue, 10 Apr 2001 16:43:28 +0200 From: Shane Sendall X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: UML RTF Subject: Events, signals, stimuli, etc. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fi@!!I'"e9oYKe9c"Ee9 Hello, I am a little confused between events, signals, and stimuli. I would be most grateful for someone to clarify this for me. Here is my understanding of communication between instances on an example (all quotes are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction, according to the spec: "A send action is an action that results in the (asynchronous) sending of a signal". Then, the signal is delivered to say instance i2, and as a consequence of the receipt, a SignalEvent is generated (according to the spec, "A signal event represents the RECEPTION of a particular (asynchronous) signal") Now the problems: 1) the spec goes on further to say about the signal event that "A signal event instance should not be confused with the action (e.g., send action) that generated it". The problem I have with my above understanding is that the send action should not be the one generating the send event but rather the reception of the signal should be the one generating it. 2)According to the spec: "A signal is a specification of an asynchronous stimulus communicated between instances" where a stimulus is more general "In the metamodel Stimulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an Operation". Thus, I conclude that the things sent between instances are stimuli. However, I'm a little confused of the relationship between events and stimuli with the following sentence taken from the spec "Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target,..." Furthermore, how are stimuli and signals related in the metamodel? Could someone clarify these issues for me? Regards -- Shane --------------------------------------------------------------------- - Shane Sendall - Swiss Federal Institute of Technology in Lausanne - - email : Shane.Sendall@epfl.ch http://lglwww.epfl.ch/~sendall/ - - phone : ++41 21 693 66 89 fax : ++41 21 693 50 79 - The details of the interaction between instances were very fuzzy in UML 1.x, and UML 2.0 has tried to address this problem. Section 13.1. gives an informal explication of the dynamic semantics of the classes in the UML metamodel. The particular question is addressed in the subsection on communications (see p. 370f of 03-08-92, in particular Figure 308 "Communication Domain Model"). Disposition: Closed, no change OMG Issue No: 4263 Title: Events, signals, stimuli, etc. Source: Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall, shane.sendall@epfl.ch) Summary: Here is my understanding of communication between instances on an example (all quotes are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction, according to the spec: "A send action is an action that results in the (asynchronous) sending of a signal". Then, the signal is delivered to say instance i2, and as a consequence of the receipt, a SignalEvent is generated (according to the spec, "A signal event represents the RECEPTION of a particular (asynchronous) signal") Now the problems: 1) the spec goes on further to say about the signal event that "A signal event instance should not be confused with the action (e.g., send action) that generated it". The problem I have with my above understanding is that the send action should not be the one generating the send event but rather the reception of the signal should be the one generating it. [Conrad: it is an indirect generation. The signal event cannot occur without an action to send it.] 2)According to the spec: "A signal is a specification of an asynchronous stimulus communicated between instances" where a stimulus is more general "In the metamodel Stimulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an Operation". Thus, I conclude that the things sent between instances are stimuli. However, I'm a little confused of the relationship between events and stimuli with the following sentence taken from the spec "Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target,..." Furthermore, how are stimuli and signals related in the metamodel? Discussion: The details of the interaction between instances were very fuzzy in UML 1.x, and UML 2.0 has tried to address this problem. Section 13.1. gives an informal explication of the dynamic semantics of the classes in the UML metamodel. The particular question is addressed in the subsection on communications (see p. 370f of 03-08-92, in particular Figure 308 "Communication Domain Model"). OMG Issue No: 4263 Title: Events, signals, stimuli, etc. Source: Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall, shane.sendall@epfl.ch) Summary: Here is my understanding of communication between instances on an example (all quotes are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction, according to the spec: "A send action is an action that results in the (asynchronous) sending of a signal". Then, the signal is delivered to say instance i2, and as a consequence of the receipt, a SignalEvent is generated (according to the spec, "A signal event represents the RECEPTION of a particular (asynchronous) signal") Now the problems: 1) the spec goes on further to say about the signal event that "A signal event instance should not be confused with the action (e.g., send action) that generated it". The problem I have with my above understanding is that the send action should not be the one generating the send event but rather the reception of the signal should be the one generating it. 2)According to the spec: "A signal is a specification of an asynchronous stimulus communicated between instances" where a stimulus is more general "In the metamodel Stimulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an Operation". Thus, I conclude that the things sent between instances are stimuli. However, I'm a little confused of the relationship between events and stimuli with the following sentence taken from the spec "Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target,..." Furthermore, how are stimuli and signals related in the metamodel? Discussion: This issue is resolved by the resolution to issue 6682. Disposition: Closed, no change To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 11 Mar 2004 16:29:20 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/11/2004 16:29:23, Serialize complete at 03/11/2004 16:29:23 Nick, I reviewed your discussion on the issue and, although I agree with most of it in principle, I am greatly concerned that it may be beyond the scope of the FTF. It includes some rearranging of the Interactions metamodel that might be hazardous at this stage. I have more detailed comments below: > If you look at the SimpleTime package (Figure 318), Duration and > TimeExpression are said to be associated with "events" (role names > and text), but are (on the meta-model) associated with NamedElement. > Consider the text (pages 387 for Duration, 397-398 for TimeExpression). > > The text for Duration association event seems to be wrong: it says > that "event" refers to the specification(s) that describes the > starting TimeExpression (??) and the ending TimeExpression (??) of > the Duration. If only one NamedElement is referenced, the duration > is from the first point in time (!!) of that NamedElement until the > last point in time of that NamedElement. > > TimeExpressions are, of course NamedElements (as almost anything > else in the spec), but I believe that the "events" of Duration are > actually the new OccurenceSpecifications. A "point in time" looks > like an Occurence in the new terminology. > > By far, not all NamedElements can be associated with "points in > time".Therefore I believe that this is too general to type "event" > association of Duration and TimeExpression to a NamedElement. It > would be more appropriate to type them as OccurenceSpecifications. Having something more concrete than NamedElement to represent an event occurrence would definitely be an important improvement. > Please correct me, if I'm wrong, but Jim's proposal does not address > the above issue. I believe that you are correct. > Duration and TimeExpression should be associated with > OccurenceSpecification. Role of these associations should be renamed > from "event" to "occurencespec". Duration should always be > associated with two OccurenceSpecifications. Agreed. > This involves some tweaks in the Interactions meta-model. This is where I start to have my doubts. The fix described above is a simple and easy fix that blends nicely with the introduction of Event types and occurrences as proposed by Jim. However, what follows is an attempt to make a more systematic fix, which in an ideal world should be made, but which threatens to be highly destabilizing. > Consider InteractionFragments in Interactions ("things" on > Lifelines). The notion of InteractionFragment is probably the source of a lot of problems, since it reflects a notational viewpoint rather than a semantic viewpoint. As you point out, it merges a number of semantically quite diverse concepts. Your suggestions are, in essence, an attempt to impose a form on the interactions metamodel that is based on the semantic viewpoint. But, the metamodel is currently in large part based on a notational viewpoint. So, my concern is that your fixes, although justifiable from a theoretical viewpoint, are really an attempt to change the architecture of the metamodel. ...... > Now the question about Gates: do we want Durations and > TimeExpressions to be associated with Gates, or not ? > If we do, then MessageEnd should be a subclass of OccurenceSpecification. In my opinion, any attempt to more closely couple the SimpleTime metamodel with Interactions is a bad thing to do -- even if it seems to make sense. This is because it then imposes anyone who uses interactions to also adopt the simple time model. Remember that this model is called that because it is based on a centralized and idealized model of time. Many distributed applications will find this model inadequate (and, to be fair, it was not intended to be a universal model). Therefore, I would strongly oppose anything that would force people into using the simple time model. To summarize: my recommendation is that we just take the first part of your suggestion and replace the NamedElement in SimpleTime model with OccurrenceSpecification and leave it at that. (Oh, and I would get rid of the generalization from EventOccurrence to NamedElement -- this is probably something that Oystein forgot to clean up.) Regards, Bran Subject: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Date: Fri, 12 Mar 2004 17:31:09 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Thread-Index: AcQBPrDelc/MH29DTaykX+2ACR/UXwALtGnwAcSAAnA= From: "Nikolai Mansurov" To: "Branislav Selic (E-mail)" , Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Mar 2004 11:38:48 -0800 To: From: Joaquin Miller Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Nick wrote: 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). But he meant to write: Duration and TimeExpression are associated with NamedElements, ... PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Mon, 15 Mar 2004 09:31:33 +0100 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Nikolai Mansurov CC: "Branislav Selic (E-mail)" , uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=1.119, required 12, HTML_20_30 0.47, HTML_FONTCOLOR_BLUE 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) X-UiO-Spam-score: s Nick Please see the comments interleaved. I am sorry not to have addressed this before, but you seem to have misunderstood the meaning of the metamodel for simple time. My message is that this works, do not fix it. The tweaks will have cascading effects that may make other places less elegant. Nikolai Mansurov wrote: Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). Originally the 'event' roles pointed to NamedElements and this was since the simple time model was not only addressing Interactions. In Interactions you would often attach the time expressions and durations to event occurrences, but in state machines there would be other kinds of metaclasses to attach to. Notice also that Common Behavior or higher in the package hierarchy and therefore the Interaction metaclasses are not available and therefore EventOccurrence cannot be used. Furthermore this is more general as it may not only associate to EventOccurrences even in Interactions, it may also associate with other interaction fragments with the obvious interpretation. This is exactly like in MSC. 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. StateInvariants and Continuations are NOT EventOccurrences if the metamodel has not been totally screwed up. They are Interaction Fragments and that is something very different and that is meaningful since the whole Interaction concept is built on Interaction Fragments. Please do not "fix" this. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? It may sound desirable to associate time expressions with gates, but the meaning of that is somewhat more involved. I do not think that is wise to do in the FTF. As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick I continue to comment below! -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. There is nothing wrong with this! You have misunderstood the modeling here. The Duration is an Interval and that interval has two Time Expressions (or one in the special case), but which specification elements are they attached to? That is what the 'event' association tells. It does not point to the Time Expressions but to the specification elements that are subject to these time expressions. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh Subject: RE: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Date: Mon, 15 Mar 2004 15:07:30 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Thread-Index: AcQKaAJ5AqHy2pOmToSAz2eyH+ttWAAWt6Nw From: "Nikolai Mansurov" To: "Oystein Haugen" Cc: "Branislav Selic (E-mail)" , Hi Oystein, Thanks for your detailed comments, I really appreciate you taking time to review, this was very valuable indeed. Regarding the "association targets" for Duration and Time Expression. I do understand that introducing a dependency between SimpleTime and Interaction packages is a concern. However, the possibility to associate Duration with ANY NamedElement is also a concern. For example, what is the meaning of a duration between two classes ? Logically, Duration should be an association between two OccurencesSpecifications, and nothing else. So, the question is, what other model elements specify OccurenceSpecifications ? Maybe we should move OccurenceSpecification to another package higher up in the hierarchy, like CommonBehaviors ? Then let Interactions::OccurenceSpecification subclass it. In fact, part of the original proposal was to rename Interactions::OccurenceSpecification into Interactions::OrderableOccurenceSpecification. Regarding the restructuring of subclasses of the InteractionFragment. You are absolutely right in pointing out that StateInvariants and Continuations are NOT subclasses of EventOccurence (OccurenceSpecification), but rather of InteractionFragment. I have to admit, this was a wrong summary of the original lengthy restructuring proposal. The rest of the proposal suggests having an abstract class CompositeOccurenceSpecification with associations to two OccurenceSpecifications (roles start and end). The reason: in Interaction one should be able to add Duration annotations also to InteractionUse, CombinedFragment and InteractionOperand. The goal of the whole restructuring is to more precisely specify the usage of Durations and Time Expressions with OccurenceSpecifications. In other words, the price of being more precise in defining the targets of Duration and TimeExpression is to either forbid InteractionUse and CombinedFragment as such targets (since they are currently not associated with EventOccurences), or to provide such associations (via an abstract class, or alterantively, directly). Best regards, Nick -----Original Message----- From: Oystein Haugen [mailto:oysteinh@ifi.uio.no] Sent: Monday, March 15, 2004 3:32 AM To: Nikolai Mansurov Cc: Branislav Selic (E-mail); uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Nick Please see the comments interleaved. I am sorry not to have addressed this before, but you seem to have misunderstood the meaning of the metamodel for simple time. My message is that this works, do not fix it. The tweaks will have cascading effects that may make other places less elegant. Nikolai Mansurov wrote: Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). Originally the 'event' roles pointed to NamedElements and this was since the simple time model was not only addressing Interactions. In Interactions you would often attach the time expressions and durations to event occurrences, but in state machines there would be other kinds of metaclasses to attach to. Notice also that Common Behavior or higher in the package hierarchy and therefore the Interaction metaclasses are not available and therefore EventOccurrence cannot be used. Furthermore this is more general as it may not only associate to EventOccurrences even in Interactions, it may also associate with other interaction fragments with the obvious interpretation. This is exactly like in MSC. 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. StateInvariants and Continuations are NOT EventOccurrences if the metamodel has not been totally screwed up. They are Interaction Fragments and that is something very different and that is meaningful since the whole Interaction concept is built on Interaction Fragments. Please do not "fix" this. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? It may sound desirable to associate time expressions with gates, but the meaning of that is somewhat more involved. I do not think that is wise to do in the FTF. As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick I continue to comment below! -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. There is nothing wrong with this! You have misunderstood the modeling here. The Duration is an Interval and that interval has two Time Expressions (or one in the special case), but which specification elements are they attached to? That is what the 'event' association tells. It does not point to the Time Expressions but to the specification elements that are subject to these time expressions. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh Date: Mon, 15 Mar 2004 21:46:43 +0100 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Nikolai Mansurov CC: Oystein Haugen , "Branislav Selic (E-mail)" , uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=1.119, required 12, HTML_20_30 0.47, HTML_FONTCOLOR_BLUE 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) X-UiO-Spam-score: s Nick Thank you for your last clarifications. Let me try and summarize what is important to me in this context. 1. Simple time model is not only for Interactions. If it were, the time concepts would have been placed there which of course would have been wrong. 2. Making tweaks to the Interaction metamodel will only make the simple time model more associated with Interactions rather than the other behavioral notations. 3. NamedElement is definitely too general, but it was/is the lowest metaclass I could find. To improve this there is a need for further alignment of the different behavior description variants which probably goes beyond this FTF. The discussion on Event etc. etc. is a good start and probably this could be the start of this other discussion on time. 4. It is possible to write in the simple time model as constraints (textually) that only some constructs actually apply and not all NamedElements. Formally it is more difficult because of the placement of Common Behavior in the total package structure. Thanks, Oystein Nikolai Mansurov wrote: Hi Oystein, Thanks for your detailed comments, I really appreciate you taking time to review, this was very valuable indeed. Regarding the "association targets" for Duration and Time Expression. I do understand that introducing a dependency between SimpleTime and Interaction packages is a concern. However, the possibility to associate Duration with ANY NamedElement is also a concern. For example, what is the meaning of a duration between two classes ? Logically, Duration should be an association between two OccurencesSpecifications, and nothing else. So, the question is, what other model elements specify OccurenceSpecifications ? Maybe we should move OccurenceSpecification to another package higher up in the hierarchy, like CommonBehaviors ? Then let Interactions::OccurenceSpecification subclass it. In fact, part of the original proposal was to rename Interactions::OccurenceSpecification into Interactions::OrderableOccurenceSpecification. Regarding the restructuring of subclasses of the InteractionFragment. You are absolutely right in pointing out that StateInvariants and Continuations are NOT subclasses of EventOccurence (OccurenceSpecification), but rather of InteractionFragment. I have to admit, this was a wrong summary of the original lengthy restructuring proposal. The rest of the proposal suggests having an abstract class CompositeOccurenceSpecification with associations to two OccurenceSpecifications (roles start and end). The reason: in Interaction one should be able to add Duration annotations also to InteractionUse, CombinedFragment and InteractionOperand. The goal of the whole restructuring is to more precisely specify the usage of Durations and Time Expressions with OccurenceSpecifications. In other words, the price of being more precise in defining the targets of Duration and TimeExpression is to either forbid InteractionUse and CombinedFragment as such targets (since they are currently not associated with EventOccurences), or to provide such associations (via an abstract class, or alterantively, directly). Best regards, Nick -----Original Message----- From: Oystein Haugen [mailto:oysteinh@ifi.uio.no] Sent: Monday, March 15, 2004 3:32 AM To: Nikolai Mansurov Cc: Branislav Selic (E-mail); uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Nick Please see the comments interleaved. I am sorry not to have addressed this before, but you seem to have misunderstood the meaning of the metamodel for simple time. My message is that this works, do not fix it. The tweaks will have cascading effects that may make other places less elegant. Nikolai Mansurov wrote: Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). Originally the 'event' roles pointed to NamedElements and this was since the simple time model was not only addressing Interactions. In Interactions you would often attach the time expressions and durations to event occurrences, but in state machines there would be other kinds of metaclasses to attach to. Notice also that Common Behavior or higher in the package hierarchy and therefore the Interaction metaclasses are not available and therefore EventOccurrence cannot be used. Furthermore this is more general as it may not only associate to EventOccurrences even in Interactions, it may also associate with other interaction fragments with the obvious interpretation. This is exactly like in MSC. 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. StateInvariants and Continuations are NOT EventOccurrences if the metamodel has not been totally screwed up. They are Interaction Fragments and that is something very different and that is meaningful since the whole Interaction concept is built on Interaction Fragments. Please do not "fix" this. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? It may sound desirable to associate time expressions with gates, but the meaning of that is somewhat more involved. I do not think that is wise to do in the FTF. As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick I continue to comment below! -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. There is nothing wrong with this! You have misunderstood the modeling here. The Duration is an Interval and that interval has two Time Expressions (or one in the special case), but which specification elements are they attached to? That is what the 'event' association tells. It does not point to the Time Expressions but to the specification elements that are subject to these time expressions. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh OMG Issue No: 4263 Title: Events, signals, stimuli, etc. Source: Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall, shane.sendall@epfl.ch) Summary: Here is my understanding of communication between instances on an example (all quotes are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction, according to the spec: "A send action is an action that results in the (asynchronous) sending of a signal". Then, the signal is delivered to say instance i2, and as a consequence of the receipt, a SignalEvent is generated (according to the spec, "A signal event represents the RECEPTION of a particular (asynchronous) signal") Now the problems: 1) the spec goes on further to say about the signal event that "A signal event instance should not be confused with the action (e.g., send action) that generated it". The problem I have with my above understanding is that the send action should not be the one generating the send event but rather the reception of the signal should be the one generating it. 2)According to the spec: "A signal is a specification of an asynchronous stimulus communicated between instances" where a stimulus is more general "In the metamodel Stimulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an Operation". Thus, I conclude that the things sent between instances are stimuli. However, I'm a little confused of the relationship between events and stimuli with the following sentence taken from the spec "Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target,..." Furthermore, how are stimuli and signals related in the metamodel? Discussion: This issue refers to the event model of UML 1.x. UML 2.0 has largely revised this model and the issue is no longer applicable. A further reformulation of the event model is forthcoming in the resolution to issue 4456. Disposition: Closed, no change OMG Issue No: 4263 Title: Events, signals, stimuli, etc. Source: Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall, shane.sendall@epfl.ch) Summary: Here is my understanding of communication between instances on an example (all quotes are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction, according to the spec: "A send action is an action that results in the (asynchronous) sending of a signal". Then, the signal is delivered to say instance i2, and as a consequence of the receipt, a SignalEvent is generated (according to the spec, "A signal event represents the RECEPTION of a particular (asynchronous) signal") Now the problems: 1) the spec goes on further to say about the signal event that "A signal event instance should not be confused with the action (e.g., send action) that generated it". The problem I have with my above understanding is that the send action should not be the one generating the send event but rather the reception of the signal should be the one generating it. 2)According to the spec: "A signal is a specification of an asynchronous stimulus communicated between instances" where a stimulus is more general "In the metamodel Stimulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an Operation". Thus, I conclude that the things sent between instances are stimuli. However, I'm a little confused of the relationship between events and stimuli with the following sentence taken from the spec "Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target,..." Furthermore, how are stimuli and signals related in the metamodel? Discussion: This issue refers to the event model of UML 1.x. UML 2.0 has largely revised this model and the issue is no longer applicable. A further reformulation of the event model is forthcoming in the resolution to issue 4456. Disposition: Closed, no change