next up previous contents
Next: Generische Klassen für verteilte Up: Ein Objektmodell für das Previous: Beziehungen zwischen den Klassen

4.3 Integration eines bestehenden Modells

 

Im folgenden Abschnitt wird beschrieben, wie ein vorhandenes Objektmodell für das integrierte Management von UNIX-Workstations durch die Wahl einer geeigneten Spezialisierungshierarchie in das in diesem Kapitel vorgestellte, auf ODP-Konzepten basierende, generische Objektmodell eingegliedert werden kann. Bisher wurden in einer Top-Down-Vorgehensweise aus den Viewpoints des RM-ODP unter Beachtung der Anforderungen aus den funktionalen Dimensionen des Managements generische Klassen herausgearbeitet, die als Basisklassen für das Management von Endsystemressourcen und verteilten Systemdiensten dienen sollen. Hierbei wurden noch keine bestimmten Systeme betrachtet. Im nächsten Schritt soll ein spezielles Objektmodell, welches sich durch entsprechende Implementierungen als geeignet für das Management von Systemressourcen eines heterogenen UNIX-Workstation-Clusters erwiesen hat, durch Spezialisierung an die Basisklassen angebunden werden. Dabei handelt es sich um ein Bottom-Up-Vorgehen, da anhand der gegebenen Managementinformation einer speziellen Ressource überlegt wird, welcher Anteil davon generell auf Ressourcen dieser Klasse angewendet werden kann. Gleichzeitig wird durch die vorhandene Implementierung sichergestellt, daß die modellierte Information auch tatsächlich durch die Ressource bereitgestellt wird. Wenn dieser Schritt gelingt, ist dadurch einerseits die Einführung der generischen Klassen gerechtfertigt und andererseits die angestrebte Anwendbarkeit der gewonnenen Managementinformation auch auf andere Systeme gegeben.

Holger Sirtl hat die Managementinformation der MNM-UNIX-MIB (siehe Abschnitt 3.7.2) in seiner Arbeit ,,Objektorientierte Modellierung von Workstations für ein integriertes Systemmanagement`` [Sir96] in ein OMT-Objektmodell überführt. Hierbei wurde nach folgendem Algorithmus vorgegangen. Für jede Gruppe der SNMP-MIB wurde eine Objektklasse im OMT-Modell kreiert. Die einfachen Datentypen einer SNMP-Gruppe wurden zu Attributen der betreffenden Objektklasse. Zum Beispiel wurde die Gruppe «System» mit den Objekttypen sysName und sysLocation zur Klasse System mit den Attributen Name und Location. SNMP-Tabellen wurden ebenfalls in Objektklassen überführt. Jede Zeile einer SNMP-Tabelle entspricht somit einer Instanz der Objektklasse. Die Variablen einer SNMP-Tabelle wurden wiederum zu Attributen der Objektklasse. Beispielsweise besitzt die SNMP-Tabelle, die die Prozeßtabelle der Workstation darstellt, u.a. die Felder processPID und processSize. Im OMT-Modell wird dagegen die Prozeßtabelle als Menge von Objektinstanzen einer Objektklasse Process mit den Attributen ID und Size modelliert. Natürlich generiert dieser Algorithmus kein echtes objektorientiertes Modell. Es fehlen Konzepte wie Aggregation, Spezialisierung (Vererbung) oder Methoden. Deshalb wurde das Modell manuell weiterbearbeitet. Vererbungshierachien wurden gebildet, indem gleiche Attribute in den aus den Gruppen erzeugten Objektklassen in eine Oberklasse geschoben wurden. Somit erben z.B. alle MOCs für spezielle Geräte die Statusattribute UsageState, AdminState und AvailState aus der gemeinsamen Oberklasse Device. Attribute, die aus sog. ,,Pushbutton-Variablen`` entstanden sind, das heißt, die durch Belegen des Attributs mit einem bestimmten Wert eine Aktion in der Ressource auslösen, wurden durch Methoden ersetzt. Die Methoden disable() und enable() der Klasse Device ersetzen somit die Zuweisung des Wertes «0» bzw. «1» an die bei vielen Geräten vorhandenen Variable action.

Das hieraus entstandende Modell zeigt die Abbildung A.4 im Anhang A. Im Mittelpunkt steht die zentrale Klasse System mit sternförmigen Aggregationsbeziehungen zu diversen Spezialisierungen der Klasse Device. Diese Modellierung bildet die Realität in der Hinsicht korrekt ab, daß eine Workstation aus verschiedenen Geräten wie Prozessor, Arbeitsspeicher, Festplatten etc. aufgebaut ist. Die Assoziation zwischen System und Process modelliert die von einer Workstation ausgeführten Prozesse. Aktive Benutzer einer Workstation werden durch die Beziehungsklasse ActiveUser zwischen System und der Klasse Account dargestellt. Die bekannte UNIX-Dateisystemhierarchie wird durch Instanzen der Klassen Filesystem - als Oberklasse für verschiedene Typen von Filesystemen - und MountPoint aufgebaut.

Das vorhandene Modell kann ohne Schwierigkeiten an die generischen ODP-Basisklassen angebunden werden. Nach dem Engineering Viewpoint verwaltet das Nucleus-Objekt eines Node  also das Betriebssystem eines Rechners  alle Rechen-, Speicher- und Kommunikationsressourcen. Die Komponenten einer Workstation, die die Ressourcen zur Verfügung stellen, werden im ODP-Modell vollständig verschattet. Natürlich sind die Objektklassen, die ein aktives Management einzelner Systemkomponenten erlauben, für das Systemmanagement wichtig. Aus diesem Grund wird die Vererbungshierarchie ausgehend von der Klasse Device zunächst unverändert in das neue Modell übernommen.

Die Klasse System des alten Modells enthält sowohl Managementinformation über die Workstation selbst als auch über das auf ihr laufende Betriebssystem. Informationen über die Maschine, wie z.B. die Typbezeichnung (Hardware), der Aufstellungsort ( Location) und die Kontaktperson werden im neuen Modell durch die Klasse node bereitgestellt, die gegebenenfalls für eine UNIX-Workstation durch eine Klasse Workstation verfeinert werden kann. Diese Attribute werden also aus der Klasse System entfernt. Die Managementinformation, die das Betriebssystem betrifft, verbleibt in der Klasse System. Diese Klasse wird in UNIXSystem umbenannt und kann nun von der generischen Klasse nucleus abgeleitet werden. Die Attribute, die bereits in der Klasse nucleus enthalten sind und folglich generell für alle Klassen von Betriebssystemen gelten, werden natürlich aus UNIXSystem entfernt, da sie von nucleus ererbt werden. Hierunter fallen zum Beispiel das Systemdatum Date, die Betriebssystemversion OS und der logische Rechnername Name. Hier wird nochmals die Vorgehensweise zur Gewinnung allgemeiner, generischer Managementinformation und -funktionalität deutlich. Für alle Attribute und Methoden einer Managementobjektklasse, die eine spezielle Ressource beschreibt, wird die Frage gestellt, ob sie generell auf alle Klassen dieser Ressource anwendbar sind. In diesem Fall können sie in eine generische Oberklasse übernommen werden.


 
Abbildung:  Objektmodell für das Systemmanagement von UNIX-Workstations - Teil 1
32#32


 
Abbildung:  Objektmodell für das Systemmanagement von UNIX-Workstations - Teil 2
33#33

Es könnte die Frage entstehen, warum die MOCs, die Geräte einer Workstation repräsentieren, eine part-of-Beziehung mit der Klasse UNIXSystem eingehen und nicht mit der Klasse Workstation. Dies liegt daran, daß die Klassen die logische Sicht des Betriebssystem auf das Gerät liefern und nicht die Sicht auf die Hardware-Komponenten selbst. Bei der Klasse Processor gibt Name den logischen Device-Namen, z.B. «/dev/p0», und SystemTime den Anteil der Betriebssystemprozesse an der genutzten Prozessorzeit an. Für eine Klasse RISC_Processor als Bestandteil (part of) der Klasse Workstation wären jetzt Hardware-Attribute wie Oberflächentemperatur ( SurfaceTemperature), Lüftergeschwindigkeit (VentilatorSpeed) oder Sockelbezeichnung (SocketDesc) denkbar. Von solchen MOCs wird im Objektmodell aber abgesehen, da diese Art von Managementinformation i.a. nicht mit Mitteln des Betriebssystems erlangt werden kann. Eine Implementierung eines Agenten hierfür würde zusätzliche spezielle Meß- und Steuer-Hardware, wie z.B. einen Temperaturfühler in obigem Beispiel, erfordern.

Analog zur Klasse System kann die Klasse Process im neuen Modell von der generischen ODP-Klasse capsule abgeleitet werden. Hierzu wird sie in UNIXProcess umbenannt, da sich von capsule auch Klassen wie OS/2_Process oder WinNT_Task ableiten lassen. In jedem Betriebssystem lassen sich einem Prozeß ein eindeutiger Identifikator, ein Benutzer, genutzte Prozessorzeit, ein Zustand, etc. zuordnen. Auch können Prozesse i.a. gestoppt oder beendet werden. Diese Attribute und Methoden vererbt capsule im Modell an UNIXProcess, die nur noch UNIX-spezifische Attribute wie GID, Priority etc. enthält. Die angesprochenen Vererbungshierarchien zeigt die Abbildung 4.5 auf Seite [*]. Das angepaßte Modell ist in den Abbildungen 4.6 und 4.7 dargestellt.

Weitere Klassen des übernommenen Modells lassen sich nicht von ODP-Basisklassen ableiten. Dies liegt daran, daß der Fokus beim bestehenden Modell auf das Management von lokalen Systemressourcen einer einzelnen Workstation gesetzt war. Dies ist auch der klassische Bereich des Systemmanagements, der die Verwaltung einzelner, nicht vernetzter Rechner umfaßt. Bei modernen Systemlandschaften handelt es sich mittlerweile aber fast ausnahmslos um Rechner, die über ein leistungsfähiges Netz miteinander verbunden sind und deren Ressourcen als einziges großes verteiltes System allen Benutzern zur Verfügung stehen. Da ein verteiltes System ein Kommunikationssystem voraussetzt, ist eine Abgrenzung des Netzmanagements vom Systemmanagement nicht mehr möglich bzw. sinnvoll. Einen immer größer werdenden Stellenwert im Systemmanagement nimmt aber die Verwaltung und Administration der verteilten Systemdienste ein. Hierzu sind auch Konzepte des Anwendungsmanagement erforderlich.

Im folgenden Kapitel wird das Objektmodell durch generische Klassen für das Management von verteilten Systemdiensten erweitert und gleichzeitig gezeigt, daß sich die eingeführten ODP-Basisklassen auf eine Vielzahl von Anwendungen und Diensten anwenden lassen.


next up previous contents
Next: Generische Klassen für verteilte Up: Ein Objektmodell für das Previous: Beziehungen zwischen den Klassen
Copyright Munich Network Management Team