Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.10.1985 - 

Folge 2: Beschreibung von SDL (Specification and Description Language)

Formale Methoden zur Beschreibung von Protokollen

Rückblick

In der vorhergehenden, ersten Folge dieser aus sieben Kapiteln bestehenden Serie wurde die Bedeutung formaler Spezifizierungsmethoden erklärt sowie auf den gesamten Inhalt dieser Artikelreiche hingewiesen. Speziell geht es um die Methoden SDL (siehe oben), Estelle und Lotos, präsentiert am Beispiel des ISDN-D-Kanal-Protokols.

Hintergrund ist der wachsende Bedarf für derartige Vorgehensweisen, da sich - so die Auffassung der Autoren - bei der Normung von Kommunikationsprotokollen (zum Beispiel OSI) die herkömmlichen, informalen Beschreibungsmittel als unzulänglich erwiesen haben.

Bei CCITT und ISO befinden sich solche Methoden zur Zeit in der Standardisierung. Auch im Software-Life-Cycle seien sie als sinnvolle Hilfsmittel einsetzbar.

Folge 1 ist in CW Nr. 40\85, Seite 22ff. erschienen.

SDL (Specification and Description Language) ist eine FDT (formale Spezifikationsmethode), die sich einer graphischen Darstellungsweise bedient. Dadurch soll insbesondere die leichte Überschaubarkeit der Darstellungen ermöglicht werden. Die Methode wurde innerhalb der CCITT zur formalen Beschreibung von Telekommunikationssystemen entwickelt, eignet sich aber zur Beschreibung beliebiger, auf Nachrichtenaustausch basierender Systeme.

Bei der Entwicklung von SDL wurde besonderer Wert darauf gelegt, daß die Methode zwar einfach zu lernen und anzuwenden ist, aber trotzdem eindeutige Spezifikationen und Beschreibungen ermöglicht. Weiterhin wurde eine einfache Erweiterbarkeit und hohe Flexibilität angestrebt, um sowohl künftige neue Entwicklungen als auch verschiedene Methodologien von Systemspezifikationen und Design zu unterstützen.

Im folgenden wollen wir das Konzept, auf dem SDL aufbaut, näher erläutern. Weiterhin erklären wir die Beschreibungssprache und die zugrundeliegenden Sprachelemente. Schon in der ersten Folge der Artikelserie haben wir ein Beispiel einer SDL-Beschreibung angeführt, an dem die leichte intuitive Verständlichkeit der Sprache ersichtlich ist. Wir wollen dieses Beispiel etwas erweitern, um eine komplette Systemspezifikation zu erhalten.

Die Methode basiert auf einem Modell von erweiterten endlichen Automaten und dient zur Beschreibung des Zusammenspiels von Ereignissen, die von außen auf ein System einwirken, und den dadurch ausgelösten Reaktionen des Systems.

Ein SDL-System besteht aus einem oder mehreren Blocks. Die Blocks dienen zur Strukturierung des Systems und enthalten Prozesse, die zeitlich parallel ablaufen. Ein Prozeß kann in mehreren Ausprägungen existieren, die von Beginn an vorhanden oder von anderen Prozessen aus gestartet worden sein können.

Jeder Prozeß wird durch einen erweiterten endlichen Automaten beschrieben. Die Blöcke werden untereinander und mit ihrer Umwelt durch (unidirektionale) Kanäle verbunden, die dem Nachrichtenaustausch mittels Signalen dienen.

Jede Kanaldefinition legt genau fest, welche Signale auf dem Kanal transportiert werden können. Signale können Daten tragen und enthalten immer die Adresse des Empfängerprozesses oder der Umgebung des spezifizierten Systems. Wenn ein Prozeß ein Signal schickt, wählt sein Block automatisch den Kanal, der dieses Signal zu dem Adressaten bringen kann.

Mit jedem Prozeß ist eine Eingabewarteschlange assoziiert, in die die ankommenden Signale eingereiht werden. Außerdem können mehrere Zeitgeber existieren, die mit bestimmten Befehlen gesetzt oder zurückgesetzt werden können. Nach Ablauf eines solchen Zeitgebers wird ein ihm zugeordnetes Signal in die Eingabewarteschlange gestellt.

Zur Adressierung von Signalen stehen in jedem Prozeß vordefinierte Variablen zur Verfügung, die den eigenen Namen, den Namen des Vaterprozesses, den Namen des Senders der letzten empfangenen Nachricht etc enthalten.

Neben der expliziten Kommunikation über die Kanäle können Prozesse, die im gleichen Block enthalten sind, über exportierte und importierte Variablen Daten austauschen. Dabei kann eine Variable immer nur von ihrem Eigentümer verändert werden. Der Export und Import von

Variablen ist als impliziter Nachrichtenaustausch definiert, so daß eine Variable immer nur von ihrem Eigentümer gesehen wird und dieser nur Kopien der Variablen an andere Prozesse weitergeben kann.

Die Beschreibungssprache

Die Spezifikation der Sprache bedient sich eines abstrakten Sprachmodells, das in zwei syntaktisch verschiedenen Formen realisiert werden kann. Die eine Form benutzt graphische Symbole zur Darstellung, während die andere Form eine lineare Syntax ähnlich einer herkömmlichen Programmiersprache hat. Beide Formen lassen sich jedoch auf das abstrakte

Modell zurückführen und sind einander äquivalent. Daher befassen wir uns hier nur mit der häufiger benutzten graphischen Darstellungsweise.

Eine Systemdefinition in SDL besteht aus einem Diagramm, das die Zusammensetzung des

Gesamtsystems aus Blöcken und Kanälen sowie die Prozeßstruktur der Blöcke zeigt. Ferner sind die Signale definiert, die über die Kanäle übertragen werden können. Das dynamische Verhalten des Gesamtsystems ist durch Prozeßdiagramme festgelegt, die für jeden im System enthaltenen. Prozeß angegeben sind. Das sind die schon weiter oben angesprochenen Diagramme von erweiterten endlichen Automaten.

SDL sieht spezielle formale Sprachmittel vor, die bei der Detaillierung von Prozeßdiagrammen verwendet werden können. Es sind dies Sprachelemente für zum Beispiel Variablenzuweisung, wie sie auch in normalen Programmiersprachen verwendet werden. Diese Sprachelemente werden nicht mehr graphisch dargestellt, sondern der linearen Syntax von SDL entnommen und als Text innerhalb der Symbole angegeben. Durch diese Sprachelemente kann SDL auch sehr detaillierte Spezifikationen formal beschreiben. Sie ermöglichen sogar die Verwendbarkeit von SDL bis hin zu Implementationen.

Leider wird in vielen Fällen von diesen Möglichkeiten der formalen Beschreibung mittels SDL nur wenig Gebrauch gemacht. Daher sind von SDL oft nur die graphischen Diagramme (meist noch mit informalem Text) bekannt. Auch wir können aus Platzgründen nicht näher auf diese Mittel zur detaillierten Spezifikation eingehen.

Wir wollen zur Erklärung der Sprache nur auf die graphische Syntax der Prozeßdiagramme eingehen, da sie das beobachtbare Verhalten eines Systems festlegen. In dem später aufgeführten Beispiel ist auch ein Blockdiagramm dargestellt, das die Einbettung von Prozessen in die Umgebung festlegt.

Endliche, erweiterte Automaten

SDL stellt erweiterte endliche Automaten dar. "Erweitert" heißt hier unter anderem, daß innerhalb einer Transition Entscheidungen über den Folgezustand getroffen werden können und daß die normale chronologische Reihenfolge der Ergebnisse verändert werden kann (durch Zwischenspeichern Von Ereignissen). Weiterhin kann ein Prozeß einen neuen, parallel laufenden, erzeugen.

Bild 1 zeigt eine Übersicht über die Symbole, aus denen sich ein Prozeßdiagramm zusammensetzen kann. Die verschiedenen Symbole eines Diagramms sind durch Linien (in bestimmten Fällen mit Pfeilspitzen versehen) verbunden. Diese Linien geben den Fluß der Kontrolle innerhalb des Graphen an.

Der Prozeßgraph beginnt mit einem Startsymbol (wenn das Startsymbol nicht explizit im Diagramm erscheint, wird der Start durch einen Zustandsnamen, der seine Rolle als Anfangszustand nahelegt, oder durch einen Kommentar bestimmt.). Die Zustände des endlichen Automaten sind durch Zustandssymbole markiert. Jedes Zusatzsymbol enthält einen oder mehrere Zustandsnamen, wobei verschiedene Symbole mit gleichem Namen den gleichen Zustand repräsentieren.

"Sprechende" Zustandsnamen

In unserem später aufgeführten Beispiel benutzen wir zusätzlich zu den "sprechenden" Zustandsnamen noch Zustandsnummern, die die eindeutige Zusammenfassung von mehreren Zustandssymbolen mit gleicher Nummer zu einem Zustand erleichtern sollen. Die Nummern sind hier als Kurzform des Zustandsnamens zu verstehen.

Auf ein Zustandssymbol folgt immer eine Auswahl von Eingabesymbolen oder Sicherungssymbolen. Das ist so zu interpretieren, daß beim Auftreten eines bestimmten Ereignisses der Pfad mit dem Eingabesymbol gewählt wird, in dem das Ereignis aufgeführt ist.

Wenn das Ereignis in einem Sicherungssymbol aufgeführt wurde, wird es in diesem Zustand nur zwischengespeichert und erst später einem Eingabesymbol zugeordnet. Die vom Sicherungssymbol fortführende Flußlinie muß immer in den Zustand zurückführen, von dem aus das Sicherungssymbol erreicht wurde.

Ereignisse, die weder in einem Eingabesymbol noch in einem Sicherungssymbol zu einem Zustand aufgeführt sind, werden ignoriert, falls sie dennoch in diesem Zustand auftreten. Nach einem Eingabesymbol kann eine beliebige Folge von Aktionen, Ausgaben, Entscheidungen und Prozeßstarts folgen, die entweder in einen neuen Zustand oder in das Stoppsymbol übergehen.

Aus Entscheidungssymbolen führen mehrere Flußlinien heraus. Sie müssen mit der Antwort zu einer Frage innerhalb des Symbols versehen sein, die zum Beschreiten der Flußlinie erforderlich ist. Die Konnektoren dienen zur Unterteilung eines großen Diagramms in mehrere kleine.

Konzepte durch Primitive definiert

Das Kommentarsymbol kann an beliebiger Stelle stehen. Es ist mit einer gestrichelten Linie mit der Komponente verbunden, auf die sich der Kommentar bezieht. Flußlinien können Pfeilspitzen tragen. Dies ist jedoch nicht bei Linien erlaubt, die aus Zuständen herausführen. Demgegenüber müssen Flußlinien, die in Zustände hineinführen, Pfeilspitzen tragen.

Neben den aufgeführten primitiven Symbolen kennt SDL noch einige andere Konzepte, die der Vereinfachung der Schreibweise und der Strukturierung dienen. Diese Konzepte sind alle unter Zuhilfenahme der schon aufgeführten Primitive definiert. So wurde das Konzept von Prozeduren eingeführt, um mit Methoden des strukturierten Designs in SDL arbeiten zu können. Das strukturierte Design wird auch durch die Möglichkeit der Substrukturierung von Blöcken, Kanälen, Prozessen etc. unterstützt. Weiterhin sind Makros zur Verkürzung der Schreibweise vorgesehen.

Das Konzept von Ereignissen, die Transitionen auslösen, wurde durch bedingte Transitionen und durch Transitionen, die durch den Wechsel eines (externen) Wertes (wie der Spannung auf einer Leitung) ausgelöst werden können, erweitert. SDL kennt auch Daten und Datentypen, die in den verschiedenen Symbolen manipuliert und benutzt werden können. Dabei ist in SDL das Konzept der abstrakten Datentypen vorgesehen. Es sind ansonsten die aus anderen Programmiersprachen bekannten Konzepte und Konstrukte zu finden. Wir wollen auch darauf nicht näher eingehen, da das den Rahmen dieses Artikels sprengen würde.

Beispiel

Eine SDL-Systembeschreibung besteht aus einem Block-Interaktions-Diagramm, einem Prozeßdiagramm, einer Signalliste und Signaldefinitionen. Bild 2 zeigt das Block-Interaktions-Diagramm für das schon in der ersten Folge dieser Artikelserie angesprochene Beispiel.

Dabei besteht die gesamte Ebene 3 für ISDN aus zwei Prozessen. Der obere (Layer-3-Steuerung) behandelt das in der letzten Folge beschriebene Protokoll, während der andere dafür verwendet wird, die ankommenden PDUs (Protocol Data Units) zu analysieren und die abgehenden PDUs zu generieren. Dieser Prozeß ist (im Sinne dieser Spezifikation) trivial und soll daher nicht genauer beschrieben werden.

In Bild 2 sind schon die Signallisten (in eckigen Klammern) enthalten. Die Signaldefinitionen, die angeben, welche Daten in den Signalen transportiert werden und welchen Datentyp sie haben, sind auf der hier benutzten Abstraktionsebene trivial und sollen daher nicht genauer angegeben werden. Es bleibt also noch das Prozeßdiagramm für Layer-3-Steuerung anzugeben. Das ist jedoch schon in der ersten Folge dieser Serie geschehen und soll daher hier nicht mehr wiederholt werden. Auch die Beschreibung des Diagramms ist dort zu finden.

(Fortsetzung der Serie folgt)

*Die Autoren, Klaus-Peter Fischer (Dipl.-Math.) und Stephan Hesse (Dipl.-Inform.), sind Software-Entwickelt speziell für Kommunikationssysteme sowie Berater auf diesem Gebiet bei der Telnet GmbH, Geschäftsstelle Rhein-Main.