Ein Computational Object Template umfaßt laut RM-ODP alle für die Instantiierung des COs erforderlichen Informationen. Unter dem Managementgesichtspunkt betrachten wir das Computational Object Template als ,,ein Stück`` Software in einem verteilten Rechensystem. Die Instantiierung des Templates entspricht dem Starten der Software-Komponente und damit beispielsweise dem Bereitstellen eines Systemdienstes.
In das Modell wird die Klasse compObjTemplate eingefügt, die wichtige Informationen für das Software-Management zur Verfügung stellt. Ein Überblick über die Aufgaben des Software-Managements und die Ansätze der DMTF findet sich in Kapitel 2.1.3. Ein Schwerpunkt ist sicherlich die Installation von Software-Komponenten. Dies wird bei der Modellierung daher besonders berücksichtigt.
Die Attribute der MOC compObjTemplate (siehe Abbildung 4.3) basieren auf der Software Standard Groups Definition der DMTF. Es ist sinnvoll, detaillierte Informationen für das SW-Management in der generischen Klasse compObjTemplate anzusiedeln, da diese Managementinformation unabhängig vom Typ der SW-Komponente ist. Damit eine Managementapplikation Aufgaben des SW-Managements in verteilter heterogener Umgebung überhaupt erfüllen kann, ist eine möglichst hohe Abstraktion von der spezifischen Komponente erforderlich. Dies rechtfertigt die Modellierung. Aus verschiedenen Gründen wurde die Managementinformation aber auf die zusätzlichen MOCs Package und InstallElement sowie Beziehungsklassen für die Abbildung der Abhängigkeiten aufgeteilt.
Im Computational Viewpoint des RM-ODP werden verteilte Anwendungen und Systemdienste als funktionale Zerlegung in Objekte dargestellt, die über wohldefinierte Schnittstellen interagieren. Hierbei soll u.a. Orts- und Verteilungstransparenz herrschen. Genausowenig ist Bestandteil des Computational Model, welche Prozesse und Dateien ein Computational Object in verteilter Umgebung realisieren. Diese Aspekte werden vom Engineering Viewpoint berücksichtigt. Daher würden für das Management relevante Attribute einer SW-Komponente, wie z.B. Installationsort oder die Liste der zu der Komponente gehörenden Dateien, gegen die Architektur des RM-ODP verstoßen, wenn sie in die MOC compObjTemplate aufgenommen werden würden. Da aber auch der Engineering Viewpoint das Konzept des SW-Pakets nicht beinhaltet, wird die Klasse Package mit diesen Attributen ins Modell aufgenommen.
Diese Modellierung spiegelt auch die Realität besser wider. Ein SW-Paket, also eine Instanz der Klasse Package, kann aus mehreren SW-Komponenten, also Instanzen der Klasse compObjTemplate, bestehen. Beispielsweise kann ein Paket für den Systemdienst NFS gleichzeitig die Komponenten NFS-Server und NFS-Client enthalten. Im folgenden wird kurz auf die Attribute und Methoden der betrachteten Klassen eingegangen.
In der Klasse compObjTemplate sind die Attribute Manufacturer, ProductName, Version, DeliveryDate, InstallationDate, SerialNumber selbsterklärend. HardwareDependencies beschreibt Anforderungen der SW-Komponente an die Hardware wie z.B. Hauptspeicherbedarf oder benötigte Bildschirmauflösung. InstallationLog ist der Name eines Logs, in dem Meldungen über Ereignisse, die während der Installation auftreten, abgelegt werden. 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. SW-Komponenten können andere Komponenten erfordern oder ersetzen oder funktional äquivalent zu anderen sein. Dies wird durch die Beziehungen mit den Beziehungsklassen RequirementInfo, SupersedingInfo und EquivalenceInfo modelliert. Dabei beschreibt das Attribut Mode Einschränkungen für die Beziehung. Beispielsweise kann eine Komponente ab einer oder bis zu einer bestimmten Version erforderlich sein.
Die Attribute der Klasse Package sind ebenfalls nahezu selbsterklärend. Location beschreibt die Orte, an denen Teile der SW-Komponenten installiert sind. SW-Pakete können installiert (install()) und deinstalliert (deinstall()) werden. Beim Einspielen einer neuen Version eines Pakets kann der Upgrade unter Sicherung des alten Stands durchgeführt werden ( applyUpdate()). Anschließend können die Änderungen zurückgenommen (rejectUpdate()) oder endgültig übernommen werden ( confirmUpdate()). Auch Pakete können andere erfordern bzw. ersetzen. Dies wird analog zur Klasse compObjTemplate modelliert. Ein SW-Paket besteht in der Praxis aus einer Anzahl von Dateien (vgl. die Gruppe FileList in [DMT95]). Im Modell wird das mit der Aggregationsbeziehung zur Klasse InstallElement berücksichtigt.
Die Modellierung wird ebenso durch die bestehenden Möglichkeiten zur Manipulation von SW-Paketen verschiedener UNIX-Varianten gerechtfertigt. Unter AIX wird die beschriebene Managementinformation und -funktionalität durch das Administrationskommando installp vollständig abgedeckt und vom AIX-eigenen Systemmanagementwerkzeug SMIT bereitgestellt.
Möglicherweise sind die Attribute und Methoden der beiden Managementobjektklassen Package und compObjTemplate nicht ausreichend, um alle Szenarien des SW-Managements mittels einer Managementanwendung behandeln zu können. Außerdem fehlt die genaue Deklaration der zum Teil nicht elementaren Attributtypen. Einerseits würde es den Rahmen dieser Arbeit sprengen, Detailfragen des Anwendungsmanagements zu betrachten, da dies eine genaue Analyse der Anforderungen von Applikationen für das Anwendungsmanagement sowie die Verifikation, ob die geforderte Information und Funktionalität überhaupt von gängigen Systemen bzw. Software-Paketen geliefert wird, erfordern würde. Andererseits darf nicht erwartet werden, daß eine Anwendung, die auf den generischen Basisklassen arbeitet, die gleiche Funktionalität wie ein proprietäres Spezialwerkzeug bietet. Unbestreitbar lassen sich aber wichtige Basisklassen für das SW-Management aus dem RM-ODP ableiten.
Im Computational Model des RM-ODP werden verteilte Anwendungen und Systemdienste als Ansammlung von Computational Objects gesehen, die sich praktisch im ,,luftleeren Raum`` befinden. Ohne sich ihrer Verteilung bewußt zu sein, kooperieren die Objekte durch Interaktionen ihrer Schnittstellen. Das Modell versteckt alle Details einer darunterliegenden verteilten Plattform, auf der die Objekte zu Prozessen werden und die Interaktionen über Kommunikationskanäle, d.h. Verbindungen in einem Rechnernetz, abgewickelt werden müssen. Eine Sicht auf diese Konzepte bietet der Engineering Viewpoint.