Hinsichtlich der Beziehungen zwischen Klassen weist die erste Version der Objektmodells dieselben Defizite auf, wie die SNMP-MIB: Es existiert keinerlei Vererbungshierarchie; Containment-Hierarchien sind nur ansatzweise vorhanden. Ein Grundgedanke des objektorientierten Paradigmas ist es jedoch, die reale Welt, d.h. die einzelnen Objekte sowie ihre Beziehungen zueinander, möglichst gut abzubilden. Die Einführung einer Vererbungshierarchie ist ein Modell für den Sachverhalt, daß eine Systemkomponente eine Spezialisierung einer anderen ist. So ist z.B. ein Mikroprozessor eine Spezialisierung eines Gerätes (Device).
Zur Wurzel des Enthaltenseins- bzw. Containment-Baumes wird die Klasse
System bestimmt. Dies entspricht auch der Realität: Ein
(End-)System ist diejenige Hauptkomponente, die andere Teilkomponenten
enthält. Dabei sollten Enthaltenseinsbeziehungen der Objektklasse
System mit möglichst spezialisierten Klassen bestehen, also
Klassen, die sich im Vererbungsbaum weiter ,,unten`` befinden. Damit
können die einzelnen Beziehungen individuell gestaltet werden: So
benötigt ein System mindestens einen Prozessor (hier also eine
1:n-Beziehung mit n1), jedoch kann es beliebig viele
permanentStorageDevices besitzen (in diesem Fall eine 1:n-Beziehung
mit n
0). Ein Drucker wiederum ist kein unmittelbarer Bestandteil
eines Systems (im Sinne einer Workstation), sondern ein
Peripheriegerät. Hier besteht also keine
Aggregationsbeziehung , sondern eine
einfache 1:n-Beziehung mit n
0. Wäre die Beziehung zwischen
System und ,,höher`` liegenden Klassen modelliert worden, so wäre
eine individuelle Gestaltung nicht möglich gewesen, da jede Subklasse
dieselbe Beziehung zu System wie die entsprechende Superklasse
gehabt hätte. Abbildung
gibt einen Überblick
über die Beziehungsstruktur eines Teils des optimierten
Objektmodells.
Eine weitere Besonderheit findet sich in der Beziehung zwischen den
Klassen Filesystem und Account (vormals die
User-Klasse). Die Klasse Account enthält in der SNMP-MIB
Attribute, die benutzerspezifische Quoten für Betriebsmittel wie zum
Beispiel Plattenplatz darstellen. Dies ist semantisch nicht
korrekt, da Quoten keine Eigenschaft eines Benutzers sind, sondern
eine Eigenschaft der Beziehung zwischen einem Benutzer und einem
Dateisystem. Aus diesem Grund werden die entsprechenden Attribute
ausgelagert und unter der Assoziationsklasse Quota
zusammengefaßt. Abbildung veranschaulicht dies.