The CollectionOfMSEs object allows the grouping of ManagedSystemElements for the purposes 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_RedundancyGroup (which is correctly subclassed from LogicalElement).
Collections typically aggregate 'like' objects, and represent an optimization. Without Collections, one is forced to define individual ElementSetting and ElementConfiguration 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 if the Collection set is completely covered.
CIM_CollectionOfMSEs - child subclasses in ROOT\cimv2
'The CollectionOfMSEs object allows the grouping of ManagedSystemElements for the purposes 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_RedundancyGroup (which is correctly subclassed from LogicalElement). Collections typically aggregate 'like' objects, and represent an optimization. Without Collections, one is forced to define individual ElementSetting and ElementConfiguration 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 if the Collection set is completely covered.'