Visuelle Programmierung

Transkript

1 Visuelle Programmierung Stefan Schiffer Grundlagen und Einsatzmöglichkeiten

2

3 Stefan Schiffer Visuelle Programmierung Grundlagen und Einsatzmöglichkeiten

4 Inhaltsverzeichnis 1. Einleitung Geschichtlicher Rückblick Aktuelle Situation 7 2. Terminologie Analyse der Begriffe Synthese der Begriffe Pro und Kontra visuelle Programmierung Kognitive Aspekte Gründe für visuelle Programmierung Gründe gegen visuelle Programmierung Reflexionen über fünf Thesen zur visuellen Programmierung Klassifikationen für visuelle Programmierung Klassifikation nach Shu Klassifikation nach Chang Klassifikation nach Myers Klassifikation nach Burnett und Baker Konzepte visueller Programmiersysteme Steuerflußorientierte VP-Systeme Datenflußorientierte VP-Systeme Funktionsorientierte VP-Systeme Objektorientierte VP-Systeme Constraintorientierte VP-Systeme Regelorientierte VP-Systeme Beispielorientierte VP-Systeme Formularorientierte VP-Systeme Multiparadigmenorientierte VP-Systeme Beispiele für visuelle Programmiersysteme C 2 : Visuelle Programmierung mit Anweisungssequenzen SERIUS: Visuelle Programmierung mit Komponentennetzen 134

5 iii 6.3 LABVIEW: Visuelle Programmierung mit Datenflußdiagrammen VISAVIS: Visuelle Programmierung mit Funktionsdiagrammen PARTS: Visuelle Programmierung mit Objektdiagrammen Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Anwendungsbereich Konzeptionelle Grundlagen Das Programmiermodell Spezialisierung und Konfiguration Datentypen Beispiel für die Konstruktion einer Applikation Zusammenfassung Potentiale visueller Darstellungen in der Programmierung Grenzen visueller Darstellungen in der Programmierung Schlußfolgerungen 266

6 iv Für Gerlinde, Birgitta und Ulrike Außer der durchhängenden Schnur, die, so weit sie hinaufstieg, unzweifelhaft erhaben aussah, war nichts zu sehen, da der Drachen den Blicken entschwunden war. Mr. Kelly war entzückt. Nun konnte er den Abstand zwischen dem Sichtbaren und dem Unsichtbaren messen, nun war er imstande, den Punkt zu bestimmen, wo Sichtbares und Unsichtbares sich berührten. Es wäre infolge der vielen, launischen Imponderabilien eine unwissenschaftliche Beobachtung. Aber das Vergnügen, das sie Mr. Kelly bereitete, würde keinesfalls geringer sein als jenes, das Mr. Adams bei seiner hübschen Deduktion Neptuns vom Uranus (vermutlich) zuteil wurde. Er fixierte mit seinen Adleraugen einen Punkt am leeren Himmel, wo der Drachen seiner Meinung nach wieder auftauchen müßte, und wand die Schnur sorgfältig wieder auf. Samuel Beckett, Murphy, 13. Kapitel

7 1 Vorwort Dieses Buch soll eine kritische aber ausgewogene Auseinandersetzung mit verschiedenen Aspekten der visuellen Programmierung sein und eine Orientierungshilfe zur Einschätzung des Anwendungsgebietes bieten. Es befaßt sich ausführlich mit Grundlagen, Techniken, Möglichkeiten und Grenzen der visuellen Programmierung und richtet sich an Praktiker, Wissenschaftler und Studenten aus dem Bereich der Softwaretechnik sowie an andere Personen, die an modernen Softwarekonzepten interessiert sind. Das Buch soll Antworten auf folgende Fragen geben: Was ist visuelle Programmierung? Wofür eignet sich visuelle Programmierung und wofür nicht? Wie sind visuelle Programmiersysteme aufgebaut? Kapitel 1»Einführung«zeigt die geschichtliche Entwicklung der visuellen Programmierung und skizziert den Stand der Technik im akademischen und industriellen Bereich. Kapitel 2»Terminologie«versucht die Begriffswelt der visuellen Programmierung systematisch zu erfassen und die zum Teil vagen Definitionen der Fachliteratur durch ein zweckmäßiges begriffliches Instrumentarium zu ersetzen. Beginnend mit dem nur scheinbar leichtverständlichen Begriff»visuell«werden die weiteren Fachbegriffe unter verschiedenen Gesichtspunkten analysiert, mit Beispielen unterlegt und schließlich in knapper Form definiert. Kapitel 3»Pro und Kontra visuelle Programmierung«untersucht die Stärken und Schwächen der visuellen Programmierung anhand allgemeiner Merkmale bildlicher Darstellungen. Auf konkrete Programmiersysteme wird nur fallweise Bezug genommen. Zu Beginn erklärt ein kurzer Abriß über kognitive Aspekte, warum visuelle Darstellungen vom Menschen besonders wirkungsvoll verarbeitet werden und wie sich daraus Vorteile für die Programmierung ergeben könnten. Anschließend werden Pro- und Kontra-Argumente von Fachautoren angeführt. Der Hauptteil des Kapitels befaßt sich mit fünf Thesen zur Rolle des Bildes in der Programmierung. Es wird gezeigt, daß manche Behauptungen über den hohen Wert visueller Darstellungen in der Programmierung zweifelhaft sind. Kapitel 4»Klassifikationen für visuelle Programmierung«stellt Taxonomien bekannter Fachautoren vor. Sprachen und Systeme der visuellen Programmierung werden nach verschiedenen Kritierien erfaßt. Dieses Kapitel vermittelt einen Eindruck von den unterschiedlichen Facetten visueller Programmierung. Die Klassifikation von Burnett und Baker dient als Grundlage für Kapitel 5. Kapitel 5»Konzepte visueller Programmiersysteme«betrachtet die konzeptionellen Grundlagen visueller Softwareentwicklungsumgebungen anhand von neun Programmierparadigmen: steuerflußorientiert, funktionsorientiert, datenflußorientiert, objektorientiert, constraintorientiert, regelorientiert, beispielorientiert, formularorientiert und multiparadigmenorientiert. Die mit diesen Denkmodellen verbundenen Vor- und Nachteile werden exemplarisch erläutert. Kapitel 6»Beispiele für visuelle Programmiersysteme«präsentiert typische visuelle Programmiersysteme (VP-Systeme) aus dem akademischen und kommerziellen Be-

8 2 reich. Die Präsentation der Systeme umfaßt eine kurze Einführung mit historischen Anmerkungen, eine Beschreibung von Anwendungsbereich und Benutzerkreis, die Darstellung der softwaretechnischen Grundkonzepte und der verwendeten Programmiersprache sowie eine Beschreibung der Interaktionsmechanismen und Werkzeuge. Die gewählten Beispiele sollen das Verständnis für die in Kapitel 6 beschriebenen Konzepte vertiefen und helfen zu verstehen, wie visuelle Programmierung in der Praxis funktioniert. Kapitel 7»Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem«beschreibt das vom Autor entwickelte multiparadigmenorientierte VP-System Vista, das die Implementierung reaktiver und transformativer Systeme unterstützt. Zuerst werden Anwendungsbereich und Grundkonzepte von Vista erläutert. Diese Abschnitte behandeln auch reaktive und transformative Systeme sowie die komponentenbasierte Softwareentwicklung. Der Hauptteil stellt das Programmiermodell mit seinen Komponenten und Werkzeugen vor. Abschließend zeigt ein vollständiges Beispiel, wie man mit Vista eine Applikation konstruiert. Die in Vista realisierten Konzepte beruhen auf dem Versuch, softwaretechnische Konstruktionsprinzipien konsequent zu berücksichtigen, und können vor allem für jene Leser eine Anregung sein, die selbst ein VP- System entwickeln wollen. Kapitel 8»Zusammenfassung«diskutiert abschließend die Potentiale und Grenzen visueller Darstellungen in der Programmierung.

9 3 Dank Mein Dank gilt allen, die an der Entstehung dieses Buches mitgewirkt haben. Zwei Personen gilt mein besonderer Dank: meinem Kollegen Joachim Hans Fröhlich, dessen fundiertes Wissen und engagierte Mitarbeit zur erfolgreichen Realisierung des visuellen Programmiersystems Vista wesentlich beigetragen haben, sowie Prof. Gustav Pomberger, der nicht nur wissenschaftlicher Ansprechpartner war, sondern auch mit großem persönlichen Einsatz die organisatorischen und finanziellen Grundlagen für jene Projekte geschaffen hat, die diesem Buch zugrundeliegen. Linz, im September 1997 Stefan Schiffer

10 iv

11 1. Einleitung Ein Algorithmus muß gesehen werden, damit er begreifbar wird, und der beste Weg zu lernen, wie ein Algorithmus funktioniert, ist, ihn auszuprobieren. Diesen Satz schrieb Knuth [73 S. 4; OZ 1] in seinem klassischen Werk»The Art of Computer Programming«. Er sprach damit bereits Anfang der 70er Jahre eines der großen Probleme an, das mit dem Verständnis softwaretechnischer Sachverhalte auch heute noch verbunden ist: Wie kann Software verständlich sein, wenn man nur ihre Ergebnisse sieht, aber nicht das Zusammenwirken der Elemente, die zu diesen Ergebnissen führen? Die Analyse des Programmtextes vermittelt vielfach nur begrenzte Einsichten. Die Beschreibung eines Programms mit einer Programmiersprache legt zwar exakt und eindeutig dessen Aufbau und Funktionsweise fest, die meisten Menschen auch Programmierer sind jedoch nicht in der Lage, komplizierte Strukturen und Abläufe nur aufgrund von Beschreibungen zu verstehen. Der Mensch braucht Anschauungsmaterial, damit ihm»ein Licht aufgeht«, und er braucht das Experiment, um seine Beobachtungen zu verifizieren. Die Arbeitsweise mechanischer Geräte folgt physikalischen Prinzipien, die uns vertraut sind. Eine Pendeluhr kann man zerlegen und das Ineinandergreifen der Zahnräder beobachten. Man kann das Geheimnis des Ankers zu ergründen versuchen, und mit ein wenig technischer Begabung wird man schließlich begreifen, warum sich die Zeiger bewegen. Wer die Funktionsweise einer am Computerbildschirm angezeigten Uhr nachvollziehen möchte, muß die Software dahinter verstehen (siehe Bild 1-1). Doch dieses Uhrwerk aus Bits und Bytes ist eine virtuelle Maschine, die man nicht einfach zerlegen kann. Selbst Experten können nur schwer durchschauen, was die vielen hundert Programmzeilen zu bedeuten haben, die notwendig sind, um aufgrund eines Taktimpulses der Computerhardware jene Bildpunkte auf den Bildschirm zu zeichnen, die das Vorrücken des Sekundenzeigers bewirken. Ausgehend von der Erkenntnis, daß der Mensch bildliche Eindrücke besonders effizient verarbeitet und konkrete Objekte besser erfassen kann als abstrakte Beschreibungen, suchte man in den letzten Jahren intensiv nach Möglichkeiten, die unsichtbare Maschine Software sichtbar zu machen. Die Konstruktion von Programmen sollte im gegenständlichen Sinn möglich sein, d.h. vereinfacht ausgedrückt, Programme sollten durch»zusammenstecken und Ausprobieren«entstehen. Bei dieser Art der Programmierung kommen vorwiegend grafische Notationen und interaktiv manipulierbare Softwarekomponenten zum Einsatz. Als Bezeichnung dafür hat sich der Begriff»visuelle Programmierung«etabliert. Visuelle Programmierung ist zu einem Synonym für intuitive und mühelose Softwareentwicklung geworden. Das Ziel visueller Programmierung ist vor allem die Erhöhung der Verständlichkeit von Programmen und die Erleichterung der Programmierung selbst. Durch visuelle Programmierung sollen auch Anwender in die Lage versetzt werden, Applikationen für den eigenen Bedarf zu erstellen, für deren Programmierung beim Einsatz konventioneller Werkzeuge und Sprachen professionelle Softwareentwickler benötigt würden.

12 Einleitung 2 Bild 1-1. Pendeluhr und Bildschirmuhr. Pendeluhr: Brockhaus [94-22 S. 526]; Bildschirmuhr: vgl. Serius [92-2 S ff] 1.1 Geschichtlicher Rückblick Grafische Darstellungen werden in der Programmierung seit langem verwendet. Haibt entwickelte Ende der 50er Jahre ein System zur automatischen Generierung von Flußdiagrammen aus Assembler- und Fortran-Programmen (vgl. Price et al. [93 S. 214]). Ivan E. Sutherland implementierte 1963 das Zeichenprogramm Sketchpad, das Kay [93 S. 71] als erstes brauchbares System mit grafischer Interaktion bezeichnet. Sutherland leistete damit einen wesentlichen Beitrag zu den Grundlagen der Mensch-Maschine- Kommunikation und damit auch zur visuellen Programmierung. Myers [94 S. 879 ff] nennt eine Reihe weiterer Forschungsarbeiten, von denen drei historisch gesehen besonders bedeutsam sind. (1) William R. Sutherland schrieb 1966 am MIT in Cambridge eine Dissertation mit dem Titel»On-Line Graphical Specification of Computer Procedures«. Er entwickelte den Graphical Program Editor, der Programme ähnlich wie Hardwareschaltpläne repräsentierte und diese interpretativ ausführte. Nach Einschätzung von Myers hat Sutherland damit das erste visuelle Programmiersystem (VP- System) geschaffen. (2) Ellis et al. entwarfen 1969 das System Grail, das Programme direkt aus maschinenlesbaren Flußdiagrammen generierte. (3) Christensen stellte in den Jahren 1968 und 1971 die grafischen Programmiersprachen AMBIT/G und AMBIT/L vor. Diese Sprachen gehörten zu den ersten visuellen Ansätzen, die vom Konzept der Anweisungssequenzen abwichen. Programme und Daten wurden als gerichtete Graphen repräsentiert und Algorithmen als Graphtransformationen beschrieben. Auf diese Weise konnten auch komplizierte Algorithmen in Form von Graphtransformationen beschrieben werden. Mitte der 70er Jahre erschlossen sich durch bessere Hard- und Software viele neue Anwendungsgebiete für den Computer. Zu dieser Zeit begann man verstärkt darüber

13 1.1 Geschichtlicher Rückblick 3 nachzudenken, welche Vorteile sich durch den Einsatz von Grafik in der Programmierung ergeben könnten entwickelte David C. Smith [75] im Rahmen seiner Dissertation an der Stanford Universität eine grafische Programmierumgebung mit dem Namen Pygmalion, die als Markstein der visuellen Programmierung gilt. In einem Rückblick aus dem Jahre 1993 bezeichnete Smith [93 S. 19] sein System als»executable Electronic Blackboard«. Die Ideen von Smith beruhen u.a. auf der Überlegung, daß Programme besser durch Vorzeigen relevanter Beispiele erstellt werden als durch Beschreibung der gewünschten Funktionen und daß Piktogramme für die Darstellung von Programmkonstrukten besonders geeignet sind. Er begründete dies damit, daß eine solche Herangehensweise und Präsentationsform das kreative Denken besonders wirkungsvoll nutzt. Pygmalion war zwar nur zur Lösung einfacher Aufgaben geeignet, wie z.b. der in Bild 1-2 gezeigten Fakultätsfunktion, kann jedoch als Vorbote der heute üblichen Benutzungsschnittstellen gesehen werden, die mit Piktogrammen und direkter Manipulation eine einfache und intuitive Bedienung des Computers ermöglichen. Smith implementierte Pygmalion in der Programmiersprache Smalltalk 72 auf einem Dynabook ALTO einen der ersten Computer mit einem Rastergrafikbildschirm (vgl. Kay [93 S. 80]). Bild 1-2. Pygmalion Fenster zur Definition der Fakultätsfunktion. Smith [93 S. 43]

14 Einleitung 4 Ende der 70er Jahre brachte die strukturierte Programmierung weitere Impulse für grafische Programmierumgebungen. Am IBM-Forschungslabor in San José entwickelten Frei et al. [78] das Programming Support System, mit dem man erweiterte Nassi- Shneiderman-Diagramme (Struktogramme) interaktiv erstellen und nach PL/I übersetzten konnte. Mit diesem Projekt wurde das Ziel verfolgt, durch den Einsatz einer grafischen Softwareentwicklungsumgebung die Qualität von Programmen signifikant zu steigern und die Produktionskosten deutlich zu senken. Das System wurde jedoch nie für die Entwicklung praxistauglicher Applikationen eingesetzt, und deshalb konnten auch keine Rationalisierungseffekte nachgewiesen werden (vgl. Shu [88 S. 166]). An der Universität Hong Kong verfolgten Pong und Ng [83] mit PIGS ein weitergehendes Konzept, das ebenfalls auf Struktogrammen beruhte. Diese Struktogramme wurden allerdings nicht in eine höhere Programmiersprache übersetzt, sondern interpretiert und dabei visualisiert. Auch dieses System hatte nur experimentellen Charakter und kam über eine prototypische Implementierung nicht hinaus. Zloof [81] leitete am Thomas-J.-Watson-Forschungslabor ein Projekt, das die Entwicklung benutzerfreundlicher Sprachen für die Büroautomation zum Ziel hatte gab IBM das dabei entstandene System QBE (Query-by-Example) als Produkt frei. QBE basiert auf einer zweidimensionalen Datenbanksprache, in der Datenbankrelationen und -abfragen mit einfachen, tabellarisch angeordneten Ausdrücken formulierbar sind, ohne daß Kenntnisse in einer herkömmlichen Programmiersprache vorausgesetzt werden. Zloof berichtet von vielen positiven Reaktionen [S. 13]. Die meisten Benutzer waren nach einer Schulung von wenigen Stunden in der Lage, QBE-Programme zu erstellen, mit denen Datenbanken definiert, abgefragt und modifiziert werden konnten. Psychologische Untersuchungen bestätigten die leichte Handhabbarkeit dieses Systems. Ein weiteres wichtiges Ereignis Ende der 70er Jahre war die Erfindung von VisiCalc, des ersten Tabellenkalkulationsprogramms, das ähnlich wie QBE auf einer leichtverständlichen, zweidimensionalen Darstellung beruhte. Durch die visuellen Repräsentation und die vertraute Strukturierung erschlossen VisiCalc und seine Nachfolger für hunderttausende Anwender den Computer als persönliches Werkzeug. Ermutigt vom bahnbrechenden Erfolg der Tabellenkalkulationsprogramme beschäftigten sich in den nächsten Jahren etliche Arbeiten mit tabellenorientierten bzw. formularbasierten Ansätzen. Heute hat man erkannt, daß für die Programmierung komplexer Softwaresysteme das Tabellenkonzept in eine Sackgasse führt: Das Anwendungsgebiet ist zu eng, und wesentliche Programmierprinzipien, etwa die funktionale Abstraktion, lassen sich nicht adäquat berücksichtigen (vgl. Ludolph et al. [88 S. 222 u. 230]). Die 80er Jahre führten zu einer Blüte von Forschungsaktivitäten auf dem Gebiet der visuellen Programmierung. Shneiderman [83] in Glinert [90-A&I S. 323] zitiert MacDonald [82], der in der Zeitschrift Datamation einen der ersten Artikel mit dem Titel»Visual Programming«schrieb und darin diese neue Art der Programmierung als Lösung für das schon damals akute Problem des Anwendungsrückstaus vorschlägt. Er meinte, daß visuelle Programmierung die Softwareentwicklung beschleunigen und auch Anwender in die Lage versetzen würde, selbst Software zu erzeugen bzw. an ihre Wünsche anzupassen. Matwin und Pietrzykowski [85] stellten die erste Version der heute kommerziell verfügbaren Programmiersprache Prograph vor. In ihrem Bericht zu Prograph heben sie auch die wegbereitende Rolle der visuellen Sprache GPL (Graphical Programming Language) hervor, die 1981 an der Universität von Utah für die DDM-1- Datenflußmaschine entwickelt wurde [S. 91].

15 1.1 Geschichtlicher Rückblick 5 Zu dieser Zeit bildete sich eine internationale Gruppe von Wissenschaftlern, die sich zum Ziel gesetzt hatten, den Schwerpunkt ihrer Forschungsaktivitäten ganz auf visuelle Sprachen zu verlegen. Viele Protagonisten der»visual Language Community«, kamen aus dem Bereich der Computergrafik. Shi-Kuo Chang [94-2 S.196; OZ 2], einer der bekanntesten Vertreter dieser Avantgarde, erzählt von der Zeit bis zum ersten»ieee Workshop on Visual Languages«im Jahr 1984: Die Vorläuferveranstaltung des»ieee Symposiums über visuelle Sprachen«(kurz VL) war der»ieee Workshop über Bilddatenbeschreibung und Verwaltung«. Der erste Workshop wurde von K. S. Fu und mir organisiert und fand 1977 in Chicago statt. Wie der Name sagt, waren die zwei Hauptthemen die Beschreibung und die Verwaltung von Bilddaten. Diese beiden Themen führten später zu zwei getrennten, aber gleichermaßen aktiven Forschungsgebieten: zu visuellen Sprachen und visuellen Datenbanken. Viele der»alten Garde«der heutigen VL-Gruppe kamen aus dem Bereich der Bildverarbeitung und des Computer-Sehens (computer vision). Tad Ichikawa, Stefano Levialdi, Steven Tanimoto und viele andere der VL-Gruppe waren aktiv an den PDDM-Workshops beteiligt. [...] Nach einigen Jahren wurde vielen von uns bewußt, daß es nicht nur um die Frage geht, wie Bilddaten zu beschreiben sind, sondern auch darum, wie Bilder zur effektiven Kommunikation verwendet werden können. Der IEEE Workshop zu Sprachen für die Automatisierung wurde von mir organisiert und fand 1981 zum ersten Mal statt. Das Programm umfaßte Abfragesprachen, Sprachen für Robotik und Spezifikationssprachen. Dadurch beteiligten sich auch Informationswissenschaftler, wie Bob Korfhage, aktiv an den folgenden Workshops. Der Kreis jener Wissenschaftler, die an visuell-orientierten Fragestellungen interessiert waren, begann zu wachsen kam von Tad Ichikawa die Anregung, eine neue Reihe von Workshops mit Schwergewicht auf visuellen Sprachen zu organisieren. [...]. Tad arbeitete unermüdlich an der Organisation des Workshops in Hiroshima, der 1984 stattfand. [...] Als Musterbeispiel für die Pionierarbeiten der ersten Tage gilt das System Pict, das Glinert und Tanimoto [84] an der University of Washington entwickelten (siehe Bild 1-3). Mit diesem Prototyp eines einfachen VP-Systems sollte man Programme erstellen können, ohne die Tastatur zu verwenden. Pict wird ausschließlich über Zeigerinstrumente wie Maus oder Joystick bedient. Der Benutzer zeichnet Programme, anstatt sie zu schreiben. Das auf den imperativen Konzepten Pascals beruhende System bietet nur einen kleinen Vorrat an Operationen und Datenstrukturen. In jedem Programmblock stehen vier Variablen zur Verfügung, symbolisiert durch die Farben Rot, Grün, Blau und Orange. Jeder Variablen kann eine maximal sechsstellige, positive, ganze Zahl zugewiesen werden. Unterprogramme und Operationen werden ausschließlich über Piktogramme identifiziert. Schriftliche Elemente kommen nur für kurze Hilfetexte zum Einsatz. Tanimoto und Glinert berichten zwar von ermutigenden Reaktionen bei der experimentellen Anwendung von Pict im Rahmen von Einführungskursen in die Programmierung, geben aber zu, daß dieses System signifikant verbessert werden müßte, um für fortgeschrittene Benutzer interessant zu sein.

16 Einleitung 6 Bild 1-3. Ausschnitt eines Pict-Programms; Farbbild im Anhang. Glinert [90-P&S S. 657, g-i] Begünstigt durch die Fortschritte im Hardwarebereich werden seit Beginn der 90er Jahre verstärkt kommerzielle Werkzeuge zur visuellen Programmierung angeboten. Ein bemerkenswertes Beispiel für den erfolgreichen Einsatz von visueller Programmierung im industriellen Umfeld ist LabVIEW von National Instruments. Dieses System zum Bau virtueller Instrumente kam 1986 auf den Markt und war die erste Programmierumgebung, die ausschließlich eine grafische Programmiersprache unterstützte. Version 1 wurde auf einem Macintosh Plus mit nur 1 MB Hauptspeicher entwickelt. Trotz der nach heutigen Maßstäben kümmerlichen Hardwarebasis, reagierten die Anwender überwiegend positiv. Doch nicht die als Zielgruppe ins Auge gefaßten Basic- Programmierer begeisterten sich für diese neue Art des Programmierens das Interesse kam primär von jenen Kunden, die bisher noch nie programmiert hatten und durch die intuitiven Konzepte von LabVIEW die Hoffnung genährt sahen, auch im eigenen Haus anspruchsvolle Applikationen entwickeln zu können. Inzwischen läuft LabVIEW auf mehreren Plattformen und verfügt über eine reichhaltige Funktionsbibliothek für einen breiten Einsatzbereich. Santori [90] schildert in einem lesenswerten Artikel, die visionären Ideen des LabVIEW-Erfinders Kodosky und ihre zielstrebige Umsetzung. Die Softwareindustrie erwartet sich hohe Umsätze mit visuellen Programmierumgebungen. Snell [95 S. 8] erwähnt eine Studie, die Produkten zur visuellen Programmierung für Ende 1999 einen Marktanteil von 3,8 Milliarden US-Dollar voraussagt. Die höchsten Chancen werden Werkzeugen eingeräumt, die zur Entwicklung von Client-Server- Applikationen geeignet sind. 30 % aller Unternehmen, die solche Werkzeuge verwenden, setzen laut dieser Studie bereits heute Visual Basic ein. Eine wichtige Rolle wird visueller Programmierung auch bei Integration von Datenbankwerkzeugen in Softwareentwicklungsumgebungen zugesprochen. Das Zusammenrücken von Datenbankanbietern und Herstellern von Softwarewerkzeugen, um gemeinsam visuelle Umgebungen zu entwickeln, ist ein deutliches Signal in diese Richtung. Doch es gibt auch skeptische Stimmen. Snell zitiert den Unternehmensberater Jay Prakash, der Bedenken bezüglich der Skalierbarkeit visueller Ansätze äußert [S. 9; OZ 3]: Wenn man ein kleines Programm baut und dieses soweit erweitern möchte, daß es in einer Abteilung oder im ganzen Unternehmen eingesetzt werden kann wie macht man das? Wirft man es weg und fängt mit der Entwicklung ganz von vorne an?

17 1.2 Aktuelle Situation 7 Hugh Bishop, ein Analytiker der Boston-Aberdeen-Gruppe bringt ähnliche Einwände vor. Er meint, daß visuelle Programmierung zwar einen Geschmack auf»zeigen-und- Klicken-Programmierung«macht, für praxistaugliche Applikationen aber nach wie vor Code geschrieben werden muß. 1.2 Aktuelle Situation In der Einleitung zum Buch»Visual Programming«aus dem Jahre 1988 spricht Shu [88 S. v; OZ 4] die auch heute noch existierende Ambivalenz an, die bezüglich der hohen Erwartungen in die visuelle Programmierung einerseits und der Unsicherheit über ihre Bedeutung und Bewertung andererseits besteht: Die Herausforderung dieser Dekade besteht darin, die Möglichkeiten des Computers auf einfache und nützliche Art jenen Menschen zugänglich zu machen, die über keine spezielle Programmierausbildung verfügen. Visuelle Programmierung ist ein konzeptionell revolutionärer Ansatz, um diese Herausforderung zu bewältigen. [...] Doch obwohl Arbeiten zu visueller Programmierung wie Pilze aus dem Boden schießen, gibt es keine Übereinstimmung darüber, was visuelle Programmierung ist, ganz zu schweigen davon, wie sie zu bewerten ist. Seit damals hat man zwar zusätzliche Erkenntnisse gewonnen; einen Konsens darüber, was den Kern der visuellen Programmierung ausmacht und wie die grundlegenden Begriffe genau zu verstehen sind, gibt es jedoch noch immer nicht. Im Gegenteil, man kann sich des Eindrucks nicht erwehren, daß eine Flut von Publikationen das Thema verwässert. Weil Bilder in der Mensch-Maschine-Kommunikation eine zentrale Rolle spielen und grafische Darstellungen in der Softwaretechnik (wie auch in jeder anderen Ingenieursdisziplin) unverzichtbar sind, kann fast alles, was mit Grafik und Computer zu tun hat, unter dem Gesichtspunkt von visuellen Sprachen bzw. visueller Programmierung betrachtet werden. Die Folge ist eine beinahe unüberschaubare Anzahl von Veröffentlichungen. Ein repräsentativer Querschnitt durch die wichtigsten Bücher, Fachzeitschriften, Sammelwerke und Tagungsbände ergibt folgende Themenliste: Visuelle Sprachen: 2D-Syntax, Piktogramme, Theorie visueller Sprachen, visuelle Sprachen für behinderte Personen. Visuelle Programmierung: constraintbasierte Systeme, deklarative Sprachen, funktionale Sprachen, formale Spezifikationsmethoden, Programmierung durch Beispiele, Software Engineering, Systementwurf, visuelle Programmiersysteme. Softwarevisualisierung: Animation, Programm- und Datenvisualisierung, Simulation. Mensch-Maschine-Kommunikation: Diagrammgestaltung, Entwurfsstrategien für Schnittstellen, grafische Benutzungsschnittstellen, interaktives Lernen, kognitive Aspekte, Multimedia, virtuelle Realität. Anwendungsgebiete: Bilddatenbanken, Bildverarbeitung, geographische Informationssysteme, kartographische Schnittstellen, parallele und verteilte Systeme, visuelle Abfragesysteme, visuelle Systeme für das Büro, visuelle Umgebungen für neue Technologien, wissenschaftliche Anwendungen. Trotz der Vielzahl von Publikationen sind entscheidende Fragen noch immer nicht beantwortet. Neben der Antwort auf die generelle Frage»Was ist visuelle Programmierung?«ist nach wie vor offen, welchen Stellenwert visuelle Programmierung in der Praxis hat und welche Kriterien zur Bewertung von visuellen Programmierumgebungen heranzuziehen sind. Zwar mangelt es nicht an euphorischen Aussagen, harte Fakten fin-

18 Einleitung 8 det man jedoch kaum. Dies liegt vor allem daran, daß viele Forscher nur einen kleinen Ausschnitt eines Anwendungsbereichs ins Auge fassen und die entwickelten Systeme meist in den Kinderschuhen steckenbleiben. Etliche Publikationen weisen keine Praxisrelevanz auf und dürfen mit gutem Gewissen als belanglos bezeichnet werden (siehe z.b. Bild 1-4). Auch dieses Buch kann nur manche der offenen Punkte beantworten. In den folgenden Abschnitten wird zunächst versucht, exakte Begriffsbestimmungen zu finden. Danach folgt eine eingehende Diskussion der Stärken und Schwächen bildlicher Darstellungen aus der Sichtweise der Softwaretechnik. Auf diese Weise soll ein sachliches Umfeld zur Einschätzung von Möglichkeiten und Grenzen der visuellen Programmierung geschaffen werden. Meßbare Kenngrößen zur Evaluation von visuellen Programmiersystemen werden jedoch nicht angeführt. Ein für Qualitäts- und Produktivitätsmessungen geeigneter Kriterienkatalog müßte neben technischen Merkmalen auch kognitionspsychologische Aspekte umfassen, um glaubwürdige Aussagen über die Tauglichkeit visueller Softwareentwicklungsumgebungen zu ermöglichen. Die dazu notwendigen Untersuchungen hätten den Rahmen dieses Buchs gesprengt. Bild 1-4. Die Fakultätsfunktion in CUBE. Najork und Kaplan [92 S. 271, Abb. 2 und Abb. 3]

19 2. Terminologie Begriffe und Worte, die Eingang in die Alltags- oder eine Fachsprache gefunden haben, werden mit einiger Verzögerung auch in Lexika und Enzyklopädien erfaßt. Die Terminologie der visuellen Programmierung ist in den allgemein akzeptierten Wortschatz der Informatik noch nicht aufgenommen. Beispielsweise hat die Ausgabe 1993 der IEEE Encyclopedia of Computer Science zwar einen Eintrag für Visual Basic aber nicht für visuelle Programmierung (vgl. ECS [93]). In der Encyclopedia of Software Engineering kommt visuelle Programmierung immerhin vor, jedoch nicht als eigenständiger Fachbegriff, sondern bloß als Verweis auf den Terminus»Programmvisualisierung«, der eine ganz andere Bedeutung hat (vgl. ESE [94]). Wegen der noch nicht stabilen Begriffe, ist eine Erhebung und Analyse der in der Fachliteratur publizierten Terminologie besonders wichtig. Dieses Kapitel versucht den teilweise mißverständlichen Definitionen ein klares und zweckmäßiges begriffliches Instrumentarium entgegenzusetzen. Der Abschnitt 2.1»Analyse der Begriffe«beginnt mit der Diskussion des nur scheinbar leichtverständlichen Begriffs»visuell«und untersucht darauf aufbauend, die weiteren Fachbegriffe der visuellen Programmierung systematisch auf ihren Bedeutungsgehalt. Der Abschnitt 2.2»Synthese der Begriffe«faßt die bei der Analyse gewonnenen Erkenntnisse in knappen Definitionen zusammen. 2.1 Analyse der Begriffe Dieser Abschnitt analysiert Umschreibungen und Definitionen aus der Literatur zu den zentralen Begriffen der visuellen Programmierung und erläutert diese anhand von Beispielen. Die dem eiligen Leser vielleicht übertrieben erscheinende Auseinandersetzung folgt aus der Überzeugung, daß nur eine möglichst genaue Terminologie klarmacht, was man in einen Topf werfen darf und was nicht. Ohne ausreichende Differenzierung besteht die Gefahr, daß sich Unterschiedliches auf denselben Begriff reduziert und nur nichtssagende Tautologien übrigbleiben Der Begriff»Visuell«Die Softwareindustrie hat erkannt, daß visuelle Programmierung ein zugkräftiges Schlagwort ist, und bietet Programmierwerkzeuge immer häufiger mit dem Zusatz»visuell«an. Die Durchdringung solcher Werkzeuge mit visuellen Konzepten ist allerdings unterschiedlich stark. Typische Beispiele für das breite Produktspektrum sind VisualWorks von ParcPlace und LabVIEW von National Instruments. VisualWorks ist eine objektorientierte Entwicklungsumgebung mit einem grafischen Editor zur Gestaltung der Benutzungsschnittstelle. Die Programmlogik wird mit Smalltalk erstellt (siehe Bild 2-1). Mit LabVIEW erstellt man sowohl die Benutzungsschnittstelle als auch die Programmlogik mit grafischen Bausteinen. Text spielt nur eine geringe Rolle und wird vor allem für Beschriftungen, Kommentare sowie Zahlen- und Zeichenkonstanten verwendet (siehe Bild 2-2).

20 Terminologie 10 Klassifiziert man visuelle Programmiersysteme (VP-Systeme) anhand des Kriteriums»Art der Programmiersprache«, so ergeben sich zwei Gruppen kommerziell verfügbarer Systeme (exemplarische Auswahl, in Klammern die Hersteller): VP-Systeme mit visueller (grafischer) Programmiersprache: AppBuilder (Novell) AVS (Advanced Visual Systems) BetterState (R-Active Concepts) LabVIEW (National Instruments) PARTS (Digitalk) Prograph (Pictorius Inc.) VisualAge (IBM) VEE (HP). Bei diesen Systemen enthält der Programmcode einen hohen Anteil grafischer Elemente und nur wenig Text. VP-Systeme mit verbaler (textueller) Programmiersprache: Delphi (Borland) Notes ViP (Lotus) PowerBuilder (Powersoft) VisualWorks (ParcPlace) Visual Basic und Visual C++ (Microsoft). Bei diesen Systemen wird die Programmlogik textuell programmiert. Grafische Elemente kommen primär beim Bau der Benutzungsschnittstelle zum Einsatz. In der Fachliteratur wird diese Trennung kaum vorgenommen, obwohl gerade daran der Unterschied zwischen dem umgangssprachlichen Gebrauch des Begriffs»Visuelle Programmierung«und wissenschaftlichen Interpretationen sichtbar wird. Visual Basic und Visual C++ sind vermutlich für die meisten Laien, aber auch für viele Experten aus der Softwarebranche typische Vertreter visueller Programmierwerkzeuge. Hingegen würde vermutlich die Mehrheit der mit visueller Programmierung befaßten Wissenschaftler diese Systeme nicht als repräsentativ beurteilen, weil sie keine visuelle Programmiersprache unterstützen.

21 2.1 Analyse der Begriffe 11 Editor für die Benutzungsschnittstelle Editor für die Programmlogik Bild 2-1. Das VP-System VisualWorks (Ausschnitt).

22 Terminologie 12 Editor für die Benutzungsschnittstelle Editor für die Programmlogik Bild 2-2. Das VP-System LabVIEW (Ausschnitt); Farbbild im Anhang.

23 2.1 Analyse der Begriffe 13 Bevor auf die Begriffe»visuelle Programmierung«und»visuelle Programmiersprachen«eingegangen wird, ist eine nähere Betrachtung des Begriffs»visuell«angebracht. Der Begriff»visuell«bedeutet im allgemeinen»das Sehen oder den Gesichtssinn betreffend«und bezeichnet somit eine bestimmte Wahrnehmungsart. Er bezieht sich demnach nicht nur auf grafische Elemente, sondern auch auf Text, der ebenso sichtbar ist, wie etwa ein Piktogramm. Ein gutes Beispiel dafür ist das in Bild 2-3 dargestellte visuelle Gedicht»Schweigen«von Eugen Gomringer. schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen schweigen Bild 2-3. Visuelle Dichtung: Eugen Gomringer»Schweigen«, Vgl. Brockhaus [94-23 S. 382] Weil unbestreitbar ist, daß die visuelle Wahrnehmung eine zentrale Rolle bei der Programmierung spielt, stellt sich die Frage, ob eine Unterscheidung zwischen visueller und nicht-visueller Programmierung überhaupt möglich ist. In einem ersten Versuch, die Bedeutung von»visuell«nicht unnötig einzuschränken und dennoch den Unterschied zu nicht-visueller Programmierung zu finden, könnte man eine ausgrenzende Definition vorschlagen: Visuelle Programmierung ist jene Art der Programmierung, für die das visuelle Wahrnehmungssystem des Menschen unentbehrlich ist. Diese Begriffsbestimmung mag auf den ersten Blick wenig gehaltvoll erscheinen, ist aber als Ausgangspunkt weiterer Überlegungen gut geeignet. Sie vermeidet den synonymen Gebrauch von grafisch und visuell, schließt Text nicht aus und erwähnt das visuelle Wahrnehmungssystem als unverzichtbares Instrumentarium. Als Beleg für die Sinnhaftigkeit dieser Definition, stelle man sich eine fiktive visuelle Programmiersprache vor, die Schlüsselwörter in Fettschrift darstellt. Außerdem sei Fettschrift das einzige Merkmal, durch das sich Schlüsselwörter von allgemeinen Bezeichnern unterscheiden. Anders gesagt, ist in dieser Sprache der Wortlaut von Schlüsselwörtern nicht reserviert, und deshalb können Variable, Prozeduren, Typen usw. genauso heißen wie Schlüsselwörter (Pascal verbietet gleiche Namen für Schlüsselwörter und Bezeichner, Fortran 77 erlaubt das). In einer solchen Sprache wäre folgende Anweisung gültig: if while then do else end. Diese bedingte Verzweigung wertet den booleschen Ausdruck while aus, ruft im Then- Zweig die Prozedur do auf und im Else-Zweig die Prozedur end. Eine alternative Betonung der Wörter mit Fettschrift ergibt eine syntaktisch ebenso korrekte Anweisung, jedoch mit einer völlig anderen Semantik: if while then do else end.

24 Terminologie 14 Dieses Konstrukt ruft zunächst die Prozedur if auf. Danach wertet die While-Schleife den booleschen Ausdruck then aus und ruft die Prozedur else so lange auf, bis then den Wert false ergibt. Eine Person, der dieser Programmtext vorgelesen wird, oder eine blinde Person, die sich der Braille-Schrift bedient, erkennt ohne weitere Hinweise nur die Zeile if while then do else end. und kann daraus weder Syntax noch Semantik ableiten, weil die Anweisungsfolge ohne visuelle Attribute mehrdeutig ist. Der Leser mag einwenden, daß geeignete Mechanismen auch in diesem Fall vermitteln könnten, welche Worte fettgedruckt sind und welche nicht. Das stimmt zwar, trifft aber nicht den Kern der Sache, denn visuelle Information ist immer in andere Repräsentationen transformierbar. Wäre das nicht der Fall, könnte auch der Computer den zuvor angeführten Ausdruck nicht interpretieren, denn im Speicher muß die Fettschrift jedenfalls in Form von Bits dargestellt werden. Um mögliche Transformationen visueller Information geht es aber nicht. Es geht darum, wie die ursprüngliche Information verarbeitet wird. Dazu ist bei visueller Programmierung das visuelle Wahrnehmungssystem des Menschen nötig. Das Beispiel zeigt, daß man die Frage, was visuelle Programmierung heißt, nur dann beantworten kann, wenn man festlegt, welcher Einfluß visuell informativen Elementen im Programmierprozeß zukommt. Dazu gehören beispielsweise Grafische Komponenten: Diagramme, Piktogramme, Farben usw. Geometrische Attribute: Form, Größe, Seitenverhältnisse usw. Topologische Eigenschaften: Verbindungen, Überlagerungen, Berührungen usw. Typographische Merkmale: Seitengestaltung, Schriftart, Einrückungen usw. Aus den zuvor angeführten Überlegungen läßt sich ableiten, daß es nur dann gerechtfertigt ist, von visueller Programmierung zu sprechen, wenn beim Programmieren visuell informative Elemente eine unverzichtbare Rolle spielen. Die Programmierung auf Basis von Zeichenketten ohne visuellen Bedeutungsgehalt, wird durch den Begriff verbale Programmierung erfaßt. Bemerkenswert ist, daß dieser Begriff in der Literatur nicht vorkommt und man vergeblich nach einer einheitlichen Bezeichnung für nicht-visuelle Programmierung sucht. Übliche Umschreibungen sind Begriffe wie eindimensionale, lineare, traditionelle, herkömmliche und textuelle Programmierung, wobei sich diese Adjektive meist auf die zugrundeliegende Programmiersprache beziehen (vgl. Shu [86 S. 12], Ambler und Burnett [89 S. 22], Poswig [93 S. 8], und Myers [94 S. 877]). Insbesonders der Terminus»textuelle Programmierung«wird gerne verwendet, um visuelle und nicht-visuelle Programmierung abzugrenzen. Der Begriff»verbale Programmierung«ist umfassender als die genannten Umschreibungen und deckt sich auch mit der Begriffswelt der Kognitionspsychologie, die zwischen der Verarbeitung verbaler und visueller Informationen durch den Menschen unterscheidet (vgl. Anderson [89 S. 104 ff]). In weiterer Folge wird unter visuell immer visuell informativ im obigen Sinn verstanden. Wenn beispielsweise von einer visuellen Sprache die Rede ist, dann ist damit eine Sprache gemeint, in der Kommunikation unabdingbar damit verbunden ist, daß man Sätze dieser Sprache sieht.

25 2.1 Analyse der Begriffe Der Begriff»Visuelle Sprache«Man könnte meinen, der Begriff»visuelle Sprache«sei ein Widerspruch in sich, weil Sprache immer verbal zum Ausdruck käme. Dem ist nicht so. Der Duden [92 S. 656] definiert Sprache als [...] ein System von Zeichen, das der Gewinnung von Gedanken, ihrem Austausch zwischen verschiedenen Menschen sowie der Fixierung von erworbenem Wissen dient. Sprache kann als akustisches, soziales oder psychisches Phänomen oder auch als System logischer Operationen aufgefaßt werden. Die Beziehung zwischen Zeichen und Bezeichnetem hängt von der jeweiligen Sprachgemeinschaft ab, die einem bestimmten Ausschnitt aus der Wirklichkeit ein bestimmtes Zeichen konventional zuordnet. Die Definition des Dudens umfaßt ein weites Spektrum von Ausdrucksmitteln und schließt sowohl natürliche als auch künstliche Sprachen ein. Die Aussage, daß Sprache nicht nur der unmittelbaren Verständigung, sondern auch der Fixierung von Wissen dient, weist auf unterschiedliche Erscheinungsformen hin. Sprache existiert in zwei Ausprägungen: auf Basis dynamischer Zeichengebung und auf Basis statischer Zeichengebung. Die dynamische Zeichengebung wird durch flüchtige Vorgänge bewirkt, z.b. durch Signale einer Ampelanlage; Senden und Empfangen der Nachrichten geschehen quasi gleichzeitig. Die statische Zeichengebung ist von Raum und Zeit unabhängig und wird durch die Fixierung von Zeichen in Materie erreicht, z.b. durch Symbole auf Verkehrstafeln; Senden und Empfangen der Nachrichten können zeitlich getrennt sein (vgl. Seiffert [91 S. 105 ff]). Der Hinweis auf die unterschiedlichen Existenzformen von Sprache ist aus zwei Gründen wichtig: 1. In den meisten formalen Systemen liegt Sprache nur in geschriebener (statischer) Form vor. Bei der schriftlichen Wiedergabe fallen die Korrekturmöglichkeiten der mündlichen Verständigung weg. Wenn der Leser etwas nicht begreift, dann kann er den Schreiber nicht fragen, was damit gemeint ist. Weil formale Notationen meist abstrakte Sachverhalte vermitteln, sind Eindeutigkeit und Verständlichkeit besonders wichtig. Leider sind diese Faktoren bei visuellen Sprachen oft nicht gegeben, da Bilder meist einen großen Interpretationsspielraum aufweisen. 2. In beispielorientieren Systemen (siehe Abschnitt 5.7, S. 124) hat der Programmierer oft nur die interaktive (dynamische) Form von Sprache zur Verfügung, um Anweisungen an das System auszudrücken. Solche Systeme leiten Algorithmen aus Beispielen ab, die der Programmierer vorzeigt. Die Aktionen des Programmierers werden aufgezeichnet und sofort in eine interne Darstellung überführt. Der Hinweis des Dudens auf den konventionalen Charakter von Sprache bezieht sich darauf, daß einzelne Zeichen oder Zeichengruppen der Realität willkürlich zugeordnet sind. Die Bedeutung von Sprachelementen ergibt sich also in der Regel nicht durch deren Erscheinungsbild, sondern durch Übereinkunft. Dadurch ist Sprache außerordentlich wandelbar. Diese Flexibilität von sprachlichen Ausdrücken hat weitreichende Konsequenzen für die visuelle Programmierung. Um visuelle Programme verständlich zu machen, müssen die Entwickler einer visuellen Programmiersprache ein ausgewogenes Verhältnis zwischen Grafik und Text finden. Den gesamten Begriffsraum der Softwareentwicklung in visuelle Symbole mit bekannter Bedeutung abzubilden ist unmöglich, denn der zu betrachtende Begriffsraum umfaßt nicht nur die Konstrukte der Program-

26 Terminologie 16 miersprache, sondern auch die Bezeichnung von Objekten, Funktionen, Typen usw. Bei verbaler Programmierung ist die Suche nach aussagekräftigen Bezeichnungen viel einfacher als bei visueller Programmierung, da der reiche Wortschatz der Umgangs- und Fachsprache zur Verfügung steht. Neue und dennoch verständliche Bezeichnungen findet man leicht durch Kombination und Abwandlung bekannter Worte. Für visuelle Symbole gilt dies nicht im gleichen Ausmaß. Die Anwendung von Sprache wird in der Definition des Dudens auf die Kommunikation zwischen Menschen beschränkt, und als Zweck steht der Gedankenaustausch im Vordergrund. Solche Einschränkungen sind unzweckmäßig, wenn mit dem Begriff»Sprache«auch die Interaktion zwischen Mensch und Computer erfaßt werden soll. Eine knappere und allgemeinere Begriffsbestimmung findet sich bei Brockhaus [94-20 S. 696]: [Sprache ist] im weitesten Sinne von Semiotik und Informationstheorie ein konventionelles System von Zeichen zu Kommunikationszwecken. Die in der Definition erwähnte Semiotik ist die Lehre von der Entstehung, dem Aufbau und der Wirkungsweise von Sprachen (Zeichen und Zeichensystemen). Sie betrachtet Sprachen unter drei Gesichtspunkten (vgl. Meyers-Philosophie [87 S. 376]): Syntax: die Verknüpfung von Zeichen, d.h. die Beziehung der Zeichen untereinander. Semantik: die Bedeutung von Zeichen, d.h. die Beziehung der Zeichen zu den bezeichneten Dingen. Pragmatik: die Wirkung von Zeichen, d.h. Beziehung der Zeichen zu den betroffenen Personen. In der Informatik und verwandten Fachgebieten, wie der Logik und Computerlinguistik, sind vor allem formale Sprachen von Bedeutung. Formale Sprachen kann man als mathematische Annäherungen an natürliche Sprachen sehen. Sie werden mit formalen Mitteln definiert, wobei primär Syntax und Semantik relevant ist, weil die Bedeutung der Zeichen mit der Wirkung gleichgesetzt werden kann (in der theoretischen Informatik umfaßt der Begriff der formalen Sprache nur die Syntax). So sind etwa Ausdrücke in Programmiersprachen eindeutige Befehle an den Computer, der bei ihrer Auslegung keinen Interpretationsspielraum hat. In der Mensch-Maschine-Kommunikation spielen pragmatische Aspekte sehr wohl eine Rolle, weil die vom Computer generierten Zeichen oftmals zu einer bestimmten Handlung auffordern und die semantische Analyse alleine für Kommunikationszwecke nicht ausreicht. In diesem Zusammenhang haben sich Sengupta et al. [94 S. 133 f] Gedanken über das»pragmatische Zoomen«in visuelle Sprachen gemacht, ein Begriff, mit dem sie jene Operationen bezeichnen, die Details über die Nutzung von grafischen Elementen freilegen oder verbergen. Chang [90 S. 2; OZ 5] weist darauf hin, daß der Begriff»visuelle Sprache«sehr unterschiedlich verstanden wird: Der Begriff visuelle Sprache hat für verschiedene Personen unterschiedliche Bedeutung. Einige verstehen darunter, daß die Sprache visuelle Objekte erfaßt. Andere verstehen darunter, daß die Sprache selbst visuell ist. Für die erste Gruppe heißt»visuelle Sprache«eine Sprache für die Verarbeitung von visueller Information. Für die zweite Gruppe heißt»visuelle Sprache«eine Sprache für die Programmierung mit visuellen Ausdrücken bzw. eine visuelle Programmiersprache. Die Gruppe von Sprachen für die Verarbeitung visueller Information umfaßt laut Chang vor allem verbale Programmiersprachen, die um spezielle Sprachkonstrukte oder Bib-

27 2.1 Analyse der Begriffe 17 liotheksroutinen zur effizienten Handhabung von visuellen Objekten erweitert wurden. Shu [88 S. 136; OZ 6] unterstützt diese Ansicht. Sie bildet drei Kategorien von visuellen Sprachen, von denen die erste ebenfalls Sprachen zur Verarbeitung visueller Informationen enthält: 1. Sprachen für die Verarbeitung von visueller Information, 2. Sprachen zur Unterstützung visueller Interaktion, und 3. Sprachen für die Programmierung mit visuellen Ausdrücken, das sind visuelle Programmiersprachen. Auch Shu weist darauf hin, daß Sprachen der ersten Kategorie auf verbaler Syntax beruhen. Nach den Regeln des allgemeinen Sprachgebrauchs sind solche Sprachen demzufolge textuelle Sprachen. Die Bezeichnung»visuelle Sprache«ist in diesem Zusammenhang irreführend, denn unabhängig davon, wozu eine visuelle Sprache dient, darf sie nur dann als visuell bezeichnet werden, wenn sie selbst visuelle Sprachelemente enthält. Eine andere Sicht der Dinge wäre sinnwidrig, da sonst jede Sprache eine visuelle Sprache wäre, sofern mit ihr ausgedrückt werden kann, wie visuelle Informationen zu handhaben sind. Somit wäre jede universelle Programmiersprache eine visuelle Sprache. Die begriffliche Einordnung von Sprachen zur Unterstützung visueller Interaktion als visuelle Sprachen (Shus zweite Kategorie) ist aus demselben Grund unangebracht. Shu versteht darunter textuelle Sprachen, mit denen etwa Bildschirmfenster für Benutzerdialoge beschrieben werden. Es kommen somit nur jene Sprachen als visuelle Sprachen in Betracht, deren Syntax auf visuellen Ausdrücken beruht. Eine knappe Definition von visueller Sprache gibt Lakin [86 S. 45; OZ 7]: Eine visuelle Sprache ist eine Menge von räumlichen Anordnungen aus Text/Grafik-Symbolen mit einer semantischen Interpretation, die verwendet wird, um kommunikative Aktionen in der Welt auszuführen. Die Begriffsbestimmung von Larkin vermeidet die unpassenden Kategorien der Definitionen von Chang und Shu und beschränkt sich auf die Feststellung, daß sich visuelle Sprachen von verbalen Sprachen nur durch die mehrdimensionale Anordnung von Text und Grafik unterscheiden. Dynamische Aspekte klammert Larkin mit dieser einfachen Definition allerdings aus. Selker und Koved [88] sprechen hingegen auch temporäre und interaktive Sprachelemente an, wie Veränderungen von Form und Farbe, Blinken, Selektionen und Gestik. Dynamische Elemente spielen in visuellen Programmierumgebungen eine wichtige Rolle. Die Notation eines visuellen Programms kommt jedoch im allgemeinen ohne diese Elemente aus. Eine Ausnahme sind beispielorientierte Systeme, bei denen der Benutzer dem System vorzeigt, welche Aktionen ein Programm ausführen soll. Wie schon zuvor angesprochen, besteht die»sprache des Vorzeigens«fast ausschließlich aus dynamischen Elementen und existiert meist nicht in statischer Form. Exkurs zur Entwicklung der Schrift Die Fähigkeit, gesprochene Sprache in schriftliche Form zu fassen, ist unerläßliche Voraussetzung für die Entwicklung hochstehender Zivilisationen. Erst durch die Kunst des Schreibens und Lesens kann Wissen gespeichert und ohne wesentlichen Informationsverlust auch über Generationen hinweg weitergegeben werden. Umso überraschender ist die Tatsache, daß laut Gutknecht [95 S. 81] nur 13 % der 5103 lebenden Sprachen auch die Schrift kennen.

28 Terminologie 18 In den meisten Sprachen mit Schrift werden Buchstaben als Grundbausteine verwendet. Grafische Schriftzeichen in Form von Bildern, Piktogrammen usw. sind nur zur Übermittlung von Informationen in eng begrenzten Bereichen üblich, etwa als Verkehrszeichen, Hinweisschilder und Markenzeichen. Eine Ausnahme bilden Sprachen, die auf Ideogrammen beruhen, wie Chinesisch, Japanisch und Koreanisch. Trotz der außerhalb Asiens geringen Verbreitung visueller Sprachen, weisen Verfechter der visuellen Programmierung immer wieder auf ihre Natürlichkeit und leichte Verständlichkeit hin. Stimmt diese Behauptung oder sind visuelle Sprachen nicht vielmehr ein evolutionärer Rückschritt? Bei Kapolka [90] findet man eine interessante Studie über die visuellen Zahlensysteme der Ägypter und Mayas. Der Autor kommt keineswegs überraschend zum Schluß, daß diese visuellen Systeme unserer heutigen Dezimalschreibweise unterlegen sind, weil sie erstens gewisse mathematische Operationen verhindern und zweitens komplizierter und unverständlicher sind als unser Zahlensystem [S. 67]. Die oft schwierige Interpretation und umständliche Manipulation grafischer Ausdrücke zeigt sich jedoch nicht nur in der Arithmetik, sondern auch in anderen Bereichen. Ein kurzer Abriß der Geschichte der Schrift soll das verdeutlichen. Kapolka sieht den Beginn des Schreibens zu jener Zeit, als der Mensch begann, Szenen aus dem Alltag in Bilder zu fassen, wobei jedes Bild einen bestimmten Gegenstand oder Sachverhalt repräsentierte [S. 45]. Diese Art des Schreibens war auf konkrete Dinge beschränkt und für die Notation abstrakter Konzepte ungeeignet. In weiterer Folge entwickelten sich die Begriffsschriften, in denen Abstraktionen mit Hilfe von Metaphern erfaßt und einzelnen Zeichen zugeordnet werden. Begriffsschriften haben den Vorteil, daß sie durch die dichte Darstellung von einem Zeichen pro Wort sehr schnell gelesen werden können, weil das Auge mehrere Zeichen und damit Worte gleichzeitig erfassen kann (vgl. Duden [84 S. 65 f]. Zudem sind Begriffsschriften nicht von der Lautgestaltung abhängig, wodurch sie in Staaten, die viele verschiedene gesprochene Dialekte umfassen, eine Kommunikationsnorm auf schriftlicher Basis bilden. So weist etwa Gernet [88 S. 37] darauf hin, daß in China die phonetischen Veränderungen des Gesprochenen, die Varianten der Dialekte und sogar der Wandel der sprachlichen Struktur keinen Einfluß auf die Schrift hatten, die bereits Ende des dritten Jahrhunderts vor Christus vereinheitlicht wurde. Obwohl es bis heute in China keine allgemeingültigen Ausspracheregeln gibt, ist eine schriftliche Verständigung jederzeit möglich. Begriffsschriften haben aber auch zwei schwerwiegende Nachteile: (1) sie setzen eine allgemeine Übereinkunft über die Bedeutung der Metaphern voraus; (2) man muß sich einen großen Zeichenvorrat für den Grundwortschatz merken, aus dem sich alle anderen Worte durch Kombination und Ableitung ergeben (im Deutschen wären dafür ca Zeichen notwendig). Wegen dieser Nachteile entstanden schließlich die heute in den meisten Sprachen üblichen Buchstabenschriften, in denen ein Regelwerk die Laute der gesprochenen Sprache auf Buchstaben abbildet. Dabei spielen abstrakte Grundformen der Laute in Form von Phonemen und abstrakte Notationen der Buchstaben in Form von Graphemen eine wichtige Rolle. Die Vorteile der Buchstabenschrift faßt der Duden [84 S. 66] wie folgt zusammen: Buchstabenschriften vereinigen die Vorteile der Laut- und Begriffsschrift in sich und schließen deren Nachteile aus. Es gibt nur ein begrenztes Inventar von Zeichen. Die Phonem-Graphem-Beziehung erlaubt es, beim leisen Lesen die variantenreichere lautliche Ebene unberücksichtigt zu lassen, und schafft konstante(re) Wortbilder, die der Leser unmittelbar auf die Bedeutung beziehen kann. Anders als in der Begriffsschrift braucht er sich diese Wortbilder aber nicht alle zu mer-