Zu einer Software-Komponente gehören eine oder mehrere ausführbare Dateien (executables). Dies wird im Objektmodell durch eine entsprechende Assoziation von der Klasse compObjTemplate zu der neuen Klasse capsuleTemplate gekennzeichnet (siehe Abbildung 4.4). Laut RM-ODP muß das Capsule Template die zur Instantiierung eines Capsules benötigte Information, die aber nicht näher spezifiziert wird, enthalten. Die Instantiierung eines Capsules ist gleichbedeutend mit dem Starten eines Prozesses. Das korrekte Starten von Anwendungen oder Systemdiensten gehört zu den Aufgaben des Konfigurationsmanagements. Für die Klasse capsuleTemplate werden daher Attribute eingeführt, die dem Konfigurationsmanagement Informationen bereitstellen. Das Attribut InstantProcedure gibt Auskunft über Ort (z.B. Pfadangabe) und Name der ausführbaren Datei. Ein Executable besitzt einen Typ (Type), z.B. Binary oder Shellskript, der auch Auskunft darüber gibt, auf welchem Betriebssystem bzw. Prozessor es ausführbar ist. Über mögliche und sinnvolle Belegung von Aufrufparametern informiert das Attribut RuntimeParameter. Size gibt die Größe des Executables an. Weiterhin wird ein Attribut RequiredObjects modelliert, das angibt, welche Objekte zur Ausführung der Datei vorhanden sein müssen. Bei den Objekten kann es sich um Initalisierungs- oder Konfigurationsdateien, um benötigte Bibliotheken oder Systemschnittstellen etc. handeln. Die Informationen sind auch für das Fehlermanagement relevant. Arbeitet ein Systemdienst nicht ordnungsgemäß, kann der Administrator überprüfen, ob die zugehörigen Prozesse (Capsules) korrekt gestartet wurden und ob alle erforderlichen Objekte in der Umgebung vorhanden sind.
Zur Modellierung dieser Klasse mag kritisch angemerkt werden, daß die (wenigen) Attribute sehr vielfältige, nicht genau erfaßte Managementinformationen enthalten. Man ist versucht, die Information auf mehrere speziellere Attribute aufzuteilen. Hierbei besteht aber die Gefahr, daß man die Allgemeinheit der generischen Klasse aufgibt, weil man Spezifika eines bestimmten Systems oder einer Maschinenarchitektur einführt. Beispielsweise kann ein Capsule Template für ein Executable auf einem Host unter MVS nicht gleich aussehen wie ein Template für eine Batch-Datei unter MS-DOS. Für unterschiedliche Plattformen muß das Capsule Template daher noch weiter spezialisiert werden. Außerdem ist es in einem erweiterten Modell denkbar, das Attribut RequiredObjects durch Assoziationen («requires») zu anderen MOCs des Engineering Viewpoint zu ersetzen. Hier ein Beispiel für eine Instanz der generischen Klasse capsuleTemplate für den Hintergrundprozeß lpd des BSD-Druckdienstes: 2ex
Weiterhin erhält die Klasse capsuleTemplate eine Aggregationsbeziehung zur Klasse clusterTemplate. Dies ist die logische Schlußfolgerung aus der Tatsache, daß im RM-ODP ein Capsule aus ein oder mehreren Clusters besteht. Managementinformation für die Klasse clusterTemplate ist analog zu capsuleTemplate definiert, wobei die Attribute Size und RuntimeParameters entfallen. Im obigen Beispiel wäre dem Capsule Template lpd eine Instanz eines Cluster Template für eine Bibliothek zugeordnet:
An dieser Stelle ist ein kleiner Bruch mit dem RM-ODP auszumachen. Die Strukturregeln für Cluster (cluster rules) in [ISO95d] legen fest, daß ein Cluster nur in genau einem Capsule enthalten sein darf. Das Konzept der dynamischen, gemeinsam genutzten Bibliotheken (dynamic shared libraries), welches in vielen Systemen aus Performance-Gründen realisiert ist, verstößt aber gegen diese Regel. Da in dieser Arbeit aber versucht wird, die Konzepte des RM-ODP für das Management von real existierenden Systemen anzuwenden, welche selbst nicht nach dem RM-ODP entworfen und konstruiert wurden, wird eine Abweichung vom Standard hier und möglicherweise auch an anderer Stelle in Kauf genommen.
Im folgenden werden generische Managementobjektklassen zum Engineering Viewpoint definiert, die Abstraktionen von Systemressourcen zur Laufzeit darstellen. Aus diesen lassen sich später MOCs ableiten, die Managementinformation aus dem traditionellen Bereich des Systemmanagements bereitstellen. Damit können Managementanwendungen auf Systemressourcen wie Prozesse, Geräte und Kommunikationsverbindungen einwirken. Die Notwendigkeit hierfür ergibt sich u.a. aus dem erforderlichen Monitoring von Ressourcen für das Leistungs- und Fehlermanagement.