Issue 2290: ElementOwnership (uml2-superstructure-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone declares ElementOwnership as an AssociationClass. This appears to be a violation of MOF compliance, since the MOF meta-meta-model does not support the notion of an AssociationClass. Of course one could extrapolate AssociationClass from the MOF meta-meta-model since it does support both Association and Class, and one could also logically extrapolate a MOF-IDL and MOF-XML mapping for an extrapolated MOF AssociationClass. However, two architects might extrapolate these mappings in perfectly valid but different manners, since there is no standard mapping for a MOF AssociationClass. Apparently such an extrapolation has been performed in order to derive the IDL for the UML meta-model that concerns ElementOwnership, but doing this without a standard mapping seems dangerous. Resolution: Revised Text: Actions taken: January 5, 1999: received issue March 9, 2005: closed issue Discussion: UML 2 does not use AssociationClasses in the metamodel itself so this issue no longer applies. End of Annotations:===== Return-Path: X-Sender: dfrankel@pop.usit.net Date: Mon, 04 Jan 1999 23:40:22 -0800 To: uml-rtf@omg.org From: "David S. Frankel" Subject: ElementOwnership Cc: mof-rtf@omg.org In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone declares ElementOwnership as an AssociationClass. This appears to be a violation of MOF compliance, since the MOF meta-meta-model does not support the notion of an AssociationClass. Of course one could extrapolate AssociationClass from the MOF meta-meta-model since it does support both Association and Class, and one could also logically extrapolate a MOF-IDL and MOF-XML mapping for an extrapolated MOF AssociationClass. However, two architects might extrapolate these mappings in perfectly valid but different manners, since there is no standard mapping for a MOF AssociationClass. Apparently such an extrapolation has been performed in order to derive the IDL for the UML meta-model that concerns ElementOwnership, but doing this without a standard mapping seems dangerous. ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: From: "KOBRYN, Cris" To: "David S. Frankel" Cc: uml-rtf@omg.org, mof-rtf@omg.org Subject: RE: ElementOwnership Date: Thu, 7 Jan 1999 16:06:49 -0800 > In UML versions 1.1, 1.2, and 1.3 the class diagram for the > Core Backbone > declares ElementOwnership as an AssociationClass. This > appears to be a > violation of MOF compliance, since the MOF meta-meta-model > does not support > the notion of an AssociationClass. You are raising the question of whether the UML metamodel and the MOF meta-metamodel are aligned using a "strict" or "non-strict" metamodeling approach. As is explained in the UML Proposal Summary v. 1.1, Section 6.1 (OMG doc# ad/97-08-02), the UML and MOF metamodels are aligned using a non-strict approach. This section explains that the UML metamodel is an instance of the MOF meta-metamodel, but it is not necessarily the case that each model element of the UML metamodel is an instance of a meta-metamodel element in the MOF meta-metamodel. > Of course one could extrapolate AssociationClass from the MOF > meta-meta-model since it does support both Association and > Class, and one > could also logically extrapolate a MOF-IDL and MOF-XML mapping for > an > extrapolated MOF AssociationClass. However, two architects might > extrapolate these mappings in perfectly valid but different > manners, since > there is no standard mapping for a MOF AssociationClass. > Apparently such > an extrapolation has been performed in order to derive the > IDL for the UML > meta-model that concerns ElementOwnership, but doing this without a > standard mapping seems dangerous. Yes, the problem can be finessed with a mapping of the sort that you describe. Perhaps you better understand now why Sridhar and I have been stressing the importance of a more "strict" approach to our 4-layer metamodeling architecture. It is easy for excessive mappings to degenerate into architectural kludges. -- Cris Return-Path: X-Sender: dfrankel@pop.usit.net Date: Thu, 07 Jan 1999 21:03:10 -0800 To: "KOBRYN, Cris" From: "David S. Frankel" Subject: RE: ElementOwnership Cc: uml-rtf@omg.org, mof-rtf@omg.org Cris-- Thanks for the response and insight into the situation. I strongly agree with you and Sridhar on this one. The non-strict approach seems empty to me. What does it really mean to say that an entire meta-model is an instance of the meta-metamodel if it doesn't mean that each meta-model construct is an instance of a meta-meta-model construct? As far as I can tell it means nothing with any computational significance. --Dave At 04:06 PM 1/7/99 -0800, KOBRYN, Cris wrote: >> In UML versions 1.1, 1.2, and 1.3 the class diagram for the >> Core Backbone >> declares ElementOwnership as an AssociationClass. This >> appears to be a >> violation of MOF compliance, since the MOF meta-meta-model >> does not support >> the notion of an AssociationClass. > >You are raising the question of whether the UML metamodel and the MOF >meta-metamodel are aligned using a "strict" or "non-strict" >> metamodeling >approach. As is explained in the UML Proposal Summary v. 1.1, Section >> 6.1 >(OMG doc# ad/97-08-02), the UML and MOF metamodels are aligned using >> a >non-strict approach. > >This section explains that the UML metamodel is an instance of the >> MOF >meta-metamodel, but it is not necessarily the case that each model >> element >of the UML metamodel is an instance of a meta-metamodel element in >> the MOF >meta-metamodel. > >> Of course one could extrapolate AssociationClass from the MOF >> meta-meta-model since it does support both Association and >> Class, and one >> could also logically extrapolate a MOF-IDL and MOF-XML mapping for >> an >> extrapolated MOF AssociationClass. However, two architects might >> extrapolate these mappings in perfectly valid but different >> manners, since >> there is no standard mapping for a MOF AssociationClass. >> Apparently such >> an extrapolation has been performed in order to derive the >> IDL for the UML >> meta-model that concerns ElementOwnership, but doing this without a >> standard mapping seems dangerous. > >Yes, the problem can be finessed with a mapping of the sort that you >describe. > >Perhaps you better understand now why Sridhar and I have been >> stressing the >importance of a more "strict" approach to our 4-layer metamodeling >architecture. It is easy for excessive mappings to degenerate into >architectural kludges. > >-- Cris > ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: From: "KOBRYN, Cris" To: "David S. Frankel" Cc: uml-rtf@omg.org, mof-rtf@omg.org Subject: RE: ElementOwnership Date: Sat, 9 Jan 1999 10:21:33 -0800 > Thanks for the response and insight into the situation. > > I strongly agree with you and Sridhar on this one. The > non-strict approach > seems empty to me. What does it really mean to say that an entire > meta-model is an instance of the meta-metamodel if it doesn't > mean that > each meta-model construct is an instance of a meta-meta-model > construct? > As far as I can tell it means nothing with any computational > significance. Loose metamodeling is more flawed than empty. (In fact, it's frequently rather full--of kludges! ;->) As for its computational significance, the reality is that most commercial metamodeling frameworks are based on loose metamodeling, rather than strict metamodeling. Metamodeling is still in a nascent stage. As we get better at it, I think that more folks will understand the advantages of a more rigorous approach (i.e., strict metamodeling). -- Cris > At 04:06 PM 1/7/99 -0800, KOBRYN, Cris wrote: > >> In UML versions 1.1, 1.2, and 1.3 the class diagram for the > >> Core Backbone > >> declares ElementOwnership as an AssociationClass. This > >> appears to be a > >> violation of MOF compliance, since the MOF meta-meta-model > >> does not support > >> the notion of an AssociationClass. > > > >You are raising the question of whether the UML metamodel and the > MOF > >meta-metamodel are aligned using a "strict" or "non-strict" > metamodeling > >approach. As is explained in the UML Proposal Summary v. > 1.1, Section 6.1 > >(OMG doc# ad/97-08-02), the UML and MOF metamodels are > aligned using a > >non-strict approach. > > > >This section explains that the UML metamodel is an instance > of the MOF > >meta-metamodel, but it is not necessarily the case that each > model element > >of the UML metamodel is an instance of a meta-metamodel > element in the MOF > >meta-metamodel. > > > >> Of course one could extrapolate AssociationClass from the MOF > >> meta-meta-model since it does support both Association and > >> Class, and one > >> could also logically extrapolate a MOF-IDL and MOF-XML > mapping for an > >> extrapolated MOF AssociationClass. However, two architects might > >> extrapolate these mappings in perfectly valid but different > >> manners, since > >> there is no standard mapping for a MOF AssociationClass. > >> Apparently such > >> an extrapolation has been performed in order to derive the > >> IDL for the UML > >> meta-model that concerns ElementOwnership, but doing this without > a > >> standard mapping seems dangerous. > > > >Yes, the problem can be finessed with a mapping of the sort that > you > >describe. > > > >Perhaps you better understand now why Sridhar and I have > been stressing the > >importance of a more "strict" approach to our 4-layer metamodeling > >architecture. It is easy for excessive mappings to degenerate into > >architectural kludges. > > > >-- Cris > > > ============================= > David S. Frankel > Director, Advanced Architecture > Genesis Development Corporation > 741 Santiago Court > Chico, CA 95973-8781 U.S.A. > > http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax =============================