|
Vermeidung von Feature-Interaktionen in IN
durch ein modulares Architekturmodell |
Diese Seite beschreibt das Postdoktoranden-Forschungsprojekt von Dr. Jan Bredereke, das an der McMaster University, Software Engineering Research Group (Prof. D. Parnas), Kanada, durchgeführt wird und ab Sept. 1997 beginnt. Das Projekt wird von der Deutschen Forschungsgemeinschaft (DFG) gefördert.
Feature-Interaktions-Probleme in Intelligenten Netzwerken sind eine Ausprägung eines allgemeinen Software-Engineering-Problems: Wie kann man Software-Systeme adäquat erweitern, wenn diese so groß sind, daß eine einzelne Person sie nicht mehr überschauen kann? Ein allgemeiner Lösungsansatz für dieses schon lange bekannte Problem ist, das Software-System modular zu entwerfen, und zwar unter Beachtung des Geheimnisprinzips. Damit wird ein Teile-und-Herrsche-Ansatz möglich. Im Falle der Intelligenten Netwerke stehen wir sogar vor besonders großen Herausforderungen: Die inhärent nebenläufige Natur dieser Software-Systeme erzeugt eine oft schwer beherrschbare Komplexität, da in der Regel bereits wenige, einfache Komponenten, die nebenläufig zusammenarbeiten, eine äußerst große Vielfalt an möglichen Ablaufszenarien besitzen. Weiterhin begrenzt die verteilte Natur dieser Software-Systeme die Menge an Informationen, die jede Komponente über den aktuellen Gesamtsystemzustand hat.
Im konzeptuellen Modell des Standards für Intelligente Netzwerke ist ein Basissystem beschrieben (basic call state model, BCSM), das die bisherigen Telefonvermittlungssysteme modelliert, und es sind Zugangspunkte (detection points, DPs) beschrieben, die es erlauben, neue Dienste und Leistungsmerkmale hinzuzufügen. Unsere Vorarbeiten haben u.a. gezeigt, daß diese Schnittstelle unzureichend ist. Einerseits ist es möglich (und zum Teil sogar notwendig), Änderungen mit globaler Reichweite beim Entwurf von neuen Leistungsmerkmalen vorzunehmen, sowohl bei dem Kontrollfluß als auch bei den Daten. In dieser Hinsicht erlauben die einzelnen Zugangspunkte zu viel und die Schnittstelle ist zu "weit"; das Geheimnisprinzip wird nicht beachtet. Diese unkontrollierten gegenseitigen Beeinflussungen von unabhängig entworfenen Leistungsmerkmalen sind eine wesentliche Ursache für Feature-Interaktions-Probleme. Andererseits war die Definition jedes Zugangspunktes (DP) mit hohen Kosten für Software-Anpassungen verbunden, weshalb an wichtigen Stellen noch gar keine DPs vorgesehen sind. Aus diesem Grunde können einige der neuen Dienste noch nicht realisiert werden, weil der Zugriff auf bestimmte Informationen und Zustände noch fehlt. In dieser Hinsicht ist die Schnittstelle noch zu "eng".
Damit ergeben sich die folgenden Fragen:
Die Ansätze zur Behandlung von Feature-Interaktionen werden i.a. in die drei Klassen Erkennung, Auflösung und Vermeidung eingeteilt. Bei der Erkennung und Auflösung sind durch den Einsatz von formalen Techniken einige Fortschritte erzielt worden. Trotzdem ist es offensichtlich, daß man mit diesem "nachsorgenden" Vorgehen die Grenze der Erweiterbarkeit nur verschieben kann, und zwar nur bis zu einem bestimmten Punkt. An diesem Punkt wird es notwendig, das gesamte System grundlegend neu zu entwerfen, nur um eine neue Klasse von Features hinzufügen zu können. Die gegenwärtigen Feature-Interaktions-Probleme haben ihre Ursache oft darin, daß viele dieser Features nicht vorhergesehen wurden. Dies kann es dann erforderlich machen, daß ein Feature nicht nur lediglich hinzugefügt wird, sondern daß auch gleichzeitig das Basissystem direkt oder indirekt modifiziert werden muß, was wiederum implizite Annahmen über das Basissystem ungültig machen kann. Velthuijsen schreibt hierzu: "One way to deal with non-monotonicity would be to develop a service platform that supports the addition of most if not all features only through monotonic extensions." Langfristig wird es notwendig sein, eine neue Plattform zu entwerfen, die die gegenwärtig bekannten Klassen von Diensten von vornherein angemessen unterstützt und darüberhinaus neuen, zusätzlichen Spielraum für Erweiterungen läßt.
In Hinsicht auf ein neues Architekturmodell für die Telefonvermittlungssysteme sind bereits erste Forschungsarbeiten durchgeführt worden: Faci et. al. [FL97] untersuchen, wie sich (Lotos-)Spezifikationsstile auf die Beschreibung der Telefonsystem-Architektur auswirken. Van der Linden [vdL94] schlägt vor, Prinzipien des Open Distributed Processing (ODP) zu verwenden. Die TINA-Initiative baut ebenfalls auf ODP auf und verwendet dessen Architekturideen. Cattrall et. al. [CHJB95] verwenden "Rollen" und vermeiden damit eine bestimmte Klasse von Feature-Interaktionen. Zibman et. al. [ZWO+95] schlagen eine Agenten-Architektur vor. Sie betonen die Bedeutung von "separation of concerns" und differenzieren z.B. zwischen Benutzern/Endgeräten, Anrufen/Verbindungen usw. Zave und Jackson [ZaJa97] beschreiben zwar keine Architektur, dafür aber Anforderungen an Telefonsysteme formal. Sie geben fünf Software-Engineering-Regeln an, die für dieses spezielle Anwendungsgebiet hilfreich sind, um die Komplexität in den Griff zu bekommen.
Ziel des Forschungsvorhabens ist es, ein neues Architekturmodell für Telefonvermittlungssysteme zu erarbeiten, in dem Feature-Interaktionen bereits von vornherein vermeidbar beziehungsweise leichter erkennbar und auflösbar sind. Dazu müssen die drei oben identifizierten Fragen beantwortet werden.
Zunächst ist die Struktur des Basissystems zu überdenken. Bisher wird es als monolithischer Block betrachtet. Es steht zu erwarten, daß seine Flexibilität gegenüber Erweiterungen erheblich gesteigert wird, indem es unter Einhaltung des Geheimnisprinzips und ``separation of concerns'' in möglichst unabhängige funktionale Komponenten strukturiert wird. Im Bereich der Betriebssysteme wird versucht, ähnliches mit einem sogenannten ``Micro-Kernel'' zu erreichen. Dort werden so viele Funktionalitäten wie nur möglich aus dem Betriebssystemkern ausgelagert und in eigene Module gekapselt, so etwa das Dateisystem und selbst das Prozeß-Scheduling. Analog könnte man z.B. die Aufbereitung von gewählten Ziffern oder das Schalten einer einzelnen Sprechverbindung kapseln.
Nachdem innerhalb des Basissystems eine Struktur mit einer sauber definierten, engen Schnittstelle zwischen seinen Komponenten eingeführt ist, soll dies auch für die darüber hinausgehenden Leistungsmerkmale fortgesetzt werden. Hierzu soll eine repräsentative Menge von Leistungsmerkmalen aus der Literatur in Klassen strukturiert werden, und zu jeder dieser Klassen soll ein differenzierter Zugangspunkt definiert werden, an den nur sie ansetzen darf. Dieser Zugangspunkt soll jeweils so eng sein, daß er nur genau die notwendigen Eingriffe zuläßt, aber zum Beispiel keinesfalls beliebige Änderungen des Kontrollflusses oder von beliebigen Datenstrukturen zuläßt. Die gesamte Schnittstelle, d.h. die Vereinigungsmenge dieser Zugangspunkte, wiederum soll dabei so weit sein, daß sie alle betrachteten Klassen von Features gezielt unterstützt. Dies verspricht die Vermeidung bereits einer ganzen Reihe von Feature-Interaktionen, denn die bisherigen ``detection points'' (DPs) sind sehr an den historisch gewachsenen Telefonsystemen orientiert, die für viele der neuen Leistungsmerkmale nicht vorbereitet sind. Wegen dieses Mangels müssen zur Zeit viele Leistungsmerkmale an DPs angeschlossen werden, die ehemals für eine ganz andere Klasse von Leistungsmerkmalen eingeführt worden sind. Nachdem wie oben beschrieben im ersten Schritt innerhalb des Basissystems eine innere Schnittstelle eingeführt ist, soll also im zweiten Schritt auch eine nach außen offene Schnittstelle definiert werden.
Eine solche Strukturierung sollte von bleibendem Nutzen sein. Selbst wenn nach Abschluß der Definition des neuen Architekturmodells eine neue Klasse von Leistungsmerkmalen erdacht wird, für die das System noch keinen dedizierten Zugangspunkt vorsieht, so soll das Erarbeiten dieses Zugangspunktes vergleichsweise einfach sein.
Methodisch ist wichtig, für jedes neue Leistungsmerkmal zu prüfen, ob bereits eine geeignete Klasse vorhanden ist. Wenn nicht, muß ein neuer Zugangspunkt hinzugefügt werden. Nur so wird es möglich, die Erkennung und Auflösung von Feature-Interaktionen zu strukturieren: In einem ersten Schritt werden die Interaktionen zwischen den Klassen untersucht, und in einem zweiten Schritt werden es die Interaktionen innerhalb jeder Klasse. Hierdurch ist eine erhebliche Senkung der Komplexität zu erwarten im Vergleich zur gegenwärtigen Überprüfung jedes Leistungsmerkmales gegen jedes andere Leistungsmerkmal.
Im Verlaufe des Definierens der Zugangspunkte, die jeweils auf eine bestimmte Klasse von Leistungsmerkmalen spezialisiert sind, soll eine weitere Frage untersucht werden: Ist es möglich, das Erweitern dieser spezialisierten Schnittstelle dadurch noch mehr zu vereinfachen, daß innerhalb des (bisherigen) Basissystems eine zweite Ebene von möglichst universell verwendbaren Zugangspunkten eingezogen wird? Die Definition eines neuen spezialisierten Zugangspunktes, der nach außen hin sichtbar ist, würde sich dann nur auf diese innere Schnittstelle abstützen. Sofern eine solche zweite Ebene von universellen Zugangspunkten, die jeweils einen weitgehenden Eingriff in das Innerste des (bisherigen) Basissystems erlauben, möglich ist, soll anschließend an ihre Definition geprüft werden, inwieweit sie ähnlich zu den bisher verwendeten detection points (DPs) ist. Im Falle einer zumindest teilweisen Vergleichbarkeit ließe sich dann das neu entwickelte Architekturmodell als partiell kompatible Fortentwicklung des bisherigen verstehen, was seine kurzfristige Einsetzbarkeit wesentlich erleichtern würde.
| Univ. Kaiserslautern | FB Informatik | AG Rechnernetze | Dr. Jan Bredereke | Vermeidung von FI in IN |