Issue 6049: PackageableElement (uml2-superstructure-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: there was declared and inheritance relationship between NamedElement and PackageableElement defining in both cases an attribute "visibility". I suggest to suppress the declaration in PackageableElement because it is inherited from NamedElement Resolution: Revised Text: Actions taken: July 31, 2003: received issue March 9, 2005: closed issue Discussion: No revision, the reviewer did not read the spec carefully. This issue overlooks the difference in multiplicity between visibility for NamedElement and visibility for Packageable Element. For NamedElement it is optional that there is a VisibilityKind, and for PackageableElement it is mandatory. Therefore the inheritance is not redundant, the inherited attribute is redefined by a change in multiplicity. Examining this reported issue turned up a defect in 7.3.1 ElementImport. The defect is as follows: Under Attributes, section 7.3.1 lists Visibility, but fails to specify any multiplicity. The absence of the multiplicity is one defect. A second defect comes in with the following confused note: “If the imported element does not have a visibility it is possible to add a visisbility to the element import.” This is confused in two respects: 1. A value for visibility is mandatory for PackageableElement, and only PackageableElements can be imported, therefor the imported element will always have a visibility. Second, visibility should be mandatory for an ElementImport, and so, if the imported element were not to have one, it would be necessary, not merely “possible”, to add one. Disposition: Closed, no change End of Annotations:===== X-Sender: linda@amethyst.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jul 2003 08:07:22 -0400 To: juergen Boldt From: "Ilver Anache Pupo" (by way of Linda Heaton ) Subject: OMG Document ptc/03-07-06 Issue? Thanks, Linda Hi, as Director for R+D Department from TESS Peru i'am reviewing OMG UML 2.0 Document -- ptc/03-07-06 (UML 2.0 Superstructure Draft Adopted Specification, and i found a conceptual problem in 1.3 Kernel - the namespaces Diagram in page 8: there was declared and inheritance relationship between NamedElement and PackageableElement defining in both cases an attribute "visibility". I suggest to suppress the declaration in PackageableElement because it is inherited from NamedElement. Ilver Anache Pupo Director of R+D Department Tecnologias Especializadas en Software y Sistemas (TESS SAC) Subject: an issue for next ballot Date: Tue, 6 Apr 2004 11:52:05 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Official Ballot 11 -- Please vote Thread-Index: AcQbeRLTj7oAwtHkRqihKAlsiSaMmgAdX2wt From: "Karl Frank" To: "Branislav Selic" Cc: X-OriginalArrivalTime: 06 Apr 2004 15:52:07.0358 (UTC) FILETIME=[1D290DE0:01C41BEF] Issue 6049: PackageableElement (uml2-superstructure-ftf) Summary: there was declared an inheritance relationship between NamedElement and PackageableElement defining in both cases an attribute "visibility". I suggest to suppress the declaration in PackageableElement because it is inherited from NamedElement Resolution: No revision, the reviewer did not read the spec carefully. This issue overlooks the difference in multiplicity between visibility for NamedElement and visibility for Packageable Element. For NamedElement it is optional that there is a VisibilityKind, and for PackageableElement it is mandatory. Therefore the inheritance is not redundant, the inherited attribute is redefined by a change in multiplicity. Examining this reported issue turned up a defect in 7.3.1 ElementImport. The defect is as follows: Under Attributes, section 7.3.1 lists Visibility, but fails to specify any multiplicity. The absence of the multiplicity is one defect. A second defect comes in with the following confused note: ā..If the imported element does not have a visibility it is possible to add a visisbility to the element import.ā.¯ This is confused in two respects: 1. A value for visibility is mandatory for PackageableElement, and only PackageableElements can be imported, therefor the imported element will always have a visibility. Second, visibility should be mandatory for an ElementImport, and so, if the imported element were not to have one, it would be necessary, not merely ā..possibleā.¯, to add one. Revised Text: No revision to the text. Actions taken: An issue was reported against 7.3.1 ElementImport July 31, 2003: received issue Issue 6049: PackageableElement (uml2-superstructure-ftf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: there was declared an inheritance relationship between NamedElement and PackageableElement defining in both cases an attribute "visibility". I suggest to suppress the declaration in PackageableElement because it is inherited from NamedElement Resolution: No revision, the reviewer did not read the spec carefully. This issue overlooks the difference in multiplicity between visibility for NamedElement and visibility for Packageable Element. For NamedElement it is optional that there is a VisibilityKind, and for PackageableElement it is mandatory. Therefore the inheritance is not redundant, the inherited attribute is redefined by a change in multiplicity. Examining this reported issue turned up a defect in 7.3.1 ElementImport. The defect is as follows: Under Attributes, section 7.3.1 lists Visibility, but fails to specify any multiplicity. The absence of the multiplicity is one defect. A second defect comes in with the following confused note: .If the imported element does not have a visibility it is possible to add a visisbility to the element import.. This is confused in two respects: 1. A value for visibility is mandatory for PackageableElement, and only PackageableElements can be imported, therefor the imported element will always have a visibility. Second, visibility should be mandatory for an ElementImport, and so, if the imported element were not to have one, it would be necessary, not merely .possible., to add one. Revised Text: No revision to the text. Actions taken: An issue was reported against 7.3.1 ElementImport July 31, 2003: received issue URL: www.tessperu.com