Issue 8459: UML 2 Super / Conformance / inconsistencies (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Summary: There are two fundamental inconsistencies in the way that conformance is defined: · BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2. · Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level. Recommendation: For the first item, move CommonBehaviors::Communications from L2 to L1 For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4 Resolution: see pages 335 - 336 of ptc/2006-04-01 Revised Text: Actions taken: March 4, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== ssue X4: UML 2 Super / Conformance / inconsistencies Source: Jim Amsden, IBM Software Summary: There are two fundamental inconsistencies in the way that conformance is defined: · BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2. · Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level. Recommendation: For the first item, move CommonBehaviors::Communications from L2 to L1 For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4 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