3 Building an adequate Object Model

After the transformation of ASN.1 templates into OMG IDL and their integration into the CASE-tool have been performed, we can now start our re-engineering of the CORBA agent. Recall that the goal of our work is a management agent which fulfills the criteria of an object-oriented system as much as possible. The critical items to be addressed in this section can be described as follows:

1.

The first object model almost completely lacks hierarchical relationships between the 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 Structure of Management Information (SMI) lacks inheritance is the cause of 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; thus, it is 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 that is met in the first version of our object model is encapsulation. If this object model is given to an IDL-compiler, implementation skeletons with every attribute flagged as private are generated. However, these would be accessible only via get- or set-operations i.e. the attributes are not accessible by other means than the ones provided by the implementor.