Issue 18177: The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance (uml25-ftf) Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com) Nature: Uncategorized Issue Severity: Summary: UML 2.5: “The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance”, with this email discussion attached Resolution: Revised Text: Actions taken: October 18, 2012: received issue Discussion: End of Annotations:===== m: Steve Cook To: Nerijus Jankevicius CC: "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: AQHNrQ2xKMTG9z8xwEu8+jIPmvC14Ze+zn2QgAAHQgCAAAIlUA== Date: Thu, 18 Oct 2012 10:22:55 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454001)(252514003)(377454001)(50986001)(47736001)(47976001)(1076001)(512874001)(16826001)(16696001)(8716001)(16406001)(550184003)(46102001)(44976002)(31966008)(28754002)(15202345001)(74502001)(33656001)(4196001)(74662001)(4396001)(3846001)(2666001)(49866001)(20776001)(51856001)(5343635001)(47446002)(5343655001)(42186003)(316001)(3746001)(3556001);DIR:OUT;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0638FD5066 Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . pleasse raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: Ed Seidewitz To: Steve Cook , Nerijus Jankevicius CC: "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Date: Thu, 18 Oct 2012 14:04:44 -0400 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: AQHNrQ2xKMTG9z8xwEu8+jIPmvC14Ze+zn2QgAAHQgCAAAIlUIAAFtMAgAABDfCAAGN1QA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.817395 p=-0.993537 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: ca5e9573-3645-4c69-a097-0079ab0c3fee Steve, Nerijus . Well, the issue is, of course, what the definition of .inheritance. is. As it is used in UML, .inheritance. is defined entirely in terms of namespace membership. A specialized classifier inherits the .inheritable. members of its general classifiers. Private members of a general classifier are not inheritable, because they are not visible to the specialized classifiers. Since inherited members are members, they must be distinguishable by name or signature (as appropriate) from other members. Redefined members are not inherited, since they are redefined in the specialized namespace. And so forth. It is actually pretty consistent, though it could be better explained in the spec, even as currently revised for UML 2.5. On the other hand, in terms of instantiation of a classifier, namespace membership and visibility and such are not what are important. Instead, you want to be able to model what values an instance of a classifier may have for any of its features. As has been noted, the fact that a feature may be .private. as a named element should not prevent the instance from having a value for that feature. This is pretty basic to the OO model! However, this is a different kind of .inheritance. than the way the term is defined in UML. Rather than trying to redefine .inheritance. in UML, I believe that all we need to do is replace the use of allFeatures() in the constraints for Slot with a different operation that doesn.t exclude features from parents that are private. Something like this (I am open to suggestions for better names for the operation!): context Classifier::allInstantiableFeatures(): StructuralFeature[*] body: self.inherit(self.allParents().feature->select(oclIsKindOf(StructuralFeature).oclAsType(StructuralFeature)->asSet()) Note that the call to .self.inherit. here acts to exclude redefined features. I agree with Steve that an instance specification should not have slots for both a redefined feature and its corresponding redefining feature. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 7:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: Ed Seidewitz To: Steve Cook , Pete Rivett , Nerijus Jankevicius CC: "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Date: Thu, 18 Oct 2012 14:15:33 -0400 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: AQHNrQ2xKMTG9z8xwEu8+jIPmvC14Ze+zn2QgAAHQgCAAAIlUIAAFtMAgAABDfCAACpJkIAAKMsggAAbo5A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.874454 p=-0.978947 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: 0f7fffe9-4a7b-4873-b73d-1814c1117735 As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: "BERNARD, Yves" To: Ed Seidewitz , Steve Cook , Pete Rivett , Nerijus Jankevicius CC: "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Date: Fri, 19 Oct 2012 08:10:07 +0200 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: AQHNrQ2xKMTG9z8xwEu8+jIPmvC14Ze+zn2QgAAHQgCAAAIlUIAAFtMAgAABDfCAACpJkIAAKMsggAAbo5CAAMSFIA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US I agree with that. Nevertheless it could be worth, in this case, to constrain the InstanceSpecification so that it cannot be any generalization relationships between its classifier. Something like: Inv: self.classifier->size() > 1 implies self.classifier->forAll(c | self.classifier->excludesAll(c.generalization.general)) Yves From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: jeudi 18 octobre 2012 20:16 To: Steve Cook; Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: Re: definingFeature of the Slot From: Nerijus Jankevicius Date: Fri, 19 Oct 2012 10:16:50 +0300 Cc: Steve Cook , Pete Rivett , "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" To: Ed Seidewitz X-Mailer: Apple Mail (2.1084) Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: "BERNARD, Yves" To: Nerijus Jankevicius , Ed Seidewitz CC: Steve Cook , Pete Rivett , "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Date: Fri, 19 Oct 2012 10:29:54 +0200 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: Ac2tycZ9EUJod2PeTP+asO6OZUsYIQACKDyg Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US I believe that, yes, we should constraint classifiers so that redefinition can be used in consistency with the generalization/specialization. For instance we could implies that any feature redefined in a specialized classifier have to be logically consistent with the feature they redefine. This would avoid the kind .non-sense. implementation that vendors have to do to comply with the current specification, as described by Nerijus. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 19 octobre 2012 09:17 To: Ed Seidewitz Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=JNv4HZx+iB8ngoSCr40XkvEQeP6BlR+pVDV8dqaKnXM=; b=DC5dAgnka0Ppov2xtDADgWavZu14WHsNI1de6PjmPi2UDEJ8xSDLKPv56qVmUrXas2 XrierUWabxLrVe329mrK+roPFIbfAxGWC00nlHZ6Hmov1cFCsBsN8KwRnZV9sH9FIiwR Pccc2Vf0t1ShFhoIV1U1e3KxIYNRwPz1A2Fe4aM95DRFAxbKB7tbt4M3y1ldKz7IBDC4 uhybEfr/IteWYLZh8l4iok3SesOZI7hwRCW4YbEQvLhSCPxlbpA0y2wu40YQsF/hI+xC ZDNTPDL0NGUa78uifsOppPx6SoMxNtZKXxcngDQvUngDdkiBPxKT90f8nSC6bYD6vVjD pR5A== Sender: bran.selic@gmail.com From: Bran Selic Date: Fri, 19 Oct 2012 04:49:20 -0400 X-Google-Sender-Auth: bH8NgLSr5lA_K1Ru10iqR9UgGcc Subject: Re: definingFeature of the Slot To: "BERNARD, Yves" Cc: Nerijus Jankevicius , Ed Seidewitz , Steve Cook , Pete Rivett , "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Are we hitting a conflict here between the need to use UML as a language for modeling existing software systems, versus the need to use UML as a specification language? The problem is that some applications people may want to model with UML suffer precisely from the type of nonsense that Yves mentions. For example, different OO languages handle redefinition differently. Should we support all or settle on one that we feel is the "right" one? The use of UML as a descriptive tool (vs. a prescriptive one) was very much a part of the original idea behind UML (e.g., to allow analysis of legacy software). Perhaps it is no longer a pressing need? Opinions? Bran On Fri, Oct 19, 2012 at 4:29 AM, BERNARD, Yves wrote: I believe that, yes, we should constraint classifiers so that redefinition can be used in consistency with the generalization/specialization. For instance we could implies that any feature redefined in a specialized classifier have to be logically consistent with the feature they redefine. This would avoid the kind .non-sense. implementation that vendors have to do to comply with the current specification, as described by Nerijus. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 19 octobre 2012 09:17 To: Ed Seidewitz Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Bran Selic CC: Nerijus Jankevicius , Ed Seidewitz , Steve Cook , Pete Rivett , "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" Date: Fri, 19 Oct 2012 11:32:27 +0200 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: Ac2t1rrKoOrBh4GSS0O5BsY43iGYUQABB96w Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US To my opinion UML should be able to deal with any kind of concepts (like redefinition) used by existing applications but not inevitably with the same name and not inevitably as a first-class one (i.e. it can be provide through a construct too). For instance, a .redefinition. where the redefined feature remains in the instances of the redefinition context can be seen (and modeled) as a simple feature addition, eventually with modification of the redefined feature.s visibility. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: vendredi 19 octobre 2012 10:49 To: BERNARD, Yves Cc: Nerijus Jankevicius; Ed Seidewitz; Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Are we hitting a conflict here between the need to use UML as a language for modeling existing software systems, versus the need to use UML as a specification language? The problem is that some applications people may want to model with UML suffer precisely from the type of nonsense that Yves mentions. For example, different OO languages handle redefinition differently. Should we support all or settle on one that we feel is the "right" one? The use of UML as a descriptive tool (vs. a prescriptive one) was very much a part of the original idea behind UML (e.g., to allow analysis of legacy software). Perhaps it is no longer a pressing need? Opinions? Bran On Fri, Oct 19, 2012 at 4:29 AM, BERNARD, Yves wrote: I believe that, yes, we should constraint classifiers so that redefinition can be used in consistency with the generalization/specialization. For instance we could implies that any feature redefined in a specialized classifier have to be logically consistent with the feature they redefine. This would avoid the kind .non-sense. implementation that vendors have to do to comply with the current specification, as described by Nerijus. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 19 octobre 2012 09:17 To: Ed Seidewitz Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=TnopcnP15w0cPZlHVA691mglFLK0WP0sPCQJjHJzjtc=; b=K2fw6jCVWSSuG95FazLqYcNlG/8zQH5wAo7FEOPZmiZN+x/hqxgI1ihFuOUjQi7IP4 VY60YKbZ6/VixKm4PuUt5iSCRB0xbLGb5R6Xq51rNVHQr1xWyLs2tSRYl8g8sprW17vv PlnXlASA77kkiBtIyIDhfXa388Um5zVgUSc98/JGv5dwuX5K0asieiuJJu2MPn5PTxpU 7oV5EtcuHjUhQiqrjLIfSVjDLVlbLc4UF4N7fBGxSBOPIWozMaiWCHz5RX4op2+cQq01 mRgzjY15icvoO0AeeHtCD4aX7ETwDcrDVnolFsFl8AgEIS8GPYq1jLz5oJf2CkxCFQBZ 2VtQ== From: "Sanford Friedenthal" To: "'Ed Seidewitz'" , "'Nerijus Jankevicius'" Cc: "'Steve Cook'" , "'Pete Rivett'" , , , Subject: RE: definingFeature of the Slot Date: Fri, 19 Oct 2012 10:33:12 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac2tyblAxiVaLQ6+SvqtrcW3GZvsZwANmrSwAAGM2/A= Ed On a related note, If I create a subclass of B in your example below with a Classifier C, should it not inherit the property q. Can I then further redefine this property q. It seems like I should be able to do this, but I understood from one of your earlier emails that I cannot do this. Please clarify. Sandy From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, October 19, 2012 10:15 AM To: Nerijus Jankevicius Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus . The UML 2.5 spec, Subclause 9.2.3 (Semantics of Classification), under .Redefinition., says that ..the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. Unfortunately, not further detail is given specifically for the redefinition of Properties, other than to say (in Subclause 9.5.3) that .Property is indirectly a kind of RedefinableElement, so Properties may be redefined.. However, there have been a number of other discussions of the semantics of redefinition (e.g., in the context of MOF, in the context of composite structure, etc.), and, in each case, the only reasonable semantics that have been proposed for Property redefinition are that the redefined and redefining Properties essentially model the same feature of the specialized Classifier containing the redefining Property. Structurally, the redefining Property .replaces. the redefined Property in the specialized namespace, but, .in the context of the specializing Classifier., if you try to reference the redefined Property, this must .resolve. to the redefining Property . i.e., they are really the same feature of the specialized Classifier. So, suppose I have a Classifier A with a Property p the is specialized by a Classifier B that has a Property q that redefines p (and, for simplicity, assume everything is public). In this case, p is not a feature of B . it has been replaced by q. Therefore, if b is an instance of B, a named reference .b.p. would not make sense . there is no member of B named .p.. On the other hand, if I up-cast b to type A, then one can reference p but not q. That is, a reference of the form .((A)b).p. (using the C-like Alf notation) does make sense. However, this reference resolves to the redefining Property q. Thus, if I set b.q to a value and then read ((A)b).p, I will get the value I set for b.q, and vice versa. Essentially, .b.q. and .((A)b).p. are just different names for the same thing. This means that, in terms of an InstanceSpecification modeling b, a slot with p as its defining feature should be the same as a slot with q as the defining feature. It would be semantically dubious for such a model to have slots for both p and q . and certainly invalid if those slots had anything but the same values. Indeed, as I have previously proposed, in the context of an InstanceSpecification with B as its Classifier, I think it makes the most sense to only allow a slot for q, not for p at all. Now, these semantics could, of course, be implemented by having .slots. for both p and q in an M0 instance of B and keeping the values in those slots properly synchronized. But that is just an implementation approach and doesn.t change the semantics that, fundamentally, p and q represent the same feature of B. -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, October 19, 2012 3:17 AM To: Ed Seidewitz Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: Ed Seidewitz To: Bran Selic CC: Nerijus Jankevicius , Steve Cook , Pete Rivett , "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" , "BERNARD, Yves" Date: Fri, 19 Oct 2012 10:38:11 -0400 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: Ac2t1rzUqbD6jsd2S3K8NTuLp6YgdAALZQqg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.859806 p=-0.982869 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: 37556619-8ee6-4b19-b5fa-4c0895111917 Bran . As I think you know, my opinion is that UML 2 has suffered greatly by, on the one hand, trying to define semantics for its modeling constructs while, on the other hand, trying to somehow use the same modeling constructs to represent things that are defined significantly differently in different OO programming languages, but just happen to have the same or similar names. I think the result has left UML 2 poorly defined in both the its role as a language for modeling existing software systems and its role as a specification language. While this has left a lot of baggage in the language, I think we are on the right track to deal with this in UML 2.5. First of all we need to be really clear about what is and isn.t well-formed as a UML model. Second, we need to be really clear on what the normative semantics of a well-formed model are (and are not) as a UML model. But, then, we allow tools that have abstract syntax conformance but not semantic conformance . so, if a tool wants to support the creation of certain well-formed UML models but interpret them strictly using Java semantics, that is fine. Conformance to the normative semantics of UML is an option that promotes semantic interoperability between tools at the model level . but such interoperability is not a requirement that all UML modelers have. In the present case of slots for redefined properties, there are really both syntactic and semantic issues. First, there is the syntactic well-formedness issue of whether an instance specification should be allowed to have slots for both a redefining property and the property it redefines. Second, there is the issue of what the normative semantics are for a well-formed instance specification with a slot for a redefining property. My point on this case has essentially been that, given a reasonable interpretation of the normative semantics of property redefinition in UML, it doesn.t make a lot of sense to allow an instance specification with slots for both a redefining property and its redefined property, and it would certainly be semantically invalid to have such slots with different values. However, consistent with my comments above, it would also be possible for us to consider instance specifications with such slots as being well-formed syntactically (they currently are not, since redefined properties are not inherited features), but to simply make it clear that there are no normative semantics for a model in which the slot values for a redefining property and its redefined property are different, or in which the value for the redefined property does not meet the constraints of the redefining property. Personally, I don.t really like this sort of thing, in which we allow well-formed models without normative semantics. But there are certainly a good number of other places in UML 2.5 that we have done this in order to handle exactly the kind of tension between syntactic flexibility and semantic precision that we see here. -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Friday, October 19, 2012 4:49 AM To: BERNARD, Yves Cc: Nerijus Jankevicius; Ed Seidewitz; Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Are we hitting a conflict here between the need to use UML as a language for modeling existing software systems, versus the need to use UML as a specification language? The problem is that some applications people may want to model with UML suffer precisely from the type of nonsense that Yves mentions. For example, different OO languages handle redefinition differently. Should we support all or settle on one that we feel is the "right" one? The use of UML as a descriptive tool (vs. a prescriptive one) was very much a part of the original idea behind UML (e.g., to allow analysis of legacy software). Perhaps it is no longer a pressing need? Opinions? Bran On Fri, Oct 19, 2012 at 4:29 AM, BERNARD, Yves wrote: I believe that, yes, we should constraint classifiers so that redefinition can be used in consistency with the generalization/specialization. For instance we could implies that any feature redefined in a specialized classifier have to be logically consistent with the feature they redefine. This would avoid the kind .non-sense. implementation that vendors have to do to comply with the current specification, as described by Nerijus. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 19 octobre 2012 09:17 To: Ed Seidewitz Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Ed Seidewitz To: Sanford Friedenthal CC: "'Steve Cook'" , "'Pete Rivett'" , "uml2-rtf@omg.org" , "uml25-ftf@omg.org" , "issues@omg.org" , "'Nerijus Jankevicius'" Date: Fri, 19 Oct 2012 10:50:07 -0400 Subject: RE: definingFeature of the Slot Thread-Topic: definingFeature of the Slot Thread-Index: Ac2tyblAxiVaLQ6+SvqtrcW3GZvsZwANmrSwAAGM2/AAAHn/AA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.844532 p=-0.979029 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: 7cc31259-0963-4dab-a239-398ca15255dd Sandy . Yes, you can do what you suggest. When I say .redefined properties are not inherited., I mean that the property being redefined is not inherited into the specializing namespace that contains the property that redefines it, not that the redefining property cannot be further inherited. For example, in the absence of redefinition, the property A::p would be inherited by B. However, since B redefines p as q, it no longer inherits p . p has been effectively replaced by B::q. If you then specialize B as C, C will inherit q, but not p (since p will not even be a member of B). However, if C redefines q as r, then, once again, C will not inherit q, which will have been replaced by r. -- Ed From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Friday, October 19, 2012 10:33 AM To: Ed Seidewitz; 'Nerijus Jankevicius' Cc: 'Steve Cook'; 'Pete Rivett'; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Ed On a related note, If I create a subclass of B in your example below with a Classifier C, should it not inherit the property q. Can I then further redefine this property q. It seems like I should be able to do this, but I understood from one of your earlier emails that I cannot do this. Please clarify. Sandy From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, October 19, 2012 10:15 AM To: Nerijus Jankevicius Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus . The UML 2.5 spec, Subclause 9.2.3 (Semantics of Classification), under .Redefinition., says that ..the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. Unfortunately, not further detail is given specifically for the redefinition of Properties, other than to say (in Subclause 9.5.3) that .Property is indirectly a kind of RedefinableElement, so Properties may be redefined.. However, there have been a number of other discussions of the semantics of redefinition (e.g., in the context of MOF, in the context of composite structure, etc.), and, in each case, the only reasonable semantics that have been proposed for Property redefinition are that the redefined and redefining Properties essentially model the same feature of the specialized Classifier containing the redefining Property. Structurally, the redefining Property .replaces. the redefined Property in the specialized namespace, but, .in the context of the specializing Classifier., if you try to reference the redefined Property, this must .resolve. to the redefining Property . i.e., they are really the same feature of the specialized Classifier. So, suppose I have a Classifier A with a Property p the is specialized by a Classifier B that has a Property q that redefines p (and, for simplicity, assume everything is public). In this case, p is not a feature of B . it has been replaced by q. Therefore, if b is an instance of B, a named reference .b.p. would not make sense . there is no member of B named .p.. On the other hand, if I up-cast b to type A, then one can reference p but not q. That is, a reference of the form .((A)b).p. (using the C-like Alf notation) does make sense. However, this reference resolves to the redefining Property q. Thus, if I set b.q to a value and then read ((A)b).p, I will get the value I set for b.q, and vice versa. Essentially, .b.q. and .((A)b).p. are just different names for the same thing. This means that, in terms of an InstanceSpecification modeling b, a slot with p as its defining feature should be the same as a slot with q as the defining feature. It would be semantically dubious for such a model to have slots for both p and q . and certainly invalid if those slots had anything but the same values. Indeed, as I have previously proposed, in the context of an InstanceSpecification with B as its Classifier, I think it makes the most sense to only allow a slot for q, not for p at all. Now, these semantics could, of course, be implemented by having .slots. for both p and q in an M0 instance of B and keeping the values in those slots properly synchronized. But that is just an implementation approach and doesn.t change the semantics that, fundamentally, p and q represent the same feature of B. -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, October 19, 2012 3:17 AM To: Ed Seidewitz Cc: Steve Cook; Pete Rivett; uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Ed, In all redefinition implementations I know, both redefined and redefining features have values at runtime (like private features do), so it makes sense to have slots for both. Redefinition works as special type of subsetting (the redefined feature has value of redefining feature at runtime, otherwise super type methods can't work). If I would need to illustrate what redefinition means and use InstanceSpecifications for that, I would like to use both slots. Is there a NEW clear definition in UML 2.5 what redefinition means, or it is still up to tool vendors to interpret that? Nerijus On Oct 18, 2012, at 9:15 PM, Ed Seidewitz wrote: As I noted in my previous message, I think an instance specification should only be allowed to have a slot for the redefining property, not the redefined property, not both. Alternatively, we could allow having a slot for either on or the other, but not both, but I don.t really think the added complexity of allowing this is worth it. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 12:43 PM To: Pete Rivett; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot I misspoke, in several ways. When I said allFeatures() does not depend on inheritedMember(), I was completely wrong. It does. When I said .all (non-static) structural features, including inherited ones, should be instantiated as a slot. I should have said .all (non-static) structural features, including inherited ones, should be instantiable as a slot.. I.e. the rule that private inherited features cannot have corresponding slots is wrong. In general I agree with Pete. However, if an instance specification x has classifier C, and property P inherited by C has been redefined in C by another property P, do you think that it is valid for x to have two slots, one for each P? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 18 October 2012 17:00 To: Steve Cook; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot We need to remember that an InstanceSpecification is not a true instance but a possibly vague specification of one or more instances. So statements like Steve.s following: do not IMHO apply Ø Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. People will create whatever slots they need for the purpose of the specification. It also seems valid for people to create slots for derived properties: again it.s a specification. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 18, 2012 4:41 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: RE: definingFeature of the Slot Nerijus You are right. Well, we do have a problem. Private structural features should be inherited, in the sense that an instance of a subclass must have slots for them. We also need to take redefinition into account properly, because a redefined structural feature should not have two slots. The whole inheritance thing needs fixing. I think the issue title that I suggested is ok. -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 12:34 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org; issues@omg.org Subject: Re: definingFeature of the Slot Steve, inheritedMember subsets member, so it is widely used via getMember(). Talking about "visibleMember", it is already defined and used in Package. Nerijus On Oct 18, 2012, at 1:22 PM, Steve Cook wrote: Nerijus The constraint might be moved I suppose. The OCL uses allFeatures() which does not depend on inheritedMember(). In fact as far as I can tell, nothing depends on inheritedMember(). Since it is confusing (because as you point out, the meaning of the word .inherited. is not used uniformly as defined by inheritedMember) perhaps inheritedMember should be renamed to visibleMember, or even removed altogether, together with inheritableMembers(). This confusion about the meaning of inherited is definitely an issue. Juergen . please raise an issue against UML 2.5: .The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance., with this email discussion attached. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 11:04 To: Steve Cook Cc: uml2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: definingFeature of the Slot Steve, Thanks for reply, I missed Constraint in InstanceSpecification, shouldn't it be moved under Slot, as defining feature is property of the Slot? Also, constraint says "inherited", but I'm not sure private members are inheritable or not? Are private features of parent part of inheritedMember() or not? inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) · inheritedMember() : NamedElement [0..*] The inheritedMember association is derived by inheriting the inheritable members of the parents. body: inherit(parents()->collect(inheritableMembers(self))->asSet()) Nerijus On Oct 18, 2012, at 12:47 PM, Steve Cook wrote: Nerijus Firstly, please use uml25-ftf list for discussions of topics like this. Secondly, all (non-static) structural features, including inherited ones, should be instantiated as a slot. The visibility determines what is allowed to access that slot, not whether there is a slot. Thirdly, there is a constraint on InstanceSpecification as follows (from UML2.5): defining_feature The defining feature of each slot is a StructuralFeature (directly or inherited) of a classifier of the InstanceSpecification. inv: slot->forAll(s | classifier->exists (c | c.allFeatures()->includes (s.definingFeature))) I do think there is a missing constraint that static features may not have a slot. I will log an issue for that. Thanks -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 18 October 2012 09:50 To: uml2-rtf@omg.org Subject: definingFeature of the Slot Hello, We had discussion in our team, should we allow instantiation of the "private inherited" features or not. Intuitively, we shouldn't, as private members should not be inherited. However, Slot has no Constraints on definingFeature, it even does not say, feature of what classifier it is (the same as classifier of InstanceSpecification or not). Don't you think we should add some constraints or clarification? -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: Steve Cook To: "uml25-ftf@omg.org" Subject: Issue 18177 - definition of inheritedMember Thread-Topic: Issue 18177 - definition of inheritedMember Thread-Index: Ac5+N77J/nze7K7TTpyZTsBwSHwD4A== Date: Thu, 11 Jul 2013 13:22:37 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(5403001)(189002)(199002)(46102001)(56776001)(59766001)(77096001)(77982001)(512954002)(53806001)(56816003)(49866001)(76482001)(54316002)(79102001)(55846006)(65816001)(74876001)(69226001)(71186001)(47446002)(51856001)(74706001)(76796001)(76786001)(54356001)(74502001)(76176001)(63696002)(80022001)(4396001)(50986001)(20776003)(74662001)(81542001)(74366001)(16236675002)(47976001)(33656001)(16406001)(44976004)(31966008)(19300405004)(6806004)(15202345003)(47736001)(83072001)(81342001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB027;H:TK5EX14HUBC105.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0904004ECB X-Virus-Scanned: amavisd-new at omg.org Issue 18177 points out that the definition of inheritedMember, which excludes private members from generalizations, causes the problem (if it is a problem) that slots for these private members may not be created for InstanceSpecifications. We had an email discussion about this last year which was somewhat inconclusive. It got side-tracked into a discussion about redefined members being excluded from inheritedMember . which indeed they currently are. Should inheritedMember (and in consequence member and allFeatures()) be changed so that it includes private members of generalizations? Or is this .close no change.? Thanks -- Steve From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Thu, 11 Jul 2013 09:35:07 -0400 Subject: RE: Issue 18177 - definition of inheritedMember Thread-Topic: Issue 18177 - definition of inheritedMember Thread-Index: Ac5+N77J/nze7K7TTpyZTsBwSHwD4AAAqe4w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Steve, > Issue 18177 points out that the definition of inheritedMember, which excludes > private members from generalizations, causes the problem (if it is a problem) > that slots for these private members may not be created for > InstanceSpecifications. > > Should inheritedMember (and in consequence member and allFeatures()) be > changed so that it includes private members of generalizations? Or is this > "close no change"? How about special-casing private members for instance specs, but not for inheritedMember in general? inheritedMember and allFeatures are about the model, so shouldn't "see" private members, whereas instance specs are about runtime and should see them. BTW, the same problem applies to the "visibility" constraint on StructuralFeatureAction. The action can access a private member if it is in a method defined on the same class as the member. Conrad X-Virus-Scanned: OK From: Ed Seidewitz To: "Bock, Conrad" CC: "uml25-ftf@omg.org" Subject: RE: Issue 18177 - definition of inheritedMember Thread-Topic: Issue 18177 - definition of inheritedMember Thread-Index: Ac5+N77J/nze7K7TTpyZTsBwSHwD4AAAqe4wAAC7r3A= Date: Thu, 11 Jul 2013 13:53:48 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.226.177] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6BDrqsr019525 Yes, I agree with Conrad on this. If we make inheritedMember include private members, then there is no difference between this and protected visibility. But visibility really shouldn't be considered as a restriction in modeling using instance specifications and actions -- but that is probably a different issue or two. (Note, by the way, that there is an open fUML issue related to this, in that runtime feature values are not being properly creating for the non-inherited private structural features from parent classifiers of an instance. Oops! Mea culpa!) -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, July 11, 2013 9:35 AM To: uml25-ftf@omg.org Subject: RE: Issue 18177 - definition of inheritedMember Steve, > Issue 18177 points out that the definition of inheritedMember, which excludes > private members from generalizations, causes the problem (if it is a problem) > that slots for these private members may not be created for > InstanceSpecifications. > > Should inheritedMember (and in consequence member and allFeatures()) be > changed so that it includes private members of generalizations? Or is this > "close no change"? How about special-casing private members for instance specs, but not for inheritedMember in general? inheritedMember and allFeatures are about the model, so shouldn't "see" private members, whereas instance specs are about runtime and should see them. BTW, the same problem applies to the "visibility" constraint on StructuralFeatureAction. The action can access a private member if it is in a method defined on the same class as the member. Conrad