Implementierungsmodell

  Das im vorigen Kapitel entworfenen Objektmodell ist aus der Bottom-Up Modellierung entstanden. Von Bedeutung für dessen Erstellung waren die Eigenschaften der Ressourcen eines PC-basierten Switch, die dem Konfigurationsmanagement zuzuordnen sind. Hinzu kamen Attribute und Methoden aus dem Leistungs- und Fehlermanagement. In diesem Kapitel soll das erstellte Objektmodell im Hinblick auf die Implementierung spezialisiert werden. Für die Umsetzung des Objektmodells müssen architektur- und implementierungsspezifische Aspekte beachtet werden.

Abbildung 4.2 zeigt das der Implementierung zugrundeliegende Objektmodell. Im folgenden sollen kurz die Unterschiede zum im vorigen Kapitel erstellten Managementobjektmodell erläutert und gerechtfertigt werden.

  

Abbildung 4.2: Objektmodell aus Implementierungssicht

Der Switch-Agent muß eine Schnittstelle für die Dienstanbindung an den ORB zur Verfügung stellen. Dazu wird das Objekt Switch aus dem Managementmodell (4.1) in ein IDL-Interface (Switch) und dessen Implementierung (SwitchStationaryAgent) umgesetzt. Das IDL-Interface bietet alle Methoden und Attribute an, die das ursprüngliche Objekt auch angeboten hat. Ein zusätzliches Attribut port_array, das aus einem Array von Objekten der Klasse Port besteht, implementiert die Beziehung consists_of zur Klasse Port. Das Attribut dte_list nimmt in einem Datentyp Vector der Programmiersprache Java eine beliebige Anzahl von Objekten der Klasse DTE auf. Der Grund für diese beiden Attribute liegt darin, daß die Methoden addmember() und remmember() aus der Klasse VLAN in die Klassen Port und DTE verschoben wurden. Dies hat u.a. implementierungstechnische Gründe. Einem Port oder einer DTE wird immer genau eine VLAN ID zugeordnet. Dahingegen können einer VLAN ID mehrere Ports bzw. DTE's zugeordnet sein. Geht man objektorientiert vor, so läßt sich die Beziehung is_member_of dadurch realisieren, daß das Objekt Port (oder DTE) ein Attribut VLAN ID besitzt, das durch eine Methode (set_vlan_id) der Klasse Port (oder DTE) verändert werden kann.

Das Interface Switch stellt die einzige Schnittstelle des Agenten dar. Der Grund hierfür liegt darin, daß es so einfacher ist, den übrigen Klassen des Implementierungsmodells neue Attribute und Methoden hinzuzufügen, ohne unbedingt auch die Schnittstellenspezifikation zu ändern. Darüberhinaus umgeht man so das Problem der Mehrfachvererbung, die Java nicht anbietet. Um die Methoden der übrigen Klassen auch dem Manager zugänglich zu machen, muß das Interface Switch diese anbieten. So realisiert das Interface die Methoden set_vlan_id() der Klassen Port und DTE dadurch, daß es diese aus den Methoden set_port_vlan_id() und set_mac_vlan_id() aufruft. Auf die gleiche Art und Weise bietet das Interface alle weiteren Methoden an, die in Kapitel 4.3 spezifiziert worden sind.

Die IDL-Schnittstelle für den Switch hat folgendes Aussehen:

#ifndef _Switch_idl_
#define _Switch_idl_

#include "/proj/fagent/masa_0.2/src/idl/AgentService.idl"
#include "/proj/fagent/NoCScontrol/src/idl/NoCSMgmtAgent.idl"

interface Switch;

interface Switch : agent::AgentService : mo::NoCSMgmtAgent
{
    void start();
    void stop();
    void protocols();
    void set_bridge_priority();
    void debug(in string para);
    void stats(in string para);
    void enable_port(in long number);
    void disable_port(in long number);
    void set_port_priority(in long number);
    void set_path_cost();
    void set_policy(in string para);
    void exempt_policy(in string para);
    void set_port_vlan_id(in long port,in long vlan_id);
    void set_mac_vlan_id(in string mac,in long vlan_id);
};
#endif

Dabei fällt auf, daß das Switch-Interface von den Interfaces AgentService und NoCSMgmtAgent die Module agent und mo erbt. Die beiden Module werden in [Kem98] und [Rad98] beschrieben. Ebenso die Notwendigkeit des hier geschilderten Agenten, von diesen zu erben. Die Vererbung ist im Implementierungsmodell (Abbildung 4.4) durch eine Generalisierung dargestellt.

Der Aufbau des Moduls AgentService sieht dabei folgendermaßen aus:

module agent {
  interface AgentService {
    agentSystem::AgentSystemService getAgentSystemService();
    string getURL();
  };
};

Die Methode getAgentSystemService() hat als Rückgabewert die CORBA-Objektreferenz auf das Agentensystem, auf dem der Agent abläuft. Die Methode getURL() liefert die URL zur Homepage des Agenten [Kem98].

Das Modul mo ist so aufgebaut:

module mo {
  interface NOCSMgmtAgent {
    string getID();
    string getEventChName();
    string getType();
  };
};

Dabei liefert die Methode getID() den compound name des Agenten, die Methode getEventChName() den Namen des vom Agenten kreierten Event Channels und die Methode getType() den Typ des Agenten (siehe Kapitel 4.5). Näheres dazu findet sich in [Rad98].