Computational Object Template

 

Ein Computational Object Template umfaßt laut RM-ODP alle für die Instantiierung des Computational Objects erforderlichen Informationen. Unter Managementgesichtspunkten entspricht ein Computational Object Template einer Softwarekomponente in einem verteilten Rechensystem. Die Instantiierung des Templates entspricht dem Starten der Softwarekomponente und liefert beispielsweise die Bereitstellung eines Systemdienstes.

  

Abbildung: Strukturelle Sichtweise des Computational Viewpoint

In das Objektmodell wird die Klasse compObjTemplate eingefügt, die wichtige Informationen für das Software-Management zur Verfügung stellt. Das Hauptanwendungsgebiet liegt dabei in der Installation von Software-Komponenten, worauf bei der Modellierung daher besonders großer Wert gelegt wird. Die Attribute der MOC compObjTemplate (siehe Abbildung ) basieren auf der Software Standard Groups Definition der DMTF. Es ist sinnvoll, detaillierte Informationen für das SW-Management bereits bei der generischen Klasse compObjTemplate anzusiedeln, da diese Managementinformation unabhängig von der konkreten Ausgestaltung der Software-Komponente ist und von der spezifischen Komponente möglichst abstrahiert werden sollte. Die dabei anfallende Managementinformation wurde aus Gründen, die wir in Kürze erläutern, zusätzlich auf die MOCs Package und InstallElement aufgeteilt; Assoziationsklassen zur Darstellung der Abhängigkeiten wurden ebenfalls eingefügt.

Im Computational Viewpoint sind verteilte Anwendungen und Systemdienste Objekte, die über wohldefinierte Schnittstellen interagieren, wobei Orts- und Verteilungstransparenz gegeben ist: Es ist nicht Bestandteil des Computational Viewpoint, welche Prozesse und Dateien ein Computational Object in verteilter Umgebung letztendlich realisieren; diese Aspekte sind stattdessen Gegenstand des Engineering Viewpoints. Für das Management durchaus relevante Attribute einer Software-Komponente - wie z.B. Installationsort oder die zu der Komponente gehörenden Dateien - dürfen daher nicht in die MOC compObjTemplate aufgenommen werden. Da jedoch auch der Engineering Viewpoint kein vergleichbares Konzept für ein Software-Paket beinhaltet, wird die Klasse Package mit diesen Attributen ins Modell des Computational Viewpoints aufgenommen. Diese Modellierung entspricht auch der Realität, da ein Software-Paket - also eine Instanz der Klasse Package - aus mehreren Software-Komponenten, d.h. Instanzen der Klasse compObjTemplate, bestehen kann. So enthält beispielsweise ein Paket für den Systemdienst NFS sowohl die Komponenten NFS-Server als auch NFS-Client. Im folgenden gehen wir auf die Attribute und Methoden der betrachteten Klassen ein.

Die Attribute Manufacturer, ProductName, Version, DeliveryDate, InstallationDate, SerialNumber der Klasse compObjTemplate sind selbsterklärend. HardwareDependencies beschreibt spezifische Anforderungen der Software-Komponente an die Hardware wie Haupt- und Plattenspeicherbedarf oder benötigte Bildschirmauflösung. InstallationLog ist der Name des Logs, in dem Meldungen über Ereignisse abgelegt werden, die während der Installation auftreten. Support gibt an, auf welche Weise Unterstützung für die Software erlangt werden kann. In State könnten Informationen darüber enthalten sein, ob die Installation erfolgreich war und ob die Komponente gestartet werden kann. Software-Komponenten können andere Komponenten erfordern, ersetzen oder zu diesen funktional äquivalent sein, was durch die Beziehungen von compObjTemplate mit den Assoziationsklassen RequirementInfo, SupersedingInfo und EquivalenceInfo modelliert wird. Dabei beschreibt das Attribut Mode Einschränkungen, welche für die Beziehung gelten: Beispielsweise kann eine Komponente ab einer oder bis zu einer bestimmten Version erforderlich sein.

Die Bedeutung der Attribute der Klasse Package ist ebenfalls klar ersichtlich: Location beschreibt die Orte, an denen Teile der Software-Komponenten installiert sind; Software-Pakete können installiert (install()) und deinstalliert (deinstall()) werden. Das Einspielen einer neuen Version eines Pakets kann unter Sicherung des alten Stands durchgeführt werden (applyUpdate()). Anschließend können die Änderungen entweder zurückgenommen ( rejectUpdate()) oder endgültig übernommen werden ( confirmUpdate()). Auch zwischen Software-Paketen können Abhängigkeiten bestehen, was analog zur Klasse compObjTemplate modelliert wird. Ein Software-Paket besteht in der Praxis aus einer Anzahl von Dateien. Im Objektmodell wird dies mit der Aggregationsbeziehung zur Klasse InstallElement berücksichtigt. Diese Überlegungen stützen sich auf die bestehenden Möglichkeiten zur Administration von Software-Paketen bei unterschiedlichen UNIX-Varianten: So wird beispielsweise unter IBM AIX die hier beschriebene Managementinformation und -funktionalität durch das Administrationskommando installp vollständig abgedeckt und vom AIX-eigenen Systemmanagementwerkzeug SMIT bereitgestellt.

Trotzdem ist es denkbar, daß die Attribute und Methoden der beiden Managementobjektklassen Package und compObjTemplate nicht ausreichend, um alle Szenarien des Software-Managements von einer Managementanwendung aus abzudecken. Andererseits kann jedoch auch nicht erwartet werden, daß eine Anwendung, die auf generischen Basisklassen arbeitet, die gleiche Funktionalität wie ein proprietäres Spezialwerkzeug bietet. Unbestreitbar lassen sich aber wichtige Basisklassen für das Software-Management aus dem RM-ODP ableiten. Im Computational Viewpoint des RM-ODP werden verteilte Anwendungen und Systemdienste als Computational Objects angesehen, die unabhängig von ihrer Verteilung durch Interaktionen an ihren Schnittstellen kooperieren. Das Modell abstrahiert bewußt von allen Details einer darunterliegenden verteilten Plattform, auf der die Objekte zu Prozessen werden und die Interaktionen über Kommunikationskanäle abgewickelt werden müssen. Konzepte für diese Abstraktionsebene bietet der Engineering Viewpoint, auf den wir nun eingehen werden.