Issue 6003: document appears to be inconsistent in how it handles concepts (uml2-rtf) Source: Honeywell (Mr. Steve Hickman, steve.hickman(at)honeywell.com) Nature: Clarification Severity: Critical Summary: This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept. In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell. I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group. Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other. Resolution: Revised Text: Actions taken: July 19, 2003: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: This issue relates to the old version of Infrastructure. In this case, there is clearly a misunderstanding on part of the submitter about the architecture of the Infrastructure and the semantics of package merge. Once these are understood, the issue disappears. However, it is definitely the case that the introductory text describing the architecture and the role of package merge are extremely unclear and need to be fixed. These will be dealt with as part of the resolution to issue 6002. Disposition: Closed, no change End of Annotations:===== From: webmaster@omg.org Date: 19 Jul 2003 10:10:38 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Steve Hickman Company: self mailFrom: shickman@ieee.org Notification: Yes Specification: UML 2.0 Infrastructure Section: various FormalNumber: ad/03-03-01 Version: Third Revision RevisionDate: 03-01-03 Page: 1-180 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461; Guidant IE5 09302001 Win2000 Distribution; .NET CLR 1.0.3705) Description This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept. In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell. I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group. Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other.