Issue 8349: Section: 14.3.25 (uml2-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept Resolution: see above Revised Text: all page numbers are from ptc/04-10-02 Page 455 figure 307 Change class name to OccurrenceSpecification Page 456 figure 308 Change class name to OccurrenceSpecification Editor’s note: The previous two changes were not made since the diagrams in question are informal diagrams that are not intended to correspond to actual metaclasses. In fact, keeping the name distinct is useful so that the informal diagrams are not confused with the actual metamodel diagrams. On the other hand, there were several additional references to EventOccurrence that were not part of this resolution that were added to the changes stemming from this resolution. Some of those were identified in the resolution to issue 8824, but were fixed under this issue number Page 476 Examples See example in Figure 320 where the TimeConstraint is associated with the duration of a Message and the duration between two OccurrenceSpecification. Editor’s note: the above change superseded by resolution 8894 UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8349 Document ptc/06-01-01 Page 268 Page 489 Notation A TimeConstraint is shown as graphical association between a TimeInterval and the construct that it constrains. Typically this graphical association is a small line, e.g., between an OccurrenceSpecification and a TimeInterval. Editor’s note: the above change superseded by resolution 8894 Page 497 In this chapter we use the term trace to mean “sequence of event occurrences” which corresponds well with common use in the area of trace-semantics which is a preferred way to describe the semantics of Interactions. We may denote this by <eventoccurrence1, eventoccurrence2, ...,eventoccurrence-n>. We are aware that other parts of the UML language definition the term “trace” is used also for other purposes. Note – I think we can leave these instances as is. • Page 509 Parallel The interactionOperator par designates that the CombinedFragment represents a parallel merge between the behaviors of the operands. The OccurrenceSpecification of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved. A parallel merge defines a set of traces that describes all the ways that OccurrenceSpecification of the operands may be interleaved without obstructing the order of the OccurrenceSpecifications within the operand. … Weak sequencing is defined by the set of traces with these properties: 1. The ordering of OccurrrenceSpecifications within each of the operands are maintained in the result 3. OccurrenceSpecifications on the same lifeline from different operands are ordered such that an OccurrenceSpecification of the first operand comes before that of the second operand. • Page 510 The interactionOperator strict designates that the CombinedFragment represents a strict sequencing between the behaviors of the operands. The semantics of strict sequencing defines a strict ordering of the operands on the first level within the CombinedFragment UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8349 Document ptc/06-01-01 Page 269 with interactionOperator strict. Therefore OccurrrenceSpecifications within contained CombinedFragment will not directly be compared with other OccurrrenceSpecifications of the enclosing CombinedFragment. • Page 528 The example in Figure 340 shows three messages communicated between two (anonymous) lifelines of types User and ACSystem. The message CardOut overtakes the message OK in the way that the receiving event occurrences are in the opposite order of the sending OccurrenceSpecification. • Page 531 In Sequence Diagrams these InteractionFragments are ordered according to their geometrical position vertically. The geometrical position of the InteractionFragment is given by the topmost vertical coordinate of its contained OccurrenceSpecifications or symbols. [1] The guard must be placed directly prior to (above) the OccurrenceSpecification that will become the first OccurrenceSpecification within this InteractionOperand • Page 531, table 14 Change diagram name in the Frame row to OccurrenceSpecification Editor’s note: should be page 552. However, since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. • Page 557 Change two diagram call-outs to OccurrenceSpecification Change 3 class names to OccurrenceSpecification • Page 561 table 16 Change diagram name in the Frame row to OccurrenceSpecification Editor’s note: Since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. • Page 564 table 18 Change diagram name in the Frame row to OccurrenceSpecification Editor’s note: Since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 8349 Document ptc/06-01-01 Page 270 • Page 566 table 19 Change diagram name in the Frame row to OccurrenceSpecification • Page 776 Editor’s note: Since this is merely a name of the sequence diagram frame, changing this to match the metaclass name is actually likely to confuse readers. Hence, this change was not included. Delete EventOccurrence from index Disposition: Resolved Actions taken: February 24, 2005: received issue August 23, 2006: closed issue Discussion: EventOccurrence does not appear in the MDL file. Change all instances of EventOccurrence to OccurrenceSpecification. This appears to be related to Issues #6980 and 6682. End of Annotations:===== m: webmaster@omg.org Date: 24 Feb 2005 15:15:54 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 14.3.25 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 544 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept. Subject: Issue 8349 Date: Fri, 22 Apr 2005 10:29:59 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 8349 Thread-Index: AcVHYOipEJFY4xy+QGCQbhJuNoadiw== From: "Baker, James D \(US SSA\)" To: X-OriginalArrivalTime: 22 Apr 2005 17:30:01.0000 (UTC) FILETIME=[E9827280:01C54760] Issue 8349: Section: 14.3.25 Click here for this issue's archive. Nature: Revision Severity: Significant Summary: The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept Resolution: EventOccurrence does not appear in the MDL file. Change all instances of EventOccurrence to OccurrenceSpecification. This appears to be related to Issues #6980 and 6682. Revised Text: all page numbers are from ptc/04-10-02 Page 455 figure 307 Change class name to OccurrenceSpecification Page 456 figure 308 Change class name to OccurrenceSpecification Page 476 Examples See example in Figure 320 where the TimeConstraint is associated with the duration of a Message and the duration between two OccurrenceSpecification. Page 489 Notation A TimeConstraint is shown as graphical association between a TimeInterval and the construct that it constrains. Typically this graphical association is a small line, e.g., between an OccurrenceSpecification and a TimeInterval. Page 497 In this chapter we use the term trace to mean .sequence of event occurrences. which corresponds well with common use in the area of trace-semantics which is a preferred way to describe the semantics of Interactions. We may denote this by . We are aware that other parts of the UML language definition the term .trace. is used also for other purposes. Note . I think we can leave these instances as is. Page 509 Parallel The interactionOperator par designates that the CombinedFragment represents a parallel merge between the behaviors of the operands. The OccurrenceSpecification of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved. A parallel merge defines a set of traces that describes all the ways that OccurrenceSpecification of the operands may be interleaved without obstructing the order of the OccurrenceSpecifications within the operand. k sequencing is defined by the set of traces with these properties: 1. The ordering of OccurrrenceSpecifications within each of the operands are maintained in the result 3. OccurrenceSpecifications on the same lifeline from different operands are ordered such that an OccurrenceSpecification of the first operand comes before that of the second operand. Page 510 The interactionOperator strict designates that the CombinedFragment represents a strict sequencing between the behaviors of the operands. The semantics of strict sequencing defines a strict ordering of the operands on the first level within the CombinedFragment with interactionOperator strict. Therefore OccurrrenceSpecifications within contained CombinedFragment will not directly be compared with other OccurrrenceSpecifications of the enclosing CombinedFragment. Page 528 The example in Figure 340 shows three messages communicated between two (anonymous) lifelines of types User and ACSystem. The message CardOut overtakes the message OK in the way that the receiving event occurrences are in the opposite order of the sending OccurrenceSpecification. Page 531 In Sequence Diagrams these InteractionFragments are ordered according to their geometrical position vertically. The geometrical position of the InteractionFragment is given by the topmost vertical coordinate of its contained OccurrenceSpecifications or symbols. [1] The guard must be placed directly prior to (above) the OccurrenceSpecification that will become the first OccurrenceSpecification within this InteractionOperand Page 531, table 14 Change diagram name in the Frame row to OccurrenceSpecification Page 557 Change two diagram call-outs to OccurrenceSpecification Change 3 class names to OccurrenceSpecification Page 561 table 16 Change diagram name in the Frame row to OccurrenceSpecification Page 564 table 18 Change diagram name in the Frame row to OccurrenceSpecification Page 566 table 19 Change diagram name in the Frame row to OccurrenceSpecification Page 776 Delete EventOccurrence from index Actions taken: February 24, 2005: received issue J.D. Baker Systems Engineering Initiatives 858 592-5197 Pager 888 374-8754