Möglichst realitätsgetreue Modellierung der Objektbeziehungen

Hinsichtlich der Beziehungen zwischen Klassen weist die erste Version der Objektmodells dieselben Defizite auf, wie die SNMP-MIB: Es ist keinerlei Vererbungshierarchie vorhanden; 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- oder Containment-Baumes wurde 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 ,,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 n$\ge$1), jedoch kann es beliebig viele permanentStorageDevices besitzen (in diesem Fall eine 1:n-Beziehung mit n$\ge$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$\ge$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 Oberklasse gehabt hätte. Abbildung 4 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 enthielt in der SNMP-MIB Attribute, die benutzerspezifische Quoten für Betriebsmittel wie zum Beispiel Plattenplatz darstellen. Dies war semantisch eigentlich nicht korrekt, da eine Quota keine Eigenschaft eines Benutzers ist, sondern eine Eigenschaft der Beziehung zwischen einem Benutzer und einem Dateisystem. Aus diesem Grunde wurden die entsprechenden Attribute ausgelagert und unter der Assoziationsklasse Quota zusammengefaßt. Abbildung 5 veranschaulicht dies.

  

Abbildung: Anwendung von OMT-Assoziationsklassen