Issue 1711: Multiplicities on Attributes and References modelled incorrectly (mof-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: The current Model defines a "multiplicity" attribute on StructuralFeature which is then inherited by MofAttribute and Reference. There is also a Constraint that says that the multiplicity of a Reference must be the same as the multiplicity of the corresponding AssociationEnd. This modeling is incorrect, as it makes it duplicates information. In particular, the ReferenceClass::create_reference() operation requires an extra multiplicity parameter. Resolution: resolved and closed Revised Text: Actions taken: July 22, 1998: received issue May 8, 2000: closed issue Discussion: What is really going here is that the multiplicity of a Reference is implied by the multiplicity of the corresponding AssociationEnd. The correct way to model this is to define separate 'multiplicity' attributes on MofAttribute and Reference. The 'multiplicity' attribute on Mo-fAttribute is a "real" one. The 'multiplicity' attribute on Reference is a derived one. This issue illustrates a shortcoming in the MOF Model; i.e. that there is no way to "over-ride" derived with non-derived or vice-versa. Proposed resolutions: Add text to section 3 to document the anomolous extra attribute. Implementation: Added text and a note explaining this to Section 3.4.12, “Refer-ence,” on page 3-44. Done [KR]. End of Annotations:===== Return-Path: To: mof-rtf@omg.org Subject: Multiplicities on Attributes and References modelled incorrectly Date: Wed, 22 Jul 1998 15:07:36 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Minor The current Model defines a 'multiplicity' attribute on StructuralFeature which is then inherited by MofAttribute and Reference. There is also a Constraint that says that the multiplicity of a Reference must be the same as the multiplicity of the corresponding AssociationEnd. This modeling is incorrect, as it makes it duplicates information. In particular, the ReferenceClass::create_reference() operation requires an extra multiplicity parameter. What is really going here is that the multiplicity of a Reference is implied by the multiplicity of the corresponding AssociationEnd. The correct way to model this is to define separate 'multiplicity' attributes on MofAttribute and Reference. The 'multiplicity' attribute on MofAttribute is a "real" one. The 'multiplicity' attribute on MofAttribute is a derived one. I also noticed that the "modl" for Appendix B no longer matches the "idl" in Appendix A. It looks like some of the addenda changes to hand tweak the IDL were not propagated to the MODL. Return-Path: Date: Thu, 30 Jul 1998 06:57:05 -0700 From: GK Khalsa Organization: Object Radiance, Inc. To: "mof-rtf@omg.org" Subject: Discussion of Issue 1711 Discussion of Issue 1711: Multiplicities on Attributes and References modelled incorrectly This issue was discussed at length during the development of the MOF Standard. Based on the current MOF modeling capabilities, we are faced with either (1) duplicating the multiplicity and isChangeable attributes in both the reference and association end; or (2) not treating attributes and references uniformly. We felt that the ability to treat references and attributes uniformly (since they both describe the state of the object) was most important. Crawley's suggestion of defining reference multiplicity separate from attribute multiplicity would not allow developers to treat both References and Attributes as StructuralFeatures when addressing multiplicity (and changeability). This limitation would also complicate implementation of the Reflective interfaces. Although the current model is a little peculiar, it poses no real problem. Remember, the presence of a MofAttribute in a model does not mandate any particular implementation. Because constraints synchronize the values of multiplicity and isChangeable attributes for Reference and AssociationEnd, implementations can hold the attribute values at a single location. The redundancy in the create_reference() operation can be addressed by defining a second constructor within the model. -- GK Khalsa khalsa@objectrad.com Object Radiance, Inc. v: +1 909 677 2518 Murrieta, CA USA f: +1 909 677 1478 Return-Path: To: GK Khalsa cc: "mof-rtf@omg.org" , crawley@dstc.edu.au Subject: Re: Discussion of Issue 1711 Date: Fri, 31 Jul 1998 16:18:07 +1000 From: Stephen Crawley > This issue was discussed at length during the development of > the MOF Standard. Based on the current MOF modeling > capabilities, we are faced with either (1) duplicating the > multiplicity and isChangeable attributes in both the > reference and association end; or (2) not treating > attributes and references uniformly. We felt that the > ability to treat references and attributes uniformly (since > they both describe the state of the object) was most > important. There was never a real consensus on this issue. It got swept under the carpet as being unimportant compared with some of the other issues we were dealing with. > Crawley's suggestion of defining reference multiplicity > separate from attribute multiplicity would not allow > developers to treat both References and Attributes as > StructuralFeatures when addressing multiplicity (and > changeability). As someone who is currently a developer, I have yet to find this to be the case in practice. In IDL and Server generators, you have to interpret the multiplicity attributes on MofAttribute and Reference meta-meta-objects differently anyway. There is little in the way of common code here ... > This limitation would also complicate > implementation of the Reflective interfaces. I don't understand this. Our implementation of the Reflective interfaces will not need to refer to the meta-meta-objects at runtime. Perhaps this is an artifact of your implementation approach? > Although the current model is a little peculiar, it poses no > real problem. Nothing fatal ... > Remember, the presence of a MofAttribute in a > model does not mandate any particular implementation. > Because constraints synchronize the values of multiplicity > and isChangeable attributes for Reference and > AssociationEnd, implementations can hold the attribute > values at a single location. Such an implementation would definitely be non-compliant! A MOF Constraint is no more than a predicate that must be satisfied. It is not permitted to change one or more of the constrained elements to make the predicate TRUE. Unless a MOFAttribute is defined as 'derived', the correct behaviors for an instance is that if you successfully set the value of an attribute, you should be able to read back the same value ... until you set it to another value. > The redundancy in the > create_reference() operation can be addressed by defining > a second constructor within the model. True, but this does not get rid of the default constructor with the unwanted argument. And it does not get rid of the constraint that we'd prefer not to have. There is a better (both theoretically and in terms of the generated IDL) solution to this kind of problem. What you do is define the 'real' attributes separately in each of the leaf classes. Then in the appropriate common superclass, you define 'derived' attributes whose values are calculated from the real attributes as required. The 'derived' attributes can be read-only or read-write. For example, in this case we could express the Model as follows: ... type StructuralFeature : ... { derived attribute MultiplicityType multiplicity; ... }; type MofAttribute : StructuralFeature { attribute MultiplicityType attr_multiplicity; // super.multiplicity gets and sets this.attr_multiplicity ... }; type Reference : StructuralFeature { ... known referencedEnd projects referencedEnd in RefersTo; // no 'real' multiplicity attribute // super.multiplicity gets and sets this.referencedEnd.multiplicity ... }; This says PRECISELY what we want from the modelling point of view AND it provides a common operations for StructuralFeature multiplicities. Note that the create operation for Reference will have no initialization parameter for 'multiplicity', and MofAttribute will have one for 'attr_multiplicity' and not 'multiplicity'. -- Steve Return-Path: From: "Iyengar, Sridhar" To: mof-rtf@omg.org, GK Khalsa Subject: RE: Discussion of Issue 1711 Date: Thu, 30 Jul 1998 14:29:25 -0600 Part of the reason why some of these complications arose were also the UML/MOF alignment work. Some of these inconsistencies and duplication of attributes get resolved if AssociationEnd, Reference and MOfAttribute are all treated as structural features, with appropriate constraints on containment. Sridhar ------------------------------------------------------------------------ --------------------------------------------- Sridhar Iyengar Unisys Fellow sridhar.iyengar@mv.unisys.com Unisys Corporation 714-380-5692 (Pho) 25725, Jeronimo Rd 714-380-6632 (Fax) Mission Viejo, CA 92691 656-5692 (Net) ------------------------------------------------------------------------ ---------------------------------------------- > ---------- > From: GK Khalsa[SMTP:khalsa@objectrad.com] > Sent: Thursday, July 30, 1998 6:57 AM > To: mof-rtf@omg.org > Subject: Discussion of Issue 1711 > > Discussion of Issue 1711: Multiplicities on Attributes and > References modelled incorrectly > > This issue was discussed at length during the development of > the MOF Standard. Based on the current MOF modeling > capabilities, we are faced with either (1) duplicating the > multiplicity and isChangeable attributes in both the > reference and association end; or (2) not treating > attributes and references uniformly. We felt that the > ability to treat references and attributes uniformly (since > they both describe the state of the object) was most > important. > > Crawley's suggestion of defining reference multiplicity > separate from attribute multiplicity would not allow > developers to treat both References and Attributes as > StructuralFeatures when addressing multiplicity (and > changeability). This limitation would also complicate > implementation of the Reflective interfaces. > > Although the current model is a little peculiar, it poses no > real problem. Remember, the presence of a MofAttribute in a > model does not mandate any particular implementation. > Because constraints synchronize the values of multiplicity > and isChangeable attributes for Reference and > AssociationEnd, implementations can hold the attribute > values at a single location. The redundancy in the > create_reference() operation can be addressed by defining > a second constructor within the model. > -- > GK Khalsa khalsa@objectrad.com > Object Radiance, Inc. v: +1 909 677 2518 > Murrieta, CA USA f: +1 909 677 1478 > Return-Path: From: "Khalsa, GK" To: mof-rtf@omg.org Subject: Re: Discussion of Issue 1711 (more) Date: Mon, 3 Aug 1998 12:27:40 -0600 <> > > Remember, the presence of a MofAttribute in a > > model does not mandate any particular implementation. > > Because constraints synchronize the values of multiplicity > > and isChangeable attributes for Reference and > > AssociationEnd, implementations can hold the attribute > > values at a single location. > Such an implementation would definitely be non-compliant! > A MOF Constraint is no more than a predicate that must be satisfied. > It is not permitted to change one or more of the constrained > elements > to make the predicate TRUE. I disagree. There is nothing wrong with specifying behavior via an OCL constraint which an implementation must oblige. That is exactly what an operation post-condition does, for instance. > Unless a MOFAttribute is defined as 'derived', the correct behaviors > for an instance is that if you successfully set the value of an > attribute, you should be able to read back the same value ... until > you set it to another value. No. For instance, derived attributes and operations are allowed to change the value of an attribute. There is nothing in the MOF which supports the above. > > The redundancy in the > > create_reference() operation can be addressed by defining > > a second constructor within the model. > True, but this does not get rid of the default constructor with the > unwanted argument. And it does not get rid of the constraint that > we'd prefer not to have. > There is a better (both theoretically and in terms of the generated > IDL) solution to this kind of problem. > What you do is define the 'real' attributes separately in each of > the leaf classes. Then in the appropriate common superclass, you > define 'derived' attributes whose values are calculated from the > real attributes as required. The 'derived' attributes can be > read-only or read-write. For example, in this case we could > express the Model as follows: <> > This says PRECISELY what we want from the modelling point of view > AND it provides a common operations for StructuralFeature multiplicities. > Note that the create operation for Reference will have no initialization > parameter for 'multiplicity', and MofAttribute will have one for > 'attr_multiplicity' and not 'multiplicity'. Here's what the IDL would look like: interface StructuralFeature : /* ... */ { MultiplicityType multiplicity() raises /* .. */; void set_multiplicity (in MultiplicityType new_value) raises /* .. */; } interface MofAttributeClass : StructuralFeatureClass { create_mof_attribute( /* .. */ in MultiplicityType attr_multiplicity, /* .. */); } interface MofAttribute : StructuralFeature, /* ... */ { MultiplicityType attr_multiplicity() raises /* .. */; void set_attr_multiplicity (in MultiplicityType new_value) raises /* .. */; } interface Reference : StructuralFeature, /* ... */ { } Here are the problems: There are two operations to read an attribute's multiplicity, and two operations to set the multiplicity. The link between the attr_multiplicity in the create operation and the multiplicity attribute is not explicit. This alternative would be OK, but certainly not "precisely what we want", and really no better than what we have. What we precisely want, I believe, are multiplicity and set_multiplicity() operations on StructuralFeature, two "multiplicity" attributes, on MofAttribute and (derived) on Reference, and a mapping of the set and get operations for those attributes to the StructuralFeature operations. This solution, of course, would require an IDL mapping model capability for the MOF. Return-Path: To: "Khalsa, GK" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Discussion of Issue 1711 (more) Date: Tue, 04 Aug 1998 10:37:21 +1000 From: Stephen Crawley A couple of side-issues <>. I'll submit them as separate issues. > > What you do is define the 'real' attributes separately in each of > > the leaf classes. Then in the appropriate common superclass, you > > define 'derived' attributes whose values are calculated from the > > real attributes as required. The 'derived' attributes can be > > read-only or read-write. For example, in this case we could > > express the Model as follows: > > <> > > > This says PRECISELY what we want from the modelling point of view > > AND it provides a common operations for StructuralFeature > multiplicities. > > Note that the create operation for Reference will have no > initialization > > parameter for 'multiplicity', and MofAttribute will have one for > > 'attr_multiplicity' and not 'multiplicity'. > > Here's what the IDL would look like: > > interface StructuralFeature : /* ... */ { > MultiplicityType multiplicity() raises /* .. */; > void set_multiplicity (in MultiplicityType new_value) raises /* > .. > */; > > } > interface MofAttributeClass : StructuralFeatureClass { > create_mof_attribute( /* .. */ > in MultiplicityType attr_multiplicity, > /* .. */); > } > interface MofAttribute : StructuralFeature, /* ... */ { > MultiplicityType attr_multiplicity() raises /* .. */; > void set_attr_multiplicity (in MultiplicityType new_value) > raises /* > .. */; > } > interface Reference : StructuralFeature, /* ... */ { > } > > Here are the problems: > There are two operations to read an attribute's > multiplicity, and two operations to set the multiplicity. Yes. That is a bit unfortunate. But at least they do the same thing ... which is the right thing. IMO, this interface redundancy is a consequence of your wanting there to be operations that work for all StructuralFeatures. > The link between the attr_multiplicity in the create > operation and the multiplicity attribute is not explicit. Nothing about derived attributes, derived associations or operations is explicit. We could try to fix that ... > This alternative would be OK, but certainly not "precisely > what we want", You are misquoting me. I said "precisely what we want FROM THE MODELLING POINT OF VIEW." > and really no better than what we have. No. It is >>definitely<< better than what we have. What we have at the moment is a Model that: 1) requires the client to provide redundant information on create, and change that information in two places if it needs to be changed, and 2) uses a deferred constraint to ensure that the two pieces of information are in step, which complicates both server side validation and client side error reporting. My proposal fixes the above, at the cost of: 1) having a pair of IDL operations on the MofAttribute interface that do the same thing. (Or is it two pairs? It doesn't matter.) The solution is not ideal, but it is definitely an improvement. > What > we precisely want, I believe, are multiplicity and > set_multiplicity() operations on StructuralFeature, two > "multiplicity" attributes, on MofAttribute and (derived) on > Reference, and a mapping of the set and get operations for > those attributes to the StructuralFeature operations. This > solution, of course, would require an IDL mapping model > capability for the MOF. That might work ... provided that: 1) the IDL mapping capability is part of the Model ... not an add-on or extension, and 2) the meaning of overloading of names by the IDL mapping route is properly defined. To illustrate the potential problems we'd have in 2), suppose that I map the operations on one MofAttribute onto another MofAttribute on the same object. Does this mean that there is in effect only one attribute? Does it cause problems for create parameters? What if MofAttributes have different base types or multiplicities? In short, this is a BIG issue that shouldn't be opened in an RTF. That is one approach. Another is to provide the capability in the MOF to override >>behaviour<< in the MOF (e.g. the derived flag) in ways that don't change IDL interface signatures, and don't break subtyping; i.e. substitution of types by subtypes. But this needs a lot more thought. Again, this is too big for an RTF. -- Steve