Introduction to the Cisco DSL Manager Object Model

This chapter provides an overview of the Cisco DSL Manager (CDM) object model. This chapter also describes the basic design of the Cisco Element Manager Framework (EMF) common object model, on which CDM objects are based.

Design Overview

The object model includes views and their containment hierarchies, classes and their inheritance structure, and attributes for each class. The object model standardizes the modeling behavior of element manager software applications, which manage Cisco network equipment.

The object model uses inheritance, rather than aggregation, to model the capabilities for each object class. The inheritance form of object oriented programming allows classes to have superclasses and subclasses. When you develop an application, you can retain some of the attributes and methods of the superclass, called the parent class, while adding new attributes or choosing to omit certain attributes. Inheritance modeling allows for greater flexibility in defining each class. With some programming languages, an object can inherit functions and characteristics from more than one class.

A modeling design that is based on inheritance enables the common object model to work effectively within the constraints of the Cisco EMF. The inheritance-modeling design is preferable to the aggregation method of design for the following reasons:

The user can avoid having to navigate through multiple objects in order to gain access to the functional areas of a single physical device.
The developer of an element manager software application can more easily include the ability to query objects and can select objects based on their technical capability, because this capability is spread across multiple objects.
The use of aggregation results in the offering of menu services that are inappropriate to the physical device that is being modeled.
The use of aggregation results in multiple-state machines per physical device, causing development to be more complex.

The common object model uses class intermixing at the interface level, as opposed to type intermixing. Using class intermixing has the following advantages:

Allows Cisco EMF generic applications to query each of the classes that are combined within a class. This combination feature provides a flexible querying capability. For example, you can query for SONET-based interfaces in the system, which would return all interfaces that are combined within the SONET base class.
Allows dialog boxes whose object lists populate from a base class. This base class can be a combination of other base classes and can also have its own derived classes. Thus, the object list of the dialog box is populated with all base class objects or any base class derived classes. For example, a generic interface dialog box has an object list that is populated with a generic interface base class. An ATMoverSONET interface class derives from the generic interface base class; therefore any objects in the ATMoverSONET interface class appear on the object list of the generic interface dialog box.
Provides a straightforward way to model the Open System Interconnection (OSI) layers. This capability provides the flexibility to model multilayer interfaces in a way that can easily be extended, while preventing class number explosion.

Design Patterns

The design for the common object model includes a chassis and module design pattern and an interface design pattern. These topics are described in the following sections.

Chassis and Module Design Pattern

The common object model uses a recurring design pattern for the chassis and module classes. A diagram of the chassis and module design pattern is shown in Figure 1-1.

The implementation of a Cisco EMF class is encapsulated. Only classes that are derived from the abstractBaseClass are deployable. This class represents some physical device entity and also models the state machine for the device. Similarly, if you want to extend the class model with new classes, you derive the new classes from the abstractBaseClass rather than from the concreteBaseClass.

A class intermixing approach allows attributes of different abstract classes to be combined in an appropriate manner. Objects from each nonabstract class can be deployed (these are referred to as concrete classes). Concrete classes are the deployable classes; in other words, you can create objects from these classes.

The chassis and module classes always inherit from the CiscoGenericFunctionality class and therefore always have some generic management capability. Each concrete class also provides the state machine implementation.

Interface Design Pattern

The common object model uses a different design pattern for modeling interfaces than those that are used for chassis and modules. The interface design pattern is applied across all interfaces. A diagram of the interface design pattern is shown in Figure 1-2.

The interface design pattern uses the concept of layer classes and union classes:

A layer class defines both the virtual attributes and the implementation attributes.
A union class inherits from one or more layer classes, thus combining the capabilities that the classes provide. The union classes are deployable and cannot be specialized.

To extend the model, you can add sublayer classes and provide appropriate new union classes.

Table of Contents