Lexikon

Fachsprachen

Formale Sprachen sind von Anfang an die entscheidende Schnittstelle zwischen Mensch und Computer gewesen. Ihre Gestaltung beeinflußt Effizienz und Qualität der Softwareentwicklung. 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 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 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 bzw. den Aufwand für die Vorbereitung bestimmter Simulationen zu verringern. Ebenso ist es möglich, aus geeigneten Produktbeschreibungen Steuerprogramme für Montagerobotor oder Treiberprogramme 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 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. 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.

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. 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 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.

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

Autor und 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