Modelling Terms

Most professions have taken words from the public domain and given them different meanings. When a mathematician and a wedding organiser use the phrase "a function in a field," for example, they probably mean very different things. Miscommunication increases when a "ring" is also thrown into the conversation.

The modelling world has also taken its jargon from common words and attached meanings related to, but not precisely the same as, the common usage. The next few paragraphs discuss the use of the terms class, inheritance, instance, property, method, association, indication, and object.

Class

The concept of class is fundamental to everything else. A class is an amalgam of characteristics defining a particular group of things (note my careful avoidance of the loaded word "object"). Domestic-Dog, for example, is a class. It does not mean any one particular dog (Fido or Patch), but describes a whole collection of dogs. There are characteristics that all domestic dogs could be assumed to have: a name and an owner, for example.

Class Inheritance

A class can have subclasses (also themselves classes). The class Dachshund, for example, might be a subclass of DomesticDog. A dachshund will have all the characteristics of a domestic dog (name, owner, etc.), but also some useful or important characteristics unique to itself: its clearance, for example, between belly and ground, measured in millimetres.

We say that the class Dachshund is a subclass of the class Domestic-Dog and that it inherits from DomesticDog. This concept of inheritance is important as it means that, when we define the class Dachshund, we do not need to repeat that dachshunds have a name and an owner; those characteristics are inherited from DomesticDog.

Subclassing in this manner is also sometimes called specialisation: Dachshund is a special type of DomesticDog.

Instances

Of course there are also actual dogs which belong to the Dachshund class: Fido, for example. Fido is said to be an instance of the class Dachshund. Because Dachshund is a subclass of DomesticDog, Fido is also, by inheritance, an instance of the class DomesticDog. Fido, therefore, can be expected to have a name, an owner and a value for his ground clearance.

It is important to notice the chain of "is-a" phrases: Fido is a Dachshund which is a DomesticDog. I explore the crucial difference between is a and has a in more detail on page 56 and in Appendix B because this is one of the major characteristics of CIM modelling and it represents a significant departure from the way in which SNMP models are produced. Figure 5.2 illustrates these relationships.

Figure 5.2: Fido without an Association

Properties

We have spoken of the characteristics of a class (e.g., name, owner, ground clearance). In CIM-speak, these are called properties. So, correctly, an instance of a class has the properties defined in its class and all of the classes from which its class inherits.

Methods

A method is another characteristic of a class: it represents a function that an instance of the class can be asked to perform. An instance of the DomesticDog class, for example, might know how to carry out the commands "sit!" and "beg!"

More usefully, a CIM_PrivilegeManagementService which, as its name suggests, holds information about the privileges of a particular user, can be asked to "AssignAccess" or "RemoveAccess" rights for a particular user . These functions are methods of the class.

Similarly, the CIM_LogicalDevice class, which represents the management information for a device, can accept the command "Reset!" ” this is therefore a method of the CIM_LogicalDevice class.

Associations

Continuing our dog example, we need to specify Fido's owner. We could do this by making the owner's name and address properties of a DomesticDog, and then set these values in Fido's instance. This is illustrated in Figure 5.2 where it can be seen that Joe owns Fido.

This technique would, however, be inefficient if Joe had several dogs: Joe's name and address would have to be repeated and, if his address changed, every occurrence of it would have to be found and modified. It would be better to store the owner Joe as an instance of a class DogOwner and then somehow link Fido's instance to it. This is illustrated in Figure 5.3. In CIM-speak, we say that we have "created an association" between the DomesticDog class and the DogOwner class.

Figure 5.3: Fido with an Association

Figure 5.3 contains an instance of a class called DogOwnership , which is an ^[3] association. The instance of the association links Joe's instance with Fido's. This separation of the association from either Fido or Joe, making it a separate entity, is another important characteristic of CIM, giving it its flexibility and extensibility. This association effectively adds has a into our model: an instance of DogOwnership says that a particular DogOwner has a particular DomesticDog or, equivalently, that a particular DomesticDog has a DogOwner.

The "pointers" held in the association, pointing to the associated items, are known in CIM-speak as references.

An important characteristic of associations as created as in Figure 5.3 is that the Dachshund and DogOwner classes have no cognisance of any association between them: associations can therefore be added to a running system without disturbing the classes already created.

Another important characteristic of associations is also illustrated in Figure 5.3; although the DogOwnership association is defined as being between a DomesticDog and a DogOwner , it is automatically inherited by subclasses of these. Thus an instance of a Dachshund, because it is also by inheritance a DomesticDog, can also have a DogOwnership association.

Note that, in addition to "normal" associations, CIM also contains the concept of a weak association. Because this type of association requires you to know about the concept of keys, I have deferred discussion of it until page 68.

Indications

We have nearly completed our vocabulary lesson ”there is just one more major topic: indication. The terms covered so far (class, instance, association) allow us to describe the dog and its properties (ground clearance and owner). There is a further concept needed to describe the signals which the dog may wish to pass to us. It may, for example, bark to indicate that it is hungry. Signals arising spontaneously from instances of a class are known as indications: the dog may indicate that it is hungry by barking. Similarly, a telecommunications link may signal that it has failed by raising an alarm.

In the same way that an association is just a special type of class, so is an indication. The indication class describes a type of indication that a managed object may raise ("I'm hungry," "I have failed," "I'm on fire") and an instance of the indication is created when that event occurs.

Outside the world of dogs, events might be the failure or recovery of a component (in which case the indication would generally be called an alarm), the creation or deletion of a class or instance by an operator or a set of accounting records being passed spontaneously from the device to its management system.

I treat the concept of an indication in Chapter 8: suffice it to say that when an alarm occurs on a device with CIM management, where any operator or logging system has registered an interest in knowing about that particular type of alarm, an instance of an indication class is created describing the alarm, giving details of its severity, date, and time of occurrence, etc. Programs known as handlers may be registered with the WBEM server to receive copies of Indications meeting certain criteria ("severity at least CRITICAL and temperature greater than 32C"). When an indication is signalled, the WBEM server checks to see which, if any, handlers have registered an interest in receiving a copy and passes the information to them.

Objects

After the careful descriptions of the terms class, association and instances given previously, the term object is a bit of an embarrassment. The term is commonly used as a synonym for "instance," but actually may refer either to a class or to an instance. The distinction is normally not important, but the intrinsic operations on associations (see page 136), unlike other intrinsic operations, can be applied to either classes or instances. It is useful to be able to say that they can be applied to "objects."

A CIM Example

Of course, CIM is not used primarily for modelling domestic animals. Taking an example from the standard network model produced by the DMTF, consider a class for describing Ethernet ports eponymously called CIM_EthernetPort, as illustrated in Figure 5.4.

Figure 5.4: The class CIM_EthernetPort

It is easy to imagine an instance of this class: a real Ethernet port on a network device. The class CIM_EthernetPort inherits from CIM_NetworkPort, which in turn inherits from CIM_LogicalPort. Thus a particular instance of an Ethernet port has all of the properties defined for the CIM_EthernetPort class (e.g., maximum data size ) but it also inherits all of the properties of the CIM_NetworkPort class (e.g., whether or not auto-sensing is possible) and all the properties of the CIM_LogicalPort class (e.g., maximum speed).

Notice again the concept of is a. Ethernet port 23 on my computer is a CIM_EthernetPort, which is a CIM_NetworkPort, which is a CIM_LogicalPort. I have also shown CIM_TokenRingPort in Figure 5.4 ”it is a CIM_NetworkPort as well.

^[3] OK, it is not always is a, sometimes it becomes is an.