UML for CIM

I use examples from the DMTF's standard models in this section to show their UML representation. Although I give some explanation, it is not necessary for you to understand fully what the models mean ”just to understand the UML nomenclature that they are illustrating.

A model can be expressed in CIM in two ways: graphically using the Unified Modelling Language (UML) or textually using a language called mof . I describe each of these representations in the next sections.

The Unified Modelling Language

The Unified Modelling Language (UML) is a graphical language standardised by the Object Management Group (OMG) which is used to "visualise, specify, construct, and document" the structure of a system. There are many books about UML and the Object Management Group's Web site ( http://www.omg.org ) contains links to a number of tutorials. In fact, the amount of UML that you need to read and write CIM models is so small that if your only reason for learning UML is to read and write CIM, then this chapter should suffice.

UML for Classes and Subclasses

We have already seen examples of classes in UML notation ”domestic dogs and IP routing tables. Figure 5.7 shows the general structure of a class in UML: a rectangle divided into three parts :

1. The highest subdivision contains the name of the class. The name may be written in italics to indicate that that class cannot have instances: it can only be a superclass of other classes.

   Within CIM, a class name has structure, being composed from a so-called schema name, an underscore , and a class name. A schema is another word for a (sub-) model and so, for example, all of the CIM classes are of the form: CIM_classname , where CIM is the schema and classname, reasonably, the class name. If you create a sub-model for your company's products, to avoid potential clashes with the names of other classes which you may inherit, you should use a trademarked name as the schema name.

   If, for example, you work for the ACNE Manufacturing Company, then you might choose the term ACNE for your schema. In that case any classes you create would have a name with the format ACNE_classname. Of course, such a class may inherit from a class in the CIM schema.

2. The middle subdivision lists some or all of the properties that characterise the class.

3. The lowest subdivision lists some or all of the actions (" methods ") that the class supports (i.e., the functions it can perform). The right-hand side of Figure 5.7 shows the example of the DomesticDog class taken from Figure 5.2 on page 52.

Figure 5.7: UML Representation of a Class

The next notation is that of linking classes together to indicate that a subclass is a particular class. This is illustrated in Figure 5.2: simply an open -headed arrow joining the subclass to the class. That figure shows that a Dachshund is a DomesticDog (as is a Poodle).

UML for Associations

Although UML itself is a very rich language with symbology for many types of diagrams, there are only a few more notations you need to understand when reading and writing CIM diagrams: those for the various types of association.

Although an association is a class in CIM, it is generally not drawn using the rectangular box that designates a class; it is rather shown as a simple line between the classes which it associates . Figure 5.8, for example, taken from the DMTF's User Model, shows that an instance of the class CIM_SecurityService (which is a CIM_Service, which is a CIM_LogicalDevice ) may be associated with an instance of the class CIM_System through an instance of the association CIM_SecurityServiceForSystem. What this means is that a particular CIM_System may be associated with a particular CIM_SecurityService.

Figure 5.8: UML Representation of an Association

Another point to note in Figure 5.8 is the star appearing at the end of the association line. This indicates that any number from 0 upwards may be part of the association. For example, one CIM_System may have any number of CIM_SecurityServices, including none. Also, one CIM_SecurityService may be associated with any number of CIM_Systems. Other symbols which could appear at the end of an association include "1" (i.e., exactly 1) and "3..5" (between 3 and 5 inclusive).

Because an association is, in fact, a class within CIM, it is occasionally necessary to indicate that it has properties other than the references to the things it associates. These are drawn under the association's name or close to the association's line and connected to it by a further line. An example is given in Figure 6.8 on page 109 where CIM_PolicyConditionInPolicyRule has two attributes: GroupNumber and ConditionNegated.

UML for Aggregation

Another notation which is sometimes useful is "aggregation": this is the extension of the has a concept in the is a model because aggregation is just a special type of association. Figure 5.9 illustrates a particular aggregation taken from the standard CIM device model.

Figure 5.9: UML Representation of an Aggregation

The lines with the open diamonds indicate aggregation, with the diamond being at the "contains" end. Figure 5.9 shows that a CIM_DiskGroup may contain ( has a ) an aggregation of CIM_StorageExtents. ^[5] It may also contain an aggregation of CIM_DiskDrives. It may also, recursively, contain an aggregation of itself, of CIM_DiskGroups.

Figure 6.8 on page 109 also uses an "aggregation diamond": in this case, to show that a CIM_PolicyRule (never mind what this is at the moment, have faith that all will become clear later) aggregates CIM_PolicyConditions and CIM_PolicyActions.

You will see later in this chapter that classes, methods, and properties may have so-called qualifiers attached to them. These qualifiers typically give additional information about the class, method, or property, restricting, for example, a numerical value to be less than 42. There is a special qualifier, AGGREGATION , which may be added to the mof definition of an association to indicate that it represents an aggregation.

UML for Composition

There is a particularly strong type of aggregation: "composition." This is illustrated in Figure 5.10 where the filled diamond means that a CIM_UnitaryComputerSystem (a desktop, mobile, NetPC, server or other type of a single node computer) may include an aggregation of CIM_Processors; the processors exist within the CIM_UnitaryComputerSystem and are dependent on it, being created and destroyed when it is. A CIM_Processor, which incidentally is a CIM_LogicalDevice, really has no life outside of a CIM_UnitaryComputerSystem.

Figure 5.10: UML Representation of a Composition

On some of the DMTF's drawings, a "diamond with a dot" notation is also sometimes used for composition; see Figure 5.11.

Figure 5.11: Alternative UML Representation of a Composition

^[5] The term StorageExtent describes a collection of storage devices (disks, etc.) used together to create a single logical storage device.