Metaschema

The Unified Modeling Language (UML) is used to define the structure of the metaschema. In the discussion that follows, italicized words refer to objects in Metaschema Structure . The reader is expected to be familiar with UML notation (see Unified Modeling Language (UML) Notation ) and with basic object-oriented concepts in the form of classes, properties, methods, operations, inheritance, associations, objects, cardinality and polymorphism.

Definition of the Metaschema

• A Schema is a group of classes with a single owner. Schemas are used for administration and class naming. Class names must be unique within its owning schema.

• A Class is a collection of instances that support the same type, that is, the same properties and methods. Classes can be arranged in a generalization hierarchy that represents subtype relationships between Classes. The generalization hierarchy is a rooted, directed graph and does not support multiple inheritance.

  Classes can have Methods , which represent the behavior relevant for that Class. A Class may participate in Associations by being the target of one of the References owned by the Association. Classes also have instances (not represented in Metaschema Structure ).

• A Property is a value used to characterize instances of a class. A Property can be thought of as a pair of "get and "set" functions that, when applied to an object¹ return state and set state, respectively.

  A Method is a declaration of a signature (that is, the method name, return type, parameters), and in the case of a concrete class, may imply an implementation.

  A Trigger is a recognition of a state change, such as create, delete, update, or access of a Class instance; and update or access of a Property.

  An Indication is an object created as a side effect of a Trigger. Because Indications are subtypes of Class, they can have Properties and Methods and be arranged in a type hierarchy.

  An Association is a class that contains two or more References. It represents a relationship between two or more objects. Because of the way associations are defined, it is possible to establish a relationship between Classes without affecting any of the related Classes, that is, addition of an Association does not affect the interface of the related Classes. Associations have no other significance. Only Associations can have References. Associations can be a subclass of a non-association Class². Any subclass of an Association is an Association.

  References define the role each object plays in an Association. The reference represents the role name of a Class in the context of an Association. Associations support the provision of multiple relationship instances for a given object. For example, a system can be related to many system components.

  Properties and Methods have reflexive associations that represent Property and Method overriding. A Method can override an inherited Method, which implies that any access to the inherited Method will result in the invocation of the implementation of the overriding Method. A similar interpretation implies the overriding of Properties.

  Qualifiers are used to characterize Named Elements (for example, there are Qualifiers that define the type of a Property or the key of a Class). Qualifiers provide a mechanism that makes the metaschema extensible in a limited and controlled fashion. It is possible to add new types of Qualifier by the introduction of a new Qualifier name, thereby providing new types of metadata to processes that manage and manipulate classes, properties, and other elements of the metaschema. See below for details on the qualifiers provided.

  Figure: Metaschema Structure

  Metaschema Structure provides an overview of the structure of the metaschema. The complete metaschema is defined by the MOF found in CIM Metaschema . The rules defining the metaschema are listed below in 28 items:

  1. Every metaconstruct is expressed as a descendent of Named Element.

  2. A Named Element is made up of zero or more Characteristics. A Characteristic is a Qualifier that characterizes a Named Element.

  3. A Named Element can Trigger zero or more Indications.

  4. A Schema is a Named Element and can contain zero or more classes. A Class must belong to exactly one schema .

  5. A Qualifier Type (nor shown in Metaschema Structure ) is a Named Element and must be used to supply a type for a Qualifier (that is, a Qualifier must have a Qualifier Type). A Qualifier Type can be used to type zero or more Qualifiers.

  6. A Qualifier is a Named Element and has a Value that can be thought of as a value plus a type. The type of the Qualifier Value must agree with the type of the Qualifier Type.

  7. A Property is a Named Element and has exactly one Domain: the Class that owns the Property.

  8. A Property can have an Override relationship with another Property from a different class. The Domain of the overridden Property must be a super-type of the Domain of the overriding Property.

  9. The Class referenced by the Range association (see References, Ranges, Domains, and Inheritance ) of an overriding Reference must be the same as, or a subtype of, the Class referenced by the Range associations of the Reference being overridden.

  10. The Domain of a Reference must be an Association.

  11. A Class is a type of Named Element. A Class can have instances (not shown on the diagram) and is the Domain for zero or more Properties. A Class is the Domain for zero or more Methods.

  12. A Class can have zero or one Supertype and zero or more Subtypes.

  13. An Association is a type of Class (Associations are Classes with an Association qualifier).

  14. An Association must have two or more references.

  15. An Association can inherit from a non-Association class.

  16. Any subclass of an Association is an Association.

  17. A Method is a Named Element and has exactly one Domain: the Class that owns the Method.

  18. A Method can have an Override relationship with another Method from a different class. The Domain of the overridden Method must be a superclass of the Domain of the overriding Method.

  19. A Trigger is an operation that is invoked on any state change, such as object creation, deletion, modification or access, or on property modification or access. Qualifiers, Qualifier Types, and Schemas may not have triggers. The operation that invokes a trigger is specified as a qualifier.

  20. An Indication is a type of Class and has an association with zero or more Named Triggers that can create instances of the Indication.

  21. Every metaschema object is a descendent of Named Element and, as such, has a Name. All names are case insensitive. The rules applicable to Name vary depending on the creation type of the object:

      1. Fully-qualified Class Names are unique within the repository. (See the discussion of schemas later in this section)

      2. Fully-qualified Association and Indication Names are unique within the repository (implied by the fact that Associations and Indications are subtypes of Class).

      3. Implicitly defined Qualifier Names are unique within the scope of the characterized object (that is, a Named Element may not have two Characteristics with the same Name). Explicitly defined Qualifier Names are unique within the defining Schema. An implicitly defined qualifier must agree in type, scope, and flavor with any explicitly define Qualifier of the same name.

      4. Trigger names must be unique within the property, class or method to which the Trigger applies.

      5. Method and Property names must be unique within the Domain Class. A class can inherit more than one property or method with the same name. Property and method names can be qualified using the name of the declaring class.

      6. Reference Names must be unique within the scope of their defining Association. Reference Names obey the same rules as Property Names. It should be noted that reference names are not required to be unique within the scope of the related class. In such a scope, the reference provides the name of the class within the context defined by the association.

         It is legal for the class System to be related to Service by two independent Associations (Dependency and Hosted Services, each with roles System and Service). It would not be legal for Hosted Services to define another Reference Service to the Service class, since a single association would then contain two references called Service.

         Figure: Reference Naming

  22. Qualifiers are Characteristics of Named Elements. A Qualifier has a Name (inherited from Named Element) and a Value. The Value is used to define the characteristics of the characterized Named Element. For example, a Class might have a Qualifier with the Name "Description", the Value of which is the description for the Class. A Property might have a Qualifier with the Name "Units", which has Values such as "Bytes" or "KiloBytes." The Value can be thought of as a variant (that is, a value plus a type).

  23. Association and Indication are types of Class; as such can be the Domain for Methods, Properties, and References (that is, Associations and Indications can have Properties and Methods in the same way as that of a Class). Associations and Indications can have instances. The instance of an Association has a set of references that relate one or more objects. An instance of an Indication represents the occurrence of an event, and is created as a result of that occurrence - usually by a Trigger. The key of an association is whatever is specified as its keys - typically this will be the concatenation of all of its references, though in some cases associations are possible that have a unique identifier of their own. Indications are not required to have keys. Typically Indications are very shortlived objects used to communicate information to an event consumer.

  24. A Reference has a Range that represents the type of the Reference. For example, in the model of PhysicalElements and PhysicalPackages, there are two References: ContainedElement, which has PhysicalElement as its Range and Container as its Domain, and ContainingElement, which has PhysicalPackage as its Range and Container as its Domain.
      Figure: References, Ranges, and Domains

  25. A Class has a Subtype-Supertype association that represents substitutability relationships between the Named Elements involved in the relationship. The association implies that any instance of a subtype can be substituted for any instance of the supertype in an expression without invalidating the expression.

      Revisiting the Container example: Card is a Subtype of PhysicalPackage. Therefore, Card can be used as a value for the Reference ContainingElement (that is, an instance of Card can be used as a substitute for an instance of PhysicalPackage).

      Figure: References, Ranges, Domains, and Inheritance

      A similar relationship can exist between Properties. For example, given that PhysicalPackage has a Name property (which is a simple alphanumeric string), Card Overrides Name to a name of alpha-only characters.

      The same idea applies to Methods. A Method that overrides another Method must support the same signature as the original Method and, most importantly, must be substitutable for the original method in all cases.
      

  26. The Override relationship is used to indicate the substitution relationship between a property or method of a subclass and the overridden property or method inherited from the superclass. This is the opposite of the C++ convention in which the superclass property or method is specified as virtual, with overriding occurring thereafter as a side effect of declaring a feature with the same signature as the inherited virtual feature.

  27. The number of references in an Association class defines the "arity" of the Association. An Association containing two references is a binary Association; an Association containing three references is a ternary association. Unary Associations (Associations containing one reference) are not meaningful. Arrays of references are not allowed. When an association is sub-classed, its "arity" cannot change.

  28. Schemas provide a mechanism that allows ownership of portions of the overall model by individuals and organizations who are responsible for managing the evolution of the schema. In any given installation, all classes are mutually visible, regardless of schema ownership. Schemas have a universally unique name. The schema name is considered part of the class name. The full class name (that is, class name plus owning schema name) is unique within the namespace and is referred to as the fully-qualified name (see Class Names ).

Property Data Types

Intrinsic Data Types shows the intrinsic data types and their interpretation:

Date, Time, and Interval Types

 

yyyymmddhhmmss.mmmmmmsutc

where:

• yyyy is a 4 digit year

• mm is the month

• dd is the day

• hh is the hour (24-hour clock)

• mm is the minute

• ss is the second

• mmmmmm is the number of microseconds

• s is a "+" or "-" indicating the sign of the UTC correction field (Universal Coordinated Time is, for all intents and purposes, the same as Greenwich Mean Time), or a ":". In this case, the value is interpreted as a time interval, and yyyymm are interpreted as days.

• utc is the offset from UTC in minutes (using the sign indicated by s). It is ignored for a time interval.

For example, Wednesday, May 25, 1998, at 1:30:15 PM EDT would be represented as:

 

19980525133015.0000000-300

Values must be zero-padded so that the entire string is always the same 25-character length. Fields which are not significant must be replaced with asterisk characters.

Similarly, intervals use the same format, except that the interpretation of the fields is based on elapsed time. For example, an elapsed time of 1 day, 13 hours, 23 minutes, and 12 seconds would be:

 

00000001132312.000000+000

A UTC offset of zero is always used for interval properties.

The string-based interval format is:

 

ddddddddhhmmss.mmmmmm:000

Indicating Additional Type Semantics with Qualifiers

 

class Acme_Example
{
        [counter]  
    uint32 NumberOfCycles;
        [gauge] 
    uint32 MaxTemperature;
        [octetstring, ArrayType("Indexed")] 
    uint8 IPAddress[10];
};

Implementers are permitted to introduce arbitrary qualifiers in this manner, for documentary purposes. The semantics are not enforced.

Supported Schema Modifications

1. A Class can be added to or deleted from a schema.

2. A Property can be added to or deleted from a class.

3. A Class can be added as a subtype or supertype of an existing class.

4. A Class can become an association as a result of the addition of an ASSOCIATION qualifier and two or more references.

5. A Qualifier can be added to or deleted from any Named Element.

6. The Override qualifier can be added to or removed from a property or reference.

7. A Class can alias a property (or reference, if the class is a descendent of Association) using the Alias qualifier. Both inherited and immediate properties of the class may be aliased.

8. A Method can be added to a class.

9. A Method can override an inherited method.

10. Methods can be deleted and the signature of a method can be changed.

11. A Trigger may be added to or deleted from a class.

In defining an extension to the schema, the schema designer is expected to operate within the constraints of the classes defined in the Core schema. With respect to classification, any component of a system added to the schema must be defined as a subclass of an appropriate Core schema class. It is expected that the schema designer will address the following question to each of the Core schema classes:

Schema Versions

• Deletion of classes, properties, or methods

• Movements of a class anywhere other than down a hierarchy

• Alteration of property type or method signature

• Alterating reference range to anything other than a supertype of the original specification

Other alterations are considered to be interface preserving. Any use of the schema changes listed above implies the generation of a new major version of the schema (as defined by the VERSION qualifier described in Standard Qualifiers ).

Class Names

 

<schema name><class name>

An underscore is used as a delimiter between the <schema name> and the <class name>. The delimiter is not allowed to appear in the <schema name> though it is permitted in the <class name>.

The format of the fully qualified name is intended to allow the scope of class names to be limited to a schema, that is the schema name is assumed to be unique and the class name is only required to be unique within the schema. The isolation of the schema name using the underscore character allows user interfaces to conveniently strip off the schema where the schema is implied by the context.

Examples of fully qualified class names are:

Qualifiers

The following sections describe meta, standard, optional and user-defined qualifiers. When any of these qualifiers are used in a model, they must be declared in the MOF file before being used. These declarations must abide by the details (name, applied to, type) specified in the tables below. It is not valid to change any of this information for the meta, standard and optional qualifiers. It is possible to change the default values. A default value is the assumed value for a qualifier when it is not explicitly specified for particular model elements.

Metaqualifiers

Standard Qualifiers

It is also important to recognize that not all of these qualifiers can be used together. First, as indicated in the table, not all qualifiers can be applied to all metamodel constructs. These limitations are identified in the "Applies To" column of the following table. Second, for a particular metamodel construct like associations, the use of the legal qualifiers may be further constrain because some qualifiers are mutually exclusive or the use of one qualifier implies some restrictions on the value of another qualifier, etc. These usage rules are documented in the "Meaning" column of the table. Third, legal qualifiers are not inherited by metamodel constructs. For example, the MAXLEN qualifier that applies to properties is not inherited by references.

The "Applies To" column in the table identifies the metamodel construct(s) that can use a particular qualifier. For the qualifiers like ASSOCIATION discussed in the previous section, there is an implied usage rule that the metaqualifier must also be present. For example, the implicit usage rule for the AGGREGATION qualifiers is that the ASSOCIATION qualifier must also be present.

Optional Qualifiers

These optional qualifiers are defined to avoid deployment of random user-defined qualifiers for these recurring situations.

User-Defined Qualifiers

Mapping MIF Attributes

Every MIF group contains a unique identification that is defined using the class string which is defined as follows:

 

defining body|specific name|version

where defining body is the creator and owner of the group, specific name is the unique name of the group and version is a three digit number that identifies the version of the group definition. In addition, each attribute has a unique numeric identifier starting with the number one.

The mapping qualifier can therefore be represented as a string that is formatted as follows:

 

MIF.defining body|specific name|version.attributeid

where MIF is a constant defining this as a MIF mapping followed by a dot. This then followed by the class string for the group this defines and optionally followed by a dot and the identifier of a unique attribute.

In the case of a Domain Mapping, all of the above information is required, and provides a way to map an individual MIF attribute to a particular CIM Property.

In the case of the recast mapping, a CIM class can be recast from a MIF group and only the MIF constant followed by the dot separator followed by the class string is required.

For example, a Domain Mapping of a DMTF MIF attribute to a CIM property could be as follows:

 

[MAPPINGSTRING("MIF.DMTF|ComponentID|001.4"),READ]
SerialNumber = "";

The above declaration defines a mapping to the SerialNumber property from the DMTF Standard Component ID group's serial number attribute. Because the qualifiers of CIM are a superset of those found in MIF syntax, any qualifier may be overridden in the CIM definition.

To recast an entire MIF group into a CIM Object, the mapping string can be used to define entire Class. For example:

 

[MAPPINGSTRINGS {"MIF.DMTF|Software Signature|002"}]
class MicroSoftWord : SoftwareSignature
{
   ...
}

Mapping Generic Data to CIM Properties

For the IETF case, the ASN.1 module name, not the RFC number, should be used as the MIB name. For example, instead of saying RFC1493, the string "BRIDGE-MIB" should be used). This is also true for the case of a company name being used as the naming authority. For the case of using a management protocol like SNMP, the SNMP OID can be used to identify the appropriate SNMP variable. This latter is especially important for mapping variables in private MIBs.

It should be noted that the concept of a naming authority for mapping data other than SNMP data into CIM properties could be derived from this requirement. As an example, this can be used to map attributes of other data stores (like directories) using an application-specific protocol (for example, LDAP).

The syntax for mapping MIF attributes as defined in Mapping MIF Attributes is as follows:

 

MIF.<defining_body | specific_name | version>.attributeid

The above MIF format can be reconciled with the more general syntax needed to map generic data to CIM properties by realizing that both forms can be represented as follows:

 

<Format>.<Scoping_Name>.<Content>

where:

• Format defines the format of the entry. It has the following values:

  MIF

  The rest of the string is interpreted as MIF data.

  MIB

  The rest of the string is interpreted as a variable. name of a MIB

  OID

  The rest of the string is interpreted as an OID that is defined by a particular protocol to represent a variable name.

• Scoping_Name defines the format used to uniquely identify the entry. It has the following values:

  defining_body | specific_name | version

  
  Used for MIF mappings.

  Naming_Authority | MIB_Name

  
  Used for MIB mappings.

  Naming_Authority | Protocol_Name

  
  Used for protocol mappings that use OIDs to represent a variable name.

• Content defines the value of the entry. It has the following values:

  attributeid

  
  Used for MIF mappings.

  Variable_Name

  
  Used for MIB mappings.

  OID

  Used for protocol mappings.

Here are two examples of the syntax. The first uses the MIB format and looks as follows:

 

[Description ("OperatingSystem's notion of the local date and time of
day"),
    MappingStrings {"MIB.IETF | HOST-RESOURCES-MIB.hrSystemDate"}]
datetime LocalDateTime;

The second example uses the OID format and looks as follows:

 

[Description ("OperatingSystem's notion of the local date and time of
day"),
    MappingStrings {"OID.IETF | SNMP.1.3.6.1.2.1.25.1.2"}]
datetime LocalDateTime;

Footnotes

1.

Note the equivocation between "object" as instance and "object" as class; this is common usage in object-oriented documents, and reflects the fact that in many cases, operations and concepts may apply to or involve both classes and instances.

2.

Associations should not be declared as subtypes of classes that are not associations. This feature may be disallowed by future versions of the CIM standard.