Class CIM_CollectionOfMSEs
extends CIM_Collection

The CollectionOfMSEs object allows the grouping of Managed SystemElements for various identification purposes and to reduce the complexity of associating Settings and Configurations. It is abstract to require further definition and semantic refinement in subclasses. The CollectionOfMSEs object does not carry any state or status information, but only represents a grouping or 'bag' of Elements. For this reason, it is incorrect to subclass groups that have state/ status from CollectionOfMSEs - an example is CIM_Redundancy Group (which is subclassed from LogicalElement). Collections typically aggregate 'like'objects, but are not required to do so. They simply identify 'bags' and may represent an optimization. This is especially true with respect to their association to Settings and Configurations. Without Collections, one is forced to define individual ElementSetting andElementConfiguration associations, to tie Settings and Configuration objects to individual ManagedSystemElements. There may be much duplication in assigning the same Setting to multiple objects. In addition, using the Collection object allows the determination that the Setting and Configuration associations are indeed the same for the Collection's members. This information would otherwise be obtained by defining the Collection in a proprietary manner, and then querying the ElementSetting and ElementConfiguration associations to determine ifthe Collection set is completely covered.

Class Hierarchy

CIM_ManagedElement
   |
   +--CIM_Collection
   |
   +--CIM_CollectionOfMSEs

Direct Known Subclasses

CIM_LogicalNetwork
CIM_IPSubnet
CIM_LANSegment
CIM_IPXNetwork
CIM_IPAddressRange
CIM_BufferPool
CIM_BGPCluster
CIM_BGPPeerGroup
CIM_DiskGroup

Class Qualifiers

NameData TypeValueScopeFlavors
AbstractbooleantrueTOSUBCLASS= falseNone
DescriptionstringThe CollectionOfMSEs object allows the grouping of Managed SystemElements for various identification purposes and to reduce the complexity of associating Settings and Configurations. It is abstract to require further definition and semantic refinement in subclasses. The CollectionOfMSEs object does not carry any state or status information, but only represents a grouping or 'bag' of Elements. For this reason, it is incorrect to subclass groups that have state/ status from CollectionOfMSEs - an example is CIM_Redundancy Group (which is subclassed from LogicalElement). Collections typically aggregate 'like'objects, but are not required to do so. They simply identify 'bags' and may represent an optimization. This is especially true with respect to their association to Settings and Configurations. Without Collections, one is forced to define individual ElementSetting andElementConfiguration associations, to tie Settings and Configuration objects to individual ManagedSystemElements. There may be much duplication in assigning the same Setting to multiple objects. In addition, using the Collection object allows the determination that the Setting and Configuration associations are indeed the same for the Collection's members. This information would otherwise be obtained by defining the Collection in a proprietary manner, and then querying the ElementSetting and ElementConfiguration associations to determine ifthe Collection set is completely covered.None TRANSLATABLE= true
Versionstring2.6.0TOSUBCLASS= falseTRANSLATABLE= true

Local Class Properties

NameData TypeQualifiers
NameData TypeValueScopeFlavors
Captionstring
DescriptionstringThe Caption property is a short textual description (one- line string) of the object.None TRANSLATABLE= true
MaxLenuint3264None None
CollectionIDstring
DescriptionstringThe identification of the Collection object. When subclassed, the CollectionID property can be overridden to be a Key property.None TRANSLATABLE= true
MaxLenuint32256None None
Descriptionstring
DescriptionstringThe Description property provides a textual description of the object.None TRANSLATABLE= true
ElementNamestring
DescriptionstringA user-friendly name for the object. This property allows each instance to define a user-friendly name IN ADDITION TO its key properties/identity data, and description information. Note that ManagedSystemElement's Name property is also defined as a user-friendly name. But, it is often subclassed to be a Key. It is not reasonable that the same property can convey both identity and a user friendly name, without inconsistencies. Where Name exists and is not a Key (such as for instances of LogicalDevice), the same information MAY be present in both the Name and ElementName properties.None TRANSLATABLE= true