Issue 8457: UML 2 Super / General / improper subsetting (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge. Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier {subsets classifier} Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization {subsets clientDependency} Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency} Recommendation: These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible. Resolution: see pages 330 - 333 of ptc/2006-04-01 Revised Text: Actions taken: March 4, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== ssue X2: UML 2 Super / General / improper subsetting Source: Jim Amsden, IBM Software Summary: The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge. Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier {subsets classifier} Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization {subsets clientDependency} Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency} Recommendation: These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible Subject: RE: Draft ballot 10 Date: Tue, 13 Sep 2005 05:55:08 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft ballot 10 Thread-Index: AcW2aOQD6ZfxzYXAQZu1pJpSW7CuewAbw2MQ From: "Pete Rivett" To: "Branislav Selic" , Issue 8134: If DeployedArtifact does indeed inherit from 2 versions of Element (and this is not achieved via PackageMerge) then why can the diagram not show 2 classes Element (from kernel) and Element (from Dependencies)? Issue 8136: the same applies Issue 8139: the policy is NOT to have constraints on diagrams - we have had other issue resolutions explicitly removing them! Issues 8137, 8140: we should really use the style {subsets X} rather than the English text "This association specializes...". Maybe we want a separate resolution to clean all these up? There are some resolutions in this ballot that use (subsets X) and others that use {subsets X} Issue 8433 needs tidying - I think this was already spotted Issue 8457: should move the first section under Revised text to Discussion (since these are just general directions not detailed changes to the document), so that Revised text now starts with 'Superstructure'. Issue 8459: I disagree with the paragraph at the end of the resolution which states the following which I think is not at all justified by the spec which has keywords and stereotypes as quite separate things (albeit regrettably using the same notation).Since none of these standard stereotypes provides any new properties or associations, they can be regarded as keywords and therefore do not require profile capabilities in order to be applied to L1 models." Moreover this explanation appears under 'revised text' and it's not clear what Text it's revising - it seems to be making a (invalid IMHO) justification for 'no change' which should be under Discussion. If we really do want to allow stereotypes to be considered keywords at L1 then there should be some very clear text added to the spec. Issue 8460: I think we're hasty removing the constraint. The reason I can see for not allowing non-derived properties to redefine derived ones is that a non-derived property requires a slot. An implementation could work on the basis that a redefinition always reuses and never needs to obtain a new slot. Issue 8462: I object to removing the constraint on subsetting. To me it's as simple as this - in order for a property C.P1 to subset a property P2 then P2 must be accessible/in the namespace of C: either directly owned by C or inherited. (C here is the Classifier that owns P1). Issue 8468: The last changes to constraints [2] and [3] would have been better to provide the OCL than adding 'OCL not available' On a more general note I think we should have a policy for when/whether to reference the finalized spec ptc/04-10-02 or the newly available formal spec. Pete -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, September 10, 2005 8:34 PM To: uml2-rtf@omg.org Subject: Draft ballot 10 Just 31 proposed resolutions. Apologies for the messay state of the draft ballot, but I did not have time to clean it up fully. Thought it better to have it out on time. Also, I have not yet had a chance to actually review the proposed resolutions. Please review them carefully and comment on anything that you feel is controversial or needs fixing -- the official ballot will be sent out on Friday. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912