Issue 13844: Figure 18.2 (which describes the contents of the Profiles package) is currently misleading (uml2-rtf) Source: Atego (Mr. Phillip Astle, phil.astle(at)atego.com) Nature: Revision Severity: Minor Summary: Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them. Resolution: Revised Text: Actions taken: March 30, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 30 Mar 2009 10:43:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML), Superstructure Section: 18.2 FormalNumber: formal/2007-11-02 Version: 2.1.2 RevisionDate: 11/02/2007 Page: 654 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them. Subject: RE: issue 13844 -- UML 2 RTF issue Date: Thu, 2 Apr 2009 15:33:35 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13844 -- UML 2 RTF issue Thread-Index: Acmzx+wGRU1OSGqURRaEpCdCwZd0iQAAYW/g From: "Ed Seidewitz" To: "Juergen Boldt" , , In the class descriptions for Class and Package (Subclauses 18.3.1 and 18.3.5), under Generalization, these classes are listed as .merge increments.. This means they are not really specializations of the listed general classes, but are intended to be merged with them at some point using package merge. Admittedly, this convention is rather confusing, but it is used throughout the spec to provide some indication of how various merge increments for a class are intended to fit together. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, April 02, 2009 3:16 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 13844 -- UML 2 RTF issue From: webmaster@omg.org Date: 30 Mar 2009 10:43:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML), Superstructure Section: 18.2 FormalNumber: formal/2007-11-02 Version: 2.1.2 RevisionDate: 11/02/2007 Page: 654 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: issue 13844 -- UML 2 RTF issue Date: Thu, 2 Apr 2009 15:37:39 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13844 -- UML 2 RTF issue Thread-Index: Acmzx+wGRU1OSGqURRaEpCdCwZd0iQAAYW/gAAAmh+A= From: "Ed Seidewitz" To: Note also that Kernel classes in the superstructure all ultimately merge in the corresponding infrastructure classes. When the Profiles package is merged into the superstructure L2 level, all the seemingly infrastructure classes in the Profiles package get merged with the superstructure Kernel classes, so, at L2 and L3, any distinction is lost. It is only in the unmerged Profile package that various classes are restricted to their infrastructure versions. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Thursday, April 02, 2009 3:34 PM To: 'Juergen Boldt'; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 13844 -- UML 2 RTF issue In the class descriptions for Class and Package (Subclauses 18.3.1 and 18.3.5), under Generalization, these classes are listed as .merge increments.. This means they are not really specializations of the listed general classes, but are intended to be merged with them at some point using package merge. Admittedly, this convention is rather confusing, but it is used throughout the spec to provide some indication of how various merge increments for a class are intended to fit together. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, April 02, 2009 3:16 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 13844 -- UML 2 RTF issue From: webmaster@omg.org Date: 30 Mar 2009 10:43:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML), Superstructure Section: 18.2 FormalNumber: formal/2007-11-02 Version: 2.1.2 RevisionDate: 11/02/2007 Page: 654 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org To: uml2-rtf@omg.org Subject: RE: issue 13844 -- UML 2 RTF issue X-KeepSent: 10B5ABB5:1C0FFF3F-8525758C:0070BB78; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Thu, 2 Apr 2009 16:38:21 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 04/02/2009 14:38:23, Serialize complete at 04/02/2009 14:38:23 Ed, There was a lot of discussion about this back when we were designing package merge. The UML2 model was full of specializations from classes in different packages that had the same name. Package merge use to result in all those classes being created with the specializations when the models were merged. This resulted in L3 having quite a large number of metaclasses named Class! It was a hopeless mess that couldn't have been implemented in a tool. So we fixed package merge to do the merge instead of relying on inheritance. As a result, the relationship between Class in Constructs and Kernel::Classes is by name, not generalization/specialization. Adding the specialization would result in a class specializing itself once the merge is done. I remember hunting down a lot of these and fixing them in the early days of implementing UML2. From: "Ed Seidewitz" To: "Juergen Boldt" , , Date: 04/02/2009 03:36 PM Subject: RE: issue 13844 -- UML 2 RTF issue -------------------------------------------------------------------------------- In the class descriptions for Class and Package (Subclauses 18.3.1 and 18.3.5), under Generalization, these classes are listed as â..merge incrementsâ.. This means they are not really specializations of the listed general classes, but are intended to be merged with them at some point using package merge. Admittedly, this convention is rather confusing, but it is used throughout the spec to provide some indication of how various merge increments for a class are intended to fit together. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, April 02, 2009 3:16 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 13844 -- UML 2 RTF issue From: webmaster@omg.org Date: 30 Mar 2009 10:43:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML), Superstructure Section: 18.2 FormalNumber: formal/2007-11-02 Version: 2.1.2 RevisionDate: 11/02/2007 Page: 654 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: issue 13844 -- UML 2 RTF issue Date: Thu, 2 Apr 2009 18:54:26 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13844 -- UML 2 RTF issue Thread-Index: Acmz00Ti944u4tmrRZWTZvOscs1UAQAEZM+A From: "Ed Seidewitz" To: "Jim Amsden" , Jim . I didn.t mean to say that I found the use of package merge confusing in this case. What I meant was confusing was the class documentation for, e.g., Profiles::Class that actually includes an entry under the .Generalizations. heading: .InfrastructureLibrary::Constructs::Class (merge increment).. It is confusing to list this under .Generalizations. because Profiles::Class does not, as you say, actually have a generalization relationship with InfrastructureLibrary::Constructs::Class. Plus there is nothing in the model that enforces that the Profiles::Class merge increment ultimately be merged with InfrastructureLibrary::Constructs::Class (indeed, in the superstructure it is ultimately merged with other superstructure merge increments for Class . but one of these is, indirectly, InfrastructureLibrary::Constructus::Class, which is merged into Kernel). But, as I mentioned, this kind of convention is used to indicate merge increments elsewhere in the spec (e.g., Communications::Class). So it is not a particular issue for the Profiles clause. (Except that it just may be a bit more confusing there because of the references to the infrastructure.) -- Ed -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Thursday, April 02, 2009 4:38 PM To: uml2-rtf@omg.org Subject: RE: issue 13844 -- UML 2 RTF issue Ed, There was a lot of discussion about this back when we were designing package merge. The UML2 model was full of specializations from classes in different packages that had the same name. Package merge use to result in all those classes being created with the specializations when the models were merged. This resulted in L3 having quite a large number of metaclasses named Class! It was a hopeless mess that couldn't have been implemented in a tool. So we fixed package merge to do the merge instead of relying on inheritance. As a result, the relationship between Class in Constructs and Kernel::Classes is by name, not generalization/specialization. Adding the specialization would result in a class specializing itself once the merge is done. I remember hunting down a lot of these and fixing them in the early days of implementing UML2. From: "Ed Seidewitz" To: "Juergen Boldt" , , Date: 04/02/2009 03:36 PM Subject: RE: issue 13844 -- UML 2 RTF issue -------------------------------------------------------------------------------- In the class descriptions for Class and Package (Subclauses 18.3.1 and 18.3.5), under Generalization, these classes are listed as .merge increments.. This means they are not really specializations of the listed general classes, but are intended to be merged with them at some point using package merge. Admittedly, this convention is rather confusing, but it is used throughout the spec to provide some indication of how various merge increments for a class are intended to fit together. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, April 02, 2009 3:16 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 13844 -- UML 2 RTF issue From: webmaster@omg.org Date: 30 Mar 2009 10:43:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML), Superstructure Section: 18.2 FormalNumber: formal/2007-11-02 Version: 2.1.2 RevisionDate: 11/02/2007 Page: 654 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org