Informatik-Lexikon

F

Fachsprachen
FDDI (Fiber Distributed Data Interface

Fachsprachen

Erläuterung

Formale Sprachen sind von Anfang an die entscheidende Schnittstelle zwischen Mensch und Computer gewesen. Ihre Gestaltung beeinflußt Effizienz und Qualität der Softwareentwicklung [8]. Der Kern der Programmierung ist es, Konzepte des Anwendungsbereichs möglichst angemessen auf diejenigen der Programmiersprache abzubilden. Man hat schon früh erkannt, daß durch an den Problembereich angepaßte Sprachen (problemorientierte Programmiersprachen) große Produktivitätssteigerungen möglich sind.

Allmählich setzt sich die Einsicht durch, daß die Schwierigkeiten der Softwareentwicklung die Erschließung und Nutzung höherer Abstraktionsebenen erfordern. Dabei sind wiederum problemorientierte Programmiersprachen wichtig, die nun aber Fach(programmier)sprachen (auch DSL – Domain Specific Languages bzw. Application Domain oder Little [5] Languages) genannt werden.

Fachsprachen sollen für relativ abgegrenzte und überschaubare Bereiche ein Verständigungsmittel sein, das Mehrdeutigkeiten und unterschiedliche Interpretationen weitgehend ausschließt. Sie bestehen aus spezifischen Grundbegriffen und Regeln, die die Verwendung der Grundelemente bestimmten Beschränkungen unterwerfen. Beispielsweise existiert für elektrische Schaltkreise eine allgemein bekannte (zweidimensionale) Fachsprache. Ihre Grundelemente sind Symbole für Bauelemente (Widerstand, Kondensator, Transistor usw.) und Verbindungen. Der Regel entsprechend können dabei nur Leitungsenden miteinander verbunden werden. Diese Schaltpläne zeigen zwei wesentliche Eigenschaften von Fachsprachen:

  • Ihre Definition bedarf gewisser Erkenntnisse über den Gegenstandsbereich (hier Elektrizitätslehre)
  • Sie stellen mehr oder weniger formalisierte Beschreibungen von Sachverhalten dar, d.h., sie sind deskriptiv geprägt.

Eine dritte, i.a. sehr unterschiedlich ausgeprägte Eigenschaft, ist die Möglichkeit des formalen Manipulierens. Auf unser Beispiel übertragen könnte man bestimmte Teilschaltungen durch andere ersetzen, ohne das prinzipielle Verhalten der Gesamtschaltung zu verändern, und zwar auf rein formaler (und damit automatisierbarer) Ebene. Das Zurückführen inhaltlicher Operationen auf rein formale ist ein wesentliches Potential formalisierter Fachsprachen. Es ist grundsätzliche Voraussetzung für die Übertragung von inhaltlichen Aufgaben an den Computer.

Gegenwärtig herrscht der Gebrauch von Fachsprachen für die deskriptive Problembeschreibung vor. Dies kann ebenfalls an unserem Beispiel illustriert werden, denn auch ohne formale Umformungen lassen sich interessante Untersuchungen anstellen. Man kann elektrische Eigenschaften (Gesamtwiderstand, Resonanzfrequenzen) oder Kosten (Bauteile, Anzahl der Lötpunkte) berechnen lassen. Typisch für diese Art der Verarbeitung ist, daß die erforderlichen Algorithmen bereits vorliegen. Die Vorteile des Fachspracheinsatzes ergeben sich aus dem Wegfall des Zwischenschritts Codierung in einem anderen Formalismus (häufig Programmiersprache).

In [3] wird das an einem Beispiel aus dem Bankbereich beschrieben. Die Fachsprache Risla (interest rate information system language) wird benutzt, um neue Bankprodukte zu beschreiben. Die Implementation stützt sich dabei auf eine vorhandene COBOL-Programmbibliothek. Der Nutzen ergibt sich dabei aus der schnelleren Umsetzung von Produktdefinitionen in Produkte und der Vermeidung von Reibungsverlusten und Mißverständnissen. Die Autoren bewerten vor allem letzteres als sehr wichtig, da die Komplexität der Bankprodukte zunimmt und damit die Vermittlung schwieriger wird.

Ähnlich wurden Fachsprachen definiert, um ein Programmpaket für stöchiometrische Berechnungen Biochemikern direkt zugänglich zu machen [1] bzw. den Aufwand für die Vorbereitung bestimmter Simulationen zu verringern [2]. Ebenso ist es möglich, aus geeigneten Produktbeschreibungen Steuerprogramme für Montagerobotor oder Treiberprogramme [4] zu generieren.

Gemeinsam ist den Beispielen, daß eine Softwarebasis (Bibliotheken, Programmpakete) vorhanden ist. Die Probleme entstehen daraus, daß ihr Einsatz durch Abhängigkeiten u. ä. sehr schwierig ist und deshalb nicht unmittelbar durch die Experten des Fachs erfolgen kann. Solche Software stellt praktisch eine virtuelle Maschine dar, die auf elementarem Niveau programmiert werden muß. Durch Fach(programmier)sprachen kann dabei die Produktivität gesteigert werden.

Fachsprachen können unabhängig vom Computer existieren. Es existieren in vielen Fachgebieten bereits stark formalisierte Fachsprachen, die prinzipiell geeignet wären, die Basis entsprechender Fachprogrammiersprachen zu bilden. Die Vorteile bei der Verwendung solcher Sprachen liegen auf der Hand:

  • kein sprachlicher Bruch zwischen Problem- und Programmbeschreibung
  • daraus resultierender geringerer Wartungs- und Schulungsaufwand
  • Programmbeschreibungen dokumentieren (und archivieren) gleichzeitig Know-how

Die Entwicklung ist bisher allerdings vorwiegend anders verlaufen. Zunächst wurden, bedingt durch Beschränkungen der Hardware, jeweils einzelne Aufgaben implementiert und, im Laufe der Zeit, an immer größere Einsatzbereiche angepaßt. Tatsächlich definieren Anwendungsprogramme Fachsprachen für ihren Einsatzbereich. Der entscheidende Unterschied zu den Fachsprachen im oben genannten Sinn besteht jedoch darin, daß ihnen gewöhnlich eine dem Nutzer vermittelbare Theorie fehlt. Eine solche Theorie ist jedoch Voraussetzung, um alle Vorteile nutzen zu können.

Damit wäre ein weiteres Merkmal von Fachsprachen berührt: Sie sind (formaler) Ausdruck von Theorien ihres Objektbereichs. Ihre Gestaltung berührt deshalb immer Kernfragen des Fachs und kann schwerlich an reine Softwareproduzenten übergeben werden. Vielmehr gibt es praktische Beispiele, daß die Gestaltung von Fachsprachen eine Herausforderung an die Fachgebiete selbst darstellen kann, bekannte Fragen unter neuen Gesichtspunkten zu analysieren. Zu Recht wird deshalb in [9] als erster Forschungsschwerpunkt die Sammlung und Formalisierung von Fachwissen in Sprachform genannt.

Fachsprachen können auch helfen, ein weiteres Problem zu lösen. Heutige Programme sind größtenteils noch Einzelanfertigungen, d.h., daß eine handwerkliche Produktion überwiegt. [12] Ein höheres Niveau, d.h., eine industrielle Softwareerzeugung erfordert, nicht Lösungen für einzelne Probleme, sondern für ganze Problemklassen zu beschreiben. Das Ergebnis ist dann ein Programm, das, statt eine gegebene Aufgabe zu lösen, solche Programme erzeugt: ein Programmgenerator. Dabei werden (meist deskriptiv geprägte) Problemspezifikationen verarbeitet, während der Lösungsalgorithmus bereits durch den Generator vorgegeben ist.

Aus dem bisher gesagten ist klar, daß neben der Definition von Fachsprachen ihre Implementation eine außerordentliche Herausforderung darstellt.

  • Sie erfordert das Verständnis der zugrundeliegenden Theorien/ Modelle, muß also in der Regel in enger Verbindung mit oder, besser, durch Spezialisten des Fachgebiets erfolgen.
  • Häufige Änderungen sind wahrscheinlich. Durch die enge Verbindung mit den Theorien des Fachgebiets wird die Fachsprache selbst zum Mittel des Erkenntnisgewinns, der gewöhnlich zu Modifikationen der Theorie führt.
  • In den Anwendungsgebieten verläuft die Entwicklung meist langsamer und weniger sprunghaft als bei der eingesetzten Hardware. Das erfordert zusätzliche Bemühungen, die erzielten Ergebnisse längerfristig zu sichern.
  • Der potentielle Benutzerkreis ist wesentlich kleiner als bei Universalsprachen. Damit sind dem vertretbaren Aufwand enge Grenzen gesetzt.

Der breite Einsatz von Fachsprachen ist deshalb an die Verfügbarkeit geeigneter Implementationswerkzeuge gebunden. Dabei zeichnen sich zwei Hauptmethoden der Unterstützung ab: Übersetzergeneratoren und Application-Frameworks.

Application-Frameworks sind Rahmenanwendungen, bei denen wesentliche Konzepte schon in die Struktur eingebunden sind, während die konkreten Operationen teilweise offen gelassen werden (d.h. abstrakt sind). Implementation einer Fachsprache bedeutet dann Implementation solcher Funktionen. Dieses Modell ist besonders vorteilhaft, wenn es mit einem Editor zur Framework-Generierung kombiniert wird. Nachteilig ist die Beschränkung durch die starren Vorgaben zu sehen. Solche Frameworks sind deshalb an bestimmte Aufgabenklassen gebunden und wegen ihres Erstellungsaufwands nur für wirklich häufige Teilaufgaben geeignet [6, 11].

Für Übersetzergeneratoren stehen zahlreiche Werkzeuge zur Verfügung. Neben denjenigen, die solide Compilerbaukenntnisse voraussetzen, findet man inzwischen auch solche, die sich an einen weiteren Interessentenkreis wenden. Speziell die Verwendung als Vorübersetzer hat, bei Wahl einer geeigneten Zwischensprache, große Vorteile. Es kann eine weitgehende Portabilität und einfache Verbindung zu anderer Software erreicht werden.

Gleichzeitig wird eine spezielle Form des Wiederverwendung praktiziert: Die in den Compilern manifestierten Fertigkeiten und automatisch auch künftige Verbesserungen werden ausgenutzt.

Die Implementation von Fachsprachen, die nicht nur der Beschreibung algorithmischer Abläufe dienen, hat enge Beziehungen zu Expertensystem-Werkzeugen [10]. Tatsächlich ist der Übergang fließend (häufig sind beide Ansätze kombiniert), und der Unterschied besteht allein darin, ob das Expertenwissen vorrangig in algorithmischoperativer oder konstatierenddeskriptiver Weise formalisiert wird. Auch die sogenannten Sprachen der vierten Generation (4GL) können, zumindest dem Anspruch nach, zu den Fachsprachen gezählt werden.

In Deutschland ist der Fachsprachengedanke durch Prof. Lehmann in Dresden frühzeitig [7] gefördert worden. Daß dieses interessante und zukunftsweisende Gebiet nun wieder stärker ins Blickfeld rückt, kann an einer zunehmenden Zahl von wissenschaftlichen Veranstaltungen zu diesem Thema abgelesen werden.

                   Artikelanfang  Seitenanfang

Literatur

  1. M. Ainsworth, J. P. Bennett: The design of a programming language for the analysis of problems in biochemistry. J. of Prog. Lang. 1(1993)2, 143–151
  2. D. Bruce: What makes a good domainspecific language? In ACM-SIGPLAN Workshop DSL ’97. Proceedings. Paris: University of Illinois Computer Science Report 1997, 17–35
  3. A.v. Deursen, P. Klint: Little languages, little maintenance? In DSL ’97 (s. 2), 109–127
  4. P.G.M. Jansen: Software Robots – Automating the Software Factory. In CC’96 Workshop on Compiler Techniques for Application Domain Languages and Extensible Languages Models (ALEL ’96). Proceedings. Linköping: Univ. 1996, 34–41
  5. R.M. Kaplan: Constructing Language Processors For Little Languages. New York: John Wiley and Sons Inc. 1994
  6. K. Koskimies: Frameworks and applicationoriented languages. In ALEL ’96 (s. 4)., 5–6
  7. N.J. Lehmann: Zur Bedeutung problemorientierter Programmierungssprachen. rt/dv (Berlin) (1970)7, 34–35
  8. J. Ludewig: Sprachen für das Software-Engineering. Informatik Spektrum 16(1993)5, 286–294
  9. T. Nilsson: Application Domain Languages: Some Suggestions for Research. In ALEL ’96 (s. 4), 1–4
  10. F. Puppe: Problemlösungsmethoden in Expertensystemen. Studienreihe Informatik, Berlin, Heidelberg, New York: Springer. 199
  11. G. Tewkesbury, D. Sanders: A Framework for the Automatic Programming of Advanced Production Machinery. In IEEE 20th Euromicro 94. Proceedings. 1994, 224–230
  12. W. M. Waite: Compiler Construction: Craftsmanship or Engineering? In T. Gyimóthy (ed.): Compiler Construction. LNCS 1060, Berlin, Heidelberg, New York: Springer 1996, 151–159

                   Artikelanfang  Seitenanfang

Autor & Copyright
Jürgen Lampe
Technische Universität Dresden,
Fachrichtung Mathematik,
Mommsenstrasse 13,
D-01062 Dresden
lampe@math.tu-dresden.de

© 1997 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang

FDDI - Fiber Distributed Data Interface

Erläuterung

FDDI („Fiber Distributed Data Interface") steht für ein lokales Hochgeschwindigkeitsnetzwerk („High Speed Local Area Network", HSLAN), das Lichtwellenleiter(LWL)-Technik in einer Doppelring-Topologie verwendet. HSLANs verbinden in durchsatzintensiven Anwendungen „Server"-Stationen mit Workstations und - als „Backbones" - herkömmliche und mittlerweile standardisierte lokale Netze (CSMA/CD, Token Bus, Token Ring). Im Vergleich zu diesen zeichnet sich FDDI aus durch

  • höhere Übertragungsrate (100 Mbit/s),
  • größere Netzausdehnung (bis zu 100 km),
  • bessere Störsicherheit (aufgrund der LWL-Eigenschaften) und
  • erweiterte Fehlertoleranz (rekonfigurierbarer Doppelring).

Allerdings erfordert der direkte Zugang zu FDDI deutlich höheren Anschaltaufwand.

Konkurrenzentwicklungen zu FDDI werden vorwiegend im Universitätsbereich betrieben. Auf breiterer wirtschaftlicher Basis stehen das von Bellcore entwickelte „Metrocore" und das Projekt IEEE 802.6 DQDB („Distributed Queue Dual Bus"). Beide Systeme verwenden ein „Slotted Bus"-Medienzugangsverfahren, das bei größeren Entfernungen und höheren Datenraten deutlich effizienter ist als das FDDI-Protokoll. Aufgrund passend gewählter Übertragungsraten und Datenrahmenlängen ermöglichen sie einen einfacheren Übergang zu öffentlichen Netzen (Breitband-ISDN).

Der Entwicklungsvorsprung, den FDDI derzeit gegenüber konkurrierenden Verfahren aufweist, zeigt sich darin, daß bereits integrierte Bausteine und Anschalt-Baugruppen erhältlich sind. Im folgenden werden die wichtigsten Festlegungen des FDDI-Normenpakets vorgestellt, ohne auf die zum Teil komplexen Zusammenhänge zwischen Betriebsparametern einzugehen: Die maximale Datenpaketlänge ist in Abhängigkeit von der fest vorgegebenen Länge eines „Elastizitätpuffers" auf 4500 Byte begrenzt, weil alle Stationen im Ring Datenpakete mit ihrem (Toleranzen unterworfenen) lokalen Takt senden. Hinsichtlich des Medienzugangsverfahrens besteht Ähnlichkeit mit dem Token Ring gemäß IEEE 802.5. Akzeptabler Durchsatz bei gestiegener Distanz erforderte eine Modifikation der Token-Weitergabe („Early Token Release", d.h. Token Transfer unmittelbar nach dem Senden eines Datenpakets). Die maximale Token-Rotationszeit wird bei der Initialisierung des Rings von allen Stationen ausgehandelt. Verbindungsstrukturen und Stationstypen zeigt Abb. 1.

Abb. 1. FDDI: Topologie und Stationstypen

Class-A-Stationen sind mit jeweils zwei Lichtwellenleitern mit ihren beiden Nachbarn verbunden und bilden dadurch einen Doppelring. Im Normalfall werden nur auf dem Primärring Daten übertragen. Im Fehlerfall stellen die Stationen beiderseits der Fehlerstelle eine Verbindung zwischen Primär- und Sekundärring her: Es entsteht ein doppelt so langer neuer Ring. Abgeschaltete oder defekte Stationen werden durch ein optisches Relais vom Ring getrennt.

Die von den Anschlußkosten her billigeren Class-B-Stationen können nur über einen Konzentrator an den Ring angeschlossen werden; ein Kabeldefekt trennt die betroffene Station vom Netz.

Die maximale Entfernung zwischen zwei Stationen beträgt 2 km, der maximale Ringumfang bei Standard-Betriebsparametern 100 km. Wird der bisher genormte Multimode-Lichtwellenleiter durch einen Monomode-Typ ersetzt, vergrößert sich der maximal zulässige Stationsabstand.

FDDI deckt im ISO-OSI-Referenzmodell die Schichten 1 und 2a ab und unterstützt - wie alle 802.X-LANs - uneingeschränkt die ISO-Teilschicht 2b (Logical Link Control). Die Struktur der unteren Schichten zeigt Abb. 2. Vom PMD („Physical Medium Dependent")-Dokument werden z.B. Steckerform, zulässige Kabeldämpfung und Ansprechzeit des optischen Relais spezifiziert. In der PHY(„Physical Layer Protocol")-Teilschicht finden die Kodierung/Dekodierung und die Seriell/Parallel-Umsetzung statt. Die MAC(„Medium Access Control")-Teilschicht interpretiert einlaufende Pakete. Für andere Stationen bestimmte Pakete werden weitergereicht; Pakete, die an die eigene Station adressiert sind, werden außerdem in den Empfangspuffer kopiert. Ein von der eigenen Station gesendetes Datenpaket wird nicht weitergereicht und damit vom Ring genommen.

Abb. 2. FDDI: Schichtenstruktur

Die FDDI-MAC-Schicht unterscheidet zwei Prioritäten: Für Nachrichten der „synchronen" Klasse steht jeder Station eine vorab einzustellende garantierte Kommunikationsbandbreite zur Verfügung. Nachrichten der „asynchronen" Klasse nutzen die verbleibende Bandbreite. Obwohl der Name dies vermuten ließe, ist die „synchrone" Klasse für die Übertragung von Sprache nicht sonderlich geeignet: Es wird nur eine mittlere Datenrate garantiert; die Verzögerungen, die einzelne Pakete erfahren, streuen bei großen Token-Rotationszeiten sehr stark. Kleine Token-Rotationszeiten führten wiederum zu einer schlechten Netzauslastung.

Das „Station Management" (SMT) hat Verbindung zu allen anderen Funktionseinheiten. Beim Initialisieren einer Station werden nach einem Selbsttest das optische Relais eingeschaltet und über PHY mit den Nachbarstationen auf niedrigster Ebene Symbolfolgen ausgetauscht. Wenn dabei keine Fehler auftreten, wird der Ring aufgebaut. Auch im laufenden Betrieb überwacht SMT das Netz und führt im Fehlerfall eine Rekonfiguration durch. Die Verteilung der synchronen Bandbreite, das Führen von Fehler- und Durchsatzstatistiken sowie die Verwaltung von Netzwerkadressen gehören ebenfalls zu den Aufgaben von SMT.

Ein Versuch, FDDI zu einem dienstintegrierenden Netzwerk im Sinne von ISDN zu machen, wurde mit FDDI-II unternommen. Zusätzlich zu den Nachrichtenklassen von FDDI unterstützt FDDI-II „isochrone" (d.h. einem festen Zeitraster unterworfene) Nachrichten. Dazu wird von einer ausgezeichneten Station, dem „Cycle Master", alle 125 Mikrosekunden ein Datenrahmen fester Länge erzeugt. Die Pakete sind in 16 Gruppen zu je 96 Byte organisiert. Jede Gruppe stellt eine „Wideband Channel" (WBC) mit einer Datenrate von 6,144 Mbit/s dar, den eine Station reservieren und dann exklusiv benutzen kann. Eine weitere Aufteilung in mehrere unabhängige Kanäle mit geringer Datenrate ist möglich: Benutzt z.B. ein Kanal jeweils nur ein bestimmtes Byte eines WBC, so entstehen 96 Kanäle zu je 64 kBit/s. Auf diese Weise können alle Standard-Raten der öffentlichen Netze eingestellt werden. Alle nicht reservierten Wideband Channels werden für synchrone bzw. asynchrone Datenübertragung genutzt. (Eine Konfiguration mit 16 reservierten Wideband Channels belegt allerdings mehr als 98 % der verfügbaren Übertragungsbandbreite.)

Abb. 3. FDDI-II: Schichtenstruktur

Abbildung 3 zeigt die FDDI-II-Schichtenstruktur. Neu im Vergleich zu FDDI ist der Baustein „Hybrid Ring Control" (HRC). Seine Aufgabe ist es, je nach Belegung eines Wideband-Channels die Datenströme über das bisherige Paket-Zugangsprotokoll (P-MAC) oder über das für isochrone Daten (I-MAC) zu leiten. Die I-MAC-Funktion selektiert aus den isochronen WBC die von der eigenen Station belegten Kanäle, CS(„Circuit Switching")-MUX besorgt die Synchronisation sowie das Multiplexen und Demultiplexen der Anwendungsverbindungen.

FDDI ist eine Entwicklung der ANSI-Arbeitsgruppe X3T9.5, deren Anfänge in das Jahr 1982 zurückreichen. Ursprünglich als „Back-End"-System zur Verbindung von Rechnern mit schnellen Platteneinheiten konzipiert, ändere sich die Hauptzielrichtung mit der Zeit zu „Back-Bone"- und „Front-End"-Systemen. 1989 wurden MAC und PHY als ISO-Normen (9314-X) niedergelegt. PMD und SMT stehen kurz vor der Normung. Die Arbeiten an FDDI-II begannen 1984 und beinhalten neben der Einführung der HRC-Komponente Modifikationen an PhY und MAC.

Aus diesen Änderungen entsteht auch der grundsätzliche Nachteil von FDDI-II: Befindet sich auch nur eine einzige Station in einem FDDI-II-Ring, die das neue Protokoll nicht beherrscht, kann der Ring nur im FDDI-kompatiblen „Basic-Mode" betrieben werden. Isochroner Datenverkehr ist erst möglich, wenn alle Stationen FDDI-II-kompatibel sind.

Während die Zukunft von FDDI gesichert scheint, bleibt abzuwarten, ob sich FDDI-II gegenüber konkurrierenden Ansätzen wie IEEE 802.6 DQDB behaupten kann.

                   Artikelanfang  Seitenanfang

Literatur

  1. Ross, F.E., Hamstra, J.R., Fink, R. L.: FDDI: A LAN Among MANs. Comput. Commun. Rev. 20, (3), 16-31 (1990
  2. Calvo, L., Teener, M.: FDDI-II, Architectural and Implementation Examples. Proc. EFOC/LAN '90, München, S. 76-86

                Artikelanfang  Seitenanfang

Autor & Copyright
Dr. H. Dietsch R. Ulrich
Informatik-Forschungsgruppe E
Universität Erlangen-Nürnberg
Martensstr. 3,
W-8520 Erlangen

© 1991 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang