next up previous contents index
Next: 5. Neue Variablentypen für Up: Gewinnung eines geeigneten Objektmodells Previous: 3. Operationen anstelle von

4. 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 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 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 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.


  
Abbildung: Anwendung von OMT-Assoziationsklassen


next up previous contents index
Next: 5. Neue Variablentypen für Up: Gewinnung eines geeigneten Objektmodells Previous: 3. Operationen anstelle von
Copyright Munich Network Management Team