10.2 The Reflective Interfaces

   This sub clause describes the interfaces defined in the “Reflective? module. These interfaces are modeled on the interfaces that are produced by the IDL mapping. However, there are some important differences:

• Reflective operations pass the values of Attributes and References, and of the Parameters to Operations and Exceptions as CORBA Any values. The mapped versions of these operations pass the values using precise types according to the meta-model.

• Reflective operations on Associations pass Instance objects with the type RefObject. The mapped versions of these operations pass Instance objects using their true types.

• The “target? feature for a Reflective operation is passed as a “designator? parameter whose type is a MOF meta-object. In the mapped case, the target is implicit in the mapped operation name.

   As stated previously, the Reflective versions of operations, which are defined in the mapped IDL, do not allow a program to violate the information and computational models implied by the meta-model definition. This includes not allowing operations that, while meaningful for a model, are not possible using the mapped interfaces. For example, while it might be meaningful to call “refSetValue? on an optional Attribute passing an "empty" argument (encoded appropriately), this is not allowed: the program must use “refSetValue.?

   This sub clause consists of a sub clause that explains some common patterns that are used for encoding parameters used by many Reflective operations. The remaining four sub clauses describe each Reflective interface in turn.

   The Reflective module make heavy use of the CORBA Any type to provide meta-model independent interfaces. This sub clause defines some common patterns used throughout the Reflective interfaces for encoding parameter values in Anys.

   NOTE: It is important that the type information (expressed as CORBA TypeCodes) in the encoded Anys be precisely as specified below. In particular, collection type aliases and their names are mandatory.

   If the base type of the value-defining feature is a DataType, the TypeCode in the encoded Any must be the full TypeCode for the base type. Type aliases must not be optimized away, and all optional names (e.g., of struct types, fields, and so on) must be present. (Optimization of type information in Anys should be done at the ORB level if at all.)

   This pattern is used for encoding complete values as CORBA Anys. It is used in most cases where a reflective operation requires or provides a complete value for an element that may be collection valued (depending on the multiplicity). Examples that use this pattern are values for Operation arguments and results, values for Exception fields and Attribute initial values in a create operation.

   Table 10.1- Standard Value Encoding Pattern

   The standard pattern for encoding complete values (above) does not fit well with the IDL templates for the specific “get? and “set? operations. To improve the alignment between the reflective and specific interfaces, the following alternative pattern is used for the “refValue? and “refSet Value? operations for Attributes and References.

   “The operation fetches the current value of the Attribute or Reference denoted by the “feature? argument. If this object is a Class proxy, only classifier scoped Attributes can be fetched.?

   “The “refSetValue? operation assigns a new value to an Attribute or Reference for an object. The assigned value must be a single value or a collection value depending on the feature’s multiplicity.? .

   Table 10.2- Alternate Value Encoding Pattern

   The following pattern is used in the reflective versions of the add, modify and remove operations that operate on the individual members of a multi-valued Attribute or Reference. The pattern is simply to encode the member as an Any containing an instance of the feature’s base type. For example:

   Any(<type>)

   © ISO/IEC 2005 - All rights reserved

    Some of the operations in the RefAssociation interface use the “generic? Link type to pass link values; see 10.3.2, “Data Types,? on page 271. While the Link type uses RefObject rather than Any, a pattern is still required to describe the encoding.

   The “generic? Link type is declared as a sequence of RefObject values with an upper bound of 2. The standard encoding of a link for a given Association is:

   Link(<assocEnd1Type>, <assocEnd2Type>)

   In other words, the sequence value contains precisely two elements, and the elements appear in the order of the corresponding AssociationEnds in the Association.

   The RefBaseObject interface is inherited by the other three reflective interfaces. It provides common operations for testing for object identity, returning an object’s meta-object, and returning its “repository container? as required for implementing structural constraints such as the MOF’s type closure rule and composition restrictions.

   Supertypes

   none (root object)

   Operations refMofId

   The “refMofId? operation returns this object’s permanent unique identifier string.

   Every MOF object has a permanent, unique MOF identifier associated with it. This identifier is generated and bound to the object when it is created and cannot be changed for the lifetime of the object. The primary purpose of the MOF identifier is to serve as a label that can be compared to definitively establish an object’s identity.

   A MOF implementation must ensure that no two distinct MOF objects within the extent of an outermost Package object ever have the same MOF identifier. This invariant must hold for the lifetime of the extent.

   A group of outermost Package extents can only be safely federated if the respective implementations can ensure the above invariant applies across the entire federation. A federation of extents in which the invariant does not hold is not MOF compliant.

   The MOF specification does not mandate a scheme for achieving this. Instead, the following approach is recommended:

1. Choose an appropriate scheme (or schemes) for allocating unique identifiers. This will depend on the nature of the federation.

2. Define a textual syntax for MOF identifier strings of the form:

   <scheme-prefix> ":" <scheme-specific-part>

   where <scheme-prefix> is either standardized elsewhere, or a vendor or user specific string that is unlikely to clash with other prefixes.

   In the absence of a more appropriate identifier generation scheme, it is recommended that the following scheme based on the DCE UUID algorithm and textual encoding be used. The recommended DCE UUID-based identifier syntax is:

   "DCE" ":" <printable-form-of-dce-uuid> [":" <decimal-digits>]

   For example:

   "DCE:d62207a2-011e-11ce-88b4-0800090b5d3e""DCE:d62207a2-011e-11ce-88b4-0800090b5d3e:1234"

   The first case would be used when it is acceptable to generate a new DCE UUID for each MOF object. The second case might be used when the overheads of doing this are too large, or the required rate of UUID generation is too high. In this case, the UUID would denote an extent incarnation, and the suffix would be a local object sequence number for the extent incarnation does not repeat during the latter’s lifetime.

   refMetaObject

   The “refMetaObject? operation returns the Model::ModelElement object that describes this object in its metamodel specification.

   If the object’s meta-object is unavailable, the return value may be a CORBA nil object reference.

   refItself

   The “refItself? operation tests whether this object and another RefBaseObject provided as an argument are the same CORBA object.

   "Invalid Object" occurs if the "otherObject" is not a valid object, or if it is inaccessible.

   © ISO/IEC 2005 - All rights reserved

   refImmediatePackage

   The “RefImmediatePackage? operation returns the RefPackage object for the Package that most immediately contains or aggregates this object.

   If this object has no containing or aggregating Package (i.e., it is the RefPackage object for an outermost Package), then the return value is a CORBA nil object reference. In complex cases where there is more than one immediate aggregating Package (see 8.8, “Extents,? on page 145 and 9.2.1, “Meta Object Type Overview,? on page 161, the return value may be any of them.

   refOutermostPackage

   The “refOutermostPackage? operation returns the RefPackage object for the Package that ultimately contains this object.

   If this object is the RefPackage object for an outermost Package, then the return value is this object.

   refDelete

    The “refDelete? operation destroys this object, including the objects it contains directly or transitively (see 9.3.4, “Lifecycle Semantics for the IDL Mapping,? on page 170 and 8.10, “Aggregation Semantics,? on page 152).

    The semantics of this operation depend on this RefBaseObject’s most derived type; see 9.2.1, “Meta Object Type Overview,? on page 161. Five sub-cases of RefBaseObject need to be considered here:

   • outermost (i.e., non-nested, non-dependent) Package objects,

• nested or dependent Package objects,

• Association objects,

   © ISO/IEC 2005 - All rights reserved

   • Class proxy objects, and

   • Instance objects. Ordinary clients may only use “refDelete? to delete instances of outermost Package objects and Instance objects.

• Deletion of an outermost Package causes all objects within its extent to be deleted; see 9.3.4.1, “Package object creation and deletion semantics,? on page 170.

• Deletion of an Instance object deletes it and its component closure; see 9.3.4.2, “Instance object lifecycle semantics,? on page 171 .

   “Invalid Deletion? occurs if an ordinary client invokes “refDelete? on a nested or dependent Package object, an Association object, or a Class proxy object.

   As part of the deletion of an outermost Package, a Package object’s implementation may use the “refDelete? operation to delete nested or dependent Package objects, Association objects, and Class proxy objects as well as Instance objects.

   refVerifyConstraints

   The “refVerifyConstraints? operation triggers verification of the Constraints attached to the target object’s meta-object.

   The operation should attempt to check any Constraints for the target object that may possibly fail, including any deferred structural constraints. If all constraints hold for the target, the result is true, and an empty set will be returned in ’problems.’ Otherwise, the result is false.

   If ’deepVerify’ is false, just the Constraints attached to this object’s meta-object are evaluated. Otherwise any Constraints attached to the meta-objects of this object’s component objects (direct or indirect) are also evaluated. For example, if a Class is defined with Constraints attached to one of its Attributes, these will only be evaluated if ’deepVerify’ is true.

   The ’maxProblems’ parameter allows the caller to specify the maximum number of ViolationType instances to be returned in ’problems.’ If ’maxProblems’ is zero, no ViolationType instances will be returned. When an implementation detects more constraint violations that can be reported, it should cease checking and return the results that it can. If ’maxProblems’ is UNBOUNDED (-1), or any other negative number, the implementation should return ViolationType instances for all constraint violations detected.

   The ’problems’ parameter is used to return ViolationType descriptors for any constraints that do not currently hold. The ’maxProblems’ parameter says how many descriptors may be returned by the call. Refer to 10.3.2, “Data Types,? on page 271 for description of ViolationType and how it is used.

   Interface

   interface RefBaseObject {

   string ref_mof_id ();

   DesignatorType ref_meta_object (); boolean ref_itself (in RefBaseObject other_object);

   RefPackage ref_immediate_package ();

   RefPackage ref_outermost_package ();

   void ref_delete ()

   raises (MofError);

   boolean refVerifyConstraints(

   in boolean deepVerify,

   in long maxProblems,

   out ViolationTypeSet problems)

   raises (MofError)

   }; // end of RefBaseObject

   The RefObject interface provides the meta-object description of an object that inherits from it, provides generic operations for testing for object identity and type membership, and a range of operations for accessing and updating the object in a model independent way.

   The model assumed by the interface is that an object has structural features and operations. The model allows structural features to have single values or collection values. In the latter case, the collection values may have ordering or uniqueness semantics. There is provision for creation of new object instances, and for obtaining the set of objects that exist in a context.

   Supertypes

   RefBaseObject

   Operations

   refIsInstanceOf

   This operation tests whether this RefObject is an instance of the Class described by the “someClass? meta-object. If the “considerSubtypes? argument is TRUE, an object whose Class is a subclass of the Class described by “someClass? will be considered as an instance of the Class.

   refCreateInstance

   This operation creates a new instance of the Class for the RefObject’s most derived interface. The operation can be called on a Class proxy object or an Instance object. The “args? list gives the initial values for the new Instance object’s instance scoped, non-derived Attributes.

   The members of the "args" list correspond 1-to-1 to the parameters for the specific create operation. They must be encoded as per 10.2.1.1, “The Standard Value Encoding Pattern,? on page 249. “Wrong Type? and “Wrong Number Parameters? when the “args? list has the wrong length or is incorrectly encoded.

   “Abstract Class? occurs when “refCreateInstance? is called to create an instance of an “abstract Class.? The remaining error conditions are directly equivalent to error conditions for the specific “create? operation.

   refAllObjects

   The “refAllObjects? operation returns the set of all Instances in the current extent whose type is given by this object’s Class. The operation can be called on a Class proxy object or an Instance object.

   If “includeSubtypes? is true, the Instance objects for any subClasses of the M2 level Class are also included in the result set. This case is equivalent to the specific “all_of_type_<class_name>.?

   If the M2 level Class has “isAbstract? set to true, the result of

   ref_all_objects(false)

   is an empty set.

   refValue

   The “refValue? operation fetches the current value of the Attribute or Reference denoted by the “feature? argument. If this object is a Class proxy, only classifier scoped Attributes can be fetched.

   .

   The result for the “refValue? operation is encoded as per 10.2.1.2, “The Alternate Value Encoding Pattern,? on page 249.

   “NotSet? occurs when the feature’s multiplicity is [0..1] and its value is unset (i.e., an empty collection). This should not occur with other multiplicities.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? and “Wrong Scope? all occur in cases where the “feature? argument does not denote an Attribute or Reference accessible from this object.

   “Underflow? occurs when the feature is a Reference with multiplicity is [1..1] and its value has not been initialized. This should not occur for an Attribute or with other multiplicities.

   refSetValue

   The “refSetValue? operation assigns a new value to an Attribute or Reference for an object. The assigned value must be a single value or a collection value depending on the feature’s multiplicity.

    The “newValue? parameter must be encoded as per 10.2.1.2, “The Alternate Value Encoding Pattern,? on page 249. “Wrong Type? occurs when this parameter is incorrectly encoded.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? and “Not Changeable? all occur in situations where the “feature? parameter does not denote a changeable Attribute or Reference that is accessible from this object.

   The remaining error conditions are directly equivalent to error conditions for the “set_<feature_name>? operation.

   refUnsetValue

   The “refUnsetValue? operation resets an optional Attribute or Reference to contain no elements. This operation can only be used when the feature’s multiplicity is [0..1].

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur in situations where the “feature? parameter does not denote an Attribute or Reference for which “unset_<feature_name>? is allowed.

   “Underflow? occurs in the same situation as for the “unset_<feature_name>? operation. For example, when “feature? is a Reference whose exposed Association End has a non-zero lower bound.

   refAddValue

   The “refAddValue? operation adds a new element to the current value of an Attribute or Reference with multiplicity that allows multiple values. If the Attribute or Reference is ordered, the new element is added at the end of the current value.

   The “newElement? parameter should contain a single value of the feature’s base type. “Wrong Type? occurs when it does not.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when the “feature? parameter does not designate a Reference or Attribute for which the “add_<feature_name>? operation is allowed.

   The remaining error conditions are directly equivalent to error conditions for the “add_<feature_name>? operation.

   refAddValueBefore

   The “refAddValueBefore? operation is similar to “refAddValue? except that the caller specifies an existing element before which the new element is to be added.

   This operation can only be used for Attributes and References that are multi-valued and ordered. If the feature is non-unique (and therefore an Attribute), the insertion is made before the first element that matches, starting from the beginning of the collection.

   The “newElement? and “beforeElement? parameters should each contain a single value of the feature’s base type. “Wrong Type? occurs when it does not.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when the “feature? parameter does not designate a Reference or Attribute for which the “add_<feature_name>_before? operation is allowed.

   The remaining error conditions are directly equivalent to error conditions for the “add_<feature_name>_before? operation.

   refAddValueAt

   The “refAddValueAt? operation is similar to “refAddValueBefore? except that the caller explicitly gives the position of the insertion. The operation is only applicable to multi-valued ordered, non-unique Attributes.

   The “newElement? parameter should contain a single value of the Attribute’s base type. “Wrong Type? occurs if it is not.

   The “position? parameter is interpreted the same way as for the corresponding specific operation. “Bad Position? occurs if the position parameter’s value is out of range, as defined for the “add_<feature_name>_at? operation (i.e., if it is greater than the size of the collection before the operation is invoked).

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when “feature? does not designate an Attribute for which the “add_<feature_name>_at? operation is allowed.

   The remaining error conditions are directly equivalent to error conditions for the specific “add_<feature_name>_at? operation.

   refModifyValue

   The “refModifyValue? operation replaces one element of a multi-valued Attribute or Reference with a new value. If the feature is an ordered and non-unique (and therefore an Attribute), the element modified is the first one that matches, starting from the beginning of the collection.

   The “newElement? and “oldElement? parameters should contain a single value of the feature’s base type. “Wrong Type? occurs if it is not.

   The “oldElement? parameter should be an existing element of the collection being updated. “Not Found? occurs if it is not.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when the “feature? parameter does not designate a Reference or Attribute that supports the “modify_<feature_name>? operation.

   The remaining error conditions are directly equivalent to error conditions for the “modify_<feature_name>? operation.

   refModifyValueAt

   The “refModifyValueAt? operation is similar to the “refModifyValue? operation, except that the element to be modified is specified by position. The operation is only applicable to multi-valued, ordered, non-unique Attributes.

   The “newElement? parameter should contain a single value of the Attribute’s base type. “Wrong Type? occurs if it is not.

   The “position? parameter is interpreted in the same way as for the corresponding specific operation. “Bad Position? occurs if the position parameter’s value is out of range, as defined for the “modify_<feature_name>_at? operation (i.e., if it is greater than or equal to the size of the collection).

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when “feature? does not designate an Attribute for which the “modify_<feature_name>_at? operation is allowed.

   The remaining error conditions are directly equivalent to error conditions for the specific “modify_<feature_name>_at? operation.

   refRemoveValue

   The “refRemoveValue? operation removes an element of a multi-valued Attribute or Reference. The operation is only applicable when the upper bound is not equal to the lower bound. When the feature is ordered and non-unique (and therefore an Attribute) the element removed is the first one in the collection that matches, starting from the beginning of the collection..

   specific analog: remove_<reference_name>(oldElement) ; (see 9.8.12, “Reference Template,? on page 231) remove_<attribute_name>(oldElement); (see 9.8.11, “Attribute Template,? on page 222)

   The “oldElement? parameter should contain a single value of the Attribute’s base type. “Wrong Type? occurs if it is not.

   “Not Found? occurs if the value in the “oldElement? parameter is not a member of the collection.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? "Not? Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when “feature? does not designate an Attribute or Reference for which the “remove_<feature_name>? operation is allowed.

   The remaining error conditions are directly equivalent to error conditions for the specific “remove_<feature_name>? operation.

   refRemoveValueAt

   The “refRemoveValueAt? operation is similar to the “refRemoveValue? operation except that the element to be modified is specified by position. Furthermore, the operation is only applicable to ordered, non-unique Attributes.

   The “position? parameter is interpreted in the same way as for the corresponding specific operation. “Bad Position? occurs if the position parameter’s value is out of range, as defined for the “remove_<feature_name>_at? operation (i.e., if it is greater than or equal to the size of the collection before the operation is called).

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? “Wrong Scope,? “Not Changeable,? and “Wrong Multiplicity? all occur when “feature? does not designate an Attribute for which the “remove_<feature_name>_at? operation is allowed.

   The remaining error conditions are directly equivalent to error conditions for the specific “remove_<feature_name>_at? operation.

   refImmediateComposite

   The “refImmediateComposite? operation returns the “immediate composite? object for this Instance as specified below.

   The immediate composite object C returned by this operation is an Instance object such that:

• C is related to this object via a relation R defined by an Attribute or Association,

• the aggregation semantics of the relation R are “composite,? and

• this object fills the role of “component? in its relationship with C.

   If the immediate object C does not exist, or if “this? object is a Class proxy object rather than an Instance object, a CORBA nil object reference is returned.

   NOTE: If the composite relationship R corresponds to a “classifier-level? scoped M2-level Attribute, the immediate composite object C will be the Class Proxy object that holds the Attribute value.

   refOutermostComposite

   The “refOutermostComposite? operation returns the “outermost composite? for this object as defined below.

   The outermost composite object C returned by this operation is an Instance object such that:

   • There is a chain of zero or more immediate composite relationships (as described for “The “refImmediateComposite?) connecting “this? object to C, and

   • C does not have an immediate composite. The above definition is such that if “this? object is not a component of any other object, it will be returned. If “this? object is a Class proxy object, a CORBA nil object reference is returned.

   NOTE: As with “refImmediateComposite? if the last composite relationship in the chain corresponds to a “classifier-level? scoped M2 level Attribute, the outermost composite object C will be the Class Proxy object that holds the Attribute value.

   refInvokeOperation

   The “refInvokeOperation? operation invokes a metamodel defined Operation on the Instance or Class proxy object with the arguments supplied.

   The “args? parameter is used to pass the values of all of the Operation’s Parameters that have directions “in,? “out,? or “inout? but not the “return? Parameter. There must be a distinct parameter value (real or dummy) in the “args? list for every “in,? “out,? and “inout? Parameter. “Wrong Number Parameters? occurs if this is not so.

   The parameter values in “args? must appear in the order of the Operation’s “in,? “out,? and “inout? Parameters as defined in the metamodel.

   The “args? member values provided by the caller for “in? and “inout? Parameter positions must be encoded depending on the Parameter’s type and multiplicity as per the “The Standard Value Encoding Pattern? on page 249. “Wrong Type? occurs if any of these values have the wrong type for the corresponding Parameter. “Underflow,? “Overflow,? or “Duplicate? occur when one of the supplied values does not fit the multiplicity specified by the corresponding Parameter.

   The caller must provide a dummy “args? member value in each “out? Parameter position. This value may be any legal CORBA Any value.

   The “args? member values passed back to the caller for “out? and “inout? Parameter positions are likewise encoded depending on the Parameter’s type and multiplicity as per 10.2.1.1, “The Standard Value Encoding Pattern,? on page 249. Note that the values passed back to the caller the “in? Parameter positions of the “args? list are dummies whose content is undefined.

   If the Operation defines a result (i.e., a Parameter with direction “return?), the result for a “The “refInvokeOperation? operation invokes a metamodel defined Operation on the Instance or Class proxy object with the arguments supplied.? call gives the result value. This is encoded depending on the “return? Parameter’s type and multiplicity as per 10.2.1.1, “The Standard Value Encoding Pattern,? on page 249. When the Operation does not define a result, the result of a “The “refInvokeOperation? operation invokes a metamodel defined Operation on the Instance or Class proxy object with the arguments supplied.? call is a dummy value whose content is undefined.

   NOTE: In the cases above where dummy values are used, it is recommended that “light weight? Any values are used. (We would recommend the use of an Any value whose type kind is tk_null. However, there is currently some question as to whether the CDR standard defines an encoding for this value.)

   “OtherException? occurs when a “refInvokeOperation? invocation needs to signal an Operation specific Exception. The “exception_designator? field of “OtherException? will denote the Exception raised, and the “exception_args? list will give the values for any Exception fields. The “exception_args? list will have one member value for each Parameter of the Exception in the order defined by the meta-model. The member values will be encoded depending on the corresponding Exception Parameter’s type and multiplicity as per 10.2.1.1, “The Standard Value Encoding Pattern,? on page 249.

   A “Semantic Error? will occur if the invoked Operation tries to return a collection value as a result, out or inout parameter that violates the Parameter’s structural constraints. This will also occur if an Exception Parameter’s value is similarly incorrect.

   “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator,? “Not Public,? and “Wrong Scope? all occur when “requestedOperation? does not designate an Operation that can be invoked using this object.

   Interface

   interface RefObject : RefBaseObject { boolean ref_is_instance_of (in DesignatorType some_class, in boolean consider_subtypes); RefObject ref_create_instance (in AnyList args)

    raises (MofError);RefObjectSet ref_all_objects (in boolean include_subtypes);void ref_set_value (in DesignatorType feature,

   in any new_value) raises (MofError); any ref_value (in DesignatorType feature) raises (NotSet, MofError); void ref_unset_value () raises (MofError); void ref_add_value (in DesignatorType feature, in any new_element) raises (MofError);

   void ref_add_value_before (in DesignatorType feature, in any new_element, in any before_element)

    raises (NotFound, MofError);

   void ref_add_value_at (in DesignatorType feature, in any new_element, in unsigned long position)

    raises (BadPosition, MofError);

   void ref_modify_value (in DesignatorType feature, in any old_element, in any new_element)

    raises (NotFound, MofError);

   void ref_modify_value_at (in DesignatorType feature, in any new_element, in unsigned long position)

    raises (BadPosition, MofError); void ref_remove_value (in DesignatorType feature, in any old_element) raises (NotFound, MofError); void ref_remove_value_at (in DesignatorType feature, in unsigned long position) raises (BadPosition, MofError); RefObject ref_immediate_composite (); RefObject ref_outermost_composite ();

   any ref_invoke_operation ( in DesignatorType requested_operation, inout AnyList args)

   raises (OtherException, MofError); }; // end of interface RefObject

   The RefAssociation interface provides the meta-object description of an association that inherits from it. It also provides generic operations querying and updating the links that belong to the association.

   The model of association supported by this interface is of collection of two ended asymmetric links between objects. The links may be viewed as ordered on one or other of the ends, and there may be some form of cardinality constraints on either end.

   The RefAssociation interface is designed to be used with associations that contain no duplicate links, though this is not an absolute requirement. There is no assumption that different association objects for a given association type are mutually aware. Links are modeled as having no object identity.

   A data model that required “heavy weight? links with object identity (e.g., so that attributes could be attached to them) would need to represent them as RefObject instances.The RefAssociation interface could be used to manage light weight links between heavy weight link objects and the objects they connect. Similar techniques could be used to represent N-ary associations. However, in both cases better performance would be achieved using a purpose built reflective layer.

   Supertypes

   RefBaseObject

   Operations

   refAllLinks

   The “refAllLinks? operation returns all links in the link set for this Association object.

   This operation returns the current link set for the current Association extent as defined for the specific version of this operation. The links are encoded as per 10.2.1.4, “The Link Encoding Pattern,? on page 250. MofError may be raised to signal a semantic error.

   refLinkExists

   The “refLinkExists? operation returns true if and only if the supplied link is a member of the link set for this Association object.

    The “someLink? parameter should be encoded as per “The Link Encoding Pattern? on page 250. “Wrong Type? occurs if the link encoding is not correct.

   refQuery

   The “refQuery? operation returns a list containing all Instance objects that are linked to the supplied “queryObject? by links in the extent of this Association object, where the links all have the “queryObject? at the "queryEnd."

   The “queryEnd? parameter must designate an AssociationEnd for this Association object. “Invalid Designator,? “Wrong Designator Kind,? and “Unknown Designator? occur in cases where this is not so. “Not Navigable? is raised if the “queryEnd? parameter designates an AssociationEnd that has “isNavigable? set to false.

   The “queryObject? parameter must be an Instance object whose type is compatible with the type of the “queryEnd? of the Association. “Wrong Type? is raised if the parameter has the wrong type.

   “Invalid Object,? “Nil Object,? or “Inaccessible Object? is raised if the “queryObject? parameter is a non-existent, nil, or inaccessible Instance object.

   While the result of this operation is declared as an ordered set of links, the ordering only has meaning if the other AssociationEnd (i.e., not the “queryEnd?) is defined ordered.

   refAddLink

   The “refAddLink? operation adds “newLink? into the set of links in the extent of this Association object. If one or other of the Association’s Ends is ordered, the link is inserted after the last link with respect to that ordering.

    The “newLink? parameter should be encoded as per 10.2.1.4, “The Link Encoding Pattern,? on page 250. “Wrong Type? occurs if the link encoding is not correct.

   Both RefObject members of the “newLink? parameter should be valid Instance objects. “Invalid Object,? “Nil Object,? or “Inaccessible Object? is raised if either one is a non-existent, nil, or inaccessible Instance object.

   “Not Changeable? occurs if this operation is invoked on an Association that has “isChangeable? set to false on either Association End.

   © ISO/IEC 2005 - All rights reserved

   “Overflow,? “Duplicate,? “Reference Closure,? “Composition Closure,? and “Composition Cycle? are directly equivalent to error conditions for the corresponding specific “add? operation.

   refAddLinkBefore

   The “refAddLinkBefore? operation adds “newLink? into the link set of an ordered Association object. The link insertion point is immediately before the link whose “positionEnd? matches the “before? Instance.

    The “newLink? parameter should be encoded as per “The Link Encoding Pattern? on page 250. “Wrong Type? occurs if the link’s encoding is not correct.

   The “positionEnd? parameter should denote an AssociationEnd of this object’s Association. One of “Invalid Designator,? “Wrong Designator Kind,? or “Unknown Designator? occurs if thus is not the case.

   “Not Changeable? occurs if this operation is invoked on an Association that has “isChangeable? set to false on either Association End. “Not Navigable? occurs if the “positionEnd? AssociationEnd has “isNavigable? set to FALSE.

   The “before? parameter should be an Instance object that is type compatible with the type of the AssociationEnd denoted by “positionEnd.? “Wrong Type? occurs if this is not the case.

   The remaining error conditions are directly equivalent to error conditions for the corresponding “add_before_<endName>? operation.

   refModifyLink

   The “refModifyLink? operation updates the “oldLink? in the Association object’s link set, replacing the Instance object at “positionEnd? with “newObject.?

    The “oldLink? parameter should be encoded as per 10.2.1.4, “The Link Encoding Pattern,? on page 250. “Wrong Type? occurs if the link’s encoding is not correct.

   The “positionEnd? parameter should denote an AssociationEnd of this object’s Association. One of “Invalid Designator,? “Wrong Designator Kind,? or “Unknown Designator? occurs if thus is not the case.

   “Not Changeable? occurs if the "positionEnd" AssociationEnd that has “isChangeable? set to false. “Not Navigable? occurs if it has “isNavigable? set to false.

   The “newObject? parameter should be an Instance object that is type compatible with the type of the AssociationEnd denoted by “positionEnd.? “Wrong Type? occurs if this is not the case.

   The remaining error conditions are directly equivalent to error conditions for the corresponding “modify_<endName>? operation. Note that any structural constraints notionally apply to the final state following the operation, and not to any intermediate states.

   refRemoveLink

   The “refRemoveLink? operation removes the “oldLink? from the association.

   “Not Changeable? occurs if this operation is invoked on an Association that has “isChangeable? set to false for either AssociationEnd.

    The “oldLink? parameter should be encoded as per “The Link Encoding Pattern? on page 250. “Wrong Type? occurs if the link’s encoding is not correct.

   “NotFound,? “Nil Object,? and “Underflow? are directly equivalent to error conditions for the corresponding specific “remove? operation. “Invalid Object? and “Inaccessible Object? cannot occur, as in the specific operation.

   Interface

   interface RefAssociation : RefBaseObject { LinkSet ref_all_links () taises (MofError); boolean ref_link_exists (in Link some_link) raises (MofError); RefObjectUList ref_query (in DesignatorType query_end, in RefObject query_object) raises (MofError); void ref_add_link (in Link new_link) raises (MofError);

   void ref_add_link_before (in Link new_link, in DesignatorType position_end, in RefObject before)

    raises (NotFound, MofError);void ref_modify_link (in Link old_link, in DesignatorType position_end,

   in RefObject new_object)raises (NotFound, MofError); void ref_remove_link (in Link old_link)raises (NotFound, MofError); }; // end of interface RefAssociation

   The RefPackage interface is an abstraction for accessing a collection of objects and their associations. The interface provides an operation to access the meta-object description for the package, and operations to access the package instance's class proxy objects (one for each Class) and its association objects.

   Supertypes

   RefBaseObject

   Operations

   refClassRef

   The “refClassRef? operation returns the Class proxy object for a given Class.

   The “class? parameter should designate the M2 level Class whose Class proxy object is to be returned. “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator? occur in various situations where this is not the case.

   refAssociationRef

   The “refAssociationRef? operation returns an Association object for a given Association.

   The “association? parameter should designate the M2 level Association whose Association object is to be returned. “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator? occur in various situations where this is not the case.

   © ISO/IEC 2005 - All rights reserved

   refPackageRef

   The “refPackageRef? operation returns a Package object for a nested or clustered Package.

   The “package? parameter should designate the M2 level Package whose Package object is to be returned. It must either be nested within the Package for this Package object, or imported with “isClustered? set to true. “Invalid Designator,? “Wrong Designator Kind,? “Unknown Designator? occur in the situations where this is not the case.

   Interface interface RefPackage : RefBaseObject { RefObject ref_class_ref (in DesignatorType type) raises (MofError); RefAssociation ref_association_ref ( in DesignatorType association) raises (MofError); RefPackage ref_package_ref (in DesignatorType package) raises (InvalidDesignator) }; // end of interface RefPackage