Issue 8084: Section: 7.3.6 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that from Infrastructure would be helpful. Resolution: see above Revised Text: OMG Issue No: 8084 U.S. Geological Survey (Ms. Jane Messenger, jmessenger@usgs.gov) There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that This is a duplicate of issue 6515, which was resolved in the FTF (Ballot 19). However, it seems that the fix for this issue was applied to the superstructure but was accidentally omitted in the infrastructure. Therefore, the fixes should be applied to the Infrastructure. The following changes need to be applied to the Infrastucture spec: 1. Add “protected” and “package” as the third and fourth literal values, respectively, in Figure 63 on page 99. 2. Add “protected” and “package” as the third and fourth literal values, respectively, in the Description subsection of VisiblityKind, section 9.20.2, page 100. 3. Add a third and fourth bullet point to the Semantics subsection of VisibilityKind, section 9.20.2, page 100. • A protected element is visible to elements that have a generalization relationship to the namespace that owns it. • A package element is owned by a namespace that is not a package, and is visible to elements that are in the same package as its owning namespace. Only named elements that are not owned by packages can be marked as having package visibility. Any element marked as having package visibility is visible to all elements within the nearest enclosing package (given that other owning elements have proper visibility). Outside the nearest enclosing package, an element marked as having package visibility is not visible. 4. Add “protected” and “package” as the third and fourth literals, respectively, of the VisiblityKind enumeration in Figure 88, section 11.6.2, page 142. 5. Add a Notation subsection to VisibilityKind at the bottom of page 100 as follows: Notation The following visual presentation options are available for representing VisibilityKind enumeration literal values: “+” public “-“ private “#” protected “~” package Actions taken: January 12, 2005: received issue August 23, 2006: closed issue Discussion: This is a duplicate of issue 6515, which was resolved in the FTF (Ballot 19). However, it seems that the fix for this issue was applied to the superstructure but was accidentally omitted in the infrastructure. Therefore, the fixes should be applied to the Infrastructure. End of Annotations:===== m: webmaster@omg.org Date: 12 Jan 2005 10:58:03 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 7.3.6 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: 08/01/2003 Page: 39 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that from Infrastructure would be helpful. To: Branislav Selic Cc: uml2-rtf@omg.org Subject: Re: Resolution proposals for Infrastructure/Classes area X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Thu, 25 Aug 2005 16:10:01 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/25/2005 16:10:03, Serialize complete at 08/25/2005 16:10:03 Bran, I have a couple of comments. Issue 8084 Literals 'protected' and 'package' were added to VisibilityKind in Infrastructure as part of the resolution for FTF issue 6515 (ballot 19)... weren't they? Issue 8226 The convention in the specification document (and Rose model) seems to be to use "unique" to indicate uniqueness rather than "nonunique" to indicate non-uniqueness. Given that the default for the MultiplicityElement::isUnique property is true, the absence of a uniqueness designator would seem to indicate that a property is unique, in which case all properties in UML would be unique (since none are designated non-unique). Is this the case? This begs the question why designators need be included in the specification (and Rose model) at all... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 Branislav Selic/Ottawa/IBM@IBMCA 08/24/2005 05:46 PM To uml2-rtf@omg.org cc Subject Resolution proposals for Infrastructure/Classes area Attached are proposals for 7 issue resolutions in the Infrastructure/Classes area. I would like to include them in the draft for ballot 9. Please review them if you care about this area. Cheers, Bran [attachment "BVS-candidates.050823.doc" deleted by Kenneth Hussey/Ottawa/IBM]