Appendix B: Is-A and Has-A Relationships

I claimed on page 56 that one of the important differences between CIM and systems such as SNMP is the use of is a rather than has a in the modelling process. This appendix tries to justify that claim by considering the difference between these two ways of modelling: by comparing the relationship that "A is a B" (a shelf is a System Component) with the relationship "A has a B" (a shelf has cards).

To illustrate the difference between the approaches, we'll return to Joe's dog ownership which we discussed in Chapter 5. For your convenience, I have reproduced Figure 5.3 as Figure B.2.

Figure B.1 shows part of a diagram based on has a. It shows, for example, that a Human has a (or may have a) Domestic Dog. Note that this does not indicate that any particular human has a dog, only that dog ownership is something that may be associated with a human. In a more complex example, the information shown in Figure B.1 might be enough to allow an operator to associate a particular human with a particular dog, whereas an operator trying to associate a particular human with a particular elephant could be rejected with an error message because it does not fit the model.

Figure B.1: A Simple Has-A Relationship

Figure B.2: Fido with an Association (Is-A)

Note that Figure B.1 could equally well be inverted to indicate that a Domestic Dog has an owner.

Contrast Figure B.1 with Figure 5.2 on page 52. In the case of Figure B.1, the basic relationship between the classes is one of ownership ( has a ) whereas in Figure 5.2 it is one of is a.

Of course we need to add the actual instances of Joe and Fido to Figure B.1; see Figure B.3. You might think that it is unnecessary to create an association between Joe and Fido since Humans are able to own Domestic Dogs, Joe is a Human and Fido is a Domestic Dog; therefore Joe owns Fido. This breaks down, however, when we add Leslie. She owns a Domestic Dog called Spot. When we add Spot and Leslie to the diagram (see Figure B.4), it is no longer clear who owns which dog. To indicate this, we add ad hoc associations as in Figure B.5.

Figure B.3: Adding Instances to Has-A

Figure B.4: Connecting the Instances with Has-A

Figure B.5: Adding Another Association with Has-A

Now I will complicate matters further by assuming that there is some sort of relationship between Joe and Leslie; perhaps Joe joined the local dog club earlier than Leslie, and we need to model it. We now have to add another ad hoc relationship as also shown in Figure B.5.

It is now unclear precisely what purpose the original lines joining the classes in Figure B.1 are serving. If they were removed from Figure B.5, then would anything be lost from the diagram? The answer is that, in the manner that has a diagrams are used in device management, one important thing would be lost: addressability. There may be several items called Spot in a larger diagram and to identify the Domestic Dog called Spot uniquely I could use a name such as Human.DomesticDog.Spot. If the lines joining the classes together are removed then some other way must be found for identifying a particular instance uniquely.

The has a class diagram effectively gives prominence to one association between humans and domestic dogs, the has a (or "owns") relationship. Other relationships, for example, is heavier than or is married to or joined the dog club earlier than, have to be handled in an ad hoc fashion.

The has a representation also has another drawback: as can be seen from Figure B.5, it effectively requires one tree for classes and a second tree for instances. For clarity, I have separated them in Figure B.6.

Figure B.6: The Class and Instance Trees

The has a relationship is the conventional (SNMP) way to represent management information: a rack has a shelf which has a slot which has a card which has a processor which has an instance of the OSPF routing software which has a routing table, etc.

As we have seen, however, this approach leads to two separate tables: one containing the class structure ("a card can have a processor but a processor cannot have a rack") and one containing the particular instances of the classes. Here, the primary relationship is really is on.

This technique was applicable to the management of hardware because the items being managed were effectively static ”a card is on a shelf is probably inviolable ”but is less applicable to software, which is mobile, and services, which are much more abstract. It is, of course, necessary to express the card/slot/shelf has a relationship in CIM and this is handled by using associations; see Figure B.7.

Figure B.7: Has-A in CIM

In summary, several major distinctions between Figure B.2 and Figure B.6 can be drawn:

• In the is a model, there is one tree containing both the class definitions and the instances.

• If another dog and owner were to be added to the system, then this would effectively form a new instance sub-tree in Figure B.6 ”the instances could be drawn in a self-contained manner with owns relationships. If a new dog and owner were to be added to Figure B.2 then the owner and dog would be distributed throughout the diagram. This makes the additions harder but the final result more integrated.

• Instances are handled more cleanly in the is a model of Figure B.2. Instances are clearly objects derived from a particular class; the separate tables for classes and instances are not required. In the has a model of Figure B.6 their precise status is unclear: they effectively form a separate sub-tree.

• In the has a model, the manipulation of classes ("add a new class of routing algorithms") is basically different from the manipulation of instances ("add another OSPF instance to processor 23") ”the former having to be done by a programmer and the latter by an operator. As system management moves towards service management, the class structure will need to be modified by the operator rather than by the equipment supplier and the combination of the class and instance tables will become a useful simplification.

• Particular relationships (e.g., marriages) are instances of first-class objects in Figure B.2 and can therefore be manipulated as objects ("list all Spot's relationships" or "list all people who have a domestic dog").

  The addition of a relationship (e.g., "is married to") is quite difficult and somewhat ad hoc in the has a model; each instance needing to be changed to provide another pointer to the specific person (i.e., instance) to whom he or she is married. It is not clear where the rules about this relationship (men/women may only marry women/men, ^[1] a man/woman may only be married to one woman/man, a man/woman need not be married to any woman /man) are to be held. If an attempt is made to add the relationship "A is married to B" then this needs to be rejected if A is already married to C.

  In the is a model of Figure B.2, by contrast, the is married to relationship could clearly contain the rules regarding the creation of the relationship, for example, that an is married to relationship cannot be created for a person if that person already has one; that would be bigamy! These rules would be inherited by all instances (and A's proposed illegal marriage to B would be detected and prevented).

These differences between the two representations are summarised in Table B.1.

Table B.1: Comparison of is a and has a

	Has A	Is A
Abstraction	Structural	Behavioural
Inheritance	Subtyping	Subclassing
Number of Trees	Two: instances handled separately from classes	One: instances handled with classes
Adding new type of device	Easy: make new sub-tree	More difficult: determine where the new classes fit into existing model
Management of	Devices	Devices, processes and services
Relationships	ad hoc and static	Integral and malleable

^[1] Except in Canada.