Issue 4720: Association Generalization Proposal (mof-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: Here is a detailed proposal for adding association generalization to MOF 1.5. This proposal does not address reference redefinition or overriding. I hope this proposal provides sufficient detail so that Steve Crawley can make changes to the specification. Please send your comments. Regards, Don Changes to Model Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35] AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract. Add a nonabstract association from AssociationEnd to AssociationEnd called RedefinesEnd. One end is called redefinedEnd, has a reference by the same name, and has multiplicity *. The other end is called redefiningEnd, has no reference, and has multiplicity *. This association is used to correlate an end with its corresponding end in a supertype association. Add new constraint: SupertypeEndsAreRedefined Evaluation policy: Deferred. Description: An end redefines each supertype's end. Context Association Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))-> forAll(ge : AssociationEnd | self.contents->select(sc | sc.oclIsTypeOf(AssociationEnd))-> forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re = ge) and se.otherEnd.redefinedEnd->exists(ore | ore = ge.otherEnd))) Add new constraint: RedefinedEndBelongsToSupertype Evaluation policy: Immediate. Description: Each redefinedEnd belongs to a supertype. Context AssociationEnd Inv: self.container.oclAsType(Association).supertypes.contents-> includesAll(self.redefinedEnd) By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an immediate constraint, but it should be deferred. Otherwise, there is no valid way to create an Association. Changes to Abstract Mapping Add the following to Core Association Semantics. A link cannot be directly created for an Association with isAbstract set to true, but can be added indirectly as a link of a subtype association. Where a generalization exists between two associations, each link of the subtype association is logically a link of the supertype association - for each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or <b, a> depending on which subtype end redefines which supertype end). Removing a link from a Link_Set causes the logical link to be removed from each subtype association's Link_Set. Removing a link from a Link_Set also causes the logical link to be removed from each supertype association's Link_Set where the logical link is not otherwise present in the supertype Link_Set based on either having been put explicitly into the supertype Link_Set (where not abstract) or on being a link of some other subtype of the supertype. The net effect is that a Link_Set is a union of links put explicitly into the Link_Set with the Link_Sets of all subtypes. Changes to IDL Mapping In the template for associations, no add or modify operations are generated for an abstract association. In the template for references, no set, add, or modify operations are generated for an abstract association. Operations on RefObject for setting, adding, and modifying, and operations on RefAssociation for adding and modifying raise a new MofError, "Abstract Association", for creating a link of an abstract association. Changes to JMI In the template for associations, no add operation is generated for an abstract association. In the template for references, no set operation is generated for an abstract association. Also, the add and set operations on a reference collection throws a new JmiException, "AbstractAssociation", for an abstract association. For the reflective JMI interfaces, JmiException "AbstractAssociation" is thrown for refAddLink on an abstract association and for refSetValue on a reference on an abstract association. Resolution: Revised Text: Actions taken: November 30, 2001: received issue Discussion: End of Annotations:===== From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: Association Generalization Proposal Date: Fri, 30 Nov 2001 20:37:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \6select(gc | gc.oclIsTypeOf(AssociationEnd))-> forAll(ge : AssociationEnd | self.contents->select(sc | sc.oclIsTypeOf(AssociationEnd))-> forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re = ge) and se.otherEnd.redefinedEnd->exists(ore | ore = ge.otherEnd))) Add new constraint: RedefinedEndBelongsToSupertype Evaluation policy: Immediate. Description: Each redefinedEnd belongs to a supertype. Context AssociationEnd Inv: self.container.oclAsType(Association).supertypes.contents-> includesAll(self.redefinedEnd) By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an immediate constraint, but it should be deferred. Otherwise, there is no valid way to create an Association. Changes to Abstract Mapping Add the following to Core Association Semantics. A link cannot be directly created for an Association with isAbstract set to true, but can be added indirectly as a link of a subtype association. Where a generalization exists between two associations, each link of the subtype association is logically a link of the supertype association - for each subtype Link there implicitly exists a supertype Link (or depending on which subtype end redefines which supertype end). Removing a link from a Link_Set causes the logical link to be removed from each subtype association's Link_Set. Removing a link from a Link_Set also causes the logical link to be removed from each supertype association's Link_Set where the logical link is not otherwise present in the supertype Link_Set based on either having been put explicitly into the supertype Link_Set (where not abstract) or on being a link of some other subtype of the supertype. The net effect is that a Link_Set is a union of links put explicitly into the Link_Set with the Link_Sets of all subtypes. Changes to IDL Mapping In the template for associations, no add or modify operations are generated for an abstract association. In the template for references, no set, add, or modify operations are generated for an abstract association. Operations on RefObject for setting, adding, and modifying, and operations on RefAssociation for adding and modifying raise a new MofError, "Abstract Association", for creating a link of an abstract association. Changes to JMI In the template for associations, no add operation is generated for an abstract association. In the template for references, no set operation is generated for an abstract association. Also, the add and set operations on a reference collection throws a new JmiException, "AbstractAssociation", for an abstract association. For the reflective JMI interfaces, JmiException "AbstractAssociation" is thrown for refAddLink on an abstract association and for refSetValue on a reference on an abstract association. X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Association Generalization Proposal In-Reply-To: Message from "Baisley, Donald E" of "Fri, 30 Nov 2001 20:37:58 CST." Mime-Version: 1.0 Date: Mon, 03 Dec 2001 12:54:21 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: #>U!!?Un!!61Zd9O71!! Don, My comments on your proposal are inline ... -- Steve > Association Generalization for MOF 1.5 > > Here is a detailed proposal for adding association generalization to > MOF > 1.5. This proposal does not address reference redefinition or > overriding. > I hope this proposal provides sufficient detail so that Steve > Crawley can > make changes to the specification. Please send your comments. > > Regards, > Don > > Changes to Model > > Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35] > AssociationMustBeRootAndLeaf, and [C-36] > AssociationsCannotBeAbstract. > > Add a nonabstract association from AssociationEnd to AssociationEnd > called > RedefinesEnd. One end is called redefinedEnd, has a reference by > the same > name, and has multiplicity *. The other end is called > redefiningEnd, has no > reference, and has multiplicity *. This association is used to > correlate an > end with its corresponding end in a supertype association. Actually, I think that the following constraint says that a RedefinesEnd link must exist between an AssociationEnd in the subtype and one in EVERY immediate supertype Association. [Which is correct, IMO.] > Add new constraint: SupertypeEndsAreRedefined > Evaluation policy: Deferred. > Description: An end redefines each supertype's end. > Context Association > Inv: self.supertypes.contents->select(gc | > gc.oclIsTypeOf(AssociationEnd))-> > forAll(ge : AssociationEnd | > self.contents->select(sc | > sc.oclIsTypeOf(AssociationEnd))-> > forAll(se : AssociationEnd | > se.redefinedEnd->exists(re | re = > ge) > and se.otherEnd.redefinedEnd->exists(ore > | ore = > ge.otherEnd))) > > Add new constraint: RedefinedEndBelongsToSupertype > Evaluation policy: Immediate. > Description: Each redefinedEnd belongs to a supertype. > Context AssociationEnd > Inv: self.container.oclAsType(Association).supertypes.contents-> > includesAll(self.redefinedEnd) I think this precludes multiple supertypes. Is this intentional? There also needs to be a constraint on types of an AssociationEnd and any AssociationEnds that they redefine. I think that they need to be the same type ... otherwise your Abstract Mapping spec breaks. > By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an > immediate constraint, but it should be deferred. Otherwise, there > is no > valid way to create an Association. Alternatively, change the OCL to say " ... size <= 2". > Changes to Abstract Mapping > > Add the following to Core Association Semantics. > > A link cannot be directly created for an Association with isAbstract > set to > true, but can be added indirectly as a link of a subtype > association. > > Where a generalization exists between two associations, each link of > the > subtype association is logically a link of the supertype association > - for > each subtype Link there implicitly exists a supertype Link > (or > depending on which subtype end redefines which supertype > end). Your use of terms / phrases like "logically" and "there implicitly exists" makes this unclear. IMO, you need to ground the definition of association generalization in a simple mathematical definition; e.g. using sets, like MOF 1.3/1.4 does. > Removing a link from a Link_Set causes the logical link to be removed from > each subtype association's Link_Set. Removing a link from a Link_Set also > causes the logical link to be removed from each supertype association's > Link_Set where the logical link is not otherwise present in the supertype > Link_Set based on either having been put explicitly into the supertype > Link_Set (where not abstract) or on being a link of some other subtype of > the supertype. The net effect is that a Link_Set is a union of links put > explicitly into the Link_Set with the Link_Sets of all subtypes. The above does not belong in the Abstract Mapping. The semantics of creating and deleting links is technology specific. Besides, this semantic for link deletion seems broken to me. At the most fundamental level, it should not depend on how the link was created. A better way to define this would be to say that there are links in the supertype association and links in the subtype association, and that what you see when you query is the union of these two sets (or more). This begs the question, should you be able to query just the subtype links? > Changes to IDL Mapping > > In the template for associations, no add or modify operations are > generated > for an abstract association. > > In the template for references, no set, add, or modify operations > are > generated for an abstract association. > > Operations on RefObject for setting, adding, and modifying, and > operations > on RefAssociation for adding and modifying raise a new MofError, > "Abstract > Association", for creating a link of an abstract association. A lot more needs to be said about the semantics of operations on a supertype and subtype association. > Changes to JMI > > In the template for associations, no add operation is generated for > an > abstract association. > > In the template for references, no set operation is generated for an > abstract association. Also, the add and set operations on a > reference > collection throws a new JmiException, "AbstractAssociation", for an > abstract > association. > > For the reflective JMI interfaces, JmiException > "AbstractAssociation" is > thrown for refAddLink on an abstract association and for refSetValue > on a > reference on an abstract association. Ditto. -- Steve From: "Pete Rivett" To: Subject: RE: Association Generalization Proposal Date: Mon, 3 Dec 2001 09:58:44 -0000 Message-ID: <003201c17be1$18be5770$0100007f@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /V)!!-#Me9> To: "Pete Rivett" , References: <003201c17be1$18be5770$0100007f@CHIMAY> Subject: Re: Association Generalization Proposal Date: Mon, 3 Dec 2001 13:20:43 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: gRT!!6&b!!c@1e9@lTd9 Hi, I agree with Pete. It seems to have a big impact on existing implementations. We should rather wait for UML 2.0 Infrastructure and MOF 2.0 instead of doing it in MOF 1.5. Martin ----- Original Message ----- From: "Pete Rivett" To: Sent: Monday, December 03, 2001 10:58 AM Subject: RE: Association Generalization Proposal > I enclose some detailed comments and questions on the proposal: it seems > that the impact in terms of the document (and implementations!) is much > greater than I had expected with this approach; and there seem still to be > areas that need to be fully worked out. > > I also attempt to document the original problem statement (which I have not > seen written yet) and outline a simpler way (I hope!) of addressing it > without the need for static association generalizations and the related > issues. This is not fully fleshed out yet but I didn't want to spend too > much time on it without getting some feedback. > > The bottom line, though, is comment a) below (which applies to both > proposals) - are we (MOF) or anyone else going to bother to apply this to > their metamodels prior to UML/MOF2? This is in terms of both implementation > cost for the vendors and the knock-on effect of the changes to core > (meta)metamodels. We should also be aware of the significant time-lag in the > trickle-through of specification versions: 4 months after its adoption I'm > not aware of any OMG submission or RTF that has even started a move to MOF > 1.4. > > ------------ > > Specific comments on the proposal: > > a) It would seem incumbent to state how the new capability is applied to > the MOF Model itself: which Associations are to be abstract and which new > subAssociations are to be added? The classic case anywhere for applying this > has go to be Contains. If MOF's not going to use it then why do we think > anyone else would (prior to UML/MOF 2)? > > b) The proposal does not address references related to redefined > AssociationEnds: how they are defined and/or constrained to prevent > implicit/accidental redefinition. > > c) We had quite a discussion about the interpretation of multiple > inheritance and I don't think the detail of the proposal really covers the > issues nor provides the abstract semantics (in terms of links referring to > associations) discussed. The assumption in the semantics is that it is the > generalization that are added to existing associations. Rather then a common > specialization being added to several existing associations (in which case > the link set is presumably the intersection of the link sets of the parent > associations). I must say that multiple inheritance does not seem to be > required to address the original problem. > > d) Because implementations have to remember whether or not a link was > created at the super-association level and there's no interface provided for > making this known, this makes certain operations non-predictable. Also, > what's the impact of explicitly adding a link at the parent level when it's > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. > > If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. > > Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. > From: "Iyengar, Sridhar" To: Martin Matula , Pete Rivett , mof-rtf@omg.org Subject: RE: Association Generalization Proposal Date: Mon, 3 Dec 2001 08:21:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: D]S!!j5Ge99[,!!#NNe9 Pete Thanks for the detailed comments. If the impact on existing implementations is non trivial - of course the RTF should defer this work. Don proposed a resolution because this issue bubbled to the top for the RTF to consider. I encourage RTF members to begin tackling the other issues on the table as well. Don making the concrete proposal is helping us decide on next steps. Let us make a go/no-go decision at the RTF call. Pete said > We should also be aware of the significant time-lag in the > trickle-through of specification versions: 4 months after > its adoption I'm not aware of any OMG submission or RTF that has even > started a move to MOF 1.4. Pete : The MOF 1.4 Board of directors vote only happened last month Dublin. But your point about time lag from spec adoption to implementation is of course valid. I expect that as a result of JMI work underway at several companies implementing MOF, we should expect implementations in months not quarters ... we shall see! The first user of MOF 1.4 (as usual) is MOF 1.4 and of JMI. UML 1.5 and future revisions of CWM etc. are expected to use MOF 1.4 (but that decision will be made by respective RTF's, RFPs etc.). Until Dublin that decision (to use MOF 1.4) was premature. Sridhar ------------------------------------------------------------------------ ---- Sridhar Iyengar Unisys Fellow, Director of Advanced Technology 25725, Jeronimo Road Mission Viejo, CA 92691 E-mail : Sridhar.iyengar2@unisys.com Phone : 949-380-5692 Fax : 949-380-6632 ------------------------------------------------------------------------ -------------- > -----Original Message----- > From: Martin Matula [mailto:martin.matula@sun.com] > Sent: Monday, December 03, 2001 4:21 AM > To: Pete Rivett; mof-rtf@omg.org > Subject: Re: Association Generalization Proposal > > > Hi, > I agree with Pete. > It seems to have a big impact on existing implementations. We > should rather > wait for UML 2.0 Infrastructure and MOF 2.0 instead of doing > it in MOF 1.5. > Martin > > ----- Original Message ----- > From: "Pete Rivett" > To: > Sent: Monday, December 03, 2001 10:58 AM > Subject: RE: Association Generalization Proposal > > > > I enclose some detailed comments and questions on the > proposal: it seems > > that the impact in terms of the document (and > implementations!) is much > > greater than I had expected with this approach; and there > seem still to be > > areas that need to be fully worked out. > > > > I also attempt to document the original problem statement > (which I have > not > > seen written yet) and outline a simpler way (I hope!) of > addressing it > > without the need for static association generalizations and > the related > > issues. This is not fully fleshed out yet but I didn't want > to spend too > > much time on it without getting some feedback. > > > > The bottom line, though, is comment a) below (which applies to both > > proposals) - are we (MOF) or anyone else going to bother to > apply this to > > their metamodels prior to UML/MOF2? This is in terms of both > implementation > > cost for the vendors and the knock-on effect of the changes to core > > (meta)metamodels. We should also be aware of the > significant time-lag in > the > > trickle-through of specification versions: 4 months after > its adoption I'm > > not aware of any OMG submission or RTF that has even > started a move to MOF > > 1.4. > > > > ------------ > > > > Specific comments on the proposal: > > > > a) It would seem incumbent to state how the new capability > is applied to > > the MOF Model itself: which Associations are to be abstract > and which new > > subAssociations are to be added? The classic case anywhere > for applying > this > > has go to be Contains. If MOF's not going to use it then > why do we think > > anyone else would (prior to UML/MOF 2)? > > > > b) The proposal does not address references related to redefined > > AssociationEnds: how they are defined and/or constrained to prevent > > implicit/accidental redefinition. > > > > c) We had quite a discussion about the interpretation of multiple > > inheritance and I don't think the detail of the proposal > really covers the > > issues nor provides the abstract semantics (in terms of > links referring to > > associations) discussed. The assumption in the semantics is > that it is the > > generalization that are added to existing associations. > Rather then a > common > > specialization being added to several existing associations > (in which case > > the link set is presumably the intersection of the link > sets of the parent > > associations). I must say that multiple inheritance does > not seem to be > > required to address the original problem. > > > > d) Because implementations have to remember whether or not > a link was > > created at the super-association level and there's no > interface provided > for > > making this known, this makes certain operations > non-predictable. Also, > > what's the impact of explicitly adding a link at the parent > level when > it's > > > > > > The information contained in this email and any attached files are > confidential and intended solely for the addressee(s). The > e-mail may be > legally privileged or prohibited from disclosure and unauthorised use. > > > > If you are not the named addressee you may not use, copy or > disclose this > information to any other person. If you received this > message in error > please notify the sender immediately. > > > > Any views or opinions presented here may be solely those of > the originator > and do not necessarily reflect those of the Company. > > > Reply-To: "Kerry Raymond" From: "Kerry Raymond" To: "Iyengar, Sridhar" , "Martin Matula" , "Pete Rivett" , References: Subject: Re: Association Generalization Proposal Date: Tue, 4 Dec 2001 10:22:07 +1000 Organization: DSTC Pty Ltd MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \FCe9^==!!Z-M!!FGl!! > If the impact on existing implementations is non trivial - of course the RTF > should defer this work. Don proposed a resolution because this issue > bubbled to the top for the RTF to consider. I encourage RTF members to > begin tackling the other issues on the table as well. Don making the > concrete proposal is helping us decide on next steps. Let us make a > go/no-go decision at the RTF call. While I am generally in favour of abstract, multiply-inheriting associations etc, I have some sympathy with Pete's comments about needing to revise the MOF's own model to use generalised associations, especially for containment. It would certainly give us a cleaner MOF and I'd be all for it. But I think the extent of change is way way out of scope for RTF and would be best incorporated in MOF 2.0. However, that's not saying that the RTF should stop discussing this (or any other of the "top" issues), because these issues have to get worked through by people with a good technical grasp of what they are doing, and frankly that will more likely in an RTF discussion than in a RFP team (where politics too frequently dominates the agenda). I guess what I'm saying is lets use the RTF as a forum to think through issues like this in some detail, but then take the results of those discussions and put them in our separate/joint MOF2.0 submissions. Kerry From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: Association Generalization Proposal -- Round 2 Date: Mon, 3 Dec 2001 20:28:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17C6B.618F163A" X-UIDL: ;:T!!B)/!!-Zcd9kj'e9 Hi all, Thanks for the comments. See responses to Steve Crawley and Pete Rivett below. An updated proposal is attached. Don ------------------------------------- Steve's comments: >Actually, I think that the following constraint says that a RedefinesEnd >link must exist between an AssociationEnd in the subtype and one in >EVERY immediate supertype Association. [Which is correct, IMO.] I will reword the description. I think the OCL is okay, but the description was not fully clear. >I think this precludes multiple supertypes. Is this intentional? I don't see the preclusion of multiple supertypes. RedefinedEnd is multivalued. >There also needs to be a constraint on types of an AssociationEnd and >any AssociationEnds that they redefine. I think that they need to be >the same type ... otherwise your Abstract Mapping spec breaks. Good point. I have added another constraint requiring a redefined end to have the same type or a supertype. >Your use of terms / phrases like "logically" and "there implicitly >exists" makes this unclear. IMO, you need to ground the definition >of >association generalization in a simple mathematical definition; e.g. >using sets, like MOF 1.3/1.4 does. I agree. I have rewritten that stuff in terms of Link and Link_Set (like the rest of that section). >The above does not belong in the Abstract Mapping. The semantics of >creating and deleting links is technology specific. Are you saying that everything about adding and removing does not go in chapter 4 and that chapter 4 should just describe a valid state? >Besides, this semantic for link deletion seems broken to me. At the >most fundamental level, it should not depend on how the link was >created. I agree. I have changed the description so that there is no dependency on how a link is created. >A better way to define this would be to say that there are links in >the supertype association and links in the subtype association, and >that what you see when you query is the union of these two sets (or >more). This begs the question, should you be able to query just the >subtype links? Please see the new description. >A lot more needs to be said about the semantics of operations on a supertype >and subtype association. Can you suggest what details are needed? ------------------------------------- Pete's comments: > a) It would seem incumbent to state how the new capability is applied to >the MOF Model itself: which Associations are to be abstract and which new >subAssociations are to be added? The classic case anywhere for applying this >has go to be Contains. If MOF's not going to use it then why do we think >anyone else would (prior to UML/MOF 2)? The proposal does not specify how association generalization is used in MOF Model, but a section is added recommending how it might be used. > b) The proposal does not address references related to redefined >AssociationEnds: how they are defined and/or constrained to prevent >implicit/accidental redefinition. The proposal does not address reference redefinition, so all of the current constraints on naming references still hold -- nothing new here. > c) We had quite a discussion about the interpretation of multiple >inheritance and I don't think the detail of the proposal really >covers the >issues nor provides the abstract semantics (in terms of links >referring to >associations) discussed. The assumption in the semantics is that it >is the >generalization that are added to existing associations. Rather then a common >specialization being added to several existing associations (in which >case >the link set is presumably the intersection of the link sets of the >parent >associations). I must say that multiple inheritance does not seem to >be >required to address the original problem. Multiple inheritance does not imply any sort of intersection. An association M with supertypes A and B does not necessarily contain all links in the intersection of A and B. > d) Because implementations have to remember whether or not a link was >created at the super-association level and there's no interface provided for >making this known, this makes certain operations non-predictable. Also, >what's the impact of explicitly adding a link at the parent level when it's >already been added at the subAssociation level? And vice-versa? Is this >constrained by multiplicity? (e.g. if an AssociationEnd has multiplicity of >1 then can a link be added for both parent and child associations?) >In fact I'm concerned about non-abstract super-Associations as a concept. >They seem to add more complications than they are worth and are not >justified by (what I see as) the problem statement (see below). I agree with you. I have changed the proposal to ..... > e) Constraints are needed to the effect that sub-AssociationEnds are >defined on types compatible with their parent AssociationEnds. And >that the >multiplicities are also 'compatible' (I think you had this in the >original >proposal under 'well-formedness rules'). Agreed. I have added constraints. > f) Need to relax the constraint on composites (section 4.10.2) since an >instance may have more than one composite owner if one composite is a >generalization of the other. The composition rule requires that an object have no more than one composite owner. The rule does not limit the number of associations through which that ownership might be shown. If a class owns an attribute through a composition called "attribute", there is nothing wrong with it owning the same attribute through another composition called "containedElement". This is exactly what happens when "attribute" specializes "containedElement". > g) Need to constrain an Association to be in the same Package as its >subAssociations (unlike class inheritance). I don't see the point of such a constraint. > However if we have P1.q1 = Q1 and P1.q2 = Q1 then P1.q will be {Q1} >and C.allLinks = {(P1, Q1)} only - which seems to break the multiplicity >constraint (2..2) on C.q despite the fact that there are 2 links. If your father and your mother are the same person, how many parents do you have? You have one father link, one mother link, and together, they make one parent link. It's a matter of perspective. From the parent perspective, they are the same link. >Even if >that is somehow allowed what happens if Q2 is then explicitly added >to P1.q? >I guess this will not break the constraint since P1.q = {Q1, Q2} >though >there are really 3 links present? In some senses the generalized >Link_set is >acting as a bag behind the scenes but this is not really followed >through >into a semantic abstract model beyond the need to somehow remember >whether >the link was set on the superAssociation or not. I agree that this is problematic. Let's forget about remembering whether a link is added to q. The add is simply redundant. It is treated just as if it had been previously added. > i) I think as a set of changes to the document it still needs the >narrative/example similar to that which was previously presented. I agree. Perhaps we can use the same example, but cut down to not show reference redefinition. > And the Issue documentation needs the problem statement added (see below). Agreed. I have added it. > j) Need to address the impact on XMI (e.g. which of the links are >serialized? especially when they may have been set for both the >parent and >the sub-Associations? and how should a consumer cope with what >otherwise >would be multiplicity violations when both are set?) Agree. I have added a section to the proposal. > k) Need to address generalization applied to derived associations - >semantics and constraints. I don't know of any special semantics or constraints. All of the normal rules apply. > l) Does not address non-changeable association ends e.g. can a >superAssociation be updateable if subAssociation is not or >vice-versa? I don't see a need for a special rule or restriction here. [] AssociationGeneralizationForMOF.doc From: "Iyengar, Sridhar" To: Kerry Raymond , "Iyengar, Sridhar" , Martin Matula , Pete Rivett , mof-rtf@omg.org Subject: RE: Association Generalization Proposal Date: Mon, 3 Dec 2001 20:38:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Dn/e92Q0e9*'Le9EP]!! Kerry Agree discussion needs to continue - but we do need to timebox the discussion so the RTF can go about its work of resolving issues on the table that aren't necessarily as controversial. Also just because MOF 1.5 supports Association Generalization as a mechanism does not mean - we have to use it in defining MOF 1.5 itself! This is an important distinction. Note that MOF 1.3 supports many CORBA data types but many metamodels chose not to use most of them! Last but not least, I dont see a lot of benefit in discussing this as part of the RTF if we decide this is a MOF 2.0 issue - we should just defer it. Let the submission teams handle it at that time and leave the RTF to solve the 'active' RTF issues! It would be better to have those discussions on the MOF2 mailing list so we confuse people less! Get your comments in so we can be ready Thursday to decide, Sridhar ------------------------------------------------------------------------ ---- Sridhar Iyengar Unisys Fellow, Director of Advanced Technology 25725, Jeronimo Road Mission Viejo, CA 92691 E-mail : Sridhar.iyengar2@unisys.com Phone : 949-380-5692 Fax : 949-380-6632 ------------------------------------------------------------------------ -------------- > -----Original Message----- > From: Kerry Raymond [mailto:kerry@dstc.edu.au] > Sent: Monday, December 03, 2001 4:22 PM > To: Iyengar, Sridhar; Martin Matula; Pete Rivett; mof-rtf@omg.org > Subject: Re: Association Generalization Proposal > > > > If the impact on existing implementations is non trivial - > of course the > RTF > > should defer this work. Don propsed a resolution because > this issue > > bubbled to the top for the RTF to consider. I encourage > RTF members to > > begin tackling the other issues on the table as well. Don > making the > > concrete proposal is helping us decide on next steps. Let us make a > > go/no-go decision at the RTF call. > > While I am generally in favour of abstract, > multiply-inheriting associations > etc, I have some sympathy with Pete's comments about needing > to revise the > MOF's own model to use generalised associations, especially > for containment. > It would certainly give us a cleaner MOF and I'd be all for > it. But I think > the extent of change is way way out of scope for RTF and would be best > incorporated in MOF 2.0. > > However, that's not saying that the RTF should stop > discussing this (or any > other of the "top" issues), because these issues have to get > worked through > by people with a good technical grasp of what they are doing, > and frankly > that will more likely in an RTF discussion than in a RFP team > (where politics > too frequently dominates the agenda). > > I guess what I'm saying is lets use the RTF as a forum to > think through > issues like this in some detail, but then take the results of those > discussions and put them in our separate/joint MOF2.0 submissions. > > Kerry > > From: "Pete Rivett" To: Subject: Association Generalization - problem statement and alternative Date: Wed, 5 Dec 2001 14:43:52 -0000 Message-ID: <008b01c17d9b$43358b70$8119fea9@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: />>!!1Vnd9al_d9aLQd9 So far there have been a few replies to my email which have focused on my comments on Don's proposal. Since it was a long email people possibly missed that I had also included at the end a statement of the original problem (as I understood it) and an outline of a more basic AssociationQuery capability that is restricted to that problem. Which I include again below. I'm not necessarily pushing this alternative and I'm still open-minded about Association Generalizations (I have not been through Don's latest Round 2 revision yet). However I think it's important to understand what they give us compared to a more basic capability: I imagine there must be other aspects of the problem (or related ones) that I have not recognized. So even if people don't think the Query capability is sensible I think it's worth fleshing out the problem statement to represent what we're really trying to address. And this will give us something to review proposals against. And help justify the change to reviewers like the Architecture Board! Pete ------------ Problem statement and alternative My recollection of the problem statement was the need to: 1) define concretely which associations are permitted (without the need for OCL constraints); 2) permit 'association queries' at the abstract level over the concrete associations defined on the subclasses. So taking the MOF Model itself as an example it should be possible to define explicit containment Associations (as defined in the containment matrix) between, for example: Class and Feature, Class and Constraint, Package and Class, Package and Constraint etc. But then permit 'ownedElements' and 'owner' to be applied to any ModelElement. Ideally in such a way that adding a new concrete containment association should not require changing the query. Association Generalization is one way of addressing the problem. But which has many issues (see above). And, I think, goes way beyond the problem statement which really just seems to need an 'association query' capability. I think we should seriously look at other options. For example, by making the association specialization purely a query/navigation-time artifact based on matching the names of the association ends and classes. This is similar to the notion in the proposal of "a Link_Set is a union of the Link_Sets of all subtypes". Except that it avoids most of the problems caused by a static structural definition that is a first-class Association in all respects. To provide the querying transparently (so that is seen to a client as a normal association) let's introduce a subclass of Association called AssociationQuery (which must be marked as 'derived' and with AssociationEnds which must have multiplicity of * and be not changeable). So let's take MOF Containment as an example and introduce explicit (normal) Associations for the permitted containments: Association 'ClassContainsFeature' with ends 'container' (of type Class) and 'containedElement' (of type Feature) Association 'ClassContainsConstraint' with ends 'container' (of type Class) and 'containedElement' (of type Constraint) Association 'PackageContainsConstraint' with ends 'container' (of type Package) and 'containedElement' (of type Constraint) We'd then define: AssociationQuery 'Contains' with ends 'container' (of Type ModelElement) and 'containedElement' (also of Type ModelElement). Contains.allLinks would be defined to return the union of (ClassContainsFeature.allLinks, ClassContainsConstraint.allLinks, PackageContainsConstraint.allLinks etc.). i.e. allLinks for each Association with association ends having the same names and compatible types as Contains. Contains.containedElement (m:ModelElement) would be defined to return the union of A.containedElement(m) for each Association A with association ends having the same names as Contains and 'container' associationEnd being a subtype of the actual class of m. So if the actual parameter m is an instance of Class then Contains.containedElement(m) would be the Union of (ClassContainsFeature.containedElement(m), ClassContainsConstraint.containedElement(m)) but would not include PackageContainsConstraint since its 'container' AssociationEnd has type Package which is not a subtype of Class. Here are some semi-formal strawman definitions: Define helper function: AssociationQuery.scopedAssociations() = select Ass from self.owner.findElementsByType("Model.Association", true) // Query all associations in the package where Ass.associationEnd->name = self.associationEnd->name // Both association end names match and Ass.associationEnds->type->allSupertypes() includes Ass.associationEnds->type; // Association end types are subtypes (Note this is over-simplified - each association end should be separately tested) Consider AssociationQuery GA with AssociationEnds p:P and q:Q. We can then define the standard association operations: A.allLinks = Union(SA.allLinks where SA in scopedAssociations(A)) PSet A.p(Q q) = Union(SA.refQuery("p", q) where SA in scopedAssociations(A) and P in (SA.associationEnd["p"].type.allSuperTypes()) QSet A.q(P p) = Union(SA.refQuery("q", p) where SA in scopedAssociations(A) and Q in (SA.associationEnd["q"].type.allSuperTypes()) And similarly for references if defined. ------ Well, what do people think? Is this any better? After giving it a good bash is the problem worth pursuing at all given the UML/MOF2 context? ------------ Problem statement and alternative My recollection of the problem statement was the need to: 1) define concretely which associations are permitted (without the need for OCL constraints); 2) permit 'association queries' at the abstract level over the concrete associations defined on the subclasses. So taking the MOF Model itself as an example it should be possible to define explicit containment Associations (as defined in the containment matrix) between, for example: Class and Feature, Class and Constraint, Package and Class, Package and Constraint etc. But then permit 'ownedElements' and 'owner' to be applied to any ModelElement. Ideally in such a way that adding a new concrete containment association should not require changing the query. Association Generalization is one way of addressing the problem. But which has many issues (see above). And, I think, goes way beyond the problem statement which really just seems to need an 'association query' capability. I think we should seriously look at other options. For example, by making the association specialization purely a query/navigation-time artifact based on matching the names of the association ends and classes. This is similar to the notion in the proposal of "a Link_Set is a union of the Link_Sets of all subtypes". Except that it avoids most of the problems caused by a static structural definition that is a first-class Association in all respects. To provide the querying transparently (so that is seen to a client as a normal association) let's introduce a subclass of Association called AssociationQuery (which must be marked as 'derived' and with AssociationEnds which must have multiplicity of * and be not changeable). So let's take MOF Containment as an example and introduce explicit (normal) Associations for the permitted containments: Association 'ClassContainsFeature' with ends 'container' (of type Class) and 'containedElement' (of type Feature) Association 'ClassContainsConstraint' with ends 'container' (of type Class) and 'containedElement' (of type Constraint) Association 'PackageContainsConstraint' with ends 'container' (of type Package) and 'containedElement' (of type Constraint) We'd then define: AssociationQuery 'Contains' with ends 'container' (of Type ModelElement) and 'containedElement' (also of Type ModelElement). Contains.allLinks would be defined to return the union of (ClassContainsFeature.allLinks, ClassContainsConstraint.allLinks, PackageContainsConstraint.allLinks etc.). i.e. allLinks for each Association with association ends having the same names and compatible types as Contains. Contains.containedElement (m:ModelElement) would be defined to return the union of A.containedElement(m) for each Association A with association ends having the same names as Contains and 'container' associationEnd being a subtype of the actual class of m. So if the actual parameter m is an instance of Class then Contains.containedElement(m) would be the Union of (ClassContainsFeature.containedElement(m), ClassContainsConstraint.containedElement(m)) but would not include PackageContainsConstraint since its 'container' AssociationEnd has type Package which is not a subtype of Class. Here are some semi-formal strawman definitions: Define helper function: AssociationQuery.scopedAssociations() = select Ass from self.owner.findElementsByType("Model.Association", true) // Query all associations in the package where Ass.associationEnd->name = self.associationEnd->name // Both association end names match and Ass.associationEnds->type->allSupertypes() includes Ass.associationEnds->type; // Association end types are subtypes (Note this is over-simplified - each association end should be separately tested) Consider AssociationQuery GA with AssociationEnds p:P and q:Q. We can then define the standard association operations: A.allLinks = Union(SA.allLinks where SA in scopedAssociations(A)) PSet A.p(Q q) = Union(SA.refQuery("p", q) where SA in scopedAssociations(A) and P in (SA.associationEnd["p"].type.allSuperTypes()) QSet A.q(P p) = Union(SA.refQuery("q", p) where SA in scopedAssociations(A) and Q in (SA.associationEnd["q"].type.allSuperTypes()) And similarly for references if defined. ------ Well, what do people think? Is this any better? After giving it a good bash is the problem worth pursuing at all given the UML/MOF2 context? The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company.