Issue 4456: Event => Event Specification (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Minor Summary: The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Resolution: This issue is resolved by the resolution to issue 6682. Revised Text: Actions taken: August 3, 2001: received issue March 8, 2005: closed issue Discussion: End of Annotations:===== Reply-To: From: "Conrad Bock" To: Cc: "Cris Kobryn" Subject: UML 1.5 issues Date: Fri, 3 Aug 2001 08:57:48 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q?+e9Oe%!!h^(!!~DRd9 Juergen, Here are my issues for UML 1.5. These are submitted as comments on the UML 1.4 as specified in ad/2001-02-13. Thanks, Conrad 11) Event => Event Specification The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Nature: Revision Severity: Minor This Event metaclass has been replaced by Trigger in UML 2.0. Note that the chapter on Actions still refers to the various subtypes of "event". This is correct if it means to refer to the informal dynamic semantics in the introductory section of common behavior, but should be replaced by the correct metaclasses if those are meant. Disposition: Closed, no change OMG Issue No: 4456 Title: Event => Event Specification Source: Kabira Technologies, Inc.NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Discussion: This Event metaclass has been replaced by Trigger in UML 2.0. Note that the chapter on Actions still refers to the various subtypes of "event". This is correct if it means to refer to the informal dynamic semantics in the introductory section of common behavior, but should be replaced by the correct metaclasses if those are meant. [Conrad: Looks like the use of the word "event" in Actions is OK, ie, it refers to the dynamic entity, but it still refers to SignalEvent, etc, which should be SignalTrigger. This should be filed as a separate issue.] Disposition: Closed, no change User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 05 Dec 2003 10:00:28 -0500 Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups From: James Odell To: Hi Thomas, I have a quick question regarding your resolution of: OMG Issue No: 4456 Title: Event => Event Specification Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov ) Summary: The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Discussion: This Event metaclass has been replaced by Trigger in UML 2.0. Note that the chapter on Actions still refers to the various subtypes of ޳event޴. This is correct if it means to refer to the informal dynamic semantics in the introductory section of common behavior, but should be replaced by the correct metaclasses if those are meant. Disposition: Closed, no change The notion of event is used 530 times within the UML 2.0 Superstructure specification. Also, in section 13.3.28 Trigger (which uses term ޳event޴ 24 times), it states that ޳In UML 2.0, the term ޳event޴ means an occurrence of an event of a particular type޲.޴ So, I find it a bit difficult to understand why the ޳Event metaclass has been replaced by Trigger in UML 2.0.޴ Like Conrad, I too am concerned about this Could you shed some light on this? Thanks, Best regards, Date: Fri, 05 Dec 2003 18:31:33 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: James Odell CC: Thomas Weigert , uml2 ftf Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups Jim, Thomas, > The notion of event is used 530 times within the UML 2.0 Superstructure specification It is also a common term in many OO languages and designs. Not sure why we changed that to a less well known term Trigger. Event and Event Occurrence (in the semantics) don't seem unreasonable terms. What was the overriding reason to reject these? Thanks, Guus James Odell wrote: Hi Thomas, I have a quick question regarding your resolution of: OMG Issue No: 4456 Title: Event => Event Specification Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov ) Summary: The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Discussion: This Event metaclass has been replaced by Trigger in UML 2.0. Note that the chapter on Actions still refers to the various subtypes of event. This is correct if it means to refer to the informal dynamic semantics in the introductory section of common behavior, but should be replaced by the correct metaclasses if those are meant. Disposition: Closed, no change The notion of event is used 530 times within the UML 2.0 Superstructure specification. Also, in section 13.3.28 Trigger (which uses term event 24 times), it states that In UML 2.0, the term event means an occurrence of an event of a particular type. So, I find it a bit difficult to understand why the Event metaclass has been replaced by Trigger in UML 2.0. Like Conrad, I too am concerned about this Could you shed some light on this? Thanks, Best regards, Jim O -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Joaquin Miller Cc: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 5 Dec 2003 13:51:10 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/05/2003 13:51:12, Serialize complete at 12/05/2003 13:51:12 To my knowledge, no existing UML tool provided the capability to define events explicitly. Instead, they were implied in things such as triggers. No one complained about that. This is one of the reasons we felt that there was no need to support the concept with its own class. Hence the impact on existing users is minimal or null. To repeat, the concept is in the (informal) UML semantics, but not in the metamodel. Why overload the metamodel which, as we know, suffers from overload as it is. In discussions such as these, it is sometimes useful to start from a practical rather than a theoretical perspective. Bran Joaquin Miller 12/05/2003 12:44 PM Please respond to Joaquin Miller To: cc: Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups ... I find it a bit difficult to understand why the Event metaclass has been replaced by Trigger in UML 2.0. Like Conrad, I too am concerned about this Could you shed some light on this? Thanks, Me, too. As we all know, "Proposals shall minimize the impact on users of the current UML 1.x... Wherever changes have adversely impacted backward compatibility with previous specifications, submissions shall provide rationales." No rationale for this change is offered in the document. (I suppose we could quibble about 'adverse.' We could then also talk about 'gratuitous.' The following might be more productive.) Rather than having to invent, for each concept, a pair of terms, and then being in the embarrassing position of asking users to remember the two terms and remember which is which, we could use a single term for each concept, and then use 'type' and 'instance.' Or, if folks like to split here, 'type' and 'instance' plus 'type' and 'occurrence.' (Of course, the tradition is to have two terms: 'Class'/'Object', 'Association'/'Link'. So our other choice is to stick with tradition. Then, to be consistent with the past and backward compatible with UML 1, we should have 'Event'/'Trigger', not 'Trigger'/'Event'.) Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 To: uml2-superstructure-ftf@omg.org Cc: Joaquin Miller Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 5 Dec 2003 14:29:13 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/05/2003 14:29:15, Serialize complete at 12/05/2003 14:29:15 For some reason my first message got reordered or lost so I am resending it (apologies for repeats): Triggers and Events are different things. A trigger may be induced by an event, but that does not mean that they are the same. Event has been removed form the metamodel as an explicit metaclass (although it exists as a concept in the description of semantics) since there did not seem to be any need to model them explicitly (e.g., independently of things such as trigger). This may change later, but only if there is an explicit need for it. Bran Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Dec 2003 14:35:55 -0800 To: uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups Triggers and Events are different things. A trigger may be induced by an event, but that does not mean that they are the same. Event has been removed form the metamodel as an explicit metaclass (although it exists as a concept in the description of semantics) since there did not seem to be any need to model them explicitly (e.g., independently of things such as trigger). I don't contradict that. But, for what little it might be worth, that is an entirely different story than the story in the final adopted specification, viz: 13.3.28 Trigger Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term event means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: Joaquin Miller , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 06:54:23 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Which kind of users are impacted by this? This is simply a metaclass namechange. I think this issue is one more example of meta level confusion. The analogy with Class/Object and Association/Link does not help: there are no metaclasses Object and Link. Trigger is a metaclass the objects of which represents elements in M1 models that _specify_ which kind of event may trigger a transition. /birger -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: 5. desember 2003 18:44 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups ... I find it a bit difficult to understand why the Event metaclass has been replaced by Trigger in UML 2.0. Like Conrad, I too am concerned about this Could you shed some light on this? Thanks, Me, too. As we all know, "Proposals shall minimize the impact on users of the current UML 1.x... Wherever changes have adversely impacted backward compatibility with previous specifications, submissions shall provide rationales." No rationale for this change is offered in the document. (I suppose we could quibble about 'adverse.' We could then also talk about 'gratuitous.' The following might be more productive.) Rather than having to invent, for each concept, a pair of terms, and then being in the embarrassing position of asking users to remember the two terms and remember which is which, we could use a single term for each concept, and then use 'type' and 'instance.' Or, if folks like to split here, 'type' and 'instance' plus 'type' and 'occurrence.' (Of course, the tradition is to have two terms: 'Class'/'Object', 'Association'/'Link'. So our other choice is to stick with tradition. Then, to be consistent with the past and backward compatible with UML 1, we should have 'Event'/'Trigger', not 'Trigger'/'Event'.) Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: "'Joaquin Miller'" , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 07:10:04 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) The quoted part of the spec may not qualify for an award on the best written text in this century, but in fact it covers more than just a metaclass name change. Have a look at the 1.4 spec at this point and try to figure out what parameters did there. 1.4 did also talk about 'type of event', while this is now covered by e.g Signal classifiers. /birger -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: 5. desember 2003 23:36 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups Triggers and Events are different things. A trigger may be induced by an event, but that does not mean that they are the same. Event has been removed form the metamodel as an explicit metaclass (although it exists as a concept in the description of semantics) since there did not seem to be any need to model them explicitly (e.g., independently of things such as trigger). I don't contradict that. But, for what little it might be worth, that is an entirely different story than the story in the final adopted specification, viz: 13.3.28 Trigger Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term "event" means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 08 Dec 2003 08:25:21 -0500 Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups From: James Odell To: Hi Birger, While I agree that all signals might be though of as events, not all events are signals. That is why some of us had Event in UML 1. According to the UML 2.0 spec: A signal is a specification of type of send request instances communicated between objects. In other words, a signal is a request. An event is more: it is a noteworthy change in state (something that happens as Jim R likes to say). While signals are something that happens, not all somethings-that-happen are signals. For example, an address change in a customers record is an event; based on this event there could be several triggers that might invoke other database updates. Also, in the UML 2 spec for signalTrigger, it says:A signal trigger specifies a signal event as caused by an object receiving a send request from some other object or from itself. A signal event may result in the execution of the behavior that implements the reception matching the received signal. A signal event makes available any argument values carried by the received send request to all behaviors caused by this event (such as transition actions or entry actions). In short, a signal trigger specifies a signal event. How can there be a signal event is there is no Event? In you previous email you wrote: Trigger is a metaclass the objects of which represents elements in M1 models that _specify_ which kind of event may trigger a transition. Even here, the notion of kind of event is acknowledged. All I am asking is to return it to its first-class position in the metamodel not do away with trigger. IMO, they are both very useful. As I mentioned in an earlier email, the notion of event is used [literally] 530 times within the UML 2.0 Superstructure specification. How can such an important notion NOT be a first class element? Kind regards, Jim On 12/8/03 1:10 AM, "Birger Mller-Pedersen (AS/ETO)" indited: The quoted part of the spec may not qualify for an award on the best written text in this century, but in fact it covers more than just a metaclass name change. Have a look at the 1.4 spec at this point and try to figure out what parameters did there. 1.4 did also talk about 'type of event', while this is now covered by e.g Signal classifiers. /birger -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: 5. desember 2003 23:36 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups Triggers and Events are different things. A trigger may be induced by an event, but that does not mean that they are the same. Event has been removed form the metamodel as an explicit metaclass (although it exists as a concept in the description of semantics) since there did not seem to be any need to model them explicitly (e.g., independently of things such as trigger). I don't contradict that. But, for what little it might be worth, that is an entirely different story than the story in the final adopted specification, viz: 13.3.28 Trigger Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term "event" means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. Cordially, Joaquin X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: "'James Odell'" , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 15:32:00 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Jim, I amnot sure that being a first-class element qualifies for being represented by a metaclass. I really do not know what being a 'first-class' element means in the world of meta levels and meta clases, but if the number of occurrences in the spec text is the measure, then think of e.g. 'object' and 'link': there are 899 occurrences of 'object' and 386 of 'link', but no metaclasses with these names. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 14:25 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Hi Birger, While I agree that all signals might be though of as events, not all events are signals. That is why some of us had Event in UML 1. According to the UML 2.0 spec: "A signal is a specification of type of send request instances communicated between objects." In other words, a signal is a request. An event is more: it is a noteworthy change in state ("something that happens" as Jim R likes to say). While signals are "something that happens", not all somethings-that-happen are signals. For example, an address change in a customers record is an event; based on this event there could be several triggers that might invoke other database updates. Also, in the UML 2 spec for "signalTrigger, it says:"A signal trigger specifies a signal event as caused by an object receiving a send request from some other object or from itself. A signal event may result in the execution of the behavior that implements the reception matching the received signal. A signal event makes available any argument values carried by the received send request to all behaviors caused by this event (such as transition actions or entry actions)." In short, a signal trigger specifies a signal event. How can there be a signal event is there is no Event? In you previous email you wrote: "Trigger is a metaclass the objects of which represents elements in M1 models that _specify_ which kind of event may trigger a transition. " Even here, the notion of "kind of event" is acknowledged. All I am asking is to return it to its first-class position in the metamodel - not do away with trigger. IMO, they are both very useful. As I mentioned in an earlier email, the notion of event is used [literally] 530 times within the UML 2.0 Superstructure specification. How can such an important notion NOT be a first class element? Kind regards, Jim On 12/8/03 1:10 AM, "Birger Mller-Pedersen (AS/ETO)" indited: The quoted part of the spec may not qualify for an award on the best written text in this century, but in fact it covers more than just a metaclass name change. Have a look at the 1.4 spec at this point and try to figure out what parameters did there. 1.4 did also talk about 'type of event', while this is now covered by e.g Signal classifiers. /birger -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: 5. desember 2003 23:36 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups Triggers and Events are different things. A trigger may be induced by an event, but that does not mean that they are the same. Event has been removed form the metamodel as an explicit metaclass (although it exists as a concept in the description of semantics) since there did not seem to be any need to model them explicitly (e.g., independently of things such as trigger). I don't contradict that. But, for what little it might be worth, that is an entirely different story than the story in the final adopted specification, viz: 13.3.28 Trigger Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term "event" means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: joaquin@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Dec 2003 08:41:05 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups The quoted part of the spec may not qualify for an award on the best written text in this century, but in fact it covers more than just a metaclass name change. My message was too long, and so my point was obscured. Here is a shorter version. Triggers and Events are different things. 13.3.28 Trigger Changes from UML 1.x The corresponding metaclass in 1.x was Event. The text might not win an award on the best written text in this century, but it certainly does qualify for entry in the contest. It is crystal clear. It says UML 2 Trigger corresponds to UML 1 Event. All i said, and say, is that these are two different stories. Let's not blame the editor of UML2: this is not a case of bad writing. (It's true that i can't make sense of the rest of the text, but this sentence is clear.) Reply-To: Joaquin Miller X-Sender: joaquin@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Dec 2003 08:55:13 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups ... not all events are signals. ... An event is [any] noteworthy change in state (Given that a trigger is a type satisfied by events,) this is covered by Figure 317. User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 08 Dec 2003 12:56:35 -0500 Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups From: James Odell To: Birger, Yes, I meant that Event (tyoe) should be a metaclass. Sorry that I was sloppy in my phrasing. I will trust you when you say that there are 899 occurrences of 'object' and 386 of 'link' -- and you make a valid point. Part of my reasoning here is that object and link are at least instances of bona fide UML metaclasses. However, event instances (such as Order 123 filled) are not instances of anything that recognizes their event-ness. Cheers, Jim On 12/8/03 9:32 AM, "Birger Mller-Pedersen (AS/ETO)" indited: Jim, I amnot sure that being a first-class element qualifies for being represented by a metaclass. I really do not know what being a 'first-class' element means in the world of meta levels and meta clases, but if the number of occurrences in the spec text is the measure, then think of e.g. 'object' and 'link': there are 899 occurrences of 'object' and 386 of 'link', but no metaclasses with these names. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 14:25 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Hi Birger, While I agree that all signals might be though of as events, not all events are signals. That is why some of us had Event in UML 1. According to the UML 2.0 spec: "A signal is a specification of type of send request instances communicated between objects." In other words, a signal is a request. An event is more: it is a noteworthy change in state ("something that happens" as Jim R likes to say). While signals are "something that happens", not all somethings-that-happen are signals. For example, an address change in a customers record is an event; based on this event there could be several triggers that might invoke other database updates. Also, in the UML 2 spec for "signalTrigger, it says:"A signal trigger specifies a signal event as caused by an object receiving a send request from some other object or from itself. A signal event may result in the execution of the behavior that implements the reception matching the received signal. A signal event makes available any argument values carried by the received send request to all behaviors caused by this event (such as transition actions or entry actions)." In short, a signal trigger specifies a signal event. How can there be a signal event is there is no Event? In you previous email you wrote: "Trigger is a metaclass the objects of which represents elements in M1 models that _specify_ which kind of event may trigger a transition. " Even here, the notion of "kind of event" is acknowledged. All I am asking is to return it to its first-class position in the metamodel - not do away with trigger. IMO, they are both very useful. As I mentioned in an earlier email, the notion of event is used [literally] 530 times within the UML 2.0 Superstructure specification. How can such an important notion NOT be a first class element? Kind regards, Jim On 12/8/03 1:10 AM, "Birger Mller-Pedersen (AS/ETO)" indited: The quoted part of the spec may not qualify for an award on the best written text in this century, but in fact it covers more than just a metaclass name change. Have a look at the 1.4 spec at this point and try to figure out what parameters did there. 1.4 did also talk about 'type of event', while this is now covered by e.g Signal classifiers. /birger -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: 5. desember 2003 23:36 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups Triggers and Events are different things. A trigger may be induced by an event, but that does not mean that they are the same. Event has been removed form the metamodel as an explicit metaclass (although it exists as a concept in the description of semantics) since there did not seem to be any need to model them explicitly (e.g., independently of things such as trigger). I don't contradict that. But, for what little it might be worth, that is an entirely different story than the story in the final adopted specification, viz: 13.3.28 Trigger Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term "event" means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. Cordially, Joaquin User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 08 Dec 2003 13:26:44 -0500 Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups From: James Odell To: Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of Event metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term trigger was chosen as a substitute for event when both UML 1 & 2 support the term event. If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: "'James Odell'" , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 19:56:49 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim Reply-To: Joaquin Miller X-Sender: joaquin@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Dec 2003 11:31:56 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: FW: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Thanks, Birger. (I am on the list.) Well, we crossed in the mail on this, as i was making a longer response on the very same topic of the diagrams. As you will see from my message, i don't have the faintest idea what the specification intends to be the distinction between trigger and event... ... between the UML metaclass, Trigger, and this event, or Event, or both that we are discussing. Cordially, Joaquin At 11:03 AM 12/8/2003, you wrote: Joaquin, I am not sure if you are on the FTF mailing list, so I forward this answer to you. Hope that it clarfies the distinction between Trigger and Event. /birger -----Original Message----- From: Birger Mller-Pedersen (AS/ETO) Sent: 8. desember 2003 19:57 To: 'James Odell'; uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 08 Dec 2003 15:07:35 -0500 Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups From: James Odell To: Birger, I was not confused about this. I understand that the event metaclasses in the Figs. 307 310 are not blessed UML metaclasses. I was only using that as an argument that: A) Events should be a bone fide UML 2.0 metaclass as it was in UML 1; B) If trigger is just a substitute for the term event, then why do it. Why not just keep event as event-- to be both compatible with UML 1 and consistent with UML 2. Cheers, Jim On 12/8/03 1:56 PM, "Birger Mller-Pedersen (AS/ETO)" indited: Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: "'James Odell'" , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 21:53:19 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) OK, if that is the problem, the the answer is (as far as I recall it, but others may have a better memory): The term 'Event' was considered the right term for what happened at 'run-time' and therefore introduced in the semantic domain models in common behavior. An implication of this was that 'Event' would not be the right name of the metaclass representing the fact a transition has a trigger specified. In addition the 1.4 model of Event had to be changed, as it was a mixture of 2.0 Trigger and 2.0 Event. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 21:08 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, I was not confused about this. I understand that the event metaclasses in the Figs. 307 - 310 are not "blessed" UML metaclasses. I was only using that as an argument that: A) Events should be a bone fide UML 2.0 metaclass as it was in UML 1; B) If "trigger" is just a substitute for the term "event", then why do it. Why not just keep event as "event"-- to be both compatible with UML 1 and consistent with UML 2. Cheers, Jim On 12/8/03 1:56 PM, "Birger Mller-Pedersen (AS/ETO)" indited: Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 16:12:26 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Thread-Index: AcO9zW2+KIqCEktjQA6qHBUpYx+MhgAAFPrA From: "Karl Frank" To: Birger Mller-Pedersen (AS/ETO) , "James Odell" , X-OriginalArrivalTime: 08 Dec 2003 21:12:26.0708 (UTC) FILETIME=[FB372140:01C3BDCF] The following is a test to see if I get it. The runtime item is an event, so the word "event" could not be used for the UML modeling element intended to specify that runtime item, because the symbol is a different thing from what it symolizes, so a different word was chosen. Instead of "event" the chosen word was "trigger." Thus "trigger" is the name of a modeling element which is intended to model or represent or "specify" events. It was agreed that UML metamodel elements represent UML model elements, instances of which are used in user-models to model run-time elements, and each of these elements at different levels are different things from their counterparts at other levels, so the policy was decided upon within U2P circles that one should not name the modeling element by the same name as is used for the real-world item (in the semantic domain). Is that what Birger is saying? If so, the situationi is exactly as in Charles Dobson's example, where a book named "Foo" has a name for its name, "Bar" being the name used for the string 'f' + 'o' + 'o', which string was the name of the book. So the name of the name of Foo (no quotes, the word is being used not mentioned) is "Bar". Karl -----Original Message----- From: Birger Mller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, December 08, 2003 3:53 PM To: 'James Odell'; uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups OK, if that is the problem, the the answer is (as far as I recall it, but others may have a better memory): The term 'Event' was considered the right term for what happened at 'run-time' and therefore introduced in the semantic domain models in common behavior. An implication of this was that 'Event' would not be the right name of the metaclass representing the fact a transition has a trigger specified. In addition the 1.4 model of Event had to be changed, as it was a mixture of 2.0 Trigger and 2.0 Event. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 21:08 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, I was not confused about this. I understand that the event metaclasses in the Figs. 307 - 310 are not "blessed" UML metaclasses. I was only using that as an argument that: A) Events should be a bone fide UML 2.0 metaclass as it was in UML 1; B) If "trigger" is just a substitute for the term "event", then why do it. Why not just keep event as "event"-- to be both compatible with UML 1 and consistent with UML 2. Cheers, Jim On 12/8/03 1:56 PM, "Birger Mller-Pedersen (AS/ETO)" indited: Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim To: James Odell Cc: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Dec 2003 16:31:56 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/08/2003 16:32:02, Serialize complete at 12/08/2003 16:32:02 Thomas and I wrote the overview of Common Behavior that discusses the role of events. This is where such things belong, not in state machines. However, in UML 1.x, Event was defined in the context of state machines and, this is why Birger, who did most of the updates to the state machines section, made his fix in that context. To repeat what I said before, the concept of "event" (whether it is a metaclass or not) is much more general than just things that trigger state machine transitions. It is a fundamental concept that has to do with the core run-time semantics of UML. It, as well as the related concepts of Message and EventOccurrence should be defined in the CommonBehavior section. Unfortunately, Message and EventOccurrence are currently, inappropriately, defined in the Interactions section (not Oystein's fault, he needed a solution to his problem and he solved it). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com James Odell 12/08/2003 01:26 PM To: cc: Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of “Event” metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term “trigger” was chosen as a substitute for event — when both UML 1 & 2 support the term “event.” If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim To: Birger Mller-Pedersen (AS/ETO) Cc: "'James Odell'" , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Dec 2003 16:36:40 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/08/2003 16:36:45, Serialize complete at 12/08/2003 16:36:45 Exactly. There is a statement in the CommonBehavior overview section that clearly states that these are not metamodel fragments but descriptions of core run-time semantics. Perhaps, as was done in the 2U submission, these things should be part of the metamodel? In my naive view, a concept should have a metaclass in the metamodel if instances of it can appear in a user model. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Birger Mller-Pedersen (AS/ETO) 12/08/2003 01:56 PM To: "'James Odell'" , uml2-superstructure-ftf@omg.org cc: Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim To: James Odell Cc: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Dec 2003 16:44:59 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/08/2003 16:45:05, Serialize complete at 12/08/2003 16:45:05 Jim, Why put something in the metamodel if there will never be an instance of it (or of any of its subclasses) in a user model? Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com James Odell 12/08/2003 03:07 PM To: cc: Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, I was not confused about this. I understand that the event metaclasses in the Figs. 307 – 310 are not “blessed” UML metaclasses. I was only using that as an argument that: A) Events should be a bone fide UML 2.0 metaclass as it was in UML 1; B) If “trigger” is just a substitute for the term “event”, then why do it. Why not just keep event as “event”-- to be both compatible with UML 1 and consistent with UML 2. Cheers, Jim On 12/8/03 1:56 PM, "Birger Møller-Pedersen (AS/ETO)" indited: Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: "'Karl Frank'" , James Odell , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Mon, 8 Dec 2003 22:57:48 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Karl, you almost got it, however, the explanation from Bran is better than the short one I gave. If you look into the common behavior introduction, you will see that there are many kinds of events, and not all of these have to do with triggers in state machines. There was no general U2P policy on the naming of metaclasses. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 8. desember 2003 22:12 To: Birger Mller-Pedersen (AS/ETO); James Odell; uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups The following is a test to see if I get it. The runtime item is an event, so the word "event" could not be used for the UML modeling element intended to specify that runtime item, because the symbol is a different thing from what it symolizes, so a different word was chosen. Instead of "event" the chosen word was "trigger." Thus "trigger" is the name of a modeling element which is intended to model or represent or "specify" events. It was agreed that UML metamodel elements represent UML model elements, instances of which are used in user-models to model run-time elements, and each of these elements at different levels are different things from their counterparts at other levels, so the policy was decided upon within U2P circles that one should not name the modeling element by the same name as is used for the real-world item (in the semantic domain). Is that what Birger is saying? If so, the situationi is exactly as in Charles Dobson's example, where a book named "Foo" has a name for its name, "Bar" being the name used for the string 'f' + 'o' + 'o', which string was the name of the book. So the name of the name of Foo (no quotes, the word is being used not mentioned) is "Bar". Karl -----Original Message----- From: Birger Mller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, December 08, 2003 3:53 PM To: 'James Odell'; uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups OK, if that is the problem, the the answer is (as far as I recall it, but others may have a better memory): The term 'Event' was considered the right term for what happened at 'run-time' and therefore introduced in the semantic domain models in common behavior. An implication of this was that 'Event' would not be the right name of the metaclass representing the fact a transition has a trigger specified. In addition the 1.4 model of Event had to be changed, as it was a mixture of 2.0 Trigger and 2.0 Event. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 21:08 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, I was not confused about this. I understand that the event metaclasses in the Figs. 307 - 310 are not "blessed" UML metaclasses. I was only using that as an argument that: A) Events should be a bone fide UML 2.0 metaclass as it was in UML 1; B) If "trigger" is just a substitute for the term "event", then why do it. Why not just keep event as "event"-- to be both compatible with UML 1 and consistent with UML 2. Cheers, Jim On 12/8/03 1:56 PM, "Birger Mller-Pedersen (AS/ETO)" indited: Jim, this illustrates the confusion: The classes in figures 307, 308, 309, and 310 are not metaclasses, they are semantic domain model classes. Trigger is a metaclass. A metaobject of this represents (e.g. in a repository) the part of a transition in a state machine model that has to do with what triggers the transition. A metaobject of meclass Activity represents the effect specification part of the transition. The transition itself is represented by a metaobject of class Transition. /birger -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: 8. desember 2003 19:27 To: uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Birger, As a matter of reference, the Overview in the UML 2.0 Common Behavior chapter (Chapter 13) has quite a few things to say about event. Figures 307, 308, 309, and 310 illustrate the use of "Event" metaclasses accompanied by a few pages of discourse. Here, the use is compatible both in meaning and term usage with UML 1. So, I am wondering why the term "trigger" was chosen as a substitute for event - when both UML 1 & 2 support the term "event." If it is really just a name change, why not just change it back to adopt to be compatible with the usage in both UML 1 & 2? Cheers, Jim From: Edwin Seidewitz To: uml2-superstructure-ftf@omg.org Subject: Events and triggers [was RE: Updated: Proposed issue resolution f or common behavior and composite structure working groups] Date: Mon, 8 Dec 2003 17:12:42 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) OK, I was going to try to stay out of this thread, but I think I might (hopefully) be able to add something that is more helpful than confusing. UML 1.x o There is an Event metaclass as part of the state machine metamodel. This class is used under the rolename "trigger" to specify the trigger of a transition. o The term "event" is not used entirely consistently in the text, sometimes meaning "something that happens" and sometimes meaning "a specification of something that happens" (AKA "event type"). (I actually think the wording was improved and made a little more consistent in the 1.4 and 1.5 specs.) o There is no way to specify anything called, or even referred to, as an "event" separately from a state machine. Instead, it is essentially recommended to signals for the purposes many people consider to be "modeling events", even though signals are not, themselves, events. o There is no way to model an "instance" of a Classifier, since Event is not a Classifier. It is, of course, possible to model an instance of a Signal (since it is a Classifier). One can also model the sending of a signal and the "event" of its reception, but there is no way to notate the "happening" of any other kind of event. o In my experience, the UML 1.x terminology for "events" (especially the last point, and the relation between the sending of signals and the "event" of their reception) was quite confusing to people, especially those who were well-versed in developing event-driven systems. They kept wanting to know how to model the "events" themselves, separately from how they were handled. They sometimes ended up using signals for this, but usually still called them "events" (at least when no UML terminology police were listening...). Action Semantics o In the action semantics, we needed to actually discuss the "somethings that happen" in order to describe run-time behavior of state machines. The first tendency was to use the term "event" for "something that happens" and "event type" for the specification of that. But this would have been largely inconsistent with the existing UML 1.4 terminology for event. So we used the term "occurrence" for "something that happens" and "event" for "the specification of an occurrence that triggers a transition on a state machine". (At least, this was the terminology when we had a formal definition of the semantics in the submission. I don't think it really made it into the UML 1.5 specification.) UML 2.0 o There is a Trigger metaclass as part of the state machine metamodel. This name seems appropriate, because its purpose is to specify the trigger of a transition. (It is also used for defining certain kinds of actions, like AcceptEventAction.) o The term "event" is (or should be) used consistently to mean "something that happens". It is a run-time concept used to explain the semantics of state machines. The Event class is used only in the definition of these semantics, it is not part of the abstract syntax metamodel. o Trigger is not a Classifier, so there is still no way to specify a Trigger separately from a state machine. (Though, with the name "Trigger", this seems less incongruous than it did for Event in UML 1.x.) o As in UML 1.x, there is still no way to model an "instance" of a Trigger. If you want something "event-like" with instances, you still have to use Signals. o I would suggest that, for how this concept is still being used in UML 2.0, "Trigger" is a better name than "Event". In my experience, the use of the term "event" in this context in UML 1.x led many people to confuse what actual was in UML with the more expansive concept they were used to from other approaches to event modeling. The concept being called "Trigger" in UML 2.0 is not really a "first class" event specification, it is only what it says it is -- a specification of the triggering of certain behavior in response to some event -- that is, "what to do" when "something happens". o Whether UML should really have a first-class modeling element for "event type" is a separate issue. -- Ed To: Joaquin Miller Cc: UML Superstructure FTF Subject: Re: ,cb, triggers and their connection with events X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Dec 2003 16:39:56 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/08/2003 16:40:02, Serialize complete at 12/08/2003 16:40:02 My answers to Joaquin's questions: 1. Is an event a "instance" of a trigger? No. 2. Is a trigger a type that is satisfied by events? No. 3. Is a trigger a list of events? No. 4. Is a trigger simply an element of a specification language, that does not directly represent anything in the modeled system, but is used as an element of a specification of behavior. I am not sure what this is asking. An event is some kind of change of state in the modeled system. 4. Are events and triggers different things, the first not an "instance" of the second? Yes. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Joaquin Miller 12/08/2003 02:27 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: ,cb, triggers and their connection with events The Overview to the UML 2.0 Common Behavior chapter (Chapter 13) has, in Figures 307, 308, 309, and 310, boxes with names that include the string "Event." In fact, Figure 307 has a box named "Event." The text tells us that these are domain models. If there is an exact specification of what a domain models is, or if there is an informal explication of domain models, i have not found it yet. But i do believe that these figures are meant to show classifications of things that happen in a system. In other words, the box labeled 'Event' is not an element of the UML 2 metamodel, nor of any metamodel. The box represents a class (set) of items, and the figures mentioned above are a classification scheme for those items. Each item, i believe, is something that happens in the modeled system. ... A text there says: "Signal events and call events are specified by the corresponding metaclasses (see "SignalTrigger" on page 396 and "CallTrigger" on page 385)." 11.3.2 says: "trigger : Trigger [1] The type of event accepted by the action, ..." So, we can be excused for reading the specification to say that an event is an "instance" of a trigger. This fits with my reading of the meaning of 'domain model.' ... 13.3.28 says "A trigger specifies the an event..." ... 13.3.28 also says "A trigger is denoted by a list of names of the triggering events, ..." ----------------- So, some simple and direct questions, that may have straight, one word, yes-or-no answers: 1. Is an event a "instance" of a trigger? 2. Is a trigger a type that is satisfied by events? 3. Is a trigger a list of events? 4. Is a trigger simply an element of a specification language, that does not directly represent anything in the modeled system, but is used as an element of a specification of behavior. 4. Are events and triggers different things, the first not an "instance" of the second? And a free bonus question that may have a straight, short answer: 6. What does 'denoted' mean in 13.3.28? ====================== Think about this: If the ongoing discussion among experts is evidence, what will readers make of our specification? Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: joaquin@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Dec 2003 14:16:25 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,cb, triggers, eventOccurrences, and events ... the concept of "event" ... is much more general than just things that trigger state machine transitions. It is a fundamental concept that has to do with the core run-time semantics of UML. It, as well as the related concepts of Message and EventOccurrence should be defined in the CommonBehavior section. Let me see if i have this straight. (I suppose i don't, but we have to start somewhere.) Here is a strict analogy: Trigger Class EventOccurrence InstanceSpecification event that triggers object Right? If not, what? .............................. [The following just for those who care; no reply to the following expected.] Here is an attempt to map U2P to 3C: Trigger one kind of Type of Action EventOccurrence Action event that triggers something that happens Cordially, Joaquin From: Edwin Seidewitz To: uml2-superstructure-ftf@omg.org Subject: RE: Events and triggers [was RE: Updated: Proposed issue resoluti on f or common behavior and composite structure working groups] Date: Mon, 8 Dec 2003 17:17:24 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Oops... Cut and paste error. UML 2.0 o There is a Trigger metaclass as part of the state machine metamodel. This name seems appropriate, because its purpose is to specify the trigger of a transition. (It is also used for defining certain kinds of actions, like AcceptEventAction.) As Bran mentioned, in UML 2.0, Trigger is not in the state machine metamodel. It is in the common behavior metamodel and it is used in both the state machine metamodel and the action metamodel. -- Ed X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Mller-Pedersen (AS/ETO) To: "'Edwin Seidewitz'" , uml2-superstructure-ftf@omg.org Subject: RE: Events and triggers [was RE: Updated: Proposed issue resoluti on f or common behavior and composite structure working groups] Date: Tue, 9 Dec 2003 07:19:18 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Ed, I think this was a very good (and adding to the non-confusion) recap of things! /birger -----Original Message----- From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] Sent: 8. desember 2003 23:13 To: uml2-superstructure-ftf@omg.org Subject: Events and triggers [was RE: Updated: Proposed issue resolution f or common behavior and composite structure working groups] OK, I was going to try to stay out of this thread, but I think I might (hopefully) be able to add something that is more helpful than confusing. UML 1.x o There is an Event metaclass as part of the state machine metamodel. This class is used under the rolename "trigger" to specify the trigger of a transition. o The term "event" is not used entirely consistently in the text, sometimes meaning "something that happens" and sometimes meaning "a specification of something that happens" (AKA "event type"). (I actually think the wording was improved and made a little more consistent in the 1.4 and 1.5 specs.) o There is no way to specify anything called, or even referred to, as an "event" separately from a state machine. Instead, it is essentially recommended to signals for the purposes many people consider to be "modeling events", even though signals are not, themselves, events. o There is no way to model an "instance" of a Classifier, since Event is not a Classifier. It is, of course, possible to model an instance of a Signal (since it is a Classifier). One can also model the sending of a signal and the "event" of its reception, but there is no way to notate the "happening" of any other kind of event. o In my experience, the UML 1.x terminology for "events" (especially the last point, and the relation between the sending of signals and the "event" of their reception) was quite confusing to people, especially those who were well-versed in developing event-driven systems. They kept wanting to know how to model the "events" themselves, separately from how they were handled. They sometimes ended up using signals for this, but usually still called them "events" (at least when no UML terminology police were listening...). Action Semantics o In the action semantics, we needed to actually discuss the "somethings that happen" in order to describe run-time behavior of state machines. The first tendency was to use the term "event" for "something that happens" and "event type" for the specification of that. But this would have been largely inconsistent with the existing UML 1.4 terminology for event. So we used the term "occurrence" for "something that happens" and "event" for "the specification of an occurrence that triggers a transition on a state machine". (At least, this was the terminology when we had a formal definition of the semantics in the submission. I don't think it really made it into the UML 1.5 specification.) UML 2.0 o There is a Trigger metaclass as part of the state machine metamodel. This name seems appropriate, because its purpose is to specify the trigger of a transition. (It is also used for defining certain kinds of actions, like AcceptEventAction.) o The term "event" is (or should be) used consistently to mean "something that happens". It is a run-time concept used to explain the semantics of state machines. The Event class is used only in the definition of these semantics, it is not part of the abstract syntax metamodel. o Trigger is not a Classifier, so there is still no way to specify a Trigger separately from a state machine. (Though, with the name "Trigger", this seems less incongruous than it did for Event in UML 1.x.) o As in UML 1.x, there is still no way to model an "instance" of a Trigger. If you want something "event-like" with instances, you still have to use Signals. o I would suggest that, for how this concept is still being used in UML 2.0, "Trigger" is a better name than "Event". In my experience, the use of the term "event" in this context in UML 1.x led many people to confuse what actual was in UML with the more expansive concept they were used to from other approaches to event modeling. The concept being called "Trigger" in UML 2.0 is not really a "first class" event specification, it is only what it says it is -- a specification of the triggering of certain behavior in response to some event -- that is, "what to do" when "something happens". o Whether UML should really have a first-class modeling element for "event type" is a separate issue. -- Ed OMG Issue No: 4456 Title: Event => Event Specification Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Discussion: This issue is resolved by the resolution to issue 6682. Disposition: Resolved Jim O 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 From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Draft of ballot 23 -- pelase review Date: Fri, 13 Aug 2004 05:27:30 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments... 4456: This issue was assigned to me, but I agree with the disposition. 7039: The resolution text is incorrect. Datatype is a classifer, so changing Association.endtype to classifier would not disallow associations to be drawn to classifier. However, it is not clear why the issue is an issue. 7553: I strongly disagree with this resolution. It does not make any sense to think of an interaction as being about nothing. A lifeline must represent something. The issuer seems to be confused about whether it is legal to have a temporary incomplete model. We have discussed many times that during development it is perfectly fine to have "under flow" of multiplicities (e.g., one does not yet specifiy some mandatory piece of information). However, in a final model we need to insist that all the necessary information is filled in. So, during the course of development it is fine if the lifeline is unattached, and a tool would not complain (as the MOF allows underflow). However, when validating a final model unattached lifelines should be illegal. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 3:46 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 23 -- pelase review Attached, please find the draft of ballot 23. This ballot has 26 issues on it. If these go through, we will have 70 issues outstanding for the last ballot (ballot 24). This may seem like a lot, but about 20 or so of those are editorial issues having to do with homogenizing the styles within the document. So, we have a very good chance of having to defer no more than a couple of dozen issues -- assuming, of course, that people take the effort next week to submit their resolutions. At this point, we have dealt with 790 issues -- which I think is pretty impressive and a credit to the FTF (particularly those who worked on the resolutions). Congratulations. Regards, Bran :wq vi issue7039