Kompositionsmodell. Der Protokollentwurf mit SDL-Patterns unterscheidet sich von traditionellen SDL-Entwurfsmethoden durch eine kollaborationsorientierte Systemsicht [37]. Kollaborationen sind im Sinne von Systemfunktionalitäten (z.B. Verbindungsaufbau oder Datentransfer) zu verstehen und stellen damit nur einen Teil des Gesamtsystems dar. Sie sind ein wesentliches Strukturierungsmittel zur Beschreibung verteilter Systeme und müssen vom Protokollingenieur entsprechend der funktionalen und nicht-funktionalen Systemanforderungen entworfen werden.

Sprachunterstützung. Zur Verbesserung des Entwurfsprozesses wurde die Notation CoSDL entwickelt, die es erlaubt, initiale Entwurfsideen in Form von Kollaborationsdiagrammen zu beschreiben [37]. CoSDL ist eine graphische Notation, die sich stark an SDL anlehnt und (ähnlich zu MSC) Interaktionsverhalten zwischen SDL-Prozessen beschreibt. Im Gegensatz zu MSC basiert CoSDL aber nicht auf der Spezifikation von Beispielabläufen, sondern beschreibt vollständige Kollaborationen zwischen SDL-Prozessen. Im Prozessmodell des SDL-Pattern-Ansatzes werden Kollaborationsdiagramme während der Systemanalyse eingesetzt und unterstützen die Selektion von SDL-Patterns. CoSDL wurde beim Re-Engineering eines ATM-Signalisierungsprotokolls erprobt [4].

Werkzeugunterstützung. Das prototypische Werkzeug SPEEDI (s. auch "Verbreiterung und Bewertung des Protokollbaukastensystems") unterstützt die kollaborationsorientierte Systemsicht bereits teilweise.

Das Protokollbaukastensystem besteht aus einem inkrementellen, musterbasierten Entwurfsprozess sowie einer SDL-Pattern-Sammlung. Von 1998 bis 2000 sollte das initiale Protokollbaukastensystem [35] [36] unter anderem durch eine geeignete Werkzeugunterstützung ausgebaut und darüber hinaus bewertet werden.

Musterbasierter Entwurfsprozess Ausgangspunkt für den Protokollentwurf sind Kommunikationsanforderungen, die in einem ersten Schritt mit dem Ziel der iterativen Behandlung in Teilanforderungen dekomponiert werden. Mit jedem nun folgenden Durchlauf werden weitere Teilanforderungen analysiert und in einen SDL-Entwurf überführt. Aufgabe der Kollaborationsanalyse ist dabei die Erstellung einer konzeptionellen Systemarchitektur (bzw. die Ergänzung der Architektur des letzten Entwicklungsschrittes) sowie die Identifikation und Modellierung von Kollaborationen zwischen den vorhandenen Architekturelementen. Der eigentliche Entwurfsschritt wird ebenfalls inkrementell durchgeführt, wobei die zuvor identifizierten Kollaborationen schrittweise in den vorhandenen SDL-Entwurf integriert werden. Dies kann durch Anwendung von SDL-Patterns oder konventionell, ohne Musterunterstützung, geschehen. Die SDL-Pattern-Anwendung besteht ihrerseits aus den Teilschritten Selektion, Adaption und Komposition. Das Resultat eines Durchlaufs ist eine ausführbare SDL-Entwurfsspezifikation, die validiert und in nachfolgenden Durchläufen ergänzt wird. Sind alle Teilanforderungen abgearbeitet, ist der inkrementelle Entwurfsprozess abgeschlossen, und die resultierende validierte SDL-Entwurfsspezifikation dient als Eingabe für die nachfolgende Implementierungsphase.

SDL-Pattern-Sammlung und Beschreibungsrahmen Der von 1995-1997 definierte Beschreibungsrahmen für SDL-Patterns [33] wurde durch die Einführung von Metasymbolen zur Beschreibung der SDL-Fragmente weiterentwickelt. Die bisherige Notation unterstützte lediglich die Darstellung der invarianten Teile einer Entwurfslösung adäquat, nicht jedoch die Darstellung der zulässigen Adaptionen an einen konkreten Kontext. Die eingeführten Metasymbole erfassen die erlaubten Variationen und werden bei der Adaption eines Musters aufgelöst, so dass ein komponierbares SDL-Fragment entsteht. Die SDL-Pattern-Sammlung selbst wurde aufgrund der in mehreren Fallstudien gesammelten Erfahrungen weiterentwickelt und ausgebaut (s. auch "Protokoll-Engineering"). Ferner wurde der Zusammenhang zwischen der in der objektorientierten Modellierung verwendeten Spezialisierung und der Anwendung von SDL-Patterns untersucht [40].

Evaluierung und Quality Improvement Paradigm Zur Evaluierung und systematischen Verbesserung wurde der SDL-Pattern-Ansatz gemäß des Quality Improvement Paradigms (QIP) erweitert [31] [32]. In Kooperation mit Teilprojekt A1 wurde ein Messprogramm zur Erfassung des Verbesserungs- und Wiederverwendungspotenzials konzipiert [10] [11] [12]. Die während der Durchführung von Fallstudien mit Hilfe von maßgeschneiderten Fragebögen erfassten Messdaten wurden analysiert, die Ergebnisse dienten als Ausgangspunkt für die Verbesserung des Ansatzes. Unter anderem wurden verschieden Maturity-Levels für SDL-Patterns definiert [38]. Die gesammelten Erfahrungselemente wurden in der SFB-EDB verwaltet. Weiterhin wurden die durchgeführten Fallstudien mit ihren Messdaten in der SFB-EDB dokumentiert. Der SDL-Pattern-Ansatz wird seit 1998 im Praktikum "Entwicklung von Kommunikationssystemen" der AG Rechnernetze eingesetzt und dort in diesem Jahr in Kooperation mit Teilprojekt A1 evaluiert.

Werkzeugunterstützung. Zur Unterstützung der musterbasierten Protokollentwicklung wurde das rechnergestützte Werkzeug SPEEDI (SDL-PattErn EDItor) realisiert [29] [56]. SPEEDI unterstützt die Anwendung (Selektion, Adaption und Einbettung) von SDL-Patterns in SDL-Spezifikationen auf der Basis von SDL-PR [8]. Ferner dokumentiert SPEEDI die Reihenfolge und Platzierung von Musteranwendungen [3], wodurch die orthogonale, musterbasierte Struktur der SDL-Spezifikation festgehalten wird. Das Browsen durch den integrierten SDL-Pattern-Pool wird durch SPEEDI bereits rudimentär unterstützt [8]. Weitere Unterstützung wird durch die Einlagerung der Mustersammlung in die SFB-EDB geboten [11].

Neuentwicklung von Protokollen Entwickelt wurden Kommunikationssubsysteme auf der Basis von Token Ring und CAN [7]. Diese Fallstudien dienten als Machbarkeitsstudien für den Einsatz des SDL-Pattern-Ansatzes.

Reengineering von Protokollen Betrachtet wurden Protokolle aus der Internet Protocol Suite: IPv6 [1], RTP [2] und ST2+ [6] [13]. Diese Fallstudien dienten der Untersuchung, ob bereits bestehende Protokolle mit ihren integrierten Entwurfslösungen durch das Protokollbaukastensystem erfasst sind bzw. ob wesentliche Lücken in der SDL-Pattern-Sammlung bestehen.

Reengineering von SDL-Spezifikationen Betrachtet wurde das ATM-Signalisierungsprotokoll (UNI 3.1) [4]. In dieser Fallstudie konnte gezeigt werden, dass eine musterbasierte Spezifikation wesentlich zur Systematisierung und Verständlichkeit beiträgt. Es stellte sich außerdem heraus, dass die in der Mustersammlung angebotenen SDL-Entwurfslösungen im wesentlichen denen entsprechen, die von externen SDL-Designern verwendet worden sind.

Die Reihenfolge der durchgeführten Fallstudien ist durch einen zunehmenden Komplexitätsgrad sowie zunehmende Durchgängigkeit des Ansatzes gekennzeichnet. Die gewonnen Erkenntnisse wurden informell festgehalten und flossen jeweils in eine Weiterentwicklung des Ansatzes ein. Beispiele hierfür sind Verbesserungen in der Beschreibung bestehender Muster, Verfeinerung von Prozessschritten oder auch die Entwicklung und Einführung einer Notation zur Beschreibung von Kollaborationen.

Zur prototypischen Implementierung von Kommunikationssubsystemen wurde der Kodegenerator EnvGen (Environment Generator) [34] [5] entwickelt. EnvGen ermöglicht in Kombination mit dem kommerziellen Kodegenerator SDT-Cadvanced eine vollautomatische Implementierung und Einbettung von SDL-Spezifikationen. Dazu werden direkt aus der SDL-Spezifikation Umgebungsfunktionen für die Laufzeitbibliothek von SDT-Cadvanced generiert, mit deren Hilfe offene SDL-Systeme über existierende Basistechnologien kommunizieren. Derzeit wird die Anbindung an ATM, CAN, QNX-IPC und BSD-Sockets unterstützt, die Anbindung an UART ist in Vorbereitung. Weitere Basistechnologien können bei Bedarf integriert werden. Ein Teilergebnis dieser Arbeit zeigt, dass sich das im Teilprojekt etablierte Pattern-Konzept auch für den Bereich der Umgebungsschnittstelle einsetzen läßt [56] [52]. In Ergänzung zu den in Arbeitspaket Protokoll-Engineering beschriebenen Fallstudien wurden prototypische Implementierungen des objektbasierten Kommunikationssubsystems auf der Basis von CAN [34] und eines ATM-Signalisierungsprotokolls (UNI 3.1) [4] automatisch generiert und getestet.

B4

Forschungsaktivitäten

Ergebnisse 98-99-00

Protokolle

peper@informatik.uni-kl.de

02.08.00