Issue 8292: Section: 13.1 (uml2-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with "As shown in Figure 308..."). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that "The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous. Resolution: see pages 240/241 of ptc/2006-04-01 Revised Text: Actions taken: February 16, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 16 Feb 2005 17:12:37 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 13.1 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 455-457 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with "As shown in Figure 308..."). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that "The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous. Issue 8292: Section: 13.1 Issue summary Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with 'As shown in Figure 308...'). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that 'The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous. Discussion Apparently, an incorrect figure has crept in for Fig.308, as the issue points out. Regarding the comment on .*., this means the same as .0..*.. -- ThomasWeigert - 19 May 2005 Reverse the resolution by substituting "0..*" everywhere where "*" appears. Use a different figure than the one in the revised text as per Fig.308.doc -- BranSelic - 20 May 2005 Do we need to adjust the text below the figure to match the terminology of the diagram? I'll review this tonight... -- ThomasWeigert - 23 May 2005 Revised Test In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous, respectively. In the paragraph immediately following Figure 309, change .The execution of a send action results in a send request, which results in a call event occurrence when it is recognized by the target object.. to "The execution of a send action results in a send request, which results in a signal event occurrence when it is recognized by the target object.. Change the use of .invocation event occurrence.. to .invocation occurrence.. Change Figure 308 for the figure below. http://www.modeldrivenengineering.org/pub/Umlrtf/RtfIssue1000000053/Fig.308.doc Resolution Resolved