Issue 8023: Association specialization semantics (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Clarification Severity: Minor Summary: Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean? Resolution: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change Revised Text: Actions taken: December 30, 2004: received issue February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== m: webmaster@omg.org Date: 30 Dec 2004 15:16:58 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: UML 2 Super Section: Classes FormalNumber: ptc/04-10-02 Version: 2.0 RevisionDate: 04-10-02 Page: - Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean? Reply-To: From: "Conrad Bock" To: Subject: RE: Draft ballot 7 -- please review Date: Tue, 2 Aug 2005 15:36:09 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 7. Conrad - Issue 8021: Section: Classes The discussion says "There are no constraints or any other connection between properties B::aend and SubB::subA", but there must be. For example, if there is an instance of SubB, and you navigate from it along the inherited B::aend, the result should be the instances of A related by that association, including the ones created on instances of SubA with SubB::subA. How can it have this semantics if B::aend and SubB::subA aren't related? Needs more discussion, especially in relation to the text references in Association Semantics, see 8023 below. - Issue 8023: Association specialization semantics This didn't address the issues that some of the text applies to Generalization. The cited text, including the proposed revision, is especially confusing because the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, as the cited text explains, but that is a minor point. Subsetting/specialization in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. In particular, for association classes, the user should be able to specialize an association class with another association class with the same semantics as to subsetting ends. Should discuss more. - Issue 8028: create dependency Figures 103 and 121 This way of modeling a constructor should be in Classes, which Thomas agrees with. His question on the wiki was about whether compliance levels permitted it, but I can't see why they wouldn't. Seems like it can be moved to Classes with no adverse effect. - Issue 8038: IsReadOnly constriant This is overconstrained, because the default value could be set dynamically before initialization, rather than a default value. As long as this happens before initialization is over, there is no violation of multiplicity. In any case, UML doesn't enforce when constraints are evaluated or inconsistencies repaired. Tim's response on the wiki only came on the 29th, so I hadn't replied, but it was only about the wording I used on the wiki, which I corrected to the above. Never mind that I filed the issue! - Issue 8078: Actor is a specialized Classifier and not BehavioredClassifier There isn't anything I can find on BehavioredClassifier that says it supports interfaces. - Issue 8677: token movement In the revised text, update the new sentence to "For brevity, the specification uses the terms "flow", "pass", "traverse" interchangeably in relation to tokens to mean offering tokens, and movement of tokens when offers are accepted. - Issue 8751: Relations I agree with the filer here. We should discuss more. - Issue 8758: Association in UseCase diagram Can't say there hasn't been enough discussion, but use cases have had associations between them for so long, that it doesn't seem Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 05 Aug 2005 10:15:25 -0700 To: UML-RTF From: Joaquin Miller Subject: Re: Draft ballot 7 -- please review Oops. I'm sure i mailed this, but it looks like maybe i did not. 6524: Does this deal with the complaint about the generated JMI interface? The resolution would be more satisfying (if so) if it explained how or (if not) said why not. 8021: "an unnamed property ::SubB (or SubB::subA by default)" seems fishy: Should the '::' jump around 'SubB' like that? 8023: How about: Specialization is, in contrast to Subsetting, a relationship in the domain of intentional semantics, which is to say it characterizes the criteria whereby membership in the collection of instances is defined, not by specifying the actual collection of instances. One classifier may specialize another by adding or redefining features; while a set cannot specialize another set, it can only be a subset or superset of another set. A naïve but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of its instances narrows. This is because instances of the more general classifier include instances of all its different specializations. In the case of associations, subsetting ends, according to this view, corresponds to specializing the association since the collection of instances of a specialization would be a subset of the collection of instances of its generalization. This view falls down because it ignores the case of classifiers which, for whatever reason (e.g. abstract classes), have no instances. Adding new criteria for membership does not narrow the set of instances if the classifier already has no instances. [I don't even like that. [-- I don't feel it helps. [-- It seems to say that UML 2 subsetting is a relationship in the domain of extensional semantics. But it is not. If we like the phrase, 'a relationship in the domain of intentional semantics,' then certainly UML 2 subsetting is a relationship in the domain of intentional semantics. [-- The example of abstract classes also seems to me to be incorrect: Abstract classes have instances. In particular, an abstract class which is specialized by concrete classes has, as instances, as many instances as those classes have.] To: Joaquin Miller Cc: UML-RTF Subject: Re: Draft ballot 7 -- please review X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 5 Aug 2005 16:59:06 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/05/2005 16:59:10, Serialize complete at 08/05/2005 16:59:10 Hello Joaquin, > Oops. I'm sure i mailed this, but it looks like maybe i did not. If you did, I have not received it. However, better late than never. > 6524: Does this deal with the complaint about the generated JMI > interface? The resolution would be more satisfying (if so) if it > explained how or (if not) said why not. I have added an explanation to the resolution. The problem is that the concept of feature redefinition -- which is not supported by most popular OO languages -- is (a) an architectural feature of UML 2 and (b) used extensively in the definition of the UML metamodel. Removing this would require major surgery to the metamodel and a change to the definition of the UML language. It is far beyond the scope of an RTF. One choice might be to defer the issue, but the issue text is not cirectly challenging the concept of redefinition but is focusing on just one particular usage of it. Therefore, I think that it is appropriate to close this issue as "no change". If someone wants to challenge the redefinition capability of UML, then an explicit issue should be formulated to that end. > 8021: "an unnamed property ::SubB (or SubB::subA by default)" seems > fishy: Should the '::' jump around 'SubB' like that? This is merely the OCL convention for giving names to un-named association ends. Jim was just using it to explain things. > 8023: How about: > Specialization is, in contrast to Subsetting, a relationship in the > domain of intentional semantics, which is to say it characterizes > the criteria whereby membership in the collection of instances is > defined, not by specifying the actual collection of instances. One > classifier may specialize another by adding or redefining features; > while a set cannot specialize another set, it can only be a subset > or superset of another set. A naïve but popular and useful view has > it that as the classifier becomes more specialized, the extent of > the collection(s) of its instances narrows. This is because > instances of the more general classifier include instances of all > its different specializations. In the case of associations, > subsetting ends, according to this view, corresponds to specializing > the association since the collection of instances of a > specialization would be a subset of the collection of instances of > its generalization. This view falls down because it ignores the > case of classifiers which, for whatever reason (e.g. abstract > classes), have no instances. Adding new criteria for membership > does not narrow the set of instances if the classifier already has > no instances. Issue 8023 has been withdrawn from the ballot. Please discuss with Jim Amsden about your preferred reformulation. Cheers...Bran From: webmaster@omg.org Date: 20 Oct 2009 08:15:09 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Johnny Willemsen Company: Remedy mailFrom: jwillemsen@remedy.nl Notification: Yes Specification: DDS4CCM Section: 8.3.1 FormalNumber: 09-02-02 Version: batch 4 RevisionDate: Sep 2009 Page: 44 Title: topic_name attribute Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: we propose to change the topic_name attribute to a regular attribute, not readonly From: "Rouquette, Nicolas F (316A)" To: Salman Qadri , Dave Hawkins CC: "uml2-rtf@omg.org" Date: Sun, 6 Sep 2009 16:28:52 -0700 Subject: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcotaPIShvRp0d8+RCiwvYcotvVi7wABUP7QAAkiMMAAAMIeAABey6XwAAScnnAAA9Uv9QAFw4PW Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Date: Mon, 07 Sep 2009 14:41:02 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.6 (X11/20070728) To: "Rouquette, Nicolas F (316A)" CC: Salman Qadri , "uml2-rtf@omg.org" Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4AA50D75.018C:SCFSTAT5015188,ss=1,fgs=0 Rouquette, Nicolas F (316A) wrote: As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. I think all RTF members, not just Conrad and Ed, ought to have sufficient time to review any proposed resolution, particularly given its complexity. The rather compressed nature of this final ballot seems a little inadequate for that purpose. In fact, I'm a little perplexed as to why there are any resolutions in the ballot that don't relate to either Japanese issues, XMI issues or Superstructure/Infrastructure contradictions, ie issue 14235. Cheers, Dave On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman *From:* Salman Qadri *Sent:* Sunday, September 06, 2009 12:54 PM *To:* Rouquette, Nicolas F (316A); Dave Hawkins *Cc:* uml2-rtf@omg.org *Subject:* RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman *From:* Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] *Sent:* Friday, September 04, 2009 3:28 PM *To:* Salman Qadri; Dave Hawkins *Cc:* uml2-rtf@omg.org *Subject:* Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets /NamedElement::namespace, Feature::featuringClassifier /I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman *From:* Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] *Sent:* Friday, September 04, 2009 10:45 AM *To:* Dave Hawkins *Cc:* uml2-rtf@omg.org *Subject:* 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: * specialization . are we consistent in the fact that generalization relationships are not exclusive? * association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Rouquette, Nicolas F (316A)" To: Dave Hawkins CC: Salman Qadri , "uml2-rtf@omg.org" Date: Mon, 7 Sep 2009 09:16:31 -0700 Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcovwN+ZOLAg50bgT5uEpKBK8ox+UQAFa/dx Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Dave, OK . deferring to Ed & Conrad was a bit awkward on my part. As I stated, I.m reluctant to introduce a resolution to 8023 in ballot 10 for the same reasons you mentioned: tight schedule, stay on focus. However, it is also a fact that once we start fixing logical inconsistencies, we are bound to find more. Saying that the scope of ballot 10 includes resolving superstructure/infrastructure contradictions is still a very broad scope. What is the criteria to decide what we fix in ballot 10? I believe that I.ve identified in my proposed resolution to 8023 a principle we can use to explain that we are limiting the scope of the contradictions pertaining to incorrect subsetting in 13991 & 14235 to be limited to Classes::{Kernel,Interfaces} & the corresponding associations in Core::Constructs. There are certainly more contradictions pertaining to incorrect subsetting and/or redefinitions elsewhere but 8023 would then provide a mechanism to detect where such contradictions are as opposed to relying on someone.s doing a detailed reading of the spec & of the xmi to find them as you and Salman have done. But, ballot 10 is so compressed that I.m hesitant to introduce a resolution to 8023. Before I give up on doing so, I wanted to get Ed & Conrad.s opinion on this because I know that they are intimately familiar with the fine print of UML semantics. However, your reaction seems to confirm my earlier suspicion that it would be too much to add a resolution to 8023 in ballot 10. - Nicolas. On 9/7/09 6:41 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > As much as I feel confident about this explanation, I.m reluctant to put > it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad > have enough time to review it and check that it is kosher w.r.t. their > enlightened understanding of UML semantics prior to voting on ballot 10. > It would be clearly counterproductive to introduce any resolution in > ballot 10 on something potentially as contentious as clarifying hidden > secrets of UML semantics. > > - Nicolas. I think all RTF members, not just Conrad and Ed, ought to have sufficient time to review any proposed resolution, particularly given its complexity. The rather compressed nature of this final ballot seems a little inadequate for that purpose. In fact, I'm a little perplexed as to why there are any resolutions in the ballot that don't relate to either Japanese issues, XMI issues or Superstructure/Infrastructure contradictions, ie issue 14235. Cheers, Dave > > On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" > wrote: > > > I was looking into (1) when I received this. > I agree we need a separate issue; please make sure to focus the > issue to the property subsetting of the two associations pertaining > to redefinitions in the superstructure & the infrastructure, i.e.: > > A_redefinedElement_redefinableElement > A_redefinitionContext_redefinableElement > > This issue is addresses a limited scope of other issues already > filed about subsetting/redefinitions. > > These 4 issues are asking for explanations of concepts related to > associations & association end properties: > > http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 > http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 > http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 > http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate > of 13927) > > This issue is focused on an apparent inconsistency in property > subsetting: > > http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 > > This issues is narrowly focused on the case of subsetting for > non-derived union properties: > > http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 > > The present issue about the specialization hierarchy of > redefinition-related associations is outside the scope of 8952 & > 11238; however, the resolution may be helpful for the 4 issues above. > > In fact, the use of .copy-down. in (2) is a practice that has not > been properly explained before; opinions may vary on why it is needed. > > The bottom line is that subsetting/redefining association end > properties implies association specialization as indicated in 7.3.3 > in UML 2.3. > Why? See below. > > Once this is understood, then you can consider the question whether > we are specializing wholly-defined elements or not. > For example, in the case of 14235, we needed to have > Interface::ownedAttribute in Classes::Interfaces subset > Classifier::attribute. > Since the {subets...} & {redefines...} notation uses base names > instead of qualified names, it would be ambiguous in the diagram > notation whether {subsets attribute} would refer to > Classes::Kernel::Classifier::attribute or > Classes::Interfaces::Classifier::attribute. > > It would also be incorrect in this case to add simply > Classes::Interfaces::Classifier::attribute without the defining > association because Classifier::attribute would be a vanilla > property, not an association-end property and the association > specialization semantics wouldn.t kick in... > > In general, the idea behind .copy-down. is to make sure that > anything we subset/redefine from the receiving > > This issue may be useful to resolve 13927; in fact, the use of > .copy-down. in (2) is precisely related to the problem of property > subsetting/redefinition in the context of package merge. > Basically, the idea of .copy down. is to make sure that in the > context of a single package, you have either: > > - the general elements (metaclasses, associations, properties) are > wholly defined in the context of the merged package without matching > definitions in the context of the receiving package > - the specific elements (metaclasses, associations, properties) are > in the context of the receiving package > > or: > > - copy-down the structure of the general elements (metaclasses, > associations, properties) from the context of the merged package to > the context of the receiving package such that the general element > in the context of the receiving package has a matching definition in > the context of the merged package. > > We need to add to 14235 a new constraint for the package merge of > properties. > > Matching properties must have matching classifiers > > (i.e., the .classifier. end of the A_attribute_classifier > association on figure 7.9 which requires that this association be > properly specialized for specializations of Classifier (which as a > large taxonomy as shown in Annex F). > > I.ll make the modification to 14235. > > - Nicolas. > > On 9/6/09 11:57 AM, "Salman Qadri" wrote: > > Actually looking at the spec under 7.3.44, owningAssociation is > expected to subset RedefinedElement::redefinitionContext. This > is, however, missing from the XMI. I also think .class. > and.datatype. should also be updated in the spec as well as the > xmi to also subset redefinitionContext. For these I will create > a separate issue. For 14235, I will add redefinitionContext as a > subset in the resolution for the new property .interface.. > > My question about the copy-down of Classifier still stands. > > Salman > > > *From:* Salman Qadri > *Sent:* Sunday, September 06, 2009 12:54 PM > *To:* Rouquette, Nicolas F (316A); Dave Hawkins > *Cc:* uml2-rtf@omg.org > *Subject:* RE: 14235 -- Re: Ballot 10: status > > Hi Nicolas, > > I updated the resolution with the suggested fixes. However in > doing so I have 2 more flags that I wanted to address with you: > > 1) The original issue proposes that the new .interface. > property should also subset > Classes-Kernel-RedefinableElement-redefinitionContext, which is > not part of the resolution but I think is needed. But I also > noticed that Classes-Kernel-Property-datatype and > Classes-Kernel-Property-class also fail to subset > Classes-Kernel-RedefinableElement-redefinitionContext, which > means that adding it to the resolution would make .interface. > inconsistent with .datatype., .owningAssociation. and .class.. > Should we add this subsettedProperty only to .interface., or > should we propose to add it to all of them, or should we do none > of them and raise this is a separate issue? For now my hunch is > we.ll create a new issue about this. > > 2) I do not see why the resolution does a copy-down of > .Classes-Kernel-A_attribute_classifier. or > .Classes-Kernel-Classifier.. In my opinion a copy-down should > only be done when something within the elements that are being > copied-down needs to change, not when they are simply being > referred to. I would suggest we remove these copy-downs into > .Classes-Interfaces. but I wanted to understand why you felt we > should do it. > > > Thanks, > > Salman > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* Friday, September 04, 2009 3:28 PM > *To:* Salman Qadri; Dave Hawkins > *Cc:* uml2-rtf@omg.org > *Subject:* Re: 14235 -- Re: Ballot 10: status > > Salman, > > I agree with your points. > Feel free to update the resolution in the SVN. > > - Nicolas. > > > On 9/4/09 12:21 PM, "Salman Qadri" > wrote: > Hi Nicolas, > > I had a couple of points on the Resolution for 14235: > > 1) > > In clause 7.3.44 Property, under Associations, add the following > at the bottom of the list: > . interface : Interface[0..1] > References the Interface that owns the Property. > Subsets /NamedElement::namespace, Feature::featuringClassifier > /I think you are should also have the subset > .Property::classifier. (to be consistent with what is done for > .datatype., point 3 under 7.3.44 under Associations). In the > XMI, this translates to > .Classes-Kernel-A_attribute_classifier-classifier. (this is > there currently for Classes-Kernel-Property-datatype as well as > Classes-Kernel-Property-class in the XMI). > > 2) > Most importantly, I think you forgot to mention the fact that we > need to add the ownedAttribute .interface. to > Classes::Interfaces::Property, set its. association to > .Classes-Interfaces-A_interface_ownedAttribute. and set its > subsettedProperty to be > .Classes-Kernel-Feature-featuringClassifier > Classes-Kernel-NamedElement-namespace > Classes-Kernel-A_attribute_classifier-classifier.. Its. id > should be .Classes-Interfaces-Property-interface. and the > .interface. member end of > .Classes-Interfaces-A_interface_ownedAttribute. as you already > mentioned in your resolution should now be > .Classes-Interfaces-Property-interface.. > > Can you update the resolution to this effect, or I can do it if > you want. > > Salman > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* Friday, September 04, 2009 10:45 AM > *To:* Dave Hawkins > *Cc:* uml2-rtf@omg.org > *Subject:* 14235 -- Re: Ballot 10: status > > Salman, > > You are correct about the property subsetting; my statement > about (3) is wrong. > > I agree that the metamodel needs a good scrubbing to carefully > review all of the hierarchies we have: > > * specialization . are we consistent in the fact that > generalization relationships are not exclusive? > * association subsetting/redefinition & association > specialization . 9374 barely scratched the surface on this. > > > - Nicolas. > > On 9/4/09 7:06 AM, "Dave Hawkins" wrote: > Rouquette, Nicolas F (316A) wrote: > > Dave, > > > > On 9/3/09 11:40 AM, "Dave Hawkins" > wrote: > > > > For 14235, while I don't disagree with the inconsistency > that there > > is no navigable Property-interface property, I don't think > it's > > true to say that owner or namespace wouldn't be populated. > The opposite > > end of Interface-ownedAttribute subsets namespace. That's > sufficient. > > > > > > Property::owner & Property::namespace are properly populated > because of > > the associations in Classes::Kernel, not because of the > associations in > > Classes::Interfaces. > > This part of 14235.s point (3) is indeed inaccurate. > > You mean the ownedElement-owner and ownedMember-namespace > associations? > I agree that has to be the case. However that's not how derived > unions are > defined in the specification. In Association (7.3.3) we have: > > "{union} to show that the end is derived by being the union of > its subsets." > > In Property (7.3.44) we have: > > "isDerivedUnion : Boolean > Specifies whether the property is derived as the union of all of the > properties that are constrained to subset it. The default value > is false." > > and > > "A property may be marked as being a derived union. This means > that the > collection of values denoted by the property in some context is > derived > by being the strict union of all of the values denoted, in the same > context, by properties defined to subset it. If the property has a > multiplicity upper bound of 1, then this means that the values > of all > the subsets must be null or the same." > > These seem pretty clear. A derived union is derived from its > subsets, not > its subsets and a derivation from its opposite end. This means > that either > the above definitions need to change or all ends of an > association must > subset a derived union if the one end does. I think this is an > issue. > > > > > > > Of greater concern is that I believe there are a large > number of > > associations where this isn't the case. That is, there is > a mismatch > > between the subsetted properties of the ends. For example: > > > > Transition::effect {subsets ownedElement} > > A_effect_transition::transition > > > > As both owner and ownedElement are derived unions and > those are defined > > to be the strict unions of their subsets I think this > probably does > > mean that owner isn't correctly populated. > > > > > > > > Transition::owner & Transition::namespace will be properly > populated for > > the same reason as above; the definition of > A_effect_transition doesn.t > > affect these properties. > > Obviously I disagree with this statement. I don't think the > specification > of the derivation supports that view. > > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 > Oracle JDeveloper Development > Oracle Corporation UK Ltd is a company incorporated in England & > Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. X-IronPort-AV: E=Sophos;i="4.44,347,1249250400"; d="scan'208,217";a="31340313" From: LONJON Antoine To: "Rouquette, Nicolas F (316A)" , Salman Qadri , Dave Hawkins CC: "uml2-rtf@omg.org" Date: Mon, 7 Sep 2009 18:42:55 +0200 Subject: RE: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcotaPIShvRp0d8+RCiwvYcotvVi7wABUP7QAAkiMMAAAMIeAABey6XwAAScnnAAA9Uv9QAFw4PWACO4ByA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi Nicolas, I like the way you present the differentiation between Generalization/Specialization and Redefinition respectively as extensional extensions and intentional extensions. I am not sure this was the original intent, but it could work. However, it leaves open the question about the way to differentiate extensional definition (.which elements are classified by that classifier.) and intentional definition (.specifying the criteria for an element to be classified by that classifier.) which comes prior to the question of going to any specialization or redefinition. In the next paragraph regarding association, I am not following you when you say that .When redefinition is applied to all of the association ends, . the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. . . Isn.t this an extensional definition rather that an intentional definition? Antoine From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, September 07, 2009 1:29 AM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -------------------------------------------------------------------------------- This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. From: Salman Qadri To: Dave Hawkins , "Rouquette, Nicolas F (316A)" CC: "uml2-rtf@omg.org" Date: Mon, 7 Sep 2009 13:04:14 -0400 Subject: RE: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcovwOCuNZ3SxD8zTQilSlrxu+MDJgAG6S+g Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n87H4lBQ028339 14235 IS trying to simply highlight a contradiction (between Interface-ownedAttribute and Interface-ownedOperation) and propose a solution. All we really need to do for 14235 is say that we should make Interface-ownedAttribute look just like Interface-ownedOperation, and Property-interface look just like Operation-interface, without questioning anything about the way it was already done for Interface-ownedOperation, because that would be out-of-scope. The issue is just trying to say that the relationship between an Interface and its' ownedAttributes ought to be bi-directional, similar to Interface and its' ownedOperations. -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, September 07, 2009 9:41 AM To: Rouquette, Nicolas F (316A) Cc: Salman Qadri; uml2-rtf@omg.org Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Rouquette, Nicolas F (316A) wrote: > As much as I feel confident about this explanation, I'm reluctant to put > it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad > have enough time to review it and check that it is kosher w.r.t. their > enlightened understanding of UML semantics prior to voting on ballot 10. > It would be clearly counterproductive to introduce any resolution in > ballot 10 on something potentially as contentious as clarifying hidden > secrets of UML semantics. > > - Nicolas. I think all RTF members, not just Conrad and Ed, ought to have sufficient time to review any proposed resolution, particularly given its complexity. The rather compressed nature of this final ballot seems a little inadequate for that purpose. In fact, I'm a little perplexed as to why there are any resolutions in the ballot that don't relate to either Japanese issues, XMI issues or Superstructure/Infrastructure contradictions, ie issue 14235. Cheers, Dave > > On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" > wrote: > > > I was looking into (1) when I received this. > I agree we need a separate issue; please make sure to focus the > issue to the property subsetting of the two associations pertaining > to redefinitions in the superstructure & the infrastructure, i.e.: > > A_redefinedElement_redefinableElement > A_redefinitionContext_redefinableElement > > This issue is addresses a limited scope of other issues already > filed about subsetting/redefinitions. > > These 4 issues are asking for explanations of concepts related to > associations & association end properties: > > http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 > http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 > http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 > http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate > of 13927) > > This issue is focused on an apparent inconsistency in property > subsetting: > > http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 > > This issues is narrowly focused on the case of subsetting for > non-derived union properties: > > http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 > > The present issue about the specialization hierarchy of > redefinition-related associations is outside the scope of 8952 & > 11238; however, the resolution may be helpful for the 4 issues above. > > In fact, the use of "copy-down" in (2) is a practice that has not > been properly explained before; opinions may vary on why it is needed. > > The bottom line is that subsetting/redefining association end > properties implies association specialization as indicated in 7.3.3 > in UML 2.3. > Why? See below. > > Once this is understood, then you can consider the question whether > we are specializing wholly-defined elements or not. > For example, in the case of 14235, we needed to have > Interface::ownedAttribute in Classes::Interfaces subset > Classifier::attribute. > Since the {subets...} & {redefines...} notation uses base names > instead of qualified names, it would be ambiguous in the diagram > notation whether {subsets attribute} would refer to > Classes::Kernel::Classifier::attribute or > Classes::Interfaces::Classifier::attribute. > > It would also be incorrect in this case to add simply > Classes::Interfaces::Classifier::attribute without the defining > association because Classifier::attribute would be a vanilla > property, not an association-end property and the association > specialization semantics wouldn't kick in... > > In general, the idea behind "copy-down" is to make sure that > anything we subset/redefine from the receiving > > This issue may be useful to resolve 13927; in fact, the use of > "copy-down" in (2) is precisely related to the problem of property > subsetting/redefinition in the context of package merge. > Basically, the idea of "copy down" is to make sure that in the > context of a single package, you have either: > > - the general elements (metaclasses, associations, properties) are > wholly defined in the context of the merged package without matching > definitions in the context of the receiving package > - the specific elements (metaclasses, associations, properties) are > in the context of the receiving package > > or: > > - copy-down the structure of the general elements (metaclasses, > associations, properties) from the context of the merged package to > the context of the receiving package such that the general element > in the context of the receiving package has a matching definition in > the context of the merged package. > > We need to add to 14235 a new constraint for the package merge of > properties. > > Matching properties must have matching classifiers > > (i.e., the 'classifier' end of the A_attribute_classifier > association on figure 7.9 which requires that this association be > properly specialized for specializations of Classifier (which as a > large taxonomy as shown in Annex F). > > I'll make the modification to 14235. > > - Nicolas. > > On 9/6/09 11:57 AM, "Salman Qadri" wrote: > > Actually looking at the spec under 7.3.44, owningAssociation is > expected to subset RedefinedElement::redefinitionContext. This > is, however, missing from the XMI. I also think 'class' > and'datatype' should also be updated in the spec as well as the > xmi to also subset redefinitionContext. For these I will create > a separate issue. For 14235, I will add redefinitionContext as a > subset in the resolution for the new property 'interface'. > > My question about the copy-down of Classifier still stands. > > Salman > > > *From:* Salman Qadri > *Sent:* Sunday, September 06, 2009 12:54 PM > *To:* Rouquette, Nicolas F (316A); Dave Hawkins > *Cc:* uml2-rtf@omg.org > *Subject:* RE: 14235 -- Re: Ballot 10: status > > Hi Nicolas, > > I updated the resolution with the suggested fixes. However in > doing so I have 2 more flags that I wanted to address with you: > > 1) The original issue proposes that the new 'interface' > property should also subset > Classes-Kernel-RedefinableElement-redefinitionContext, which is > not part of the resolution but I think is needed. But I also > noticed that Classes-Kernel-Property-datatype and > Classes-Kernel-Property-class also fail to subset > Classes-Kernel-RedefinableElement-redefinitionContext, which > means that adding it to the resolution would make 'interface' > inconsistent with 'datatype', 'owningAssociation' and 'class'. > Should we add this subsettedProperty only to 'interface', or > should we propose to add it to all of them, or should we do none > of them and raise this is a separate issue? For now my hunch is > we'll create a new issue about this. > > 2) I do not see why the resolution does a copy-down of > "Classes-Kernel-A_attribute_classifier" or > "Classes-Kernel-Classifier". In my opinion a copy-down should > only be done when something within the elements that are being > copied-down needs to change, not when they are simply being > referred to. I would suggest we remove these copy-downs into > "Classes-Interfaces" but I wanted to understand why you felt we > should do it. > > > Thanks, > > Salman > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* Friday, September 04, 2009 3:28 PM > *To:* Salman Qadri; Dave Hawkins > *Cc:* uml2-rtf@omg.org > *Subject:* Re: 14235 -- Re: Ballot 10: status > > Salman, > > I agree with your points. > Feel free to update the resolution in the SVN. > > - Nicolas. > > > On 9/4/09 12:21 PM, "Salman Qadri" > wrote: > Hi Nicolas, > > I had a couple of points on the Resolution for 14235: > > 1) > > In clause 7.3.44 Property, under Associations, add the following > at the bottom of the list: > * interface : Interface[0..1] > References the Interface that owns the Property. > Subsets /NamedElement::namespace, Feature::featuringClassifier > /I think you are should also have the subset > "Property::classifier" (to be consistent with what is done for > 'datatype', point 3 under 7.3.44 under Associations). In the > XMI, this translates to > "Classes-Kernel-A_attribute_classifier-classifier" (this is > there currently for Classes-Kernel-Property-datatype as well as > Classes-Kernel-Property-class in the XMI). > > 2) > Most importantly, I think you forgot to mention the fact that we > need to add the ownedAttribute "interface" to > Classes::Interfaces::Property, set its' association to > "Classes-Interfaces-A_interface_ownedAttribute" and set its > subsettedProperty to be > "Classes-Kernel-Feature-featuringClassifier > Classes-Kernel-NamedElement-namespace > Classes-Kernel-A_attribute_classifier-classifier". Its' id > should be "Classes-Interfaces-Property-interface" and the > 'interface' member end of > "Classes-Interfaces-A_interface_ownedAttribute" as you already > mentioned in your resolution should now be > "Classes-Interfaces-Property-interface". > > Can you update the resolution to this effect, or I can do it if > you want. > > Salman > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* Friday, September 04, 2009 10:45 AM > *To:* Dave Hawkins > *Cc:* uml2-rtf@omg.org > *Subject:* 14235 -- Re: Ballot 10: status > > Salman, > > You are correct about the property subsetting; my statement > about (3) is wrong. > > I agree that the metamodel needs a good scrubbing to carefully > review all of the hierarchies we have: > > * specialization - are we consistent in the fact that > generalization relationships are not exclusive? > * association subsetting/redefinition & association > specialization - 9374 barely scratched the surface on this. > > > - Nicolas. > > On 9/4/09 7:06 AM, "Dave Hawkins" wrote: > Rouquette, Nicolas F (316A) wrote: > > Dave, > > > > On 9/3/09 11:40 AM, "Dave Hawkins" > wrote: > > > > For 14235, while I don't disagree with the inconsistency > that there > > is no navigable Property-interface property, I don't think > it's > > true to say that owner or namespace wouldn't be populated. > The opposite > > end of Interface-ownedAttribute subsets namespace. That's > sufficient. > > > > > > Property::owner & Property::namespace are properly populated > because of > > the associations in Classes::Kernel, not because of the > associations in > > Classes::Interfaces. > > This part of 14235's point (3) is indeed inaccurate. > > You mean the ownedElement-owner and ownedMember-namespace > associations? > I agree that has to be the case. However that's not how derived > unions are > defined in the specification. In Association (7.3.3) we have: > > "{union} to show that the end is derived by being the union of > its subsets." > > In Property (7.3.44) we have: > > "isDerivedUnion : Boolean > Specifies whether the property is derived as the union of all of the > properties that are constrained to subset it. The default value > is false." > > and > > "A property may be marked as being a derived union. This means > that the > collection of values denoted by the property in some context is > derived > by being the strict union of all of the values denoted, in the same > context, by properties defined to subset it. If the property has a > multiplicity upper bound of 1, then this means that the values > of all > the subsets must be null or the same." > > These seem pretty clear. A derived union is derived from its > subsets, not > its subsets and a derivation from its opposite end. This means > that either > the above definitions need to change or all ends of an > association must > subset a derived union if the one end does. I think this is an > issue. > > > > > > > Of greater concern is that I believe there are a large > number of > > associations where this isn't the case. That is, there is > a mismatch > > between the subsetted properties of the ends. For example: > > > > Transition::effect {subsets ownedElement} > > A_effect_transition::transition > > > > As both owner and ownedElement are derived unions and > those are defined > > to be the strict unions of their subsets I think this > probably does > > mean that owner isn't correctly populated. > > > > > > > > Transition::owner & Transition::namespace will be properly > populated for > > the same reason as above; the definition of > A_effect_transition doesn't > > affect these properties. > > Obviously I disagree with this statement. I don't think the > specification > of the derivation supports that view. > > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 > Oracle JDeveloper Development > Oracle Corporation UK Ltd is a company incorporated in England & > Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Rouquette, Nicolas F (316A)" To: LONJON Antoine , Salman Qadri , Dave Hawkins CC: "uml2-rtf@omg.org" Date: Mon, 7 Sep 2009 12:24:09 -0700 Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcotaPIShvRp0d8+RCiwvYcotvVi7wABUP7QAAkiMMAAAMIeAABey6XwAAScnnAAA9Uv9QAFw4PWACO4ByAABgakzg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Antoine, On 9/7/09 9:42 AM, "LONJON Antoine" wrote: Hi Nicolas, I like the way you present the differentiation between Generalization/Specialization and Redefinition respectively as extensional extensions and intentional extensions. I am not sure this was the original intent, but it could work. Thanks. My explanation is based on the semantics of associations in 7.3.3 . see the text about subsetting & redefinition. However, it leaves open the question about the way to differentiate extensional definition (.which elements are classified by that classifier.) and intentional definition (.specifying the criteria for an element to be classified by that classifier.) which comes prior to the question of going to any specialization or redefinition. I don.t know of any way at this time to define a classifier by extension. We can define a classifier by intention using a generalization relationship or by redefinition if it is nested (the reasons for this are because redefinition requires a classifier context) We can define a property by extension using subsetting and by intention using redefinition. So, if your open question is about differentiating between defining a property by extension or by intention, then I agree that the difference would be worth explaining as well. In the next paragraph regarding association, I am not following you when you say that .When redefinition is applied to all of the association ends, . the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. . . Isn.t this an extensional definition rather that an intentional definition? This is an intentional definition because the redefinition of the association ends is restricting the membership criteria specified in the redefined association ends. - Nicolas. Antoine From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, September 07, 2009 1:29 AM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -------------------------------------------------------------------------------- This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kcQ4k63mEQqWC0hmFj98S6vWlg20TUEPh3xuAHMu0go=; b=Zly+t8B91rQWM1bzG286eZjw7t7tCM7sY/vrb4eSIi+pqxQl1tp6F5s9WMO2aUnIXX P7u21pmlLMwWmmuABJLGVcPIQhT90F6JoZU0ls2YWBtfUojyTRNjQI8AiTNjvqVVwF6h T757oc2U6U4/pGm7e9azF6t9efCjBfSBGj36A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mKtmeGZAtzophQslfgXSzENnJgCCdRybhhfhzoHC78GvP6FAqTUu7MD24xRSNSut8J Y88hUOz7it/wWnJ+LfXxJ2ifH3B06qbQsdNYUBt466RbF0a144d+hKarQH9IXijn0U+6 48QoARO7vPlQLRnziha7dqmX9+h0dOmmdMhqg= Date: Tue, 8 Sep 2009 10:58:01 +0200 Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status From: Bran Selic To: "Rouquette, Nicolas F (316A)" Cc: Salman Qadri , Dave Hawkins , "uml2-rtf@omg.org" Excellent, rationalization of redefinition, Nicolas, it almost makes the original intent look rational. I believe that this explanation should eventually find its way into the spec as a kind of cleanup item. However, I recommend against its inclusion in an urgent fix ballot for two reasons: (1) it is only a partial fix to the issue of association and feature semantics and, as such, it may lead to conflicts with potential future fixes (in other words, I think we need to think about it some more) and (2) it is not an urgent issue (the problem has been around for a long time and the world is still intact) and I do not think it is a good idea to set a precedent of "sneaking" in non-urgent issue resolutions in an urgent ballot, which in many ways shortcircuits the usual peer review process. This opens up a loophole for some serious misuse in the future. BTW, note that redefinition also applies to behavioral features, not just structural features. When we introduced the concept of redefinition in UML 2, the idea was to simply capture what is established practice in most common OO languages. For example, most such languages will allow you to redefine the implementation of a method in a subclass without being too particular about whether or not the redefined method is semantically compatible with the one that it is redefining. (This is because such things are practically impossible to formally verify except in very trivial cases.) We did throw in some mumbo-jumbo about the redefined element being "consistent with" what it is redefining, but, this is really just a placebo (the default isConsistentWith( ) OCL query is a that simply returns "false" -- it is, in fact, a semantic variation point that should be overridden in any specific implementation of UML). The semantics of links are still not quite finalized. For example, Dragan Milicev proposed a perfectly reasonable semantics for links (and, consequently associations) that are currently not supported in fUML, but which, in my opinion, should be allowed in UML. In this variation, it is quite possible for one end of an association to be "unique" while the other is non-"unique" (for a contrary view see, for example, issue 5977). The idea is to think of links as function-like mappings from a source domain to a target domain which imposes a kind of "directionality" to them. This is a different view from the traditional one in which there is no directionality to a link (NB: this has nothing to do with navigability, which is practically an irrelevant feature nowadays). I won't go into more details here, but merely want to point out that there is still work left to do to define the semantics of things as basic as association ends and that, therefore, you should avoid trying to introduce partial fixes through urgent ballots. Cheers...Bran On Mon, Sep 7, 2009 at 1:28 AM, Rouquette, Nicolas F (316A) wrote: I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Salman Qadri To: "Rouquette, Nicolas F (316A)" , Dave Hawkins CC: "uml2-rtf@omg.org" Date: Tue, 8 Sep 2009 09:44:04 -0400 Subject: RE: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcotaPIShvRp0d8+RCiwvYcotvVi7wABUP7QAAkiMMAAAMIeAABey6XwAAScnnAAA9Uv9QAFw4PWAE/72iA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi, I agree with Nicolas on this. The key point to underline here is that for the association to be considered a specialization, ALL ends of the specializing Association must subset or redefine the corresponding ends of the general association. If only one end, for example, has the redefinition, then the associated links of both ends must be treated independently, on each association. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, September 06, 2009 7:29 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cOoOXrgZJx14YjamRwNUU4DUxDGpvRlGGqylEXzwLHQ=; b=IPjUVpBDt+OqK93CFDu4s2jzl22bcXHVAzzz8FWu3zdwdTbKaR+apDpy24xvrMUnG9 se9+qy+GeuZD82Q4x7L0uHkkUretszj2Kr7gmklHlXo+d94uQNuc7MYnk607DB5uP01i HA8p29zaA8IVtLGBlNeACeEsFigpB/NpoDq2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nEIc+GptIP27wI2zigkDD9CEMP3UCT767AjShvCIF0iXIxRkwNEjBwR9ZDbudApb5z hO0iQtALyUJvDLqKl5Z27+B2re52PZ6EnZJhGHFgdMFH3mIPELU7j5fuAFmKhDzrOZSX FexXSW/qupoKg4oudHBaCe6NuWYlgSoChiyAo= Date: Tue, 8 Sep 2009 16:02:20 +0200 Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status From: Bran Selic To: Salman Qadri Cc: "Rouquette, Nicolas F (316A)" , Dave Hawkins , "uml2-rtf@omg.org" This illustrates my previous point about the semantics of associations and links. In the Milicev model of links, Salman's statement below would not be valid. So, until we agree on such semantics, it's probably better to defer any resolutions related to this topic from ballot 10. Cheers...Bran On Tue, Sep 8, 2009 at 3:44 PM, Salman Qadri wrote: Hi, I agree with Nicolas on this. The key point to underline here is that for the association to be considered a specialization, ALL ends of the specializing Association must subset or redefine the corresponding ends of the general association. If only one end, for example, has the redefinition, then the associated links of both ends must be treated independently, on each association. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, September 06, 2009 7:29 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Salman Qadri To: Bran Selic CC: "Rouquette, Nicolas F (316A)" , Dave Hawkins , "uml2-rtf@omg.org" Date: Tue, 8 Sep 2009 11:14:07 -0400 Subject: RE: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: AcowjPzgIoqr61woQU2Sh7bbmoWCDgAA039Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Personally, to me the Milicev model is exactly what implementation should always boil down to, and here is my layman summary of his model: Each association end has a list of opposites that it must maintain. That.s it, and the idea is great. Why is the Milicev idea so useful? Because typically in any implementation of an Instance Specification, Links are just a notion that are not user-interactable or user-visible. Even for OMG purposes, the concept of a Link is used mainly in a theoretical context, as one possible view of the instance world. The resulting semantics of the ends are fixed, with or without links. The Milicev model is essentially a kind of implementation to achieve the same semantic results. The point is, in terms of semantics, the constraints on every property, and the expectations of every property from the user-perspective, must ALWAYS be true. That is the bottom line. Beyond that we are trying to explain what we must do to ensure this. At the theoretical level, Nicolas is claiming, in my opinion rightly so, that if ALL ends of an association redefine or subset the corresponding ends of another association, then we can consider the former a .specialization. of the .latter.. What difference does it make if the Association is a specialization or not? Consider a Class A that inherits Class B, then basically the point is that an instance of A is also an instance of B. Similarly, in this case it means that a .Link. of one association will also be a .Link. of another association. This is essentially a form of reduction of the problem into something simpler. Also, depending on the implementation, this can make it much easier to prevent unintended duplicated entries in the case of a non-unique end. In a Milicev implementation, for example, this boils down to one less element in his collection of linked roles for an end. My point was, that if it is not the case that ALL ends have a redefined or subsetted end, then the Association should not be considered a specialization. I said that the .links of both ends must be treated independently.. Suppose you have a case, which is typical of the UML metamodel, where there is a redefined property on one end, but not the other, then in a Milicev implementation for the end that does the redefining, the end will must not only have the opposite end in its collection, but also the opposite of the redefined end. The only real difference that Milicev would provide in this case, is that the opposite ends will have only 1 opposite role in their collection, because a redefined property relationship enforces one slot. This is the point that really makes a Milicev model of links different to the OMG model of links, but again, this has no bearing on a theoritcal discussion based on the OMG model of Links. Syed Salman Qadri Sr. Software Engineer The MathWorks Inc. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Tuesday, September 08, 2009 10:02 AM To: Salman Qadri Cc: Rouquette, Nicolas F (316A); Dave Hawkins; uml2-rtf@omg.org Subject: Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status This illustrates my previous point about the semantics of associations and links. In the Milicev model of links, Salman's statement below would not be valid. So, until we agree on such semantics, it's probably better to defer any resolutions related to this topic from ballot 10. Cheers...Bran On Tue, Sep 8, 2009 at 3:44 PM, Salman Qadri wrote: Hi, I agree with Nicolas on this. The key point to underline here is that for the association to be considered a specialization, ALL ends of the specializing Association must subset or redefine the corresponding ends of the general association. If only one end, for example, has the redefinition, then the associated links of both ends must be treated independently, on each association. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, September 06, 2009 7:29 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension . i.e., specifying which elements are classified by that classifier - by intension . i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension . i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension . i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension . i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension . i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension . i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension . i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of .Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to .Classes-Interfaces-A_interface_ownedAttribute. and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of .Classes-Interfaces-A_interface_ownedAttribute. as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization . are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization . 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.