Issue 5695: Invalid explicit references for some 'association generalizations' in the (cwm-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: This applies to CWM 1.1 (and also CWM 1.0). Sun MDR user Vincent Lombart spotted that he was getting the same association exported twice, which I tracked down to the following problem in the metamodel. There should be no explicit association between ClassifierMap and TransformationMap: the diagram in the CWM spec just documents the fact that the inherited ownedElement association is used to link these classes. The CWM XMI file is produced by the Unisys Rose integration which explicitly ignores such associations (signalled by '/' on the association ends - normal derived associations have '/' on the association name). This is used in several places e.g. in Relational model to show that Column and ColumnSet are linked using the owner-feature association. However in the ClassifierMap case there are also corresponding references explicitly defined as pseudo-attributes on Classifier and TransformationMap which has caused the references erroneously to be generated into the XMI file. On further investigation, the following inherited associations have superfluous references: XML:ElementType <-> XML:Schema XML:ElementType <-> XML:Attribute Transformation:TransformationMap <-> Transformation:ClasifierMap Transformation:TransformationActivity <-> TransformationStep (in this case the references are called 'step' and 'activity') BusinessNomenclature:Taxonomy <-> Concept BusinessNomenclature:Glossary <-> Term BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one reference is called just 'domain') Proposed resolution: Delete the above references/pseudo-attributes (with stereotype of <<reference>> though this is hidden on the diagram). Resolution: Revised Text: Actions taken: October 23, 2002: received issue Discussion: End of Annotations:===== From: "Pete Rivett" To: Cc: Subject: Invalid explicit references for some 'association generalizations' in the metamodel Date: Tue, 22 Oct 2002 23:44:29 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal This applies to CWM 1.1 (and also CWM 1.0). Sun MDR user Vincent Lombart spotted that he was getting the same association exported twice, which I tracked down to the following problem in the metamodel. There should be no explicit association between ClassifierMap and TransformationMap: the diagram in the CWM spec just documents the fact that the inherited ownedElement association is used to link these classes. The CWM XMI file is produced by the Unisys Rose integration which explicitly ignores such associations (signalled by '/' on the association ends - normal derived associations have '/' on the association name). This is used in several places e.g. in Relational model to show that Column and ColumnSet are linked using the owner-feature association. However in the ClassifierMap case there are also corresponding references explicitly defined as pseudo-attributes on Classifier and TransformationMap which has caused the references erroneously to be generated into the XMI file. On further investigation, the following inherited associations have superfluous references: XML:ElementType <-> XML:Schema XML:ElementType <-> XML:Attribute Transformation:TransformationMap <-> Transformation:ClasifierMap Transformation:TransformationActivity <-> TransformationStep (in this case the references are called 'step' and 'activity') BusinessNomenclature:Taxonomy <-> Concept BusinessNomenclature:Glossary <-> Term BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one reference is called just 'domain') Proposed resolution: Delete the above references/pseudo-attributes (with stereotype of <> though this is hidden on the diagram). Pete Rivett (pete.rivett@adaptive.com) Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com 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: "Tolbert, Doug M" To: Pete Rivett Cc: cwm-rtf@omg.org Subject: RE: Invalid explicit references for some 'association generalizat ions' in the metamodel Date: Tue, 22 Oct 2002 17:56:37 -0500 X-Mailer: Internet Mail Service (5.5.2656.59) Pete, I recall that Dan's intent for these was that the reference was a renaming of the association end that implemented the reference. Have I got this right, Dan? Doug -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, October 22, 2002 3:44 PM To: issues@omg.org Cc: cwm-rtf@omg.org Subject: Invalid explicit references for some 'association generalizations' in the metamodel This applies to CWM 1.1 (and also CWM 1.0). Sun MDR user Vincent Lombart spotted that he was getting the same association exported twice, which I tracked down to the following problem in the metamodel. There should be no explicit association between ClassifierMap and TransformationMap: the diagram in the CWM spec just documents the fact that the inherited ownedElement association is used to link these classes. The CWM XMI file is produced by the Unisys Rose integration which explicitly ignores such associations (signalled by '/' on the association ends - normal derived associations have '/' on the association name). This is used in several places e.g. in Relational model to show that Column and ColumnSet are linked using the owner-feature association. However in the ClassifierMap case there are also corresponding references explicitly defined as pseudo-attributes on Classifier and TransformationMap which has caused the references erroneously to be generated into the XMI file. On further investigation, the following inherited associations have superfluous references: XML:ElementType <-> XML:Schema XML:ElementType <-> XML:Attribute Transformation:TransformationMap <-> Transformation:ClasifierMap Transformation:TransformationActivity <-> TransformationStep (in this case the references are called 'step' and 'activity') BusinessNomenclature:Taxonomy <-> Concept BusinessNomenclature:Glossary <-> Term BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one reference is called just 'domain') Proposed resolution: Delete the above references/pseudo-attributes (with stereotype of <> though this is hidden on the diagram). Pete Rivett (pete.rivett@adaptive.com) Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com 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: "Pete Rivett" To: "'Tolbert, Doug M'" Cc: Subject: RE: Invalid explicit references for some 'association generalizations' in the metamodel Date: Wed, 23 Oct 2002 00:10:57 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Hi Doug, Renaming/redefinition might have been the desire but it's not a capability supported by MOF (prior to MOF 2.0 - and you know the troubles we're having trying to define it there!). And we don't attempt to do renaming like this in other models such as Relational. The effect (at least with the Sun repository) is to get both references (inherited and 'renamed') exported (i.e. the same information is output twice). I'm afraid we've got little choice but to live with the limitations of MOF 1.x and retain the inherited names (deleting the references). One other option might be to make the *Association* derived in which case it won't be exported and new names can be introduced. However there's nothing that will automatically tie this to the inherited association (we can include OCL for the derivation in the spec/model but implementations, even those like ours that do process OCL, will generally ignore for implementing the derivation). Pete > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: 22 October 2002 23:57 > To: Pete Rivett > Cc: cwm-rtf@omg.org > Subject: RE: Invalid explicit references for some 'association > generalizations' in the metamodel > > > Pete, > > I recall that Dan's intent for these was that the reference > was a renaming > of the association end that implemented the reference. Have > I got this > right, Dan? > > Doug > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Tuesday, October 22, 2002 3:44 PM > To: issues@omg.org > Cc: cwm-rtf@omg.org > Subject: Invalid explicit references for some 'association > generalizations' in the metamodel > > > This applies to CWM 1.1 (and also CWM 1.0). > Sun MDR user Vincent Lombart spotted that he was getting the same > association exported twice, which I tracked down to the > following problem in > the metamodel. > > There should be no explicit association between ClassifierMap and > TransformationMap: the diagram in the CWM spec just documents > the fact that > the inherited ownedElement association is used to link these classes. > The CWM XMI file is produced by the Unisys Rose integration > which explicitly > ignores such associations (signalled by '/' on the > association ends - normal > derived associations have '/' on the association name). This > is used in > several places e.g. in Relational model to show that Column > and ColumnSet > are linked using the owner-feature association. > > However in the ClassifierMap case there are also > corresponding references > explicitly defined as pseudo-attributes on Classifier and > TransformationMap > which has caused the references erroneously to be generated > into the XMI > file. > > On further investigation, the following inherited associations have > superfluous references: > > XML:ElementType <-> XML:Schema > XML:ElementType <-> XML:Attribute > Transformation:TransformationMap <-> Transformation:ClasifierMap > Transformation:TransformationActivity <-> > TransformationStep (in this case > the references are called 'step' and 'activity') > BusinessNomenclature:Taxonomy <-> Concept > BusinessNomenclature:Glossary <-> Term > BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one > reference is called just 'domain') > > Proposed resolution: > Delete the above references/pseudo-attributes (with stereotype of > <> though this is hidden on the diagram). > > > > Pete Rivett (pete.rivett@adaptive.com) > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > 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. 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