3 Building an adequate object model

In addition to the transformations cited in the previous section, there are obviously some open issues for the design of the CORBA agent. Remember that the goal of our work is an agent which fulfills as much as possible the criteria of an object-oriented system. The critical items to be addressed can be described as follows:

1.

The first object model lacks almost completely (apart from one exception) a hierarchy between the several object classes.
The containment relationship between different classes applies only to the System class; the model doesn't have inheritance. As a consequence, polymorphism is not supported, too. Thus, three out of the four main principles of the object-oriented paradigm are not fulfilled. This is a consequence of the Internet information model which has no notion of containment and inheritance relationships between object classes.

2.

The "type" variables are not in accordance with the principles of object-oriented design.
Examples of such "type" variables in the above described MIB extract are Type in the Storage class and Type in the Device class. Although it is possible to distinguish between different kinds of the Storage object class (like RAM, hard disks, tapes or diskettes) by setting the Type variable appropriately, the specifics of each kind of media are not reflected correctly. In object-oriented modeling, this can easily be expressed through the concept of inheritance. The fact that the Internet information model lacks inheritance is the cause for this anomaly.

3.

The problem of ''pushbutton'' variables is still there.
The setting of a variable with a specific value results in the execution of an operation; it is therefore difficult to understand the meaning of some attributes. This stems from the fact that SNMP has no action protocol data unit.

4.

The data types of the attributes are restricted to the base ASN.1 types.
Even attributes with a restricted range of potential values like e.g., OpState or AdState of the Processor object class are bound in the first version of the object model to an integer data type. While this may sound like a ''cosmetic'' problem, it is important to restrict the value ranges of attributes with respect to conformance testing.

The only principle of object-oriented design which is met in the first version of our object model is encapsulation. If this object model had been the input to the IDL-compiler, implementation skeletons would have been generated where every attribute is flagged as private. These would have been accessible only via get- or set-operations i.e. the attributes are not accessible by other means than the ones provided by the implementor.