Issue 1770: MofAttribute values do not have aggregation==composite semantics (mof-rtf) Source: (, ) Nature: Severity: Minor Summary: Summary: The spec should make it clear that the values of a MofAttribute are NOT intended to have aggregation semantics. For example, an instance of a Class should be allowed to refer to itself as an attribute, or to share an (object) attribute with other instances. This applies to MofAttributes whose type is a Class or a DataType (where its typecode is any kind of object reference type). Resolution: resolved and closed Revised Text: Actions taken: August 4, 1998: received issue May 8, 2000: closed issue Discussion: Discussion: a resolution needs to reconcile the following: • The UML model of Attributes (apparently) makes attribute values components of class instance. • The CORBA IDL model of attributes makes the attribute value holders the class in-stance components. • For MOF Attribute values that may be "ordinary" CORBA object references, (i.e. those defined using DataTypes), we cannot implement MOF composition seman-tics. • There is a requirement for a light-weight (i.e. minimal runtime cost) way of attach-ing Class instances to other Class instances. The non-composite Attribute seman-tics currently provide this. Alternatives: 1. Status quo. MOF Attributes have no composition semantics. The Class instance is a composition of holders rather than of values. 2. UML approach. All MOF Attributes are composites. CORBA data types, but how do we support composite semantics for "ordinary" CORBA objects? 3. Hybrid approach. MOF Attributes whose types are specified as Classes are com-posites are those whose types are specified as DataTypes are not. 4. Attribute Aggregation. Add an "aggregation" attribute to Attribute with the same semantics as the AssociationEnd "aggregation" attribute. This requires a change to the MOF Model that diverges further from the UML metamodel. Assuming that we allow do Attributes to have composite aggregation semantics, how do we implement it efficiently? It cannot be done by looking at all instances of all Classes that have Attributes with an appropriate Class. The only scalable algorithm is as follows: // Return true iff it is legal to assign `obj' to an attribute // of `container' boolean is_composition_legal(Object obj, Object container) { if (obj.my_container() != null) return false; while (container != null) { if (container.my_container() != obj) return false; container = container.my_container(); } return false; } There are two problems with the above: 1. It assumes that you can find the container of any object. This is currently "magic". To fix this we need to add a "my_container()" operation to RefObject. 2. The cost of the test is O(N) where N is the depth of containment of the container. On the other hand, if we add a "my_container()" operation to RefObject, we make it possi-ble to implement composite aggregation on Associations more efficiently. (Currently, it may be necessary to check multiple composite Associations.) Proposed resolutions: 1. Support the following Attribute type / aggregation semantic combinations: • Class: either "composite" or "none", • CORBA datatype: "composite" only with all embedded interface types "none", "ordinary" CORBA interfaces: "none" only. 1. Model the choice of aggregation semantics for Class valued Attributes using DataTypes. 2. Add an operation to RefObject to return an object's container. For example: RefObject container(in nos_levels); When called with nos_levels == 1 returns the container (or nil), with nos_level == 2 returns the container's container (or nil) and so on. When called with nos_levels == -1, returns the outermost container (or nil). For consistency with immediate_containing_package and outermost_containing_package, two new operations immediate_container and outermost_container are proposed for the RefObject interface. Note that these op-erations are about "logical" containment of RefObjects through M1-associations and not the physical containment of RefObjects within a given RefPackage. Thus these new operations will always return RefObject. For consistency, it raises NotSet if there is no container object. Implementation: Added text and IDL for the immediate_composite and outermost_composite operations in Section 6.2.3, “Reflec-tive:: RefObject,” on page 6-10 and in the RefObject interface in Appendix B.2 “MOF IDL Summary”. [KR] Rewritten. [SC] Implementation: Documented that if the appropriate composite attribute is class-lev-el, then the result will be the class proxy. [SC] Implementation: It has been agreed that embedded Class references are pure object references without any containment semantics. Documented in “In-stance object lifecycle semantics” on page 5-9. Done [SC] End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: MofAttribute values do not have aggregation==composite semantics Date: Tue, 04 Aug 1998 16:55:22 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Editorial Severity: Minor The spec should make it clear that the values of a MofAttribute are NOT intended to have aggregation semantics. For example, an instance of a Class should be allowed to refer to itself as an attribute, or to share an (object) attribute with other instances. This applies to MofAttributes whose type is a Class or a DataType (where its typecode is any kind of object reference type). Additional text: If we do let MofAttributes do acquire aggregation==composite semantics by default, they become very heavy-weight. Every time you assign an attribute value that is or might contain a Class object reference, you have to do a whole lot of containment checking and cyclicity checking. Return-Path: From: "Khalsa, GK" To: mof-rtf@omg.org Subject: Re: MofAttribute values do not have aggregation==composite Date: Thu, 6 Aug 1998 14:11:17 -0500 I'm surprised that there is disagreement on the aggregation semantics of Attributes. From a modeling perspective (OO, ER, Semantic, etc.) attributes have always been considered the aggregate parts of the object or entity whole. If we do not define attributes with composite aggregation semantics, then: Data values will require object identity. How else can the value "blue" of enum Color be shared as the attribute value of a car object on one machine and the attribute of a fish object located on a second machine? Data values must be owned by their object, otherwise the implementation of attributes will be "heavyweight". There is little downside to implementing MofAttributes with composite semantics. For data values, this is the norm. For object values, it is easy enough to track composite's ownership of objects. Implementations already are required to accomplish this 'bookwork' in order to support composite associations. CORBA Object References which do not correspond to a Class in a metamodel are a special case. They can be used as an attribute value only when the type of the attribute is a DataType instance with a typeCode attribute which dealiases to tk_objref. If an attribute has a type of CORBA Any, then the attribute value will not be the object reference, but an Any which includes the reference. In the first case, since the value is a datatype, we should treat the object reference as the owned element, distinct from the object it refers to (treat is as a reference or a pointer). Similarly, for the second case, the Any, and its enclosed object reference should be the owned element, not the object referred to. This approach allows us to treat all attribute values as composed elements of the owning object (by-value semantics) yet avoids forcing implementations from enforcing composition rules (and changeability rules) on objects of unknown type.