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-

29 2.1 Analyse der Begriffe 19 ken, da er sie auf Grund der Phonem-Graphem-Beziehung jederzeit als Buchstabenfolge entschlüsseln kann. In visuellen Sprachen, die auf Piktogrammen und Grafiken beruhen, werden diese Vorteile aufgegeben und zu den Nachteilen der alten Begriffsschriften zurückgekehrt. (Unter Piktogramm ist eine abstrakte bildliche Darstellung zu verstehen, die eine Klasse von Gegenständen oder Sachverhalten repräsentiert; vgl. Staufer [87 S. 5]). Man mag einwenden, daß formale Sprachen, wie sie für die Programmierung verwendet werden, bloß eingegrenzte Problemkreise erfassen und deshalb das Vokabular eingeschränkt ist, wodurch manche Nachteile nicht zum Tragen kommen. Das mag in manchen Fällen gelten, doch wie Beispiele in diesem Buch belegen, kann auch in engen Anwendungsbereichen ein Bild selten einen gut gewählten Namen an Ausdruckskraft überbieten. Für allgemeine Problemstellungen ist keinesfalls zu erwarten, daß ein System visueller Zeichen die Bedeutung beliebiger Objekte ebenso leicht verständlich vermitteln kann wie verbale Sprachen. Verschärft wird das Problem dadurch, daß in den meisten visuellen Sprachen die Symbole nicht linear angeordnet, sondern im zweidimensionalen Raum beliebig verteilt sind. Dadurch gibt es keine vorgegebene Leserichtung, was die Interpretation außerordentlich erschwert. Die Abkehr von verbalen Sprachen birgt die Gefahr in sich, auf eine Ebene zurückzufallen, auf der nicht alles notierbar ist, was mit Worten ausdrückbar ist. Leider ignorieren viele Proponenten der visuellen Programmierung diesen und andere Einwände. Man sollte deshalb überschwenglichen Behauptungen über die Vorteile visueller Sprachen kritisch gegenüberstehen. Exkurs zur Syntax visueller Sprachen Ein interessanter Punkt im Zusammenhang mit visuellen Sprachen ist die Frage nach ihrer syntaktischen Struktur. In informellen visuellen Sprachen, die z.b. für Handskizzen Verwendung finden, stehen syntaktische Aspekte im Hintergrund, da ein strenger Zusammenhang zwischen den einzelnen Sprachzeichen oft nicht gegeben bzw. offensichtlich ist. Es bedarf deshalb keines explizit beschriebenen Regelwerks (einer Grammatik), das festlegt, wie gültige Sätze aus den einzelnen Zeichen zu bilden sind. In formalen visuellen Sprachen hingegen insbesondere in visuellen Programmiersprachen muß es für die Syntax sehr wohl klare Regeln geben, da sonst eine eindeutige Interpretation unmöglich ist. Umso verwunderlicher mag es erscheinen, daß trotz zahlreicher Arbeiten zu Grammatiken für visuelle Sprachen bis heute keine normierte Beschreibungsform existiert, wie das in textuellen Programmiersprachen längst üblich ist. (Mit Grammatiken und Compilern zu visuellen Sprachen beschäftigen sich u.a. Chang et al. [89], Golin und Reiss [90], Costagliola et al. [91], Meyer [92], Wittenburg [92], Golin und Magliery [93], Marriot [94] sowie Rekers und Schürr [95]). Wie ist es möglich, daß trotz fehlender Grammatiken so viele visuelle Programmiersprachen existieren? Die Antwort ist leicht zu finden, wenn man sich die Funktionsweise von VP-Systemen ansieht. In den meisten VP-Systemen erstellt man Programme grundsätzlich anders als in herkömmlichen Programmierumgebungen. Man verwendet keinen separaten Editor und Compiler, um das Programm zuerst zu notieren und dann zu übersetzen, sondern man wählt die Programmelemente interaktiv aus. Das VP- System überführt sodann jedes vom Programmierer gewählte Element in eine interne Repräsentation und stellt sicher, daß nur syntaktisch gültige Kombinationen entstehen. Die Regeln für gültige Kombinationen sind in das System eingebaut und nicht explizit

30 Terminologie 20 in Form einer Grammatik beschrieben. Nur in ganz wenigen Systemen gibt es Compiler, die visuellen Programmcode als Ganzes verarbeiten, d.h. die einzelnen Elemente wie Kästen, Anschlußpunkte und Linien anhand einer Grammatik analysieren und daraus eine andere Repräsentation oder ein ausführbares Programm erzeugen. Doch selbst in diesen Systemen werden die Programme zunächst mit einem integrierten Editor erstellt, der eine interne Repräsentation erzeugt, die der Compiler später verarbeitet. Eine Ausnahme bildet möglicherweise ein Compiler von Kahn und Saraswat [90], der in der Lage sein soll, ein visuelles Programm zu übersetzen, das in einem standardisierten Grafikformat (Postscript) vorliegt. Ob die angekündigten aber nicht näher beschriebenen Arbeiten positiv abgeschlossen wurden, ist dem Verfasser nicht bekannt. Erfolgreiche Forschung auf dem Gebiet des Übersetzerbaus für visuelle 2D-Sprachen wird u.a. an den Universitäten Salerno, L Aquila und Neapel betrieben. Dort haben Costagliola et al. [95] das Compilergenerator-System VLCC (Visual Language Compiler-Compiler) entwickelt, das sowohl einen Editor als auch einen Compiler aufgrund einer kontextfreien, positionalen Grammatik generiert. Positionale Grammatiken für visuelle Sprachen unterscheiden sich von Grammatiken für verbale Sprachen dadurch, daß sie nicht nur eindimensionale Beziehungen zwischen Zeichenketten, sondern zusätzlich mehrdimensionale Beziehungen zwischen grafischen Objekten berücksichtigen [S. 57]. VLCC kann verschiedene Arten zweidimensionaler Sprachen handhaben, z.b. Piktogrammsprachen, in denen Positionen und Kompositionsregeln von Symbolbildern eine Rolle spielen und Diagrammsprachen, in denen grafische Objekte über Anschlußpunkte und Linien mit anderen grafischen Objekten verknüpft werden [S. 56]. Das System verarbeitet nicht nur Grammatiken für visuelle Programmiersprachen sondern auch Beschreibungen allgemeiner Darstellungen wie Schaltpläne und Netzwerkübersichten. Als Beispiel für die Möglichkeiten von VLCC führt der Artikel u.a. die Generierung einer Umgebung für das Erstellen und Kompilieren von strukturierten Flußdiagrammen an (siehe Bild 2-4). Die Arbeiten von Costagliola et al. zeigen zum ersten Mal, daß Compilergeneratoren auch für visuelle Sprachen praktikabel sind, d.h. aufgrund einer Metasprache und einer allgemeinen Parsing-Technik effiziente Compiler erzeugen können. Die Autoren berichten, daß der Spezifikationsaufwand für Syntax und Semantik einer visuellen Sprache mit VLCC ungefähr gleich hoch ist, wie für eine textuelle Grammatik, die mit dem Unix-Werkzeug YACC spezifiziert wird.

31 2.1 Analyse der Begriffe 21 Grammatikeditor Grammatik Bild 2-4. Diagrammeditor Strukturierte Flußdiagramme in VLCC. Costagliola et al. [95 S. 63 Abb. 8, S. 64 Abb. 9.b, S. 65 Abb. 11] Das Bild zeigt eine VLCC-Grammatik für einfache strukturierte Flußdiagramme, den Editor für das Erstellen dieser Grammatik und den Editor für das Zeichnen von Flußdiagrammen. Der Einsatz von VLCC umfaßt folgende Schritte: 1. Beschreiben der Grammatik der Flußdiagramme mit einer Metasprache, die sowohl visuelle als auch textuelle Regeln erlaubt und semantische Aktionen vorsieht. 2. Generieren des Editors und Compilers. 3. Eingeben der Flußdiagramme mit dem generierten Editor. 4. Übersetzen der Flußdiagramme mit dem generierten Compiler in eine textuelle Programmiersprache, wie z.b. Pascal. Dazu werden die semantischen Aktionen der Grammatik verwendet. 5. Ausführen der Flußdiagramme, nachdem der erzeugte Pascal-Code mit einem herkömmlichen Compiler übersetzt wurde Der Begriff»Visuelle Programmierung«Nach der vorangegangen Analyse der Basisbegriffe folgt nun die Diskussion des Begriffs»visuelle Programmierung«. Exakte und eindeutige Definitionen findet man in der Literatur nicht. Meist werden eher vage Charakterisierungen gegeben, die zwar ein intuitives Verständnis vermitteln sollen, für eine exakte Abgrenzung von visueller Pro-

32 Terminologie 22 grammierung zu herkömmlicher Programmierung jedoch wenig geeignet sind. Einer der ersten Erklärungsversuche stammt von Shu [88 S. 9; OZ 8]. Sie schreibt: Wir meinen mit dem Begriff»Visuelle Programmierung«die Verwendung von bedeutungsvollen grafischen Repräsentationen im Programmierprozeß. Leider ist diese Umschreibung recht undeutlich. So läßt etwa der breite Interpretationsspielraum des Ausdrucks»bedeutungsvolle grafische Repräsentationen«die Frage offen, ob der Einsatz einer modernen Softwareentwicklungsumgebung per definitionem zu visueller Programmierung führt, weil solche Umgebungen immer eine Vielzahl von grafischen Elementen umfassen. Dazu meint Shu, daß beispielsweise der bloße Gebrauch eines Fenstersystems noch kein Indiz für visuelle Programmierung ist, da einem Fenstersystem keine signifikante Bedeutung beim Programmieren zukommt [S. 9 ff]. Somit trägt das Wort»bedeutungsvoll«einen Großteil der Last, zwischen visueller und nicht-visueller Programmierung differenzieren zu müssen. Zudem unterscheidet Shu nicht zwischen informellen und formalen grafischen Darstellungen. Zwar definiert sie»programmierung«als die Spezifikation von Anweisungen, die der Computer interpretieren kann [S. 9], stellt aber ausdrücklich fest, daß visuelle Programmierung alle Aspekte der Programmierung berührt, insbesondere auch das System, das zur Programmierung benutzt wird. In diesem Zusammenhang bleibt ungeklärt, ob auch die Verwendung informeller Entwurfsnotationen als visuelle Programmierung zu bezeichnen ist. Weiters nimmt die Definition keine Rücksicht auf die Tatsache, daß sich das Merkmal»visuell«auch auf textuelle Darstellungen beziehen kann, etwa auf den bewußten Einsatz von Seitengestaltung, Schriftarten und Schriftgrößen. Chang [90 S. vi; OZ 9] charakterisiert visuelle Programmierung wie folgt: Unter visueller Programmierung verstehen wir die Verwendung von visuellen Ausdrücken (z.b. Piktogramme, Zeichnungen oder Gesten) im Programmierprozeß. Diese Definition ist noch undeutlicher als jene von Shu, weil Chang den Ausdruck»bedeutungsvolle grafische Repräsentationen«durch den dehnbaren Begriff»visuelle Ausdrücke«ersetzt. Burnett und McIntyre [95 S. 14; OZ 10] fassen visuelle Programmierung ebensoweit: Bei visueller Programmierung verwendet man visuelle Ausdrücke, wie Diagramme, Freihandskizzen, Piktogramme oder sogar grafische Manipulationen. Wenn die Syntax einer Programmiersprache solche Ausdrücke enthält, dann wird sie eine visuelle Programmiersprache genannt (visual programming language VPL). Eine visuelle Programmierumgebung (visual programming environment VPE) stellt visuelle Arten des Umgangs mit einer Programmiersprache zur Verfügung, unabhängig davon, ob die Sprache visuell oder textuell ist. Nach ihrem Verständnis kann bereits dann von visueller Programmierung gesprochen werden, wenn ein Programmierer die Architektur eines Softwaresystems auf einem Blatt Papier skizziert. Hier stellt sich die Frage, ob im Lichte dieser Definition nichtvisuelle Programmierung jemals existiert hat. Was unter»visuellen Arten des Umgangs mit einer Programmiersprache«zu verstehen ist, bleibt ebenfalls der Phantasie des Einzelnen überlassen. Grafton und Ichikawa [85 S. 7; OZ 11] verwenden statt visueller Programmierung den Begriff»grafische Programmierung«:

33 2.1 Analyse der Begriffe 23 Die allgemeine Vorstellung von grafischer Programmierung ist die, daß eine Anordnung von grafischen Symbolen in zwei (oder möglicherweise mehreren) Dimensionen das Programm repräsentiert. Nach Grafton und Ichikawa würde der Einsatz eines grafischen Editors zum Bau von Benutzungsschnittstellen nicht unter visueller Programmierung einzuordnen sein, weil die Autoren verlangen, daß ein visuelles Programm durch grafische Symbole repräsentiert sein muß. Myers [94 S. 877; OZ 12] drückt sich ähnlich, aber nicht so restriktiv aus: Visuelle Programmierung (VP) bezieht sich auf jedes System, das dem Anwender erlaubt, ein Programm auf zwei- (oder mehr-) dimensionale Weise zu spezifizieren. Obwohl das eine sehr breite Definition ist, werden konventionelle textuelle Sprachen nicht als zweidimensional betrachtet, weil Compiler oder Interpretierer sie als lange, eindimensionale Ströme verarbeiten. Die Definition von Myers wird vermutlich am häufigsten zitiert. Sie stammt aus der aktuellen Version einer bereits 1986 publizierten Taxonomie (vgl. Myers [86]). Myers bleibt allgemeiner als Grafton und Ichikawa. Er spricht von»programmspezifikation«, wo Grafton und Ichikawa von»programm«sprechen. Myers meint damit allerdings nicht die Anforderungsdefinition, sondern die Implementierung, da er im gleichen Atemzug konventionelle textuelle Sprachen erwähnt. Die unpassende Bezeichnung einer Tätigkeit als System (»Visuelle Programmierung bezieht sich auf jedes System...«) ist vermutlich auf terminologische Freizügigkeit zurückzuführen. Die Definitionen von Grafton, Ichikawa und Myers lenken das Augenmerk auf die Verwendung von Beschreibungsmitteln, deren syntaktische Konstrukte in zwei oder drei Dimensionen angeordnet sind. Sie betonen damit sowohl die formalen als auch die räumlichen Aspekte der visuellen Programmierung, wobei mit»mehrdimensional«wohl die dritte Dimension gemeint ist, da die Autoren keinen Hinweis darauf geben, wie die vierte und höhere Dimensionen ins Spiel kommen könnten. Eventuell sind damit dynamische Ausdrucksmöglichkeiten angesprochen, die durch die Einbeziehung der Zeit die vierte Dimension berühren Der Begriff»Visuelle Programmiersprache«Wie bereits erwähnt, können etliche Produkte zu Recht als VP-Systeme bezeichnet werden, obwohl sie nur verbale Programmiersprachen unterstützen. Es besteht somit kein zwingender Zusammenhang zwischen visueller Programmierung und visuellen Programmiersprachen. Fortgeschrittene VP-Systeme basieren jedoch immer auf visuellen Programmiersprachen, denen man allgemein höhere Ausdruckskraft, bessere Verständlichkeit und leichtere Benutzbarkeit zuspricht. Viele Forschungsaktivitäten auf dem Gebiet der visuellen Programmierung sind von der Entwicklung solcher Sprachen getrieben. In der Literatur finden sich überraschend wenige Definitionen für den Begriff»visuelle Programmiersprache«. Vermutlich gilt für die meisten Autoren die implizite Annahme Visuelle Programmiersprache = Programmiersprache + visuelle Elemente wobei sie davon ausgehen, daß nicht näher erklärt werden muß, was eine Programmiersprache ist. Demzufolge würde sich das Problem auf die Definition visueller Elemente

34 Terminologie 24 reduzieren. Das dürfte ebenfalls als trivial erachtet werden, und so gesehen wäre eine Definition überflüssig. Leider ergeben sich dadurch Mißverständnisse. Im allgemeinen Sprachgebrauch der Informatik ist eine Programmiersprache eine formale Notation zur Beschreibung von Algorithmen, die ein Computer ausführt (vgl. Ghezzi und Jazayeri [87 S. 41]). Unerheblich ist, ob die Sprache prozedural angibt, wie ein Algorithmus ablaufen soll, oder deklarativ spezifiziert, was ein Algorithmus berechnen soll, solange beliebige Algorithmen beschreibbar sind. Rechenberg [94 S. 165 ff] zeigt, daß für universelle Programmierung die Ausdruckskraft der Sprache der While-Programme ausreicht. Mit dieser minimalen Sprache können auf einem abstrakten Computermodell (der Maschine mit wahlfreiem Zugriff) beliebige Algorithmen beschrieben werden. While-Programme bestehen aus nur vier Anweisungen: drei Befehlen zum Löschen, Inkrementieren und Dekrementieren des Inhalts einer Speicherzelle und einer speziellen While-Schleife für die Iteration. Die While-Schleife wiederholt Anweisungen so lange, wie die Inhalte von zwei Speicherzellen ungleich sind. Mit diesem Satz von Anweisungen kann man alle höheren Operationen ausdrücken und damit alle Algorithmen formulieren. Die Sprache der While- Programme enthält nur unverzichtbare Elemente keine Anweisung kann weggelassen werden. Eine Sprache, die als Programmiersprache im engeren Sinn gelten will, muß demzufolge alle Konstrukte von While-Programmen direkt oder indirekt enthalten, wobei statt der Iteration auch die Rekursion möglich ist, weil beide Konzepte stets ineinander überführbar sind. Mit einigen visuellen Sprachen ist es nicht möglich, beliebige Algorithmen zu beschreiben, weil sie nicht die Ausdruckskraft der Sprache der While-Programme erreichen. Burnett [94 S. 168] nennt solche Sprachen»unvollständig«und führt HI-VISUAL und AVS als Beispiele an. Andere Autoren treffen keine Unterscheidung zwischen vollständigen und unvollständigen Sprachen, wodurch der Anwendungsbereich der jeweiligen Sprache schwer abzuschätzen ist. Borne [93 S. 218] präsentiert beispielsweise eine visuelle, objektorientierte Sprache, die nur lineare Programme ohne Ablaufstrukturen, wie Verzweigungen und Schleifen, erlaubt. Trotz dieser schwerwiegenden Einschränkung spricht sie von einer»visuellen Allzwecksprache«. Sprachen, die auf dem reinen Datenflußprinzip beruhen, verfügen ebenfalls über keine Ablaufstrukturen. Beispiele dafür sind ConMan von Haeberli [88] in [Glinert 90-A&I S. 104], wo es kein allgemeines Interaktionskonstrukt gibt (vgl. Hils [92 S. 89]) und InterCONS von Smith [88 S. 112], wo man Schleifen lediglich durch Mausklicks steuern kann. Dennoch werden diese Sprachen von den Autoren als visuelle Programmiersprachen bezeichnet. Im strengen, traditionellen Sinn sind somit manche visuelle Sprachen bestenfalls Sprachen zum Programmieren, d.h. zur Entwicklung von Programmen oder Programmteilen, aber keine echten Programmiersprachen, d.h. zur Beschreibung von beliebigen Algorithmen. Es stellt sich die Frage, ob die Terminologie solche Unterschiede berücksichtigen soll. Der Verfasser meint»ja«, weil visuelle Programmierung das Programmieren zu Recht weiterfaßt als bisher üblich. Im traditionellen Sinn ist Programmieren (Codieren) ohne eine Programmiersprache kaum vorstellbar; in der visuellen Programmierung versteht man jedoch unter Programmieren auch den Einsatz von Werkzeugen zur interaktiven Konstruktion von Softwarebausteinen. Ein Beispiel ist das Zusammensetzen von Dialogfenstern mit einem grafischen Editor. Eine Programmiersprache wird dabei nicht verwendet. Trotzdem entsteht Software, wenn auch kein Algorithmus im klassischen

35 2.1 Analyse der Begriffe 25 Sinn. Ist schon durch diese breitere Sichtweise nicht immer klar, welche Rolle eine Programmiersprache beim Programmieren einnimmt, so kommt bei visuellen Sprachen noch ein weiterer Aspekt hinzu: Viele VP-Systeme integrieren die Sprache so stark, daß die Grenzen zwischen Programmiersprache und Programmierumgebung verschwimmen. Bild 2-5 zeigt als typisches Beispiel die Fallunterscheidung in Prograph. Dieses VP-System stellt jeden Fall in einem separaten Fenster dar; es ist nicht möglich, alle Fälle in einem einzigen Fenster zu notieren, so daß man mit einem Blick alle Bedingungen überschauen kann. Bei einer derart engen Verflechtung von Umgebung und Sprache verwundert es nicht, daß für viele visuelle Programmiersprachen keine formale Grammatik existiert, wie dies im Exkurs zur Syntax visueller Sprachen bereits zum Ausdruck kam. Bild 2-5. Verflechtung von Benutzungsschnittstelle und Programmiersprache: die Fallunterscheidung in Prograph. Jeder Fall wird in einem separaten Fenster dargestellt, wobei die Beschriftung des oberen Fensterrands anzeigt, um welchen Fall es sich handelt. Die einzelnen Fälle kann man durch Öffnen und Schließen des entsprechenden Fensters ein- und ausblenden. Eine differenzierende Definition ist also notwendig und wird in Abschnitt 2.2.3, S. 44, versucht. Zuvor sollen jedoch noch andere Autoren zu Wort kommen, die sich ebenfalls um Begriffsbestimmungen für visuelle Programmiersprachen bemühen.

36 Terminologie 26 Shu [88 S. 138; OZ 13] schreibt: Eine visuelle Programmiersprache kann informell als eine Sprache definiert werden, die visuelle Repräsentationen (zusätzlich oder anstelle von Worten und Zahlen) verwendet, um zu ermöglichen, was sonst in einer traditionellen eindimensionalen Programmiersprache geschrieben werden müßte. Die angesprochene Äquivalenz mit»traditionellen eindimensionalen«programmiersprachen ist nicht unmittelbar einsichtig. Vielleicht meint Shu damit, daß die nicht näher spezifizierten visuellen Repräsentationen denselben Stellenwert einnehmen müssen wie Konstrukte in universellen Programmiersprachen, d.h. daß sie unverzichtbare Sprachbestandteile sind und nicht bloß Dekorationen einer primär verbalen Notation. Shus Erläuterungen legen diese Interpretation nahe. Sie könnte aber auch gemeint haben, daß visuelle Programmiersprachen nur andere Darstellungen von verbalen Programmiersprachen mit den prinzipiell gleichen Ausdrucksmöglichkeiten sind. Dem widersprechen Ambler und Burnett [89] in Glinert [90-P&S S. 26; OZ 14], indem sie darauf hinweisen, daß es für»natürliche«visuelle Programmiersprachen, durch die ein neues Programmierparadigma entsteht, möglicherweise keine Eins-zu-Eins-Abbildung in Textform gibt: Visuelle Sprachen werden allgemein in zwei Kategorien unterteilt. Die erste Kategorie, visuell transformierte Sprachen, enthält jene visuellen Sprachen, die inhärent nicht-visuell sind, aber durch visuelle Repräsentationen überlagert sind. [...] Sie erleichtern die Spezifikation und das Verständnis von Programmen, die auf bekannten Sprachparadigmen beruhen. Die zweiten Kategorie, natürliche visuelle Sprachen, versucht neue Programmierparadigmen hervorzubringen, deren inhärenter natürlicher Ausdruck visuell ist und für die es möglicherweise kein genaues textuelles Äquivalent gibt. [Anmerkung: Im Zitat ist zwar von visuellen Sprachen die Rede, gemeint sind aber visuelle Programmiersprachen, weil der Aufsatz von Ambler und Burnett keine allgemeinen visuellen Sprachen behandelt] Es ist nicht leicht zu entscheiden, ob visuelle Programmiersprachen ein Paradigma begründen können, das nur visuell denkbar ist. Dazu müßte man untersuchen, ob solche Sprachen visuelle Ausdrücke umfassen, für die kein verbales Äquivalent existiert. Wie hierbei vorzugehen wäre, ist unklar. Zudem ist fraglich, was der Begriff»Paradigma«überhaupt bedeutet. Eine Sammlung von Meinungen zur Paradigmenfrage in der visuellen Programmierung haben Dudley und Mahling [91] zusammengestellt, doch auch sie können keine definitive Antwort geben. Angesichts der vielfältigen Interpretationen dieses Begriffs verwundert das nicht. Tatsächlich begründen die meisten visuellen Programmiersprachen keine neues Programmierparadigma. Sie sind leicht in Sprachklassen einzuordnen, die es schon lange gab, bevor jemand von visueller Programmierung sprach. Beispielsweise beruhen Datenflußsprachen, die als typische Vertreter für natürliche visuelle Sprachen gelten, auf der funktionalen Programmierung. Dieses Art der Programmierung empfahl Backus [78 S. 614] bereits im Jahre 1978 gerade wegen der formelhaften, textuellen Notation mit ihren vielfältigen mathematischen Möglichkeiten. Andere visuelle Sprachen basieren auf den Konzepten der imperativen oder deklarativen Programmierung, wo ebenfalls textuelle Notationen der Standard sind. Eine Ausnahme bilden beispielorientierte Sys-

37 2.1 Analyse der Begriffe 27 teme, mit denen man Programme durch Vorzeigen erstellt. Diese Systeme weisen allerdings meist keine explizite Programmiersprache auf. Sieht man als wesentliche Eigenschaft natürlicher visueller Programmiersprachen nicht die Begründung eines neuen Paradigmas, sondern die Angemessenheit der visuellen Notation in Bezug auf die Problemstellung, dann fällt die Zustimmung zu den zwei Sprachkategorien von Ambler und Burnett leichter, denn es ist richtig, daß es visuelle Programmiersprachen gibt, die bei einer Transformation in textuelle Form viel an Eleganz verlieren. Dazu gehören u.a. visuelle Sprachen für die parallele Datenverarbeitung. Bei der Programmierung paralleler und verteilter Systeme spielen Graphen eine wichtige Rolle, etwa zur Definition der Verbindungen zwischen Prozessoren oder der Bestimmung von Abhängigkeiten in Bezug auf Berechnungsreihenfolge und Ressourcenzuteilung. Auf Graphen beruhende Strukturen erfaßt man am besten visuell und daher können visuelle Sprachen in diesem Problembereich komplexe Zusammenhänge ausdrücken, die durch verbale Notationen nur schwer beschreibbar sind. Die Definition von Smith [87-2 S. 11; OZ 15] soll einen abschließenden Eindruck von den unterschiedlichen Sichtweisen und manchmal auch oberflächlichen Formulierungen vermitteln, die für die Terminologie der visuellen Programmierung bezeichnend sind. Das Zitat soll nicht als sarkastischer Seitenhieb mißverstanden werden, sondern wird deshalb angeführt, weil Penz [90 S. 3-4] gerade Smiths Definition als die»gezielteste und unmißverständlichste«bezeichnet. Smith charakterisiert visuelle Programmiersprachen folgendermaßen: Ein Prozeß oder Algorithmus wird beschrieben; Die Schnittstelle umfaßt grafische Anzeigen und Zeigegeräte; Der Prozeß oder Algorithmus kann ausgeführt werden; Die Verwendung von Text wird minimiert; insbesondere wird der Prozeß oder Algorithmus nicht mit Text beschrieben. Neugierig macht die Unterscheidung zwischen Prozeß und Algorithmus. Leider folgen keine Erklärungen zu diesem Punkt. Weiters ist nicht ganz klar, welche Schnittstelle Smith meint, da Sprachen keine Schnittstelle haben. Wahrscheinlich spricht er von der Benutzungsschnittstelle als sprachliches Medium. Offen bleibt, warum Zeigegeräte dazugehören. Smith bezieht sich damit eventuell auf eine von ihm zitierte Aussage von Kozen et al. [87], die meinen, daß die Grafik am Bildschirm nicht die ganze Sprache ausmacht, sondern daß die Manipulation der angezeigten Objekte ebenfalls ein Sprachbestandteil ist. Warum die Ausführbarkeit des Algorithmus gefordert wird, ist schwer nachvollziehbar, denn ein Algorithmus ist per definitionem ausführbar. Vielleicht meint Smith, daß die Beschreibung maschinell in ein Computerprogramm übersetzbar sein muß. Unbestimmt ist auch die Rolle von Text. Nimmt man Smiths Aussagen wörtlich, dann darf Text nicht zur Beschreibung dessen dienen, was eine visuelle Programmiersprache beschreibt, nämlich Prozesse und Algorithmen. Wozu wird dann Text überhaupt benötigt? Vielleicht für Kommentare, doch das hat nichts mit der Programmlogik zu tun. Programmdarstellung in verbalen und visuellen Sprachen Im folgenden werden die Unterschiede zwischen verbalen und visuellen Programmiersprachen anhand einer C-Funktion aus einer Arbeit von Baecker und Marcus [90] verdeutlicht. Baecker und Marcus beschäftigen sich mit der typographischen Gestaltung von Programmen, um diese besser lesbar und verständlicher zu machen. Sie entwarfen

38 Terminologie 28 für eine umfangreiche Applikation ein sogenanntes Programmbuch [S. 145] und wollen damit ihre Vorstellungen eines visuell vorbildlich aufbereiteten Quelltextes im Sinne des von Knuth [84] entwickelten Literal Programming zeigen. Die als Beispiel verwendete Funktion getsline ist diesem Programmbuch entnommen. Die Funktion getsline liest Zeilen einer Datei, ersetzt Zeilenendezeichen mit Null- Zeichen, überspringt Kommentarzeilen und gibt die erste Zeile zurück, die kein Kommentar ist. Bild 2-6 und Bild 2-7 zeigen Varianten in traditionellem C, während Bild 2-8 eine Reimplementierung in der visuellen Sprache G darstellt. /* getsline - get a script line, stripping the trailing newline and deleting comments. */ /* buf or NULL */ char *getsline (buf, size, fp) /* where the input should go */ char *buf; /* size of the buf array */ unsigned int size; /* where to get the input from */ FILE *fp; { register int len; while (fgets(buf, (int) size, fp)!= NULL) { /* Remove trailing newline. */ len = strlen (buf); if (len > 0 && buf[len - 1] == \n ) buf[len - 1] = \0 ; /* If it s not a comment, return it, else loop around. */ if (buf[0]!= # ) return (buf); } return (NULL) } Bild 2-6. Rein verbale Darstellung der Funktion getsline. Bild 2-7. Visuell aufbereitete Darstellung der Funktion getsline. Baecker und Marcus [90 S. 205] Kommentare sind in grau unterlegte Kästen eingefaßt bzw. als Randbemerkungen notiert der Funktionsname ist in großer Fettschrift dargestellt der Funktionskopf mit den Deklarationen ist deutlich vom Funktionsrumpf getrennt Schlüsselworte sind kursiv geschrieben geschwungene Klammern wurden weggelassen und durch gestaltende Elemente wie Einrückungen und Trennlinien ersetzt runde Klammern besitzen verschiedene Größen, je nach Schachtelungsstiefe geschickt gewählter Leerraum erleichtert dem Auge das Erfassen zusammengehörender Teile.

39 2.1 Analyse der Begriffe 29 Bild 2-6 repräsentiert die Funktion als amorphe Folge von Zeichenketten. Dieser»Programmbandwurm«ist zwar syntaktisch korrekt aber kaum lesbar. Würde man versuchen, den Visualisierungsgrad zu messen, so wäre das Ergebnis nahezu null, da dieser Text nur die reine verbale Information sichtbar macht, ohne visuelle Hinweise auf den logischen Aufbau zu geben. Vermutlich sind nur wenige Programmierer in der Lage, die Funktion auf Anhieb zu verstehen, ohne den Text neu zu formatieren. Bild 2-7 stellt die Funktion durch den SEE-Prozessor aufbereitet dar. Der SEE- Prozessor ist eine Art Übersetzer, der C-Quelltext liest und diesen mit Formatieranweisungen anreichert, so daß eine optisch ansprechende Darstellung der Programmkonstrukte auf verschiedenen Medien, wie Bildschirm und Laserdrucker, möglich ist (vgl. Baecker und Marcus [90 S. 36 u. 270]). Bild 2-7 zeigt denselben Algorithmus wie Bild 2-6, die Funktion ist jedoch wesentlich besser lesbar. Der SEE-Prozessor macht den Programmtext sozusagen»sichtbar«oder exakter ausgedrückt, er repräsentiert den Programmtext in einer Art und Weise, die es dem visuellen Wahrnehmungssystems des Menschen erlaubt, die dargebotene Information effizient zu verarbeiten. Trotz der ansprechenden Formatierung handelt es sich bei Bild 2-7 um kein visuelles Programm, denn die visuellen Merkmale haben entweder gar keine syntaktische Relevanz (z.b. kursive Schlüsselworte) oder sind bloß dekorative Darstellungen lexikalischer Elemente (z.b. Trennlinien und Einrückungen anstelle von geschwungenen Klammern). Die Bedeutung der einzelnen Ausdrücke wird durch die Visualisierung nicht berührt. Bild 2-8 zeigt die Funktion notiert in der visuellen Programmiersprache G des VP- Systems LabVIEW. Die Programmelemente sind im zweidimensionalen Raum frei angeordnet. Alle syntaktischen Konstrukte besitzen eine grafische Repräsentation in Form von Piktogrammen, Linien, Kästen, Anschlußpunkten usw. Bild 2-8 zeigt somit ein visuelles Programm im klassischen Sinn. Die Programmelemente stehen in Bild 2-8 durch topologische Eigenschaften in Beziehung zueinander, indem sie etwa miteinander verbunden oder ineinander enthalten sind. Geometrische Attribute wie Größe und Seitenverhältnisse spielen ebensowenig eine Rolle wie die Namen der Programmelemente. Die grafische Darstellung vermittelt zwar einen guten Eindruck von der grundsätzlichen Struktur des Programms; um alle Details zu erkennen und zu verstehen, sind jedoch eine genaue Analyse und zusätzliche Hilfsmitteln notwendig. Insbesondere sind im Unterschied zur textuellen Darstellung nicht alle Programmzweige gleichzeitig sichtbar. Zusammenfassung Die charakteristischen Eigenschaften von verbalen und visuellen Programmiersprachen können zusammenfassend wie folgt skizziert werden: Verbale Programmiersprachen: visuelle Elemente sind syntaktisch und semantisch bedeutungslos. Die syntaktische Struktur des Programms ergibt sich einzig und alleine aus der linearen Anordnung der lexikalischen Elemente. Die Semantik beruht ausschließlich auf der Interpretation jener Programmkonstrukte, die bei der syntaktischen Analyse erkannt werden. Visuelle Anreicherungen haben nur informellen Charakter. Dazu gehören beispielsweise Formatierungen, die zwar das Lesen erleichtern, die der Compiler bei der Übersetzung in Maschinencode jedoch ignoriert.

40 Terminologie 30 Visuelle Programmiersprachen: visuelle Elemente sind syntaktisch oder semantisch bedeutungstragend. Die Syntax eines visuellen Programms ergibt sich aus den verwendeten Grafiken und Texten, ihrer räumlichen Anordnung und ihren Verbindungen. Die Semantik beruht auf der Interpretation der syntaktischen Strukturen und der semantischen Anreicherung syntaktisch äquivalenter Programmkonstrukten durch visuelle Attribute. Ein Beispiel für eine semantische Anreicherung wäre etwa eine rote Umrandung von Operationen in Bild 2-8, die darauf hinweist, daß an dieser Stelle ein Haltepunkt gesetzt ist, der den Programmablauf unterbricht. Bild 2-8. Visuelles LabVIEW-Programm der Funktion getsline; Farbbild im Anhang. Ein- und Ausgabeparameter sind durch Piktogramme dargestellt, die den Typ des Parameters kennzeichnen ( = Dateireferenz, = 32-Bit-Ganzzahl und = Zeichenkette). Die den Symbolen zugeordneten Namen (fp, size und buf) sind Kommentare; sie haben keine syntaktische Bedeutung. Die kräftige Umrandung von fp und size kennzeichnet diese Parameter als Eingabegrößen, die schwache Umrandung von buf zeigt, daß dieser Parameter eine Ausgabegröße ist. Funktionen sind ebenfalls als Piktogramme dargestellt und mit Linien untereinander verbunden. Über diese Linien werden bei der Programmausführung Daten transportiert. Aussehen und Farbe der Linien bestimmt den Datentyp. Ablaufstrukturen sind als rechteckige Kästen dargestellt. Sie umschließen die Operationen, für die sie gelten. Der äußerste Kasten im Diagramm ist eine While-Schleife. Darin eingebettet befinden sich zwei ineinander geschachtelte If-Konstrukte, von denen jeweils der True-Zweig angezeigt wird. Kommentare befinden sich frei plaziert zwischen den Programmelementen Der Begriff»Softwarevisualisierung«In der visuellen Programmierung verwendet man visuell wahrnehmbare Materialien, um Software zu konstruieren. In der Softwarevisualisierung, geht es nicht um den Konstruktionsprozeß an sich, sondern um die Verbesserung des Verständnisses für bestimmte Eigenschaften von Software durch visuelle Darstellungen. Dabei spielt es keine Rolle, ob die visualisierten Eigenschaften mit einer visuellen oder mit einer verbalen Programmiersprache definiert wurden. Visuelle Programmierung und Softwarevisualisierung sind also prinzipiell voneinander unabhängige Konzepte. Trotzdem darf ein Überblick zu Softwarevisualisierung in einem Buch über visuelle Programmierung nicht feh-

41 2.1 Analyse der Begriffe 31 len, weil grafische Darstellungen bei der Analyse von Software einen hohen Wert besitzen. Bei der Softwareentwicklung steht der Programmierer immer wieder vor der Situation, sich bestimmte Programmabläufe und Datenstrukturen bildlich veranschaulichen zu müssen, um die Funktionsweise eines Programms zu verstehen. Ohne geeignete Softwarewerkzeuge sind dazu eine hohe Vorstellungskraft oder Skizzen auf Papier notwendig. Manuelle Softwarevisualisierungen stoßen allerdings schnell an Grenzen: (1) Der Aufbau eines mentalen Bildes ist durch natürliche Gegebenheiten beschränkt, etwa der persönlichen Vorstellungsgabe und der Menge an Information, die das Gehirn gleichzeitig bearbeiten kann. (2) Handzeichnungen sind ebenfalls nur für kleine Visualisierungen geeignet und zudem statischer Natur, wodurch dynamische Abläufe nicht gut erfaßbar sind. (3) Sowohl mentale Bilder als auch Handskizzen sind höchst fehleranfällig. Für Softwarevisualisierung ist deshalb ein auf das Anwendungsgebiet abgestimmtes maschinelles Instrumentarium unerläßlich. Ein gutes Softwarevisualisierungs-System (SV-System) erlaubt vielfältige Einblicke ins»innere«eines Softwaresystems. So können etwa kritische Bereiche bezüglich Speicherbelegung, Laufzeitverbrauch und sonstiger Ressourcen schneller identifiziert werden, als dies durch bloße Analyse des statischen Programmcodes oder durch unübersichtliche Statistiken möglich ist. Besonders interessant und wichtig sind Illustrationen von algorithmischen Lösungsideen. Jedes gute Lehrbuch über Algorithmen und Datenstrukturen enthält Grafiken, die Veränderungen der Daten in Bezug auf die Abfolge der einzelnen Anweisungen darstellen. Sortierverfahren, das Rucksackproblem, dynamische Listen, verschiedene Arten von Baumstrukturen und allgemeine Graphen sind typische Klassen von Algorithmen und Datenstrukturen, die durch visuelle Darstellungen schneller und besser begreifbar sind als durch rein verbale Beschreibungen (siehe Bild 2-9 und Bild 2-10). Konvexe Hülle Bild 2-9. Visualisierung von Lösungsideen. Konvexe Hülle: Gloor [92 S. 28, Abb. 2]; Sortieren einer Datei: Wirth [86 S. 76, Abb. 2.2] Sortieren einer Datei

42 Terminologie 32 Bild Visualisierung von Datenstrukturen: Linksrotation eines binären Suchbaums. Cormen et al. [90 S. 267, Abb. 14.3] Softwarevisualisierung wird in der Literatur meist als Programmvisualisierung bezeichnet. Für das Verständnis der folgenden Zitate können die beiden Begriffe zunächst als bedeutungsgleich betrachtet werden. Später wird auf differenzierende Merkmale genauer eingegangen. Myers [94 S. 878; OZ 16] erklärt den Unterschied zwischen visueller Programmierung und Programmvisualisierung folgendermaßen: Programmvisualisierung (PV) ist ein ganz anderer Begriff als visuelle Programmierung. Bei visueller Programmierung werden Grafiken benutzt, um das Programm selbst zu erzeugen, während bei Programmvisualisierung das Programm in konventioneller textueller Weise spezifiziert wird und die Grafiken dazu benutzt werden, um bestimmte Aspekte des Programms oder seiner Ausführung zu zeigen. In der Vergangenheit wurden leider viele Systeme zur Programmvisualisierung fälschlicherweise als visuelle Programmierung bezeichnet. Systeme zur Programmvisualisierung können entlang von zwei Achsen klassifiziert werden: ob sie Code, Daten oder den Algorithmus des Programms illustrieren und ob sie dynamisch oder statisch sind. Myers hat recht, wenn er den Unterschied zwischen der visuellen Konstruktion und der visuellen Repräsentation von Software betont. Falsch ist jedoch der Hinweis, daß Programmvisualisierung nur der Illustration von textuell spezifizierten Programmen dient. Auch Shu [88 S. 13] begeht diesen Fehler, wenn sie schreibt, daß Programmvisualisierung dazu dient, die Entwicklung und das Testen von Software zu erleichtern, die in traditionellen Programmiersprachen erstellt wird. Die Fehleinschätzung von Myers und Shu ist leicht durch das Argument zu belegen, daß viele Aspekte der Programmvisualisierung völlig unabhängig von der verwendeten Programmiersprache sind. So hat etwa die Illustration des Laufzeitverhaltens (z.b. Speicherausnutzung und Prozessorbelastung) nichts damit zu tun, ob das zugrundeliegende Programm visuell oder textuell er-

43 2.1 Analyse der Begriffe 33 stellt wurde. Allerdings decken visuelle Programmiersprachen zwei Bereiche der Programmvisualisierung meist zwangsläufig ab: die statische Visualisierung von Code und Daten. Diese Eigenschaft visueller Programmiersprachen garantiert freilich keine guten Visualisierungen, weil die visuellen Repräsentationen von Code und Daten auf die vollständige Definition von Programmen und nicht auf die ausschnittsweise Darstellung interessanter Aspekte ausgerichtet ist. Moriconi und Hare [85 S. 72 f] konzentrieren ihre Bemühungen nicht auf die Darstellung von Programmcode, sondern auf die Visualisierung von Softwaredesign. Ihr System PegaSys soll die Vorteile grafischer Darstellungen mit den Stärken formaler Dokumentation verbinden. PegaSys erfaßt Programmentwürfe als eine Hierarchie strukturierter Bildern, die Daten- und Steuerflußabhängigkeiten zwischen diversen Programmkomponenten darstellen. Moriconi und Hare meinen, daß die komplexen Wechselwirkungen zwischen Komponenten wie Unterprogrammen, Modulen, Prozessen und Datenobjekten auf einer möglichst abstrakten Ebene dargestellt werden sollten, um die wesentlichen Konzepte eines Programmentwurfs zu erfassen. Brown et al. [85 S. 27] beziehen ausdrücklich auch visuelle Repräsentationen der Systemdokumentation in die Visualisierung von Software mit ein. Sie sehen als Aufgabe der Programmvisualisierung die Unterstützung des Menschen beim Aufbau klarer und korrekter Bilder von der Struktur und Funktionsweise eines Programms. Als Zielgruppe nennen sie alle Personen, die in die Entwicklung und Wartung von Software involviert sind. Sie betonen, daß Programmvisualisierung in allen Phasen der Softwareentwicklung eine wichtige Rolle spielt von der Anforderungsanalyse bis zur Wartung. Die Überlegungen von Brown et al. deuten darauf hin, daß der Begriff»Programmvisualisierung«zu eng ist, um auszudrücken, worum es bei der Visualisierung von Software geht. Price et al. [93] haben deshalb den Begriff»Softwarevisualisierung«geprägt. Sie begründen in ihrer Taxonomie von Softwarevisualisierungs-Systemen diesen Terminus wie folgt [S. 212 f; OZ 17]: Programmvisualisierung (PV) wurde von mehreren Autoren definiert, doch es besteht ein allgemeiner Konsens darüber, daß darunter der Einsatz verschiedener Techniken zur Erhöhung des Verständnisses für Computerprogramme zu verstehen ist, während visuelle Programmierung der Einsatz von»visuellen«techniken ist, um ein Programm zu spezifizieren. Die Schwierigkeit mit dem Begriff»Programmvisualisierung«liegt darin, daß er mehrdeutig ist, wenn man ihn im Kontext seiner bestimmenden Bestandteile betrachtet. Unter Algorithmenvisualisierung (oder Algorithmenanimation) versteht man die Visualisierung einer auf hoher Ebene liegenden Beschreibung von Software, im Unterschied zu Code- oder Datenvisualisierung (die zusammen eine Art von Programmvisualisierung sind), wo tatsächlich implementierter Code visualisiert wird. Wir bevorzugen den Begriff Softwarevisualisierung (SV) um dies alles zu erfassen, weil dadurch die Mehrdeutigkeit eliminiert wird und alle Aspekte des Softwareentwurfsprozesses abgedeckt sind, von der Planung bis zur Implementierung. Der Begriff erfaßt auch Software, die aus mehreren Programmen zusammengestellt ist. Obwohl Price et al. ebenso wie Brown et al. den gesamten Softwareentwicklungsprozeß mit einbeziehen, zählen sie die grafische Darstellung von Softwaredokumentation nicht zu Softwarevisualisierung. Sie sprechen dies zwar nicht ausdrücklich an, es darf aber vermutet werden; keines der zwölf Beispiele, auf denen die Taxonomie beruht, betrifft die Visualisierung von Dokumentation und auch die Taxonomie selbst sieht keine Ka-

44 Terminologie 34 tegorie dafür vor. Der Ausschluß der Dokumentation erscheint vernünftig, weil sonst der Begriff»Softwarevisualisierung«einen zu großen Bereich umfassen und damit an Gehalt verlieren würde. An dieser Stelle sei nachdrücklich darauf hingewiesen, daß die klassische Datenvisualisierung ebenfalls nichts mit Softwarevisualisierung zu tun hat. Zur Datenvisualisierung gehören etwa Darstellungen medizinischer, meteorologischer, ökonomischer und technischer Daten. Tufte [90] bringt in seinem Buch»Envisioning Information«zahllose Beispiele zu diesem Thema. Leider stiftet die oft referenzierte Monographie von Shu [88] auch auf diesem Gebiet Verwirrung. Shu führt darin die Visualisierung von Daten oder Informationen über Daten als einen Aspekt der visuellen Programmierung an [S. 13]. Dabei nennt sie grafische Darstellungen von Datenbeständen aus Datenbanken als typisches Beispiel. Warum sie dieses Beispiel wählt ist unklar, denn Applikationen für diesen Bereich haben weder mit visueller Programmierung noch mit Softwarevisualisierung zu tun, sondern sind Anwendungen des Information Retrievals. Mehr zu diesem Thema findet sich bei Robertson et al. [93] und Spoerri [93]. Price et al. [93 S. 213; OZ 18] definieren Softwarevisualisierung wie folgt: Wir definieren SV als den Einsatz von Fertigkeiten aus den Bereichen der Typographie, des Grafikdesigns, der Animation und der Cinematographie zusammen mit moderner Mensch-Maschine-Interaktionstechnologie, um zu ermöglichen, daß der Mensch Software sowohl verstehen als auch effektiv nutzen kann. Sie verdeutlichen mit einem Venn-Diagramm (siehe Bild 2-11), wie die gängigen Begriffe der Literatur aus ihrer Sicht zusammenspielen. Es ist hier nicht möglich, die fein abgestuften Kategorien der Klassifikation von Price et al. Im Detail zu erläutern. Ihre Taxonomie enthält ca. 50 hierarchisch strukturierte Kategorien, wobei die erste Ebene Bereich, Inhalt, Form, Methode, Interaktion und Effektivität von Softwarevisualisierung umfaßt. Lesern, die sich für Softwarevisualisierung besonders interessieren, wird das Studium dieser Taxonomie ausdrücklich empfohlen, da sie viele aufschlußreiche Perspektiven bietet. Eine von Price et al. abweichende Einteilung findet sich bei Stasko und Patterson [92], die Softwarevisualisierung entlang von vier Dimensionen betrachten: Aspekt, Abstraktion, Animation und Automation. Auch Myers [94] hat ein Klassifikationsschema entwickelt, das sich auf nur zwei Achsen beschränkt: den Visualisierungsbereich und die Visualisierungsart.

45 2.1 Analyse der Begriffe 35 Softwarevisualisierung Algorithmenvisualisierung Programmvisualisierung Codeanimation Daten- Animation Statische Codevisualisierung Statische Datenvisualisierung Visuelle Programmierung Statische Algorithmenvisualisierung Algorithmenanimation Bild Bereiche der Softwarevisualisierung nach Price et al. Price et al. [93 S. 213] Price et al. weisen darauf hin, daß in manchen Fällen die Bereichsgrenzen verschwimmen, etwa wenn es um Visualisierungen von sehr abstrakten Programmspezifikationen geht oder die Trennung von Instruktionen und Daten nicht eindeutig möglich ist. Auch die Abgrenzung von Programmvisualisierung und Algorithmenvisualisierung kann schwierig sein. Price et al. schlagen vor, den Anwendungszweck als Unterscheidungskriterium heranzuziehen [S. 247]. Wenn das SV-System dazu dient, allgemeine Berechnungsverfahren zu veranschaulichen, dann sollte von Algorithmenvisualisierung gesprochen werden. Steht hingegen die Implementierung eines bestimmten Algorithmus im Vordergrund, dann handelt es sich um Programmvisualisierung. Kriterien dafür sind Darstellungen von Source-Code in einer bestimmten Programmiersprache im Gegensatz zu abstrakten Pseudocode sowie die Anzeige von Programmvariablen anstelle von universellen Datenrepräsentationen.

46 Terminologie 36 SV-Klassifikationsschema nach Roman und Cox Der Rest dieses Abschnitts beschäftigt sich mit einem Klassifikationsschema von Roman und Cox [93], das die wesentlichen Merkmale von Softwarevisualisierung übersichtlich darstellt. Wie viele andere Autoren, sprechen auch Roman und Cox nicht von Softwarevisualisierung, sondern von Programmvisualisierung. Sie verstehen darunter»die Abbildung oder Transformation eines Programms in eine grafische Repräsentation«[S. 12]. Trotz dieser programmbezogenen Definition ist es zulässig, in Verbindung mit der Arbeit von Roman und Cox weiterhin von Softwarevisualisierung zu sprechen, denn die Autoren beschränken sich nicht nur auf die Visualisierung von Code und Daten eines bestimmten Programms, sondern beziehen auch abstrakte Darstellungen von Algorithmen mit ein [S. 17]. Nach Roman und Cox sind bei Softwarevisualisierung drei Personengruppen beteiligt [S. 13]: Programmierer erstellen die zu visualisierende Software; Animatoren definieren und erstellen die Visualisierung; Betrachter beobachten und steuern die Visualisierung. Eine Person kann mehreren Gruppen angehören und somit unterschiedliche Rollen wahrnehmen. Die Bezeichnung»Animator«ist etwas unglücklich gewählt, da die Visualisierung von Software nicht immer mit Animation verbunden ist, sondern auf statische Darstellungen beschränkt sein kann. Im Sinne einer einheitlichen Terminologie wird diese Bezeichnung hier dennoch beibehalten. Roman und Cox klassifizieren Softwarevisualisierung anhand von fünf Kriterien [S. 14 ff]: 1. Bereich: welche Aspekte von Software werden visualisiert? 2. Abstraktion: mit welchem Detaillierungsgrad werden die visualisierten Aspekte dargestellt? 3. Spezifikationsmethode: auf welche Weise definiert der Animator die Visualisierung? 4. Benutzungsschnittstelle: was sieht der Betrachter, und wie kann er kontrollieren, was das System zeigt? 5. Präsentation: welche Darstellungsprinzipien verwendet der Animator, um die Bedeutung der Visualisierung zu vermitteln? Im folgenden wird nur Punkt 1 erklärt, da die Frage nach den visualisierten Eigenschaften am interessantesten ist. Eine detaillierte Erläuterung aller Punkte mit zahlreichen Beispielen und mehrfarbigen Grafiken findet sich im Originalartikel. Der Visualisierungsbereich gibt an, welche Softwareaspekte grafisch dargestellt werden. Roman und Cox führen vier Aspekte an: Code, Steuerung, Daten und Verhalten. Bild 2-12 und Bild 2-13 zeigen eine mögliche Visualisierung dieser Aspekte für einen Sortieralgorithmus. Die Grafiken sind nur als Beispiele zu sehen. Ein reales SV-System würde vermutlich manche Informationen anders darstellen. So könnte etwa die Datenvisualisierung in Bild 2-13 durch die Anzeige der Feldindizes und der Zahlenwerte noch informativer gestaltet werden. Der Phantasie des Animators sind diesbezüglich keine Grenzen gesetzt.

47 2.1 Analyse der Begriffe 37 for i := 1 to n for j := i to n a [i] > a [j] true t := a [i] a [i] := a [j] a [j] := t false for i := 1 to n for j := i to n if a [i] > a [j] then t := a [i] a [i] := a [j] a [j] := t endif endfor endfor Code Steuerung Bild Verschiedene Aspekte der Softwarevisualisierung; Farbbild im Anhang. Vgl. Roman und Cox [93 S. 12 f] Code. Durch die grafische Darstellung als Nassi-Shneiderman-Diagramm wird die Programmstruktur besser sichtbar als durch rein textuelle Notationen. Die Dynamik eines Sortierlaufs ist aber nicht erkennbar. Steuerung. Dieses Bild erinnert an die Anzeigen konventioneller Debugging-Werkzeuge. Die aktuelle Anweisung ist selektiert und durch einen Pfeil markiert. Durch Positionsänderungen von Pfeil und Selektion bei der Ausführung von Anweisungen bekommt der Beobachter einen guten Eindruck von der Ablaufsteuerung, insbesondere von den Schleifenstrukturen. Die Veränderung der Daten ist jedoch nicht ersichtlich.

48 Terminologie i j Daten Bild Verhalten Verschiedene Aspekte der Softwarevisualisierung; Farbbild im Anhang. Vgl. Roman und Cox [93 S. 12 f] Daten. Das Zahlenfeld a wird als eine Reihe von Balken dargestellt, deren Höhe proportional zur Größe der jeweiligen Zahl ist. Die aktuellen Indizes i und j sind mit Kreisen umrandet, die sich über den zu vertauschenden Feldelementen befinden. Eine Animation dieser Visualisierung macht den Sortiervorgang augenfällig. Verhalten. Die obere Zahlenreihe stellt die Anfangsbelegung des Feldes dar, die untere Reihe entspricht der aktuellen Belegung. Die Symbole dazwischen zeigen die gesamte Sequenz von Vertauschungen. Die Überblicksdarstellung kann Einsichten in die Funktionsweise des Sortierprogramms vermitteln, die durch die schrittweise Visualisierung von Steuerung und Daten nicht möglich sind. Code. Die Visualisierung des Programmcodes umfaßt die Darstellung des Quelltextes und die durch den Quelltext festgelegten Beziehungen zwischen einzelnen Softwareteilen (z.b. Modulverbindungen und Vererbungshierarchien). Die einfachste Form der Codevisualisierung ist durch sogenannte Pretty-Printers zu erzielen, das sind Werkzeuge zur typographischen Aufbereitung von Programmen, um die Lesbarkeit zu erhöhen. Bild 2-7, S. 28, zeigt ein C-Programm, das durch den SEE-Prozessor von Baecker und Marcus [90] verarbeitet wurde. Fortgeschrittene Versionen von Pretty-Printers unterstützen auch grafische Darstellungen, z.b. als Annotationen des Programmtextes und in Form von Flußdiagrammen. Weitere Anwendungen von Codevisualisierungen finden sich bei CASE-Tools, die beispielsweise die statische Aufrufhierarchie von Prozeduren als gerichtete Graphen darstellen oder die Vererbungshierarchie einer Klassenbibliothek als Baumstruktur visualisieren. Steuerung. Die Visualisierung der Programmsteuerung stellt dar, welche Komponenten wann aktiv sind und an welchen Kommunikationsbeziehungen sie teilnehmen. Im einfachsten Fall wird die aktuelle Anweisung markiert. Bessere Visualisierungen zeigen komplexere Zusammenhänge, etwa die dynamische Aufrufreihenfolge von Prozeduren oder Moduldiagramme, in denen der aktive Modul hervorgehoben ist. Besonderen Wert hat die Steuerungsvisualisierung in der parallelen Datenverarbeitung, wo mehrere Komponenten zugleich aktiv sind und komplizierte Sachverhalte, wie etwa die Synchronisation von Prozessen ohne grafische Darstellung nur schwer durchschaubar sind. Das VP-System Vista illustriert beispielsweise parallele Prozesse durch verschiedene Farben. Zur Prozeßsynchronisation verwendete Semaphore werden durch das Symbol einer Ampel dargestellt, die zwischen Rot (belegt) und Grün (frei) umschaltet (siehe

49 2.1 Analyse der Begriffe 39 Bild 2-14). Die Visualisierung der Steuerung gewinnt durch kontinuierliche Animationen sehr an Ausdruckskraft, weil die Dynamik dadurch viel besser zur Geltung kommt, als dies durch einzelne Schnappschüsse des Programmzustandes möglich ist. Daten. Die Visualisierung von Datenstrukturen kann statisch oder dynamisch erfolgen. Die statische Visualisierung stellt skalare Werte (z.b. Zahlen, Zeichen und Speicherworte) und strukturierte Daten (z.b. Felder, Verbunde und Zeigerstrukturen) als Standbilder dar. Die dynamische Visualisierung beruht auf animierten Sequenzen, die Änderungen der Datenstrukturen unmittelbar widerspiegeln. Bei der Softwarevisualisierung ist der Fokus meist auf die internen Datenstrukturen gerichtet. Die Darstellung von Einund Ausgabedaten fällt gewöhnlich in den Bereich der klassischen Datenvisualisierung, wo die Interpretation der Daten und nicht die Analyse der Softwarestruktur im Mittelpunkt steht (eine Ausnahme sind beispielsweise Visualisierungen von Sortieralgorithmen, die nur dann einen Sinn ergeben, wenn die Eingabedaten zusammen mit der Veränderung ihrer Anordnung gezeigt werden). Bild 2-15 zeigt die Visualisierung einer LISP-Datenstruktur mit dem System KAESTLE von Boecker et al. [86]. Verhalten. Die Visualisierung des Softwareverhaltens zeigt die Abfolge der Zustandsänderungen. Der Zustand von Software ergibt sich aus dem Zustand der Steuerung und der Datenstrukturen. Die Beobachtung von Ereignissen, die Zustandsänderungen auslösen oder durch Zustandsänderungen eintreten, kann das Verständnis für die Funktionsweise von Software bedeutend erhöhen. Beispiele für solche Ereignisse sind die Änderung des Wertes von Variablen, das Betreten und Verlassen von Prozeduren, die Freigabe von Ressourcen sowie das Senden und Empfangen von Nachrichten. Ein SV- System kann die Abfolge von Ereignissen unmittelbar visualisieren oder für eine spätere Visualisierung aufzeichnen. Die Aufzeichnung hat den Vorteil, daß der Betrachter die Ereignisse und Zustandstransformationen wie bei einem Film in verschiedenen Geschwindigkeiten vorwärts und rückwärts verfolgen kann. Bild 2-16 zeigt den Stack Browser des Objekt-Architektur-Analysators (OAA) von Fröhlich [96]. OAA unterstützt die Analyse des Verhaltens hybrider, objektorientierter Programme auf der Ebene von Objekten und Beziehungen zwischen Objekten. Das Programmverhalten auf dieser Abstraktionsebene wird durch eine Folge von parameterisierten Ereignissen beschrieben. Verschiedene Piktogramme stellen Ereignisse verschiedener Typen dar.

50 Terminologie 40 Baustein prompter Prozeß blau Prozeß pink Bild Visualisierung von Prozessen und Semaphoren in Vista; Farbbild im Anhang. Baustein prompter. Am Eingang ask sind zwei Verbindungen angeschlossen. Ein Semaphor an diesem Eingang, die als Ampel dargestellt ist, synchronisiert die einlaufenden Prozesse. Das Semaphor ist nicht aktiviert, und deshalb steht die Ampel auf Grün. Prozeß blau. Ein Prozeß, der als blaue, weit gestrichelte Linie dargestellt ist, hat den Baustein prompter durchlaufen und ist auf den Haltepunkt am Ausgang out getroffen. Die rote Ampel weist drauf hin, daß das Semaphor nun aktiviert ist. Weitere Prozesse können prompter nicht betreten. Prozeß pink. Ein weiterer Prozeß, der als pinkfarbene, eng gestrichelte Linie dargestellt ist, möchte den Baustein prompter betreten. Der Prozeß muß am Semaphor warten, bis der erste Prozeß den Haltepunkt durchlaufen hat.

51 2.1 Analyse der Begriffe 41 Bild Visualisierung einer LISP-Datenstruktur: der Unterschied zwischen append und nconc. Shu [88 S. 30, Fig 2-10] Die unterschiedliche Wirkungsweise der Funktionen append und nconc ist deutlich zu erkennen: Während append zusätzliche Elemente einfügt, um zwei Listen zu verbinden, modifiziert nconc das letzte Element der ersten Liste, so daß es auf das erste Element der zweiten Liste zeigt. Durch Analyse der Datenvisualisierung wird klar, daß nach der Ausführung von nconc alle Verweise auf die erste Liste nunmehr auf die vereinigte Liste zeigen, während append diesen Nebeneffekt vermeidet. Aus der textuellen Repräsentation der verketteten Listen ist dieser Unterschied nicht ersichtlich.

52 Terminologie 42 Bild Stack Browser des Objekt-Architektur-Analysators. Vgl. Fröhlich [96] Der Stack Browser zeigt die Geschichte einer Operation. Das Werkzeug ordnet vergangene, aktuelle und zukünftige Ereignisse jenen Operationen zu, die in einer Ereignisfolge zu einem bestimmten Zeitpunkt aktiv sind. Der Stack Browser ist Teil einer Sammlung von Werkzeugen u.a. zum Browsen von strukturierten Ereignisfolgen, ereignisrelevanter Ausschnitte des Programmtextes und Objektstrukturen. Im Bild zeigt der Stack Browser Ereignisse, die zum Zeitpunkt 1471 in aktivierten Operationen aufgetreten sind (Spalte Before) und noch auftreten werden (Spalte After). Zum Zeitpunkt 1471 wurde im Objekt 14 (oberste Zeile der Spalte In) der Klasse FixedStation (Informationszeile ) in einem Aktivierungseintrag für die parameterlose Prozedur Print der Klasse FixedStation (oberste Zeile der Spalte Operation) eine Nachricht (Ereignis ) gesendet. Der Aktivierungseintrag befindet sich auf Stackebene 15 (Spalte Level). In der gleichen Operation wurde vor dem Ereignis zum Zeitpunkt 1471 eine Verbindung zu einem Objekt über eine lokale Variable hergestellt (oberste Zeile der Spalte Before, Ereignis ). Nach dem Zeitpunkt 1471 wird eine statisch gebundene Methode aufgerufen (oberste Zeile der Spalte After, Ereignis ). Das Objekt 16 der Klasse FixedStation sendete zum Zeitpunkt 1463 (2. Zeile der Spalte At) in der Prozedur Print der Oberklasse Station die Nachricht Print, die zur Aktivierung der Methode Print für das Objekt 14 führte. Die Wiederholungen in den obersten 6 Zeilen des Stack Browsers weisen auf einen rekursiven Ablauf hin.

53 2.2 Synthese der Begriffe Synthese der Begriffe Auf Grundlage der Diskussionen und Beispiele der vorigen Abschnitte folgt nun die Synthese der Begriffe. Ziel ist nicht die endgültige Fixierung der Terminologie. Dem stehen der schwankende Sprachgebrauch und die unscharfen Randgebiete entgegen. Statt dessen wird der Versuch unternommen, Begriffserklärungen zu entwickeln, die im Kontext dieses Buches schlüssig und in ihrer Präzision ausreichend sind. Jeder Begriff wird zunächst definiert und anschließend erklärt. Hilfsbegriffe, die in der Definition vorkommen und in der Erklärung näher erläutert werden, sind in der Erläuterung in kursiver Schrift gesetzt Der Begriff»Visuell«Visuell ist die Bezeichnung für jene Eigenschaft eines Objekts, durch die mindestens eine Information über das Objekt, die für das Erreichen eines Handlungsziels unverzichtbar ist, nur durch das visuelle Wahrnehmungssystem des Menschen gewonnen werden kann. Ein Objekt ist hier ein Gegenstand im logischen Sinn, d.h. alles Abstrakte und Konkrete, worauf mit sprachlichen Mitteln unterscheidend Bezug genommen werden kann. Die Definition ist bewußt abstrakt gehalten, weil der Begriff»visuell«in weiterer Folge nicht nur im Kontext der Programmierung, sondern auch in anderem Zusammenhang verwendet wird. In Bezug auf die Softwareentwicklung könnte die Definition wie folgt lauten: Unter»visuell«ist jene Eigenschaft eines Objekts (Sprachkonstrukts, Programmbausteins, Element der Benutzungsschnittstelle usw.) zu verstehen, die zur Folge hat, daß mindestens eine Information über das Objekt, die für die Softwareentwicklung unverzichtbar ist, nur über das visuelle Wahrnehmungssystem gewonnen werden kann. Programme, die mit verbalen Programmiersprachen erstellt werden, sind zwar sichtbar aber nicht visuell, weil Quelltext primär durch das verbale Wahrnehmungssystem interpretiert wird, unabhängig davon, ob die Aufnahme optisch, akustisch oder taktil erfolgt. Visuelle Programmiersprachen hingegen umfassen Elemente wie Farben, Formen, Verbindungen, Überlagerungen, Berührungen usw., deren Interpretation über das visuelle Wahrnehmungssystem erfolgt. Programme, die mit solchen Sprachen erstellt werden, sind daher nicht nur sichtbar, sondern auch visuell im hier definierten Sinn Der Begriff»Visuelle Sprache«Eine visuelle Sprache ist eine formale Sprache mit visueller Syntax oder visueller Semantik und dynamischer oder statischer Zeichengebung. Eine formale Sprache besteht aus Grundzeichen (dem Alphabet), einem Regelwerk zur Bildung von Ausdrücken aus Grundzeichen (der Beschreibung der Syntax), Interpretationsregeln zur Ermittlung der Bedeutung von Ausdrücken (der Beschreibung der Semantik) und eventuell Umformungsregeln für Ausdrücke. In einer formalen Sprache sind Ausdrücke ungültig, die nicht der definierten Syntax genügen, und es sind Ausdrücke bedeutungslos, die nicht der definierten Semantik entsprechen. Die Beschreibung

54 Terminologie 44 von Syntax und Semantik muß nicht in einer formalen Sprache vorliegen, jedoch vollständig und widerspruchsfrei sein. Syntax und Semantik visueller Sprachen beziehen meist den zwei- oder dreidimensionalen Raum ein, während verbale Sprachen auf eindimensionalen Zeichenketten beruhen. Ein Beispiel für ein visuelles syntaktisches Konstrukt ist ein Pfeil zwischen zwei Elementen einer Grafik, der beide Elemente in Beziehung zueinander setzt. Ein Beispiel für ein visuelles semantisches Konstrukt ist eine Färbung dieses Pfeils, die den Zustand dieser Beziehung ausgedrückt, etwa Grün für aktiv und Grau für inaktiv. Dynamische (einmalige) Zeichengebung beruht auf flüchtigen Vorgängen, etwa dem Vorzeigen einer Aktionsfolge zur Generierung eines Programms. Statische (bleibende) Zeichengebung wird durch die Aufschreibung von Zeichen erreicht, etwa durch das Erfassen eines Programms in einer Datei. Eine visuelle Sprache kann auch Textzeichen umfassen. Dies ergibt sich aus der Definition des Begriffs»visuell« Der Begriff»Visuelle Programmiersprache«Eine visuelle Programmiersprache ist eine visuelle Sprache zur vollständigen Beschreibung der Eigenschaften von Software. Sie ist entweder eine Universalprogrammiersprache oder eine Spezialprogrammiersprache. Mit einer visuellen Universalprogrammiersprache (kurz»universalsprache«) kann jedes Berechnungsverfahren formuliert werden, das auf einer Turingmaschine ausführbar ist. Weil auf einer Turingmaschine alle berechenbaren Probleme lösbar sind, bezeichnet man Universalsprachen als vollständig bzw. berechnungsuniversell. Die Vollständigkeit einer einfachen visuellen Datenflußsprache, die ohne Text auskommt, beweisen Brown und Kimura [94] anhand der Programmaschine von Minsky. Bild 2-17 zeigt als Beispiel für eine visuelle Universalsprache ein Programm der funktionalen Sprache VisaVis, die Poswig [93 S. 52 ff] im Rahmen seiner Dissertation entwickelt hat. Poswig begründet die Universalität von VisaVis anhand eines Äquivalenzsatzes aus der Theorie der funktionalen Sprachen, der aussagt, daß die Klasse der auf Turingmaschinen berechenbaren Funktionen gleich der Klasse der partiell rekursiven Funktionen ist [S. 110 ff]. Eine visuelle Spezialprogrammiersprache (kurz»spezialsprache«) ist nicht berechnungsuniversell, weil wesentliche Sprachkonstrukte wie Schleifen oder Verzweigungen fehlen. Dennoch ist es mit Spezialsprachen möglich, für einen eingeschränkten Anwendungsbereich vollständige Programme zu definieren. Ein Beispiel dafür ist die Programmierung mit Makrorekordern.

55 2.2 Synthese der Begriffe 45 Bild Ein Programm, das mit einer visuellen Universalsprache erstellt wurde; Farbbild im Anhang. Vgl. Poswig [96 S. 71 f und S. 92] Das Bild zeigt eine Implementierung des Quicksort-Algorithmus mit der visuellen Universalsprache VisaVis. Das visuelle Alphabet von VisaVis umfaßt den Pfeil als Symbol für die Verbindung zweier Elemente und verschiedenfarbige Symbole zur Darstellung von Daten und Funktionen. Die Farben der Symbole sind Teil der Semantik und illustrieren den Zustand des dargestellten Elements: Grün steht für unspezifiziert, Gelb für spezifiziert und Rot für Resultat bzw. unveränderliche Prädikatfunktion. Die Notation von VisaVis wird in Abschnitt 6.4.3, S. 150, näher erklärt Der Begriff»Visuelle Softwarebeschreibungssprache«Eine visuelle Softwarebeschreibungssprache ist eine visuelle Sprache zur Beschreibung bestimmter Aspekte von Software. Aus den damit erstellten Beschreibungen ist Programmcode maschinell generierbar. Nicht jede Sprache zur Beschreibung von Software ist eine Programmiersprache, mit der alle Eigenschaften von Software vollständig definierbar sind. So erfassen etwa Notationen für den Softwareentwurf meist nur die Grobstruktur und die prinzipielle Funktionalität eines Systems. Erst die Implementierung des Entwurfs in einer bestimmten Programmiersprache bestimmt die Feinstruktur und sämtliche Details des Systemverhaltens. Ein Beispiel für die Verwendung einer einfachen visuellen Softwarebeschreibungssprache ist eine grafische Notation, mit der sich Vererbungsbeziehungen zwischen Klassen ausdrücken lassen (siehe Bild 2-18). Visuelle Softwarebeschreibungssprachen müssen der Bedingung genügen, daß aus den damit erstellten Beschreibungen Programmcode maschinell generierbar ist. Diese Bedingung ist notwendig, um grafische Entwurfsnotationen auszugrenzen, die zwar auf einer visuellen Sprache beruhen, aber keinen direkten Bezug zur konkreten Implementierung der damit entworfenen Software haben. Die Einbeziehung solcher unspezifischer Notationen würde den Begriff»visuelle Programmierung«verwässern, bei dessen Definition visuelle Softwarebeschreibungssprachen vorkommen. Für das Beispiel aus Bild 2-18 wären generierte Programmcodestücke etwa Klassenköpfe in einer konkreten Programmiersprache, die Klassennamen und Oberklassenrelationen enthalten.

56 Terminologie 46 Object Model View DialogView ListView TextView Bild Eine einfache visuelle Softwarebeschreibungssprache für Vererbungsbeziehungen. Die Grundzeichen der Sprache sind ein beschriftetes Rechteck und ein Pfeil. Die semantischen Regeln legen fest, daß das Rechteck für eine Klasse steht und der Pfeil für die Beziehung»erbt von«, wobei die Spitze des Pfeils auf die vererbende Klasse zeigt. Die syntaktischen Regeln legen fest, daß bei Klassenhierarchien mit einfacher Vererbung und einer einzigen Wurzelklasse jede Beschriftung nur einmal vorkommt, ein Pfeil immer zwei Rechtecke verbindet und von jedem Rechteck, außer der Wurzel, höchstens ein Pfeil ausgeht Der Begriff»Visuelle Programmierung«Visuelle Programmierung ist die Erstellung von Software mit visuellen Programmiersprachen und visuellen Softwarebeschreibungssprachen. Eine Menge integrierter Werkzeuge zur visuellen Programmierung heißt VP-System. Nicht unter visueller Programmierung einzuordnen sind u.a. die Verwendung von Programmierumgebungen mit grafischer Benutzungsschnittstelle für verbale Programmiersprachen, die Anwendung grafischer Entwurfsmethoden (auch werkzeugunterstützt), wenn damit nicht zumindest Teile der Software maschinell generierbar sind, die Entwicklung von Software für die grafische Datenverarbeitung (z.b. Computergrafik, Bildverarbeitung und Mustererkennung) sowie begleitende Tätigkeiten der Softwareentwicklung, wie grafisches Editieren der Dokumentation Der Begriff»Softwarevisualisierung«Softwarevisualisierung ist die werkzeugunterstützte, visuelle Darstellung von Software für Analysezwecke, d.h. für Untersuchungen der statischen und dynamischen Eigenschaften von Software. Visuelle Programmierung und Softwarevisualisierung haben unterschiedliche Zielsetzungen: bei visueller Programmierung steht die Implementierung im Vordergrund; bei Softwarevisualisierung liegt der Schwerpunkt auf der Illustration softwaretechnischer Sachverhalte. Softwarevisualisierung zeigt, wie Software strukturiert ist, was sie macht, wie sie funktioniert, warum sie funktioniert oder warum nicht. Dabei spielt es keine

57 2.2 Synthese der Begriffe 47 Rolle, ob die visualisierten Eigenschaften mit einer visuellen oder mit einer verbalen Programmiersprache definiert wurden. Der Betrachter von Softwarevisualisierungen, sei es ein Programmierer oder eine andere Person, analysiert die Darstellungen unter verschiedenen Gesichtspunkten, wie Laufzeitkomplexität, Ressourcenbedarf und algorithmische Konzepte, mit dem Ziel, das Verständnis für die Struktur und Funktionalität zu erhöhen und Verbesserungsmöglichkeiten zu erkennen. Softwarevisualisierung setzt den Einsatz von Werkzeugen voraus. Handskizzen softwaretechnischer Sachverhalte sind nicht unter Softwarevisualisierung einzuordnen. Darstellungen von Ergebnissen der grafischen Datenverarbeitung, wie Ein- und Ausgabedaten von Bildverarbeitungssoftware und technisch-wissenschaftliche Visualisierungen, gehören ebenfalls nicht zu Softwarevisualisierung. Ebensowenig umfaßt Softwarevisualisierung die Darstellung von visuellen Softwarebeschreibungen und visuellen Programmen.

58 3. Pro und Kontra visuelle Programmierung Dieses Kapitel untersucht die Stärken und Schwächen der visuellen Programmierung. 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 aus der Literatur 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 von Bildern in der Programmierung zweifelhaft sind. Grundlage der Überlegungen und Schlußfolgerungen sind Literaturstudien sowie Erfahrungen und Beobachtungen anhand einer Reihe universitärer Programmierprojekte mit kommerziell verfügbaren VP- Systemen. Zudem flossen Erkenntnisse ein, die bei der Entwicklung und Anwendung von Vista gewonnen wurden (siehe Kapitel 7). 3.1 Kognitive Aspekte Man könnte meinen, daß visuelle Programmierung alleine deshalb besonders geeignet sein müßte, Software schnell und gut zu entwickeln, weil Bilder vielfach natürlicher und leichter verständlich sind als Text. Lange bevor ein Kind das Schreiben und Lesen beherrscht, hat es gelernt, auf visuelle Eindrücke zu reagieren. Das Bilderbuch, aus dem die Eltern vorlesen, regt mit farbigen Zeichnungen die Phantasie des Kindes an, und noch bevor es die richtigen Worte findet, kann es auf Dinge zeigen, denen sein Interesse gilt. Auch die Erfahrungen des Alltags bestätigen, daß bildliche Darstellungen unverzichtbare Kommunikationsmittel sind. Für die Aufbereitung und Vermittlung schwieriger Zusammenhänge eignen sich grafische Darstellungen meist besonders gut. Im technischen Bereich, zu dem auch die Softwareentwicklung zählt, ist Kommunikation ohne Bilder undenkbar. Liegt daher nicht der Schluß nahe, daß durch visuelle Darstellungen und Interaktionsmechanismen auch in der Programmierung die geistigen Fähigkeiten des Menschen besser nutzbar zu machen sind als durch rein verbale Ansätze? Antworten auf diese Frage kann die Kognitionspsychologie geben. Dieser Wissenschaftszweig ergründet einerseits, welche Arten von Information der Mensch verarbeitet und befaßt sich andererseits mit den Vorgängen bei der Wahrnehmung, Speicherung und Verwendung von Information. Dazu werden Aktivitäten wie Erfassen, Lernen, Erinnern, Verstehen und Problemlösen vor allem anhand empirischer Untersuchungen analysiert, wobei auch medizinische Erkenntnisse einfließen (vgl. Wessells [90 S.14]). Kognitionspsychologen konnten etwa nachweisen, daß die beiden Hemisphären des menschlichen Gehirns für bestimmte Aufgaben spezialisiert sind (vgl. Wessells [90 S. 281 ff] und Shu [88 S. 1]). Die linke Gehirnhälfte ist überwiegend für logisches und analytisches Denken verantwortlich und verwertet geschriebene und gesprochene Information. Die rechte Gehirnhälfte ist vornehmlich für gefühlsbezogene und ästhetische Kognition zuständig und benutzt bildliche und räumliche Information. Die Informationsverarbeitung geschieht in der verbal orientierten Gehirnhälfte sequentiell und in der

59 3.1 Kognitive Aspekte 49 visuell orientierten Hemisphäre parallel. Staufer [87 S. 52 ff] nennt Experimente, die zeigen, daß Bilder schneller verarbeitet werden als Text und einen weitaus tieferen Eindruck hinterlassen als verbale Ausführungen. Diese Beobachtung wird auch durch subjektive Erfahrung unterstützt: Es fällt im allgemeinen leicht, unter hunderten Personen auch nach längerer Zeit ein bekanntes Gesicht zu erkennen sehr viel schwieriger ist es aber, sich den dazugehörigen Namen in Erinnerung zu rufen. Gerstendörfer und Rohr [87 S. 432] verweisen in diesem Zusammenhang auf Experimente von Bugelski, die gezeigt haben, daß Personen mit Hilfe einer speziellen Merktechnik, die verbale Informationen in Bilder umsetzt, bis zu 40 Wörter mit völlig unterschiedlicher Bedeutung behalten konnten. Dies überschreitet bei weitem die Kapazität des Kurzzeitgedächtnisses, das üblicherweise sieben plus/minus zwei Informationseinheiten aufnehmen kann (vgl. Miller [56]). Gerstendörfer und Rohr geben jedoch zu bedenken, daß nicht alle Menschen auf die gleiche Weise ihren Verstand benutzen, um ein Problem zu lösen [S. 432 f]. Entsprechend unterschiedlich sind die Leistungen bei verschiedenen Aufgabenstellungen. Visualisierer, das sind Menschen, die ein mentales Bild während der Problemlösung aufbauen, sind erwartungsgemäß bei jenen Aufgaben besonders erfolgreich, die räumliche Strukturen betreffen, haben aber Schwierigkeiten mit komplizierten Instruktionsfolgen. Hier schneiden Verbalisierer und Formalisierer bedeutend besser ab. Trotz der unterschiedlichen Herangehensweise verschiedener Menschen an dasselbe Problem gibt es Klassen von Aufgaben, die unabhängig von der individuellen Lösungsstrategie in einer bestimmten Form präsentiert werden sollten, damit eine effektive Durchführung gewährleistet ist. So sollten etwa strukturelle Aufgaben, wo es z.b. um das Anordnen von Dingen geht, immer bildlich dargestellt werden, da sie sonst schlecht verständlich und damit schwer ausführbar sind. Der Leser mag sich die Frage stellen, worin der Zusammenhang zwischen kognitionspsychologischen Erkenntnissen und der Nutzung des Computers zu sehen ist. Auch wenn voreilige Schlüsse unangebracht sind, so darf doch davon ausgegangen werden, daß durch die praktische Umsetzung kognitionspsychologischer Erkenntnisse die Denkleistung nicht nur für die Lösung alltäglicher Probleme gesteigert werden kann, sondern auch im Umgang mit dem Computer wesentliche Verbesserungen zu erwarten sind. Hinsichtlich der Mensch-Maschine-Kommunikation liegt etwa klar auf der Hand, daß die Einführung grafischer Benutzungsschnittstellen auf Grundlage des Schreibtischmodells einen Quantensprung an Bedienungsfreundlichkeit nach sich gezogen hat. Realitätsbezogene Piktogramme, freibewegliche Zeigeinstrumente, verschiebbare Fenster usw. stellen den Computer mit seinen abstrakten Mechanismen in ein natürliches Umfeld, das der Benutzer kennt und versteht. Der durchschlagende Erfolg des Schreibtischmodells steht in vollkommenem Einklang mit Erkenntnissen der Kognitionspsychologie: Rohr [86 S. 89 f, 86-2 S. 341 ff] stellt fest, daß der Mensch die Welt um sich herum in Grundeinheiten und deren Beziehungen auflöst. Ein künstliches System wird umso schneller und besser verstanden, je einfacher es ist, artifizielle Elemente auf bereits bekannte Objekte und Relationen abzubilden. Dabei spielen Metaphern eine große Rolle, etwa die sinngemäße Übertragung der Bedeutung eines Dateiverzeichnisses auf das Konzept eines Ordners. Bei Rohrs Untersuchungen zeigte sich, daß der Gebrauch von Bildern das Lernen eines neuen Systems signifikant unterstützt, vorausgesetzt, daß geeignete Darstellungen existieren. Für abstrakte Konzepte gibt es allerdings oft keine guten Abbildungen. In diesem Fall sollte man auf den Gebrauch von Metaphern und Bildern verzichten, da der Lernende zu fal-

60 Pro und Kontra visuelle Programmierung 50 schen Annahmen über die Eigenschaften des Systems verleitet werden könnte (vgl. Rohr [86-2 S. 343 u. 347]). Die hohe Effektivität von Metaphern betont auch Glinert [90 S. 171], der Untersuchungen von Mayer [81] anführt, die sich mit dem Lernen der Programmierung auseinandersetzen. Glinert interpretiert Mayers Resultate als Hinweis darauf, daß das Programmieren leichter erlernt wird, wenn physikalische oder mechanische Modelle als Beispiele für die Programme dienen. Er schließt daraus, daß grafische Programmiersprachen realistische Sinnbilder verwenden sollten. Bild 3-1 zeigt ein Beispiel für eine Metapher, die das bekannte System einer Fließbandfertigung in die Welt der Datenflußprogrammierung überträgt und dabei die wesentlichen Aspekte des Programmiermodells erfaßt. Es liegt deshalb nahe, ausgehend von den Erfolgen grafischer Benutzungsschnittstellen und den zugrundeliegenden kognitiven Mechanismen einen Analogschluß zu ziehen und folgendes zu behaupten: Visuelle Elemente machen das Programmieren einfacher und führen zu besseren Programmen. Für diese These sprechen mehrere Gründe. Zum einen würde sich durch den Einsatz von Bildern die zur Problemlösung verfügbare Denkkapazität erhöhen, weil die visuelle Gehirnhälfte nicht länger brachliegt. Zum anderen kämen bei der Bildverarbeitung leistungsstarke, parallel arbeitende Denkeinheiten zum Einsatz, wodurch die verbal orientierten Einheiten entlastet würden (vgl. Staufer [87 S. 56]). Dadurch wären Zusammenhänge schneller erfaßbar, Konzepte besser erlernbar und Fehler eher vermeidbar, kurz gesagt, die Umsetzung einer Aufgabenstellung in ein Programm würde bedeutend erleichtert. Die Softwareentwicklung könnte aus diesen positiven Effekten großen Nutzen ziehen. Erstens würde sich die Produktivität professioneller Programmierer und die Qualität der Programme erhöhen. Zweitens würde die Zahl der Programmierer insgesamt steigen. Dies ist deshalb zu erwarten, weil anschauliches und konkretes Programmiermaterial vermutlich auch jener großen Zahl von Computeranwendern den Zugang zum Programmieren ermöglichen würde, die durch textuelle Programmiersprachen überfordert sind. Visuelle Programmierung könnte jeden Benutzer in die Lage versetzen, maßgeschneiderte Applikationen für seine persönlichen Bedürfnisse zu erstellen oder vorhandene Software an seine Vorstellungen anzupassen. So dürfte man hoffen, daß der enorme Anwendungsrückstau zurückginge. Die große Diskrepanz zwischen benötigten und verfügbaren Computerprogrammen hängt ja nicht zuletzt mit der rasanten Verbreitung des Personal Computers zusammen, die dazu geführt hat, daß immer mehr Anwender mit einer Vielzahl individueller Anforderungen einer anteilsmäßig kleinen Zahl professioneller Programmierer gegenüberstehen, die auf die rasch wachsenden Bedürfnisse nicht schnell genug reagieren können. Visuelle Programmierung würde einen guten Teil der Anwendungsentwicklung vom Programmierexperten zum Benutzer verlagern.

61 3.2 Gründe für visuelle Programmierung 51 Bild 3-1. Metaphorische Korrespondenz als Basis für eine visuelle Programmiersprache. Glinert [90 S. 175, Abb. 3-15] Dem aufmerksamen Leser wird nicht entgangen sein, daß in den vorangehenden Sätzen konsequent der Konjunktiv verwendet wurde. Es gibt nämlich keineswegs gesicherte Erkenntnisse, daß grafische Darstellungen textuellen Notationen generell überlegen sind. Abschnitt 3.4»Reflexionen über fünf Thesen zur visuellen Programmierung«, setzt sich eingehend mit den Eigenschaften des Bildes in der Programmierung auseinander, und es sei bereits an dieser Stelle vorweggenommen, daß bildliche Darstellungen mit vielen Problemen behaftet sind. Im folgenden kommen Befürworter und Gegner der visuellen Programmierung zu Wort. Jene, die für den Einsatz von Grafik in der visuellen Programmierung sprechen, knüpfen vor allem wegen der hohen Leistung des menschlichen Bildverarbeitungssystems und der Natürlichkeit von Bildern hohe Erwartungen an visuelle Programmierung. Jene Stimmen, die sich skeptisch äußern, nehmen nicht auf psychologische Phänomene Bezug, sondern führen technische Eigenschaften von Software und ihrer Beschreibungsmittel an, die sich ihrer Meinung nach der bildlichen Repräsentation prinzipiell entziehen. 3.2 Gründe für visuelle Programmierung Shu [88 S. 7 f] meint, daß der Einsatz von Bildern in der Programmierung deshalb vielversprechend ist, weil Bilder mächtigere Kommunikationsmittel sind als Worte, weil sie das Lernen, Verstehen und Erinnern erleichtern und weil sie auf keine Sprachbarrieren stoßen. Deshalb würden Bilder auch Laien einen unmittelbaren Zugang zur Programmierung ermöglichen [S. 3]. Ichikawa et al. [90 S. 3] sehen die Fundamente visueller Sprachen ebenfalls darin, daß Diagramme und andere visuelle Repräsentationen das Verstehen und die Ideenübermittlung unterstützen. Hirakawa und Ichikawa [94 S. 61] behaupten, daß bei der Benutzung visueller Ausdrücke keine Notwendigkeit besteht, computerspezifische Konzepte zu erlernen. Raeder [85 S. 12 f] spricht den direkten Zugriff auf alle Teile eines Bildes an, der mit der Möglichkeit verbunden ist, zwischen einer Gesamtsicht und einer Detailsicht zu wechseln. Er erwähnt die kompakte Kodierung und hohe Transferrate von bildlichen Informationen. Die Visualisierung von Programmabläufen nennt er als wichtige Voraussetzung für das Verstehen eines Programmes. Weiters sieht er eine Entlastung des

62 Pro und Kontra visuelle Programmierung 52 Programmierers durch die Möglichkeit, bildliche Objekte direkt manipulieren zu können, ohne für diese Objekte spezielle Namen vergeben oder merken zu müssen. Schließlich weist er auf den ästhetischen Gehalt von Bildern hin, womit auch die Qualität eines Programms ausgedrückt werden könnte. Ein»gutes«Programm würde hübsch aussehen, während ein»schlechtes«programm einen häßlichen Eindruck hinterließe. Finzer und Gould [84] in Glinert [90-P&S S. 357] argumentieren, daß bei der Softwareentwicklung mit überlappenden Design- und Implementierungsphasen bildlich vorliegende Entwurfsideen schrittweise in eine textuelle Programmsprache umzusetzen sind. Dieser Transformationssprozeß unterbricht die Entwurfsphase, stört die Kreativität und bringt die Gefahr mit sich, daß Entwurfsideen verlorengehen. Durch den durchgehenden Gebrauch von Bildern wäre dieses Problem behoben. Suleiman und Citrin [92 S. 141 f] weisen darauf hin, daß die auf der englischen Sprache basierenden Programmiersprachen für jene Menschen besonders schwer erlernbar sind, die eine Sprache sprechen, deren Struktur vom Englischen grundsätzlich abweicht. Sie unterstützen ihre Behauptungen durch Beispiele aus der arabischen Sprache und schlagen Piktogramme als international verständliche Sprachkonstrukte vor. Cox und Pietrzykowski [88] in Glinert [90-P&S S. 313] sprechen ebenfalls linguistische Aspekte an. Sie beschäftigen sich insbesondere mit der Idee der Programmvariablen als Platzhaltersymbol für unbekannte Werte. Ihren Darlegungen zufolge haben Variablen nur in solchen Sprachen eine natürliche Grundlage, in denen neue Worte aus einem Alphabet ohne Bedeutungsgehalt gebildet werden können. In Sprachen, die auf Ideogrammen beruhen, wie Chinesisch, Japanisch und Koreanisch, ist es unmöglich, neue Symbole einzuführen, die unbekannte Objekte bezeichnen, weil das Alphabet dieser Sprachen nur Symbole mit definierter Bedeutung kennt. Cox und Pietrzykowski schlagen daher bildhafte Programmrepräsentation ohne Variablen vor. Kimura et al. [90 S. 397] beschreiben eine visuelle Programmiersprache für Schulkinder. Sie lehnen Variablen mit den Hinweis ab, daß es Kindern schwerfällt, die damit verbundenen Programmzustände zu meistern. 3.3 Gründe gegen visuelle Programmierung Brooks [87] in DeMarco und Lister [90 S. 22 f] steht auf dem Standpunkt, daß Software nicht sichtbar gemacht werden kann, weil sie nicht im Raum existiert und deshalb geometrische Darstellungen versagen. Seiner Ansicht nach kann jede grafische Wiedergabe eines Softwaresystems bestenfalls einen bestimmten Teilaspekt repräsentieren, aber keinen Gesamteindruck des Systems vermitteln. Außerdem seien die üblichen Bildschirme zu klein, um aussagekräftige Darstellungen in einem brauchbaren Detaillierungsgrad zu liefern. Nickerson [94 S. 232 ff] weist darauf hin, daß es seiner Meinung nach keine befriedigende grafische Notation für Rekursion und Selbstbezüglichkeit gibt. Er vermißt vor allem die Namensgebung in rein bildlichen Darstellungen und kritisiert wie Brooks deren großen Platzbedarf. Nickersons zieht den Schluß, daß das Produktivitätspotential rein visueller Sprachen für die Konstruktion großer Systeme sehr gering ist und sich deshalb die Erforschung solcher Sprachen als fruchtlos erweisen wird. Ähnlich argumentieren Leibs und Goldberg [93 S. 45] wenn sie anmerken, daß Text hinsichtlich des Platzbedarfs optimiert ist, was für Bilder nicht gilt. Weiters meinen sie, daß der Einsatz rein visueller Programmiersprachen bei der Konstruktion großer Systeme auf unüber-

63 3.3 Gründe gegen visuelle Programmierung 53 windliche Hindernisse stößt, sei es wegen der schlechten Skalierbarkeit, der mangelnden Ausdruckskraft oder der umständlichen Benutzung. Der große Informatiker Dijkstra [89 S. 1403] vertritt nach Besichtigung des Visualisierungssystems MacGnome (vgl. Myers [94 S. 889]) die Ansicht, daß damit gerade jene Aspekte eines Programms darstellt werden, die ein guter Programmierer ignorieren sollte. Besonders schlimm wiegt seines Erachtens, daß man Programmieranfänger mit diesem System ausbildet, wodurch wie er meint, bleibende mentale Schäden bei den meisten Studenten die Folge sein dürften. Sein nicht weniger berühmter Kollege Hoare [85 S. 35; OZ 19] drückt sich zwar nicht so pointiert aus, steht Bildern in der Programmierung aber ebenfalls mit Zurückhaltung gegenüber. Er verweist etwa auf die Schwierigkeiten, die sich ergeben, wenn man einen mathematischen Beweis für die Äquivalenz der beiden Zustandsdiagramme aus Bild 3-2 versucht: Offensichtlich illustrieren diese zwei unterschiedlichen Bilder den exakt selben Prozeß [...] Es ist eine der Schwächen von Bildern, daß Beweise über eine solchen Gleichheit bildlich schwierig zu führen sind. Wegen dieser und weiterer Bedenken setzt Hoare visuelle Darstellungen sparsam ein und hält sich dabei an die von ihm postulierte Regel, niemals ein Bild zu verwenden, das nicht mehr Information vermittelt als eine verbale Beschreibung (vgl. Hoare und Jones [89 S. 358]). Bild 3-2. Zwei äquivalente Zustandsdiagramme eines Süßigkeitsautomaten. Hoare [85 S. 35]

64 Pro und Kontra visuelle Programmierung Reflexionen über fünf Thesen zur visuellen Programmierung Befürworter der visuellen Programmierung zitieren gerne den Satz»Ein Bild sagt mehr als tausend Worte und gehen davon aus, daß dies auch für weite Bereiche der Softwareentwicklung gilt. Sie meinen damit in erster Linie, daß bildhaft dargestellte Programme intuitiv erfaßbar sind, woraus sich ihres Erachtens nach viele Vorteile ergeben. Leider bleiben die einzelnen Argumente oft oberflächlich. Sie stützen sich zum Teil auf Thesen, die mit passenden Beispielen unterlegt zwar auf den ersten Blick einleuchten, jedoch bei näherer Betrachtung an Überzeugungskraft verlieren. Wegen der euphorischen Erwartungen werden gerne die speziellen Bedingungen vergessen, unter denen Software entsteht, und der überproportionale Komplexitätszuwachs bei großen Programmen wird fast völlig ignoriert. Wenn es um den Wert grafischer Darstellungen in der Programmierung geht, spielen generelle Überlegungen zu den Vor- und Nachteilen von Bildern eine untergeordnete Rolle. Das Augenmerk muß scharf auf das wesentliche Kennzeichen der Programmierung gerichtet sein: Programmieren im engeren Sinn ist der Einsatz formaler Mittel zur präzisen und klaren Beschreibung von Anweisungen oder Sachverhalten, die der Computer interpretieren kann. Die dazu verwendeten Notationsformen dürfen keinen Deutungsspielraum erlauben weder für den Menschen noch für die Maschine. In ihrem aufschlußreichen Artikel»Why Looking Isn t Always Seeing«bringt Petre [95 S. 34; OZ 20] die Sache auf den Punkt, wenn sie das genußvolle Betrachten eines Kunstwerks der analytischen Interpretation eines Programms gegenüberstellt (siehe auch Bild 3-3): Hinter zumindest einigen der Behauptungen, daß grafische Repräsentationen textuellen Darstellungen überlegen sind, steht das implizite Modell, daß der Programmierer ein Programm auf dieselbe Weise aufnimmt, wie der Betrachter eines Gemälde: Er steht davor,»saugt«es ein, läßt das Auge von Stelle zu Stelle wandern und erhält einen ganzheitlichen Eindruck, der mehr ist als die Summe seiner Teile. Ein Zweck von Programmen ist jedoch die klare und eindeutige Darstellung von Informationen. Ihre effektive Nutzung setzt zielbewußte Durchsicht voraus, nicht das ungefesselte, herumwandernde Auge des flüchtigen Kunstbetrachters. Das Ziel ist nicht poetische Interpretation, sondern zuverlässige Interpretation. Petre zeigt, daß die Effektivität eines Beschreibungsmittels nicht hauptsächlich davon abhängt, ob es visuelle oder verbale Ausdrucksformen erlaubt, sondern ob die Möglichkeit besteht, durch gute äußere Form zusätzliche Lesehinweise zu geben. Demgemäß gibt es in der Softwareentwicklung zwei Notationsebenen: (1) Die Ebene der primären Notation, wo Software mit grafischen oder textuellen Mitteln formal beschrieben wird und (2) die Ebene der sekundären Notation, wo informelle Interpretationshilfen für die formalen Ausdrücke der primären Notation gegeben werden. Zur sekundären Notation gehören gestaltende Maßnahmen wie Gruppierungen, Leerraum, Markierungen und Symmetrie. Das Verständnis grafischer Darstellungen hängt stark vom klugen Gebrauch sekundärer Notation ab. Eine schlecht gestaltete Grafik stiftet mehr Verwirrung als ein schlecht gestalteter Text [S. 43]. Es verwundert deshalb nicht, daß radikale Ansätze aus der Anfangszeit der visuellen Programmierung gescheitert sind. Diese ersten Versuche hatten zum Ziel, wenn immer möglich Text aus Programmen zu verbannen, da die eindimensionale, textuelle und statische Repräsentation traditioneller Programmiersprachen als Hauptverursacher für Frustration und Mißerfolg gesehen wurde (vgl. Glinert und Tanimoto [84 S. 7]). Heute besteht weitgehend Einigkeit darüber, daß Programmierung mit Bildern alleine nicht

65 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 55 praktikabel ist. Selbst Pioniere von damals geben zu, einem Irrtum erlegen zu sein (vgl. Kimura [92 S.125]). Es zeigte sich, daß die kompromißlose Beschränkung auf grafische Elemente neben den zuvor angesprochenen ästhetischen Problemen auch die Anwendung fundamentaler Programmierprinzipien vereiteln und dadurch den Programmierprozeß behindert statt ihn zu fördern. Zu diesen Prinzipien gehören etwa die Bezeichnung von Programmkomponenten mit aussagekräftigen Namen oder die Erläuterung wichtiger Programmstellen durch Kommentare. Aktuelle Entwicklungen beschreiten vernünftigere Wege: Text und Grafik ergänzen einander, wobei die Grafik nach wie vor im Mittelpunkt steht. Trotz dieser Erkenntnisse wird der geflügelte Satz vom Bild, das mehr als tausend Worte sagt, noch immer gerne zitiert. So treffend diese Sentenz auch klingen mag, so muß man sich doch drei Fragen stellen: 1. Kann ein Bild durch tausend Worten nicht zu viel sagen? 2. Kann ein Wort nicht mehr als tausend Bilder sagen? 3. Kann ein Bild verschiedenen Betrachtern nicht Unterschiedliches sagen? Die erste Frage bezieht sich auf die dekorativen Elemente von Bildern, die der Gestalt oder Ästhetik dienen, aber keine wichtigen Informationen vermitteln. Die zweite Frage spricht den geringen Abstraktionsgrad von Bildern an, der ihre Ausdrucksmöglichkeiten begrenzt. Die letzte Frage wirft das Problem der exakten Interpretation von Bildern auf. Es liegt auf der Hand, daß die Antwort auf alle Fragen»Ja«lautet und somit bildliche Darstellungen substantielle Schwächen aufweisen, die genau zu ergründen sind, bevor visuelle Programmierung allgemein empfohlen werden kann. Bild 3-3. Dasselbe Bild, vier Betrachter, vier Interpretationen. Petre [95 S. 34, Abb. 1] Die nächsten Abschnitte beschäftigen sich mit angeblichen Vorteilen bildlicher Darstellungen in der Programmierung. Es werden fünf Thesen genannt, die aus zahlreichen Fachpublikationen extrahiert wurden. Jede These wird kurz erläutert, mit exemplarischen Zitaten unterlegt und durch eine Gegenthese samt knapper Begründung kontrastiert. Die Gegenthese ist nicht der Literatur entnommen, sondern stammt vom Verfasser.

66 Pro und Kontra visuelle Programmierung 56 Es folgt ein ausführlicher Diskurs, der These und Gegenthese bezüglich ihrer Gültigkeit für die Softwareentwicklung prüft, bevor ein Fazit gezogen wird These: Visuelle Programme erleichtern die Kommunikation Diese These beruht auf der Überlegung, daß bei Verwendung von visuellen Darstellungen eine hohe Ähnlichkeit mit Objekten erzielt werden kann, die sowohl Programmentwicklern als auch Auftraggebern vertraut sind, wodurch die Kommunikation über Programmstruktur und Programmfunktion erleichtert würde. Zudem kann die mehrdimensionale Informationskodierung bei Bildern (z.b. Position, Form, Farbe und Helligkeit) deren Ausdrucksstärke gegenüber Text erhöhen, wodurch Informationen besser vermittelbar sind. Zitate Kahn und Saraswat [90 S. 8; OZ 21]:»In vielen Fällen ist eine topologisch vollständige Visualisierung knapper als Text, und oft kann dieselbe Information viel eleganter präsentiert werden.«raeder [85 S. 12; OZ 22]:»Gute Bilder, die Objekte der realen Welt repräsentieren und zur Darstellung von Abstraktionen verwendet werden, helfen nicht nur dem Spezialisten seine Gedanken schneller und besser zu formulieren und zu kommunizieren, sondern helfen auch dem Anfänger, der nach einem Anhalt sucht, um eine ungewohnte Materie zu bewältigen.«shu [88 S. 7, OZ 23]:»Grafische Darstellungen und Bilder haben im Programmierprozeß an Einfluß gewonnen. Diese Art der Programmierung wird durch folgende Prämissen stimuliert: 1. Bilder sind als Kommunikationsmittel mächtiger als Worte. Sie können mehr Bedeutungsgehalt in einer knapperen Ausdruckseinheit vermitteln. [...]«Staufer [87 S. 53]:»Ein Piktogramm besitzt ein weitaus größeres Maß an Kompatibilität als jedes mögliche Wort. Der spontane Bekanntheitswert des Zeichens ist wesentlich stärker als der des Zeichens Dokument. Auch die Bedeutungshaltigkeit eines Piktogramms ist größer, weil es dem realen Gegenstand in weitaus größerem Maß ähnelt als das dafür gebräuchliche Wort.«Gegenthese Visuelle Programme sind per se nicht besser kommunizierbar als verbale Programme. Begründung: Effektive Kommunikation beruht auf Konventionen. Damit die vom Sender aufbereitete (verschlüsselte) Information vom Empfänger verstanden (entschlüsselt) werden kann, müssen Sender und Empfänger eine Übereinkunft über das verwendete Zeichensystem, die Kodiervorschriften und den Begriffsraum treffen. Diese Bereiche sind bei verbaler Kommunikation weitgehend normiert, bei visueller Kommunikation hingegen nicht. Dadurch können Mißverständnisse entstehen. Zudem ist vieles nicht bildlich darstellbar, was verbal beschreibbar ist. Dies gilt insbesondere für abstrakte Begriffe, wie sie in der Softwareentwicklung häufig benötigt werden.

67 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 57 Diskurs Shu führt zur Unterstützung der Behauptung, daß Bilder mächtigere Kommunikationsmittel sind als Worte, ohne weiteren Kommentar die in Bild 3-4 gezeigten Schädel an. Selbst bei solchen einfachen Darstellungen (die überdies nichts mit visueller Programmierung zu tun haben) ist unklar, was gemeint ist. Geleitet durch die Bildunterschrift kann das linke Bild so interpretiert werden, daß der menschliche Schädel im Laufe des Lebens wächst, während das rechte Bild sowohl Schrumpfung als auch Vergrößerung bedeuten kann. Ohne nähere Erläuterungen tappt der Betrachter im Dunklen. Von einem mächtigen, d.h. ausdrucksstarkem Kommunikationsmittel kann hier keine Rede sein. Es soll nicht bestritten werden, daß eine große Klasse grafischer Darstellungen effizient Informationen vermittelt, die textuell nur schlecht repräsentierbar sind. Beispielsweise kann man die Veränderungen in den Proportionen der Schädel aus Bild 3-4 nur visuell gut erfassen; eine textuelle Beschreibung wäre langwierig und schwer verständlich. Doch das trifft nicht den Kern der Sache, denn diese Bilder sind Beispiele für Datenvisualisierung und nicht für visuelle Programmierung. Das gilt auch für grafische Repräsentationen von Meßdaten, die bedeutend klarer und dichter sein können als die Darstellung in Form von Zahlenreihen. Tufte [83] hat dazu ein exzellentes Buch mit dem Titel»The Visual Display of Quantitative Information«verfaßt, wo er viele Beispiele für informative Grafiken anführt. Er weist aber auch auf die Fallstricke von Visualisierungen hin und definiert den sogenannten»lügenfaktor«, der angibt, in welchem Mißverhältnis die grafische Darstellung zur Realität steht [S. 57]. Zahlreiche Diagramme statistischer Daten überführt er damit als Verfälschungen der Wirklichkeit (siehe Bild 3-5). Bild 3-4. Sind Bilder tatsächlich bessere Kommunikationsmittel als Text? Shu [88 S. 8, Abb. 1-4] Bedeutet die rechte Darstellung, daß der menschliche Schädel im Laufe der Evolution schrumpfte oder wuchs? Ohne verbale Erläuterung oder zusätzliche visuelle Annotationen (etwa einem Pfeil) ist darüber keine Aussage zu treffen. Weiters ist zu bedenken, daß in der Programmierung häufig mathematische Fragestellungen interessieren. Diagramme sind in diesem Fall textuellen Darstellungen bezüglich Präzision, Dichte und Handhabbarkeit klar unterlegen. Die Grafik wird zwar benötigt, um den mathematischen Hintergrund zu illustrieren, kann aber meist nur einen Ausschnitt des Wertebereichs zeigen, den ein Algorithmus oder eine Formel definiert. Bilder mathematischer Sachverhalte sind demzufolge nur selten vollständig und bedeuten

68 Pro und Kontra visuelle Programmierung 58 Informationsverlust, was ebenfalls der These vom»mächtigen Kommunikationsmittel«widerspricht. Doch nicht nur Informationsverlust kann mit Grafiken verbunden sein, auch das Gegenteil ist häufig der Fall: Bilder können Informationen enthalten, die irrelevant sind und den Betrachter zu falschen Schlüssen verleiten. Hiebl [94 S. 10] zitiert ein Beispiel von Glinert et al. [91 S. 90], wo auf die Schwierigkeiten hingewiesen wird, einen ungerichteten Graphen zu zeichnen, dessen Kanten und Knoten in textueller Form gegeben sind (siehe Bild 3-6). Hiebl meint, an diesem Beispiel könne man gut erkennen, daß textuelle Notationen ausdrucksschwach und mehrdeutig sind, wenn es um konkrete Sachverhalte geht: eine Illustration des Graphen ist auf verschiedene Weise möglich, als Rechteck, Dreieck und Tetraeder, doch welche dieser Formen zu zeichnen ist, kann dem Text nicht entnommen werden. Somit würden Informationen im Text fehlen, die das Bild vermittelt. Tatsächlich ist nicht die textuelle Beschreibung, sondern die bildliche Darstellung mit Mängeln behaftet. Der Text beschreibt präzise die Eigenschaften eines bestimmtes Exemplars der Klasse ungerichteter Graph, nicht mehr und nicht weniger. Diese Beschreibung genügt, um sinnvolle Operationen anzuwenden, etwa die Funktion Kürzester Pfad (G,a,b), welche die minimale Anzahl von Kanten des Graphen G zwischen zwei beliebigen Knoten a und b berechnet. Die bildliche Darstellung hingegen spiegelt Eigenschaften vor, die der Graph nicht hat, z.b. die Lage der Knoten im Raum und die Länge der Kanten. Diese redundanten Informationen können zu Fehlinterpretationen verleiten. Besonders deutlich wird dies bei Bild 3-6 (c), das eine räumliche Figur vortäuscht. Trotz der genannten Bedenken gibt es ernstzunehmende Hinweise, daß in bestimmten Anwendungsbereichen visuelle Programmiersprachen von großer Bedeutung für die Kommunikation von Entwicklern und Auftraggebern sein können. Ein hohes Kommunikationspotential liegt vor allem dann vor, wenn Ähnlichkeiten zwischen Programmiersprache und Darstellungen existieren, mit denen die Auftraggeber vertraut sind. Baroth und Hartsough [94 S. 24] berichten, daß bei der Entwicklung von Meßinstrumenten mit LabVIEW, die Trennung der Phasen Anforderungsdefinition und Implementierung vollständig entfällt. Durch die ständige Kommunikation anhand des grafischen LabVIEW-Codes, der elektronischen Schaltplänen ähnelt und im Beisein des Auftraggebers interaktiv am Computer entwickelt wird, fließen Änderungen der Anforderungen sofort in das Produkt ein. Wenn alle Anforderungen erfüllt sind, ist auch das System fertig. Bei diesem Entwicklungsprozeß überblickt der Kunde zwar nicht alle Details der grafischen Syntax, er erkennt und versteht aber die Grobstruktur des Systems soweit, daß er an entscheidenden Stellen Vorschläge machen kann [S. 34]. Baroth und Hartsough meinen, daß eine solche Interaktion zwischen Entwickler und Auftraggeber auf Basis einer konventionellen Programmiersprache kaum vorstellbar ist, weil diese von den Auftraggebern nicht verstanden würde. Fazit Effektive Kommunikation mit bildlichen Illustrationen ist dann möglich, wenn verbale Erläuterungen eventuelle Zweideutigkeiten beseitigen und sich die grafische Repräsentation auf das Wesentliche beschränkt. Für die Darstellung und Analyse von Daten sind mit Bedacht gewählte Diagramme von hohem Wert und textuellen Darstellungen meist überlegen. Dies gilt auch für die Visualisierung diverser Programmaspekte, wie der anschaulichen Präsentation von Datenwerten und der Darstellung dynamischer Abläufe.

69 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 59 In bestimmten Anwendungsbereichen kann die bildliche Darstellung von Programmstrukturen ein gutes Kommunikationsmedium zwischen Entwickler und Auftraggeber sein. Ob die gemeinsame, interaktive Softwareentwicklung von Programmierer und Kunden eine hohe Qualität garantiert, ist allerdings fraglich. Bild 3-5. Ein Lügenfaktor von 14,8. Tufte [83 S. 57] Sinngemäße Übersetzung der Anmerkungen von Tufte: Die New York Times vom 9. Aug berichtete, daß der U.S.-Kongreß und das Verkehrsministerium eine Reihe von Regulierungen zur ökonomischen Treibstoffnutzung beschlossen hatten. Beginnend mit 18 Meilen pro Gallone im Jahre 1978 sollten bis zum Jahre 1985 in mehreren Schritten 27,5 Meilen pro Gallone erreicht werden. Das entspricht einem Zuwachs von 53%. Der im Bild gezeigte Zuwachs errechnet sich aus der relativen Länge der Linien für 1978 und 1985, das sind 5,3 0,6 100 = 783% 0,6 Die tatsächliche Veränderung von 53% wird demzufolge durch Linien repräsentiert, die sich um 783% ändern, woraus sich ergibt 783 Lügenfaktor = = 53 14, 8

70 Pro und Kontra visuelle Programmierung 60 p q p p s s s (a) r r (b) q r (c) q Bild 3-6. Eindeutige Beschreibung und mehrdeutige Darstellung eines Graphen. Hiebl [94 S. 10] Gegeben ist ein ungerichteter Graph G mit den Knoten p, q, r, s und den Kanten pq, pr, ps, qr, qs und rs These: Visuelle Programme sind leicht verständlich Diese These beruht auf der Überlegung, daß Bilder wegen ihrer»natürlichkeit«unmittelbar begreifbar sind. Deshalb wäre leicht durchschaubar, was die Eigenschaften und der Zweck von visuellen Programmkomponenten sind und welche Bedeutung die Beziehungen zwischen den Komponenten haben. Zitate Glinert [90 S. 173 f; OZ 24]:»Der primäre Vorteil der Verwendung von visuellen statt textuellen Darstellungen ist die Möglichkeit eines unmittelbaren Verstehens durch einen ungeübten Beobachter.«Kahn und Saraswat [90 S. 7; OZ 25]:»Die Struktur von Programmen kann durch eine gut entworfene zweidimensionale Gestaltung besser erfaßt werden als dies mit Zeilensequenzen möglich ist, die im wesentlichen eindimensional sind. Eine gut entworfene bildliche Syntax ermöglicht Programmierern verschiedene Arten von Programmanomalien visuell aufzufinden. Noch wichtiger ist vielleicht, daß ein Mittel zur Erkennung der dynamischen Struktur einer Berechnung in hohem Maße dabei hilft, zu verstehen, wie Programme arbeiten. Dieses verbesserte Verständnis erleichtert die Konstruktion, die Fehlersuche, die Modifikation, die Verbesserung und die Dokumentation von Programmen.«Myers [94 S. 878; OZ 26]:»Es scheint klar zu sein, daß ein eher visueller Programmierstil für Menschen leichter zu verstehen und hervorzubringen ist, insbesondere für Nicht- Programmierer oder Programmieranfänger.«Shu [88 S. 7; OZ 27]:»Bilder helfen beim Verstehen und Erinnern.«Gegenthese Visuelle Programme sind meist schwerer verständlich als verbale Programme. Begründung: Für visuellen Programmcode werden meist Liniendiagramme verwendet. Diese Diagramme sind ab einer gewissen Komplexität nicht mehr überblickbar, weil zu viele Linien die Konzentration auf einzelne Diagrammteile stören, weil Zusammenhänge nicht mehr erfaßbar sind und weil der Linienverlauf durch Überkreuzungen unklar wird. Selbst einfache Diagramme erfordern durch ihre zweidimensionale Struktur einen

71 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 61 hohen Interpretationsaufwand, wie kognitionspsychologische Experimente nachgewiesen haben. Insbesondere ist die Leserichtung oft unklar. Zudem ist die Bedeutung von grafischen Elementen aus der Darstellung selbst nicht immer ableitbar, sondern kann vom Kontext abhängen. Diskurs Zweifellos tragen gute Grafiken viel zur besseren Veranschaulichung von Informationen bei. Tufte [90] zeigt anhand vieler Beispiele, wie komplexe Daten und Zusammenhänge in Form von Diagrammen, Tabellen, Karten, Pläne usw. so präsentiert werden können, daß der Betrachter mühelos die wesentlichen Informationen entnehmen kann (siehe Bild 3-7). In der Programmierung können Bilder ebenfalls zum leichteren Verstehen beitragen, vor allem wenn es darum geht, durch geeignete Visualisierungen die Wirkungsweise von Programmen darzustellen. Durch die hohe Rechenleistung moderner Computer sind nicht nur statische Grafiken, sondern auch animierte Sequenzen möglich, durch die man einen unmittelbaren Eindruck von den Geschehnissen im»inneren«des Programms erhalten kann, etwa der Ausführung von Anweisungen und der Veränderung von Datenstrukturen. Beispielsweise können gut gewählte Visualisierungen die Konzepte verschiedener Sortierverfahren und die daraus resultierenden Geschwindigkeitsunterschiede viel besser vermitteln, als dies durch die bloße Inspektion von Programmcode möglich wäre. Bild 3-7. Jahreszyklus des Popillia japonica Newman. Tufte [90 S. 110] Bei aller Zustimmung zur verständnisfördernden Wirkung bildlicher Darstellungen dürfen die damit verbundenen Probleme nicht übersehen werden. Wang und Lee [93 S. 330 f] weisen auf den großen Interpretationsspielraum für Bilder hin, der dadurch entsteht, daß die Bedeutung eines Bildes oft nicht im Bild selbst enthalten ist, sondern vom Kontext abhängt. Zum Beispiel kann eine Linie sowohl eine Hierarchiebeziehung als auch eine Kommunikationsbeziehung zwischen zwei Objekten repräsentieren. Ob ein Bild

72 Pro und Kontra visuelle Programmierung 62 richtig verstanden wird, hängt von der richtigen Auslegung durch den Betrachter ab. Dieser muß über die Fähigkeit verfügen, gewisse Bildelemente zu ignorieren und anderen besondere Aufmerksamkeit zu schenken, je nachdem welche Informationen das Bild vermitteln soll. Dazu muß er das Anwendungsgebiet und dessen Konventionen kennen. Beispielsweise spielen bei Mengendarstellungen mit Venn-Diagrammen die Größe der Kreise keine Rolle. Jemand, der mit der Symbolik von Venn-Diagrammen nicht vertraut ist, wird eventuell von der Größe der Kreise auf die Größe der Menge schließen, daraus falsche Schlüsse ziehen und somit das Diagramm falsch interpretieren. Es genügt also nicht, passiv die in einer Grafik enthaltene Information aufzunehmen, sondern es muß aktiv das zugrundeliegende Modell extrahiert werden. Dieser Prozeß stellt zum Teil hohe Anforderungen an den Betrachter. Novak und Bulko [93 S. 171 f] setzen sich eingehend mit der Interpretation von Diagrammen auseinander und kommen zum Schluß, daß zur Abschwächung der inhärenten Mehrdeutigkeit grafischer Darstellungen fast immer unterstützender Text notwendig ist. Sie weisen weiters darauf hin, daß durch die zweidimensionale Anordnung von Bildelementen die Zerlegung eines Diagramms in seine Einzelteile schwierig ist. Es gibt keine klaren Regeln, wie Diagramme zu analysieren sind, und somit können miteinander in Beziehung stehende Teile oftmals nur mit Mühe identifiziert werden. Es sei an dieser Stelle nochmals auf die wichtige Rolle der guten Gestaltung als Hilfsmittel zur Interpretation hingewiesen, die Petre [95 S. 35] als sekundäre Notation bezeichnet. Die verständliche Darstellung von Programmcode in grafischer Form ist leider nur schwer realisierbar. So sind etwa die Ergebnisse von Laboruntersuchungen zur Lesbarkeit von Flußdiagrammen nicht ermutigend (vgl. Green und Petre [92 S. 2]), und auch moderne Ansätze in Form von Datenflußdiagrammen und objektorientierten visuellen Sprachen können in vielen Fällen nicht überzeugen. Zwar berichten Baroth und Hartsough [94 S. 34] von industriellen Projekten, bei denen Ingenieure und Wissenschaftler mit wenig Programmiererfahrung in der Lage waren, die Grobstruktur datenflußorientierter LabVIEW-Programme rasch zu verstehen, doch die Programme wurden gemeinsam mit LabVIEW-Experten entwickelt. Zudem kamen die Anfänger teilweise aus dem Elektronikbereich, in denen das verwendete»draht-baustein- Modell«gut bekannt ist. In Situationen, wo eine bekannte Metapher für die Programmierung verwendet wird, besteht zudem die Gefahr, daß durch die visuell ansprechende und vertraute Form von Diagrammen die dahinterliegende Logik nur scheinbar verstanden wird. Petre [95 S. 42] nennt dies den»cobol Effekt«: weil das Vokabular geläufig ist, glaubt man das Programm zu begreifen, obwohl man seine Funktionsweise in Wirklichkeit mißversteht. Der Leser möge versuchen, das einfache LabVIEW Programm aus Bild 2-8, S. 30, zu analysieren. Auch dem in der Datenflußprogrammierung wenig geübten Betrachter wird es nicht schwerfallen, einen ungefähren Eindruck von der Programmstruktur zu bekommen, doch das Programm im Detail zu verstehen ist wohl kaum möglich. Verglichen mit einem C-Programm adäquater Funktionalität mag der Analyseaufwand trotzdem gering sein, da es sich um ein kleines und maßgeschneidertes Beispiel aus dem Anwendungsbereich von LabVIEW handelt. Für umfangreichere Aufgabenstellungen muß dies aber nicht mehr gelten. Poswig [93 S. 22; OZ 28] zitiert Kiel und Shepherd [88], die bei allem Lob für LabVIEW auch auf die schlechte Lesbarkeit komplexer Programme hinweisen: Sicher, die vielen nützlichen Möglichkeiten von LabVIEW, etwa die mathematischen Routinen und die grafischen Anzeigen, können vom unerfahrenen Pro-

73 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 63 grammierer leicht verwendet werden. Ebenso sind einfache Diagramme in der Tat selbsterklärende Programme. Unseres Erachtens kann ein unerfahrener Programmierer mit LabVIEW ein weitaus anspruchsvolleres Modell erzeugen, als das in anderen höheren Programmiersprachen möglich ist. Kompliziertere LabVIEW- Programme können jedoch ebenso schwer zu entziffern und von Fehlern zu befreien sein, wie Programme in anderen Sprachen. LabVIEW kann dubiose Programmiertricks erfordern, und die Methoden, die zum Speichern von Variablenwerten und zum Verzweigen bei einer bestimmten Bedingung notwendig sind, sind oft umständlich [...] Das Problem der verständlichen grafischen Darstellung von Programmcode ist bei objektorientierter Programmierung besonders schwer in den Griff zu bekommen. In vielen objektorientierten VP-Systemen wird der Ansatz verfolgt, Objekte durch Piktogramme bzw. Benutzungsschnittstellen-Elemente darzustellen und Nachrichten durch beschriftete Pfeile. Diese Art der grafischen Darstellung hat allerdings den Nachteil, daß bereits kleine Diagramme völlig unübersichtlich werden. Bild 3-8 zeigt eine einfache PARTS- Applikation mit allen Objekten und Nachrichten. Um das Bild nicht noch mehr zu überladen, wurden sowohl die Namen der Nachrichten als auch deren Parameter ausgeblendet. Trotzdem ist das Programm undurchschaubar und kann nur mit größter Mühe besser strukturiert werden. Das Linienwirrwarr ist leider inhärent mit dem Programmierparadigma verbunden. Wie die meisten objektorientierten Applikationen sind auch PARTS-Applikationen ereignisgesteuert. Immer wenn ein Ereignis eintritt, wird mit einer Kette von Nachrichten reagiert, die im allgemeinen viele Objekte berührt. Jeder Linienzug, der eine Nachrichtenkette visualisiert, muß demnach durch die Piktogramme aller beteiligten Objekte geführt werden. Weil auch sehr einfache Applikationen auf eine Vielzahl von Ereignissen reagieren, führen meist dutzende Linienzüge kreuz und quer durch die Diagramme. Auf diese Weise entsteht der verheerende Spaghetti-Effekt. Bei textuellen Notationen ist das nicht der Fall, weil dort Objekte über Namen angesprochen werden und daher keine visuelle Verbindung zwischen der Deklaration und der Benutzung eines Objekts besteht. Auch Datenflußdiagramme leiden nicht so stark unter dem Spaghetti-Effekt. Bei diesen grafischen Notationen für erweiterte funktionale Programmiersprachen verbindet man Funktionen anstelle von Objekten. Anders als Objekte haben Funktionen kein Zustandsgedächtnis, und deshalb kann eine Funktion mehrmals im Diagramm plaziert werden, was einem mehrmaligen Funktionsaufruf entspricht. Obwohl beim Bezug auf Objekte über ihren Namen auf grafische Verbindungselemente verzichtet werden kann, sieht Raeder [85 S. 12; OZ 29] gerade den Zwang zur Benennung von Objekten als Nachteil verbaler Programmiersprachen: In konventionellen Programmiersprachen können Objekte nur durch Namen referenziert werden. Das bedeutet, daß alle Objekte indirekt referenziert werden; sie sind also für den Programmierer unsichtbar. Namen werden nicht benötigt, wenn der Programmierer Bilder benutzt, denn Bilder sind unmittelbare, visuelle Objektrepräsentationen. Der Programmierer ist davon befreit, sich ständig auf unsichtbare Objekte beziehen zu müssen. Ähnlich argumentieren Kahn und Saraswat [90 S. 8]. Sie sehen einen der Hauptnachteile von textuellen Notationen darin, daß über Namen hergestellte Verbindungen zwischen Objekten bei Schreibfehlern verlorengehen, was bei bildlichen Darstellungen

74 Pro und Kontra visuelle Programmierung 64 nicht geschehen kann. Zwei wesentliche Punkte werden bei dieser Argumentation ignoriert: (1) gut gewählte Namen haben einen hohen Bedeutungsgehalt und können dadurch gezielter Information über ein Objekt vermitteln als ein Bild oder eine unbenannte visuelle Verbindung. (2) Die indirekte Referenz von Objekten über Namen versetzt den Programmierer in die Lage, im jeweiligen Kontext irrelevante Objekte und Verbindungen mental auszublenden und bei Bedarf wieder einzublenden. Das visuelle Chaos in Bild 3-8 entsteht ja gerade dadurch, daß man»den Wald vor lauter Bäumen nicht mehr sieht«. Der Einwand, das Ein- und Ausblenden irrelevanter Informationen sei nur eine Frage technisch ausgereifter Interaktionsmechanismen ist unzutreffend, denn die Menge der Objekte und Beziehungen, die während einer Programmanalyse als relevant betrachtet werden, kann sich aufgrund komplexer Bedingungen so schnell ändern, daß jede Interaktion mit dem Computer den Gedankenfluß stört. Green und Petre [92] führten eine interessante Untersuchung zur Lesbarkeit von visuellen und textuellen Notationen durch. Sie verwendeten dazu logische Ausdrücke, die sie sowohl visuell in der Programmiersprache von LabVIEW als auch textuell in Form von Pseudocode notierten. Bild 3-9 zeigt ein einfaches Beispiel, wo für eine bestimmte Belegung der Eingangswerte Tired und Thirsty mit den booleschen Größen True oder False zu entscheiden ist, welche Werte die Ausgangsgrößen Sleep, Drink und Argue haben. Bild 3-8. Ein einfaches PARTS-Programm. Sayles et al. [94 S. 292, Abb. 9.36]

75 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 65 Sleep: if Tired Drink: if Tried & Thirsty Argue: if Tried & Thirsty LabVIEW-Programm Pseudocode Bild 3-9. Zwei äquivalente logische Ausdrücke als LabVIEW-Programm und in Pseudocode. Green und Petre [92 S. 13 u. 14] Zwei Gruppen von Versuchspersonen nahmen am Experiment teil. Gruppe 1 waren Programmierer, die LabVIEW mindestens sechs Monate lang eingesetzt hatten. Gruppe 2 waren erfahrene Programmierer und Designer von elektronischen Meßinstrumenten, die LabVIEW selbst nicht kannten, aber mit Techniken zur Komponentenverbindung wie sie in LabVIEW verwendet werden, bestens vertraut waren. Es soll hier weder auf die Ausführung noch auf die Teilresultate des Experiments genauer eingegangen werden, da die Untersuchung zu umfangreich war, um an dieser Stelle ausführlich behandelt zu werden. Interessant ist das Gesamtergebnis: Laut Aussage von Green und Petre besteht kein Zweifel daran, daß für den betrachteten Problemkreis grafische Darstellungen in jedem Fall schlechter lesbar sind als textuelle Notationen. Dies gilt auch für Personen, die große Erfahrung mit digitaler Schalttechnik und Gatterstrukturen besitzen und deshalb keine Schwierigkeiten mit der Notation von LabVIEW haben sollten, da LabVIEW gerade auf diesen Anwenderkreis zugeschnitten ist. Der Grund für das schlechte Abschneiden der grafischen Darstellung wird klar, wenn man Bild 3-10 betrachtet. Diese Grafik zeigt den langen Weg, den die Augen der Versuchspersonen zurücklegen mußten, damit sie bestimmen konnten, welche Ausgabegrößen True sind, wenn Tired = False und Thirsty = False gilt. Green und Petre beobachteten die Versuchspersonen bei der Problemlösung und leiteten aus den Suchmustern den im Bild dargestellten kognitiven Prozeß ab. Es ist offensichtlich, wie kompliziert das Verfahren ist, um die logische Verknüpfung auszuwerten. Vier Merkhilfen und vierzehn Einzelschritte sind zur Evaluation dieses kleinen Beispiels notwendig. Petre [95 S. 38; OZ 30] schildert die Schwierigkeiten, die auch Experten beim Lesen solcher Grafiken hatten: Der Anblick von Personen, die mit Maus oder Fingern über den Bildschirm»krabbelten«, wobei sie laut sprachen, um ihr Kurzzeitgedächtnis aktuell zu halten, war bemerkenswert. Einer der Unterschiede zwischen dem Verhalten von Experten und Anfängern war, daß die Experten ihre Finger besser einsetzten, manchmal auch alle zehn, um Punkte entlang eines Schaltkreises zu markieren. Die Auswertung des Pseudocodes aus Bild 3-9 ist hingegen äußerst einfach. Drei Schritte reichen aus, um zum Ergebnis zu gelangen:

76 Pro und Kontra visuelle Programmierung Erste Zeile: Tired ist False Zeile verwerfen. 2. Zweite Zeile: Tired ist True. Thirsty ist False. True & False gibt False Zeile verwerfen. 3. Dritte Zeile: Tired ist True. Thirsty ist True. True & True gibt True Ende mit Argue gleich True. Die Experimente von Green und Petre zeigen deutlich, daß nicht amateurpsychologische Überlegungen die Argumentationsgrundlage für visuelle Programmierung bilden dürfen, sondern daß in jedem Fall eine empirisch gestützte und wissenschaftlicher Systematik folgende Auseinandersetzung mit den Stärken und Schwächen grafischer Darstellungen notwendig ist. Fazit Die verständnisfördernde Wirkung von grafischen Darstellungen in der Programmierung ist am größten bei Entwurfskizzen und Diagrammen zur Systemarchitektur sowie in der Softwarevisualisierung. Durch gut gestaltete Bilder, informative Animationen, erläuterndem Text und angemessener Benutzerinteraktion kann ein weitaus höheres Verständnis für komplexe Zusammenhänge erzielt werden als dies auf reine textuelle Weise möglich ist. Voraussetzung ist allerdings, daß der Betrachter mit dem Kontext vertraut ist, in dem die Visualisierung stattfindet. Nur dann kann er den Bildelementen die richtige Bedeutung zuordnen. Die Darstellung von Programmcode in grafischer Form ist eher verständnishemmend als verständnisfördernd. Dies gilt insbesondere für Diagramme, wo Beziehungen zwischen einzelnen Elementen durch Linien dargestellt sind. In solchen Diagrammen führen komplexere Strukturen unausweichlich zu unentwirrbaren Liniengeflechten.

77 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung Nimm den ersten Wahrheitswert Tired = False. Suche Tired im Programm. 1. Propagiere False entlang der Linie nach rechts. Am Kreuzungspunkt angelangt, lege einen Finger auf die Verzweigung und merke den Wert False. Betrachte der Reihe nach jede mögliche Richtung. 2. Propagiere False nach rechts. Sleep ist False. Verwerfe den Zweig. 3. Kehre zum Finger zurück, der in Schritt 1 auf die Verzweigung gelegt wurde. Propagiere False nach unten. Bei Erreichen des Invertors transformiere True nach False. Bild Propagiere False weiter nach rechts. Am Kreuzungspunkt angelangt, lege einen Finger auf die Verzweigung und merke den Wert True. Betrachte der Reihe nach jede mögliche Richtung. 5. Propagiere True nach rechts. Bei Erreichen des Und-Gatters, lege einen Finger auf das Gatter und merke den Wert True auf der ersten Anschlußlinie. 6. Suche entlang der zweiten Anschlußlinie nach rückwärts bis Thirsty erreicht ist. Erkenne den Wert von Thirsty als False. 1. Kehre zum Finger zurück, der in Schritt 5 auf das Und-Gatter gelegt wurde. Auf der ersten Linie liegt True an, auf der zweiten False. 8. Das Gatter liefert False. Propagiere False nach rechts. Drink ist False. Verwerfe den Zweig. 1. Kehre zum Finger zurück, der in Schritt 4 auf die Verzweigung gelegt wurde. Propagiere True nach unten. Beim Erreichen des Und- Gatters, lege einen Finger auf das Gatter und merke den Wert True. 10. Suche entlang der zweiten Anschlußlinie nach rückwärts, bis der Invertor erreicht ist. 11. Suche weiter zurück, bis Thirsty erreicht ist. Dieser Wert ist False. 12. Gehe wieder nach vor. Bei Erreichen des Invertors transformiere False nach True. 13. Kehre zum Finger zurück, der in Schritt 9 auf das Und-Gatter gelegt wurde. Auf beiden Linien liegt True an. 14. Das Gatter liefert True. Ende mit Argue gleich True. Ein typisches Suchmuster bei der Auswertung des LabVIEW-Programms aus Bild 3-9. Vgl. Green und Petre [92 S. 13] Die Zahlen geben die Reihenfolge an, in der die einzelnen Segmente mit den Augen abgetastet wurden und korrespondieren mit den Schritten des beobachteten kognitiven Prozesses. Pfeile zeigen die Abtastrichtung. Der Stern markiert jene Punkte, wo ein Finger (mental oder physisch) als Merkhilfe plaziert wurde, um später dorthin zurückzukehren.

78 Pro und Kontra visuelle Programmierung These: Visuelle Programmierung ist leicht erlernbar Diese These beruht u.a. auf der Überlegung, daß bildliche Darstellung und direkte Manipulation von visuellen Objekten die spielerische Seite im Menschen ansprechen und deshalb für das Erlernen der Programmierung ein hohes Motivationspotential aufweisen. Zudem soll die leichte Verständlichkeit von visuellen Programmen, den Lernprozeß unterstützen. Zitate Kimura et al. [90; OZ 31] in Glinert [90-P&S S. 397]:»Durch das Prinzip der direkten Objektmanipulation akzeptieren Schulkindern ein grafisches Objekt eher als Text. Durch die direkte Manipulation von Werten in einer Datenflußsprache, statt durch die indirekte Manipulation der Werte über Variablen, wird aus demselben Grund der Lerneffekt verstärkt.«myers [94 S. 889; OZ 32]:»Die in diesem Aufsatz diskutierten Systeme zeigen, daß einige erfolgreiche Gebiete für visuelle Programmierung bisher folgendes einschließt: Unterstützung bei der Programmierausbildung (FPL, Pict, usw.) [...]«Shu [88 S. 9; OZ 33]:»Bilder können einen Anreiz schaffen, das Programmieren zu lernen.«tanimoto und Glinert [86; OZ 34] in Glinert [90-A&I S. 331]:»Zusätzlich zum Fehlen einer Theorie über die Verständlichkeit eines Systems gibt es wenige Studien darüber, wie ein Computer als Medium für linguistische Ausdrücke auf einer fundamentaleren Ebene dienen könnte, nämlich, wie die einfachsten Arten von Prädikation (Nebeneinanderstellung von Objekt und Aktion oder Objekt und Attribut) durch den Einsatz von Computergrafik und strukturierter Interaktion verbessert werden könnte. Grafische Mittel für solche Ausdrücke können ein wichtiger Teil des Lernprozesses für das Programmieren sein.«gegenthese Die Vermittlung effektiver Problemlösungsstrategien hat größeren Einfluß auf den Lernerfolg als die visuelle Darstellung von Programmkonstrukten. Begründung: Durch die Einweisung in geeignete Programmierprinzipien und -techniken wird auf die eigentliche Schwierigkeit beim Erlernen der Programmierung eingegangen, nämlich für ein gegebenes Problem eine korrekte, programmtechnische Lösung zu finden. Visuelle Programmiersprachen können dazu kaum einen besseren Beitrag leisten als verbale Programmiersprachen. Diskurs Viele visuelle Programmierumgebungen und Programmiersprachen sind mit dem Ziel entstanden, Kindern und Anfängern den Einstieg in die Programmierung zu erleichtern. Beispiele sind die Arbeiten von Glinert und Tanimoto [84], Finzer und Gould [84], Tanimoto und Runyan [86], Smith [87], Kimura et al. [90], Lieberman [93] und Halbert [93]. Eine ansprechende Benutzungsschnittstelle mit vertraut wirkenden Objekten und die Möglichkeit, diese Objekte direkt zu manipulieren, sind gute Voraussetzungen, um

79 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 69 Hemmungen abzubauen. Shu [88 S. 288] mißt bildhaften Sprachen einen bedeutend höheren pädagogischen Wert zu als textuellen Sprachen und geht damit mit anderen Autoren konform. Als ernstgemeintes Beispiel für Spaß und Spiel beim Erlernen einer Programmiersprache zeigt sie ein Programm in Mandala (siehe Bild 3-11). Um die These der leichten Erlernbarkeit zu überprüfen, soll hier nicht Ad-hoc- Programmierung betrachtet werden, sondern der seriöse Programmierunterricht als Beurteilungsgrundlage dienen. In diesem Zusammenhang ist das Ausbildungsziel maßgebend, denn hohes Motivationspotential alleine darf kein Grund sein, eine visuelle Programmiersprache zu wählen. Von einer sinnvollen Einführung in die Programmierung erwartet man, daß sie die Grundlagen für den Umgang mit komplexen Problemstellungen legt und die dazu notwendigen Konzepte, Prinzipien und Techniken vermittelt. Für das imperative Programmierparadigma, das bei der Ausbildung von Anfängern auch heute noch vorherrschend ist, gehören dazu elementare Datenstrukturen und Algorithmen, schrittweise Verfeinerung, guter Programmierstil und der Einsatz überschaubarer Programmbibliotheken. Die verwendete Programmiersprache soll diese Lehrinhalte unterstützen und möglichst einfach sein. Bilder können zwar helfen, gewisse Aspekte zu verdeutlichen, bringen aber auch Nachteile mit sich. Blaschek et al. [87 S. 21] meinen etwa, daß Flußdiagramme zwar die strukturellen Eigenschaften von Algorithmen gut zum Ausdruck bringen, jedoch bei undiszipliniertem Gebrauch unübersichtliche Strukturen entstehen. Gerade bei Programmieranfängern ist Disziplin jedoch eher selten anzutreffen. Die Verwendung grafischer Hilfsmittel, die einen großen Freiheitsgrad in der Programmgestaltung erlauben, kann daher in der Lernphase zur Fixierung eines schlechten Programmierstils führen. Dijkstra [89 S. 1403] lehnt Visualisierungen strikt ab, weil er dadurch das Abstraktionsvermögen gefährdet sieht. Ein Programm wie jenes in der Sprache Mandala aus Bild 3-11 würde ihn wohl am Verstand der Entwickler zweifeln lassen. Hoare äußerte sich in seiner Inaugurationsrede zum Thema»The mathematics of programming«an der Universität von Oxford ebenfalls skeptisch (siehe Bild 3-12). Er bezweifelt zwar nicht die Nützlichkeit von Bildern für die Vermittlung von Ideen, empfiehlt jedoch wie Dijkstra, sich besser auf die Mathematik zu verlassen. Das Hochgefühl, ohne viel Nachzudenken durch Kombination weniger Piktogramme in Minutenschnelle ein simples Programm erstellen zu können, kann tatsächlich trügerisch sein. Entscheidend ist, ob das Gelernte ausreicht, auch schwierigere Probleme zu meistern. Im Software-Engineering-Praktikum des Instituts für Wirtschaftsinformatik an der Universität Linz wurde beim Einsatz von VP-Systemen ein signifikanter Einbruch der Poblemlösungkapazität für komplexere Aufgaben beobachtet. Die Studenten sollten einfache Büroapplikationen programmieren. Dazu verwendete eine Gruppe die visuelle Sprache Serius und eine andere die verbale Sprache Smalltalk. Die Serius-Gruppe konnte in kurzer Zeit und ohne viel Mühe einen Prototypen bauen, während die Smalltalk- Gruppe noch mit den Sprachkonzepten und der Programmierumgebung kämpfte. Das Blatt wendete sich jedoch zu Gunsten der zweitgenannten Gruppe, als die Studenten gelernt hatten, die Möglichkeiten von Smalltalk zu nutzen. Ab diesem Zeitpunkt war die Smalltalk-Gruppe der Serius-Gruppe weitaus überlegen. Sie konnte alle funktionalen Anforderungen erfüllen und schnell und flexibel auf Änderungswünsche reagieren. Die Serius-Gruppe hingegen kam über die erste prototypische Implementierung kaum hin-

80 Pro und Kontra visuelle Programmierung 70 aus und mußte frustriert feststellen, daß die Konzepte von Serius, die anfänglich so überzeugend und motivierend wirkten, bei weitem nicht ausreichten, um ein taugliches Programm zu schreiben. Dazu der Kommentar eines Praktikumsteilnehmers, der beide Programmierumgebungen einsetzte: Serius ist eine jener Sprachen, bei der man mit sehr geringem Aufwand relativ gute bzw. sichtbare Erfolge erzielen kann, allerdings ist jede weitere Verbesserung umso schwieriger. Diesem schnellen Erfolgserlebnis war auch ich aufgelaufen, wodurch meine erste Version des Taschenrechners nur schwer erweiterbar war, da ich auch nicht annahm, daß Erweiterungen geplant waren. Den größten Rückschlag erlitt ich, als ich eine Funktion von Smalltalk nach Serius übertragen wollte. Nach stundenlanger Arbeit mußte ich einsehen, daß dies fast unmöglich war, da ich für eine einzige Smalltalk-Zeile (Zuweisung mit indizierten Feldern) ca. zehn Serius-Funktionen verwenden mußte, was durch die geringe Bildschirmgröße noch zusätzlich verschlimmert wurde. Am meisten stört mich im Vergleich zu Smalltalk, daß es nicht möglich ist, sich in derselben Programmiersprache Funktionen selbst zu erstellen. Das in Bild 3-13 dargestellte Programm belegt, daß nicht Unvermögen der Studenten die Bewältigung komplexerer Problemstellungen verhinderte, sondern daß die fehlenden Strukturierungsmöglichen die Bemühungen scheitern ließen, bei der Programmkonstruktion nach den Prinzipien des Software Engineerings vorzugehen. Das Bild zeigt einen Teil einer simplen Patientenverwaltung und ist den Beispielen entnommen, die beim Kauf von Serius mitgeliefert werden. Man erkennt leicht, daß Serius strukturierte Programmierung nicht unterstützt und deshalb schon bei kleinen Programmen der Überblick rasch verlorengeht. Bei der Frage nach dem Stellenwert visueller Programmiersprachen in der Lehre darf auch die Vorbildung von Programmieranfängern nicht vergessen werden. Eine Ausbildung in formalen Methoden hat vermutlich einen größeren Einfluß auf den Lernerfolg als eine visuelle Programmiersprache jemals haben kann. Veer et al. [86 S. 86] stellten in einem Experiment fest, daß Anfänger ohne mathematische Erfahrungen eine Programmiersprache niemals so schnell lernen, wie Anfänger mit mathematischem Hintergrund, auch wenn die Programmiersprache grafische Elemente enthält. Die Schulung in systematischer Problemlösung scheint deshalb ein Schlüsselfaktor in der Programmierausbildung zu sein. Fazit Es ist richtig, daß visuelle Programmiersprachen durch Piktogramme und interaktive Manipulation motivierend auf Anfänger wirken, weil sie syntaktische Aspekte zurückdrängen und einen spielerischen Umgang mit den Sprachkonstrukten erlauben. Der anfängliche Enthusiasmus für visuelle Programmiersprachen schlägt jedoch rasch in Frustration um, wenn geeignete Sprachkonzepte zur Bewältigung komplexer Problemstellungen fehlen oder umständliche Interaktionsmechanismen das schnelle Editieren größerer Programme verhindern. Solche Mängel erzwingen den Umstieg auf eine andere, meist textuelle Sprache, wodurch ein guter Teil des Lernaufwandes umsonst war.

81 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 71 Bild Ein visuelles Programm in der Sprache Mandala; Farbbild im Anhang. Shu [88 S. 11, Abb. 1-6] Zitat aus Spektrum der Wissenschaft, November 11/1984, S. 2, wo dieses Bild am Titelblatt zu sehen ist:»die Graphik von Jerome Kuhl verdeutlicht nicht nur das Thema dieses Heftes, sondern ist selbst Computer-Software: ein Programm in der mit Bildern arbeitenden Programmiersprache MANDALA, die derzeit von Jaron Z. Lanier und seinen Mitarbeitern bei VPL Research in Palo Alto (Kalifornien) entwickelt wird. Im Beispiel hüpft oben ein Känguruh von einem dreifachen Violinschlüssel, der ein Programm zum Spielen dreistimmiger Kanons aktiviert, über ein Bildsymbol, das erlaubt, Musik in der traditionellen Notenschreibweise zu lesen, zu einem Eiswürfel, an dem die Sprungfolge»eingefroren«wird, so daß sie sich später durch ein einzelnes Symbol aufrufen läßt. Jedes Bildsymbol kann eine Hierarchie von Unterprogrammen einschließen. So»erweitert sich«der Dreier-Violinschlüssel zu der darunter stehenden kreisförmigen Schleife. Beim Durchlaufen der Schleife werden (in Abständen von vier Takten) die drei eingezeichneten Vögel ausgesandt. Rechts von der Schleife ist die in jedem Vogel enthaltene Folge von Instruktionen dargestellt. Wenn ein die Notenlinien entlangfliegender Vogel auf eine Note trifft, läßt er sie erklingen; vom Ende des Notensystems kehrt er zum Anfang zurück. Auch den Kanon selbst hat Lanier mit MANDALA komponiert«.

82 Pro und Kontra visuelle Programmierung 72 b x y Bild Bedingte Verzweigung als Steuerflußdiagramm. Hoare und Jones [89 S. 358] Zitat aus Hoare und Jones [89 S. 357 f]:»[the figure] shows a picture of the conditional as a structured flow chart. Such pictures actually inhibit the use of mathematics in programming, and I do not approve of them. They may be useful in first presenting a new idea, and in committing it to memory. Their rôle is similar to that of the picture of an apple or a zebra in a child s alphabet book. But excessive reliance on pictures continued into later life would not be regarded as a good qualification for one seeking a career as a professional author. It is equally inappropriate for a professional programmer. Confucius is often quoted as saying that a picture is worth ten thousand words so please never draw one that isn t.«bild Ausschnitt aus einer Serius-Anwendung.

83 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung These: Visuelle Programmierung überwindet Sprachbarrieren Diese These beruht auf der Überlegung, daß gebräuchliche Piktogramme international verständlich sind und daß deshalb auch visuelle Programme ohne großen Übersetzungsaufwand über Sprachgrenzen hinweg austauschbar sein müßten. Zitate Kahn und Saraswat [90 S. 8; OZ 35]:»Wenn man die Abhängigkeit von Text aufgibt, werden Schwierigkeiten beim Transfer von Quellprogrammen zwischen Personen, die verschiedene Sprachen sprechen, signifikant reduziert. Nur Zeichenketten und Kommentare sind noch zu übersetzen.«shu [88 S. 9; OZ 36]:»Bilder bilden keine Sprachbarrieren. Wenn sie ordentlich entworfen sind, werden sie von Menschen unabhängig davon verstanden, welche Sprache die Menschen sprechen.«suleiman und Citrin [92 S. 143; OZ 37]:»Die Verwendung von Bildern ist eine attraktive Lösung für das Problem, eine Präsentation für Programmstrukturen zu finden, die unabhängig ist von natürlichen Sprachen. Piktogramme werden in einer Vielzahl von Situationen verwendet, um die internationale Kommunikation zu erleichtern (man denke an Flughäfen und Bahnhöfe), und einige Forscher auf dem Gebiet der visuellen Sprachen haben erwähnt, daß visuelle Repräsentationen von Programmen potentiell unabhängig davon verständlich sind, welche Sprache man spricht, obwohl es scheint, daß wenig getan wurde, um diese Behauptungen zu verifizieren.«tanimoto und Glinert [86; OZ 38] in Glinert [90-A&I S. 330]:»Zusätzlich zum Wunsch, die Programmierung einer breiteren Personenschicht zugänglich zu machen als dies derzeit der Fall ist, könnte ein grafisches Programmiersystem auch als Medium für den internationalen Austausch von Programmen dienen. Konventionelle Sprachen, die auf Text beruhen, sind auf die Verwendung von Schlüsselworten beschränkt, deren Ursprünge in einer bestimmten gesprochenen Sprache liegen, meist im Englischen.«Gegenthese Eine international verständliche Bildersprache für die Programmierung allgemeiner Softwaresysteme kann es nicht geben. Begründung: Die natürliche Sprache mit ihren differenzierten Ausdrucksmöglichkeiten ist in der Programmierung unverzichtbar, um Dinge zu benennen und Lösungsideen zu vermitteln. Es ist ausgeschlossen, daß grafische Darstellungen in einem offenen Begriffsraum, wie ihn die Programmierung von Softwaresystemen umfaßt, jemals den gleichen Standardisierungsgrad und die gleiche Aussagekraft wie die Wörter einer natürlichen Sprache erreichen können. Diskurs Shu [88 S. 9] versucht ihre These mit Hilfe des Beispiels»Verkehrszeichen«zu stützen, die überall auf der Welt verstanden würden. Es stimmt, daß unter den autofahrenden Nationen sich sowohl die Verkehrssituationen als auch die Verkehrszeichen ähneln und letztere deshalb über Sprachgrenzen hinweg (meist) evident sind. Unklar ist hingegen der Zusammenhang mit den Kommunikationsbedürfnissen in der Programmierung.

84 Pro und Kontra visuelle Programmierung 74 Die Analogie zwischen Verkehrszeichen und Programmkonstrukten gilt bestenfalls für die Schlüsselworte einer Programmiersprache, die ein begrenztes Vokabular mit einer genau definierten Bedeutung umfassen. Internationale Anstrengungen vorausgesetzt, könnte man eindeutige Piktogramme für die gängigsten Schlüsselworte finden, so daß diese unabhängig von den nationalen Sprachen ein genormtes Erscheinungsbild hätten. Wozu aber solche Bemühungen? Die Herausforderung bei der Entwicklung von Programmen liegt ja nicht im Verstehen der Sprachkonstrukte, sondern in der Bewältigung der Komplexität der Programmbausteine. Das begrenzte Vokabular der englischen Schlüsselworte if, then, else usw. richtig in die eigene Sprache zu übersetzen, hat wohl noch jeder Softwareentwickler geschafft, und wer dazu nicht in der Lage ist, wird auch niemals ein Programm schreiben können. Ungleich schwieriger als das Verstehen von Schlüsselworten ist die aussagekräftige Benennung von Programmeinheiten wie Variablen, Prozeduren und Modulen. Professionelle Programmierer legen hohen Wert darauf, sprechende Namen zu vergeben, weil sie wissen, daß davon in hohem Maß das Programmverständnis abhängt. Dies hat selbstverständlich in einer lebenden Sprache zu geschehen, da nur auf diese Weise ein ausreichender Bedeutungsgehalt gewährleistet ist. Kahn und Saraswat [90 S. 8] ignorieren diese Tatsache, wenn sie meinen, daß man Namen vermeiden sollte und Programmcode durch die Minimierung von Text leichter zwischen verschiedenen Sprachgemeinschaften transferierbar ist (siehe Bild 3-14). Auf technischer Ebene stimmt das zwar man braucht kaum etwas zu übersetzen, aber es ist fraglich, ob der eingesparte Übersetzungsaufwand den erhöhten Verständnisaufwand ausgleicht. Zudem programmieren vermutlich sehr viele Programmierer in Englisch, auch wenn ihre Muttersprache nicht Englisch ist, und der Austausch von Programmcode über Sprachgrenzen hinweg sollte deshalb ohnehin kein essentielles Problem sein. Zur Illustration der Aussagekraft von Piktogrammen möge sich der Leser fragen was dieses (wohldurchdachte) LabVIEW-Symbol bedeutet: Das Symbol repräsentiert die Funktion Substring(string,offset,length). Jeder Programmierer wird nun wissen, welche Bedeutung dem Piktogramm zugrundeliegt. Dazu ein weiteres Beispiel: vermutlich wäre es sehr schwierig, mit einer komplexen Applikation (etwa einem Textverarbeitungsprogramm) zurechtzukommen, wenn alle Befehle ausschließlich als Piktogramme dargestellt sind. Selten gebrauchte Befehle sind textuell dargestellt gewiß besser verständlich als Piktogramme. Wer auch nur ein wenig Englisch versteht, dem wird der Menüeintrag»Insert Page Break«mehr sagen, als das Symbol. Ware [93 S. 92] bringt als grundsätzliches Argument gegen die These der kulturell übergreifenden Verständlichkeit von Bildern vor, daß Symbole mit Konventionen verbunden und im sozialen Kontext zu interpretieren sind. Was in einem bestimmten Umfeld klare Bedeutung hat, kann anderswo auf Unverständnis stoßen. Horton [94 S. 241 ff] zeigt anhand etlicher Beispiele, wie schwierig die Suche nach aussagekräftigen Piktogrammen sein kann, die für unterschiedliche Kulturkreise gedacht sind. Beispielsweise bedeutet eine Hand mit gekrümmtem Daumen und Zeigefinger vielerorts»ja paßt genau«. In Frankreich hingegen ist diese Geste ein Zeichen für Wertlosigkeit, in Japan ist Geld damit gemeint und in Südamerika ist dieses Fingerzeichen eine grobe

85 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 75 Beleidigung. Als Interaktionssymbol etwa für den erfolgreichen Abschluß einer Operation sollte das Piktogramm demnach vermieden werden. Fazit Den gesamten Begriffsraum der Programmierung in Bildern zu fassen ist unmöglich. Ein Bilder-Esparanto würde unüberwindliche Kommunikationsbarrieren errichten, die jede Verständigung zum Erliegen brächten. Nur in einem eng begrenzten Umfeld können Bilder unterstützt durch verbale Beschreibung die Wiedererkennung von Programmkomponenten erleichtern.

86 Pro und Kontra visuelle Programmierung 76 Bild Ist internationale Verständlichkeit in der Programmierung durch Verzicht auf Text erreichbar? Diagramm aus Pictorial Janus. Kahn et al. [91 S. 6, Abb. 3] Zitat [S. 5 f]:»[die Abbildung] zeigt eine Beispielkonfiguration mit einem Agenten append, dessen linker unterer Anschluß mit einer Liste verknüpft ist. Er besitzt zwei Regeln, die sein Verhalten definieren. Die obere Regel beschreibt das Verketten einer leeren Liste mit einer beliebigen anderen Liste. Die Vorbedingungen dieser Regel bestehen aus einer leeren Liste, die mit dem linken unteren Anschluß, und einem Senderecht, das mit dem rechten Anschluß verbunden sein muß. Der linke obere Anschluß ist leer und gestattet somit den Anschluß einer beliebigen Liste. Als Ergebnis wird die am linken oberen Anschluß anliegende Liste mit dem am rechten Anschluß anliegenden Senderecht verknüpft. Die untere Regel innerhalb des Agenten beschreibt den (rekursiven) Fall, daß an das Ende einer nicht-leeren Liste eine andere Liste angehängt werden soll. Die Vorbedingung unterscheidet sich von der ersten Regel nur dadurch, daß am linken unteren Anschluß eine nicht-leere Liste (im weiteren als Eingangsliste bezeichnet) verlangt wird. Der Rumpf dieser Regel besteht aus einem rekursiven Aufruf von append, der durch die Verwendung eines Aufrufpfeils spezifiziert ist. Die Eingangsdaten des linken oberen Anschlusses sowie der Rest der Eingangsliste werden dabei unverändert weitergegeben. Der Regelrumpf erzeugt weiterhin ein neues Listenelement, dessen Kopf aus dem Kopf der Eingangsliste besteht. Für den Rest des neuen Listenelements wird ein Senderecht erzeugt und mit dem rechten Anschluß des rekursiven Aufrufs verknüpft. Das neue Listenelement wird über seinen internen Anschluß mit dem am rechten Anschluß der Regel anliegenden Senderecht verbunden. «Alles klar?

87 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung These: Visuelle Programmierung heißt optimale Kognition Diese These beruht auf der Überlegung, daß bei verbaler Programmierung beinahe ausschließlich die linke Gehirnhälfte zum Einsatz kommt, während die rechte Gehirnhälfte mit ihren leistungsstarken Mechanismen zur Verarbeitung bildlicher Informationen weitgehend brachliegt. Durch visuelle Programmierung würden sowohl die hohen Transferraten des visuellen Wahrnehmungskanals bestmöglich genutzt als auch die Verarbeitung der erfaßten Informationen beschleunigt. Zudem hat das Auge direkten Zugriff auf alle Teile einer Grafik und kann ein visuelles Objekt ganzheitlich erfassen, was bei Text nicht möglich ist. Kognitionspsychologische Untersuchungen zeigen außerdem, daß man Bilder besonders leicht im Gedächtnis behält. Zitate Glinert [90 S. 148; OZ 39]:»Es gibt verschiedene Gründe, warum die Annahme berechtigt ist, daß Bilder für die Mensch-Maschine-Kommunikation gut sein können. [...] Bilder werden oft leicht gelernt und als Chunks [wörtlich: Bündel] von Informationen abgerufen, wie Psychologen das nennen.«hiebl [94 S. 12]:»Die vielzitierte Redewendung ein Bild sagt mehr als tausend Worte darf nicht als bloße Floskel angesehen werden. Einzelne Psychologen schätzen, daß durch den Einsatz von Grafik die Mensch-Maschine-Kommunikation bis zu einhunderttausendmal effektiver gestaltet werden kann als bei verbaler Interaktion.«Raeder [85 S. 12; OZ 40]:»Unsere Augen ermöglichen einen unmittelbaren und direkten Zugriff auf jeden Teil eines Bildes sowie Detail- und Überblicksansichten. [...] Ein Vergleich von Bildern und Text macht klar, daß Bilder allgemein schneller Informationen vermitteln als Text: sowohl Zugriff als auch Dekodierung sind effizienter. Man denke daran, daß die Sensorik des Menschen für Echtzeit-Bildverarbeitung eingerichtet ist. Die Verarbeitung von Text ist ein viel jüngeres Phänomen.«Shu [88 S. 1 und S. 7; OZ 41]:»Für das Interesse an visueller Programmierung wurden mehrere Gründe genannt. Viele betreffen die bessere Nutzung der rechten Gehirnhälfte, die bei der Verwendung des Computers unnötigerweise ruht und [daher] unterbeschäftigt ist. [...]. Bilder unterstützen das Verstehen und Erinnern.«Staufer [87 S. 70]:»Bilder werden nicht nur leichter wiedererkannt, sondern der Inhalt von Bildern wird auch besser gespeichert als der von verbalen Beschreibungen. [...] Die bessere Gedächtnisleistung bei Bildern ergibt sich als äußerst zuverlässiges Phänomen unter den verschiedensten Bedingungen. Es ist wahrscheinlich, daß vor allem in quantitätsmäßiger Beziehung Piktogramme bezüglich ihrer Merkleistung verbalen Bezeichnungen überlegen sind.«tanimoto und Glinert [84; OZ 42] in Glinert [90-P&S S. 268]:»[...] Die menschlichen Funktionen zur Bildspeicherung und Bildverarbeitung sind mächtige parallele Prozessoren. [...] Bilder könnten eine hohe Bandbreite in der Mensch-Maschine- Kommunikation bereitstellen.«gegenthese Die Nachteile visueller Programme eliminieren die Vorteile der besseren Nutzung des Wahrnehmungssystems durch bildliche Darstellungen.

88 Pro und Kontra visuelle Programmierung 78 Begründung: Hohe Transferraten für visuelle Informationen sind deshalb unerheblich, weil nicht der Übertragungskanal, sondern die Bedeutungsanalyse den Flaschenhals bei der kognitiven Verarbeitung eines Programms bildet. Der Diskurs zur zweiten These zeigt, daß visuelle Programme oft schwer verständlich sind. Direkter Zugriff auf einzelne Bildteile ist nur dann von Vorteil, wenn die grafische Darstellung eines Programms eine dichte und klar erkennbare Struktur aufweist. Das ist oft nicht der Fall, wie viele Beispiele in diesem Buch zeigen. Die gute Merkfähigkeit für Bilder spielt in der Softwareentwicklung eine nebengeordnete Rolle, weil Merkfähigkeit mit Interpretierbarkeit verknüpft ist. Die Softwareentwicklung hat meist mit der Bewältigung komplexer Sachverhalte zu tun, die nur mit komplexen Grafiken eindeutig beschreibbar sind. Dies gilt insbesondere für Programmcode. Wie die Ausführungen hinsichtlich der Verständlichkeit von visuellen Programmen zeigten, ist grafischer Programmcode oft nur mit Mühe interpretierbar und damit auch nur sehr schwer im Gedächtnis zu behalten. Diskurs Reader nimmt auf die menschliche Entwicklungsgeschichte Bezug, die wie er sinngemäß meint den Menschen seit Urzeiten auf Bildverarbeitung mit Echtzeitanforderungen trainiert hat, während Textverarbeitung eine weit jüngere Fähigkeit ist. Was die Fähigkeit, auf visuelle Reize rasch zu reagieren, mit Programmierung zu tun hat, legt Reader allerdings nicht überzeugend dar. Ebenfalls weit hergeholt sind von Hiebl zitierte Berechnungen, die zeigen sollen, daß Grafik die Mensch-Maschine-Kommunikation bis zu Mal effektiver machen kann als verbale Interaktion. In diesen Kalkulationen wird die Bandbreite des menschlichen Wahrnehmungskanals für bildliche Daten mit 40 Mbit/s angesetzt und mit jener des Kanals für geschriebene Daten von 400 Bit/s verglichen. Die Nutzlosigkeit solcher Vergleiche liegt auf der Hand, da nichts darüber ausgesagt ist, wieviel Zeit benötigt wird, um den übertragenen Daten die für die jeweilige Aufgabe relevanten Informationen zu entnehmen. Dies gibt auch Hiebl zu bedenken, der dem Zahlenspiel skeptisch gegenübersteht. Ein weiteres Argument in diesem Zusammenhang ist der direkte Zugriff des Auges auf einzelne Teile eines grafischen Programms. Doch auch dieses Argument hat Schwächen. Das Auge kann Beziehungen von Programmkomponenten nur dann durch Hinund Herspringen zwischen einzelnen Programmteilen rasch erfassen, wenn Struktur und Bedeutung eines Programms klar sind und eine übersichtliche Darstellung existiert. Leider sind grafische Programme meist schlechter strukturiert als Text, wie viele Beispiele in den vorigen Abschnitten zeigen. Dies hat zur Folge, daß der vermeintlich effiziente, weil direkte Zugriff, zu einem orientierungslosen Abtasten des Bildes nach zusammengehörenden Teilen führt. Zudem weisen Grafiken eine geringe Darstellungsdichte als Text auf. Ist eine Grafik größer als ein Bildschirmfenster, was auch für kleine Programmstücke schnell der Fall sein kann, dann muß sie entweder in Teilgrafiken zerlegt werden oder ist nur ausschnittsweise darstellbar. Im ersten Fall kann sich der Betrachter nur durch ständigen Wechsel zwischen den Teilgrafiken einen Überblick verschaffen, im zweiten Fall ist ein mühsames Verschieben des Bildschirmausschnitts in meist zwei Dimensionen notwendig. Dadurch sinkt die Lesegeschwindigkeit drastisch (siehe Bild 3-15). Hingegen erlaubt gut strukturierter Text durch gestaltende Mittel wie Überschriften, Absätze, Einrückungen und Fettschrift ebenfalls direkten Zugriff auf einzelne Programmbereiche und kann zusätzlich wegen der linearen Anordnung sehr schnell durchgeblättert und gelesen werden. Darüber hinaus unterstützt Text besonders gut Vergleiche auf Ähnlichkeit, wie sie in der Programmierung häufig notwendig sind.

89 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 79 In einer von Petre [95 S. 40] zitierten Studie griffen Programmierer immer zur textuellen Repräsentation und ignorieren die ebenfalls verfügbare grafische Darstellung, wenn es darum ging, die strukturellen Gemeinsamkeiten von Programmen herauszufinden. Wer jemals ein Suchbildrätsel gelöst hat (entdecke die acht Unterschiede), weiß warum. Manchmal wird auch die hohe Kapazität des visuellen Gedächtnisses als Argument für visuelle Programmierung ins Treffen geführt. Tatsächlich ist die Merkfähigkeit für Bilder beachtlich. Anderson [89 S. 106] berichtet von einem Experiment, bei dem Versuchspersonen zehntausend unterschiedliche Bilder gezeigt wurden. In einem zweiten Durchlauf wurden diese Bilder paarweise zusammen mit neuen Bildern vorgelegt, und die Personen mußten entscheiden, welches Bild sie bereits gesehen hatten. Die Quote der richtig erkannten Bilder lag bei 73 %. Bei der Aufnahme bildlicher Information bleiben jedoch visuelle Einzelheiten oder räumliche Beziehungen von Bildelementen kaum im Erinnerung. Statt der bildlichen Darstellung prägt sich eine abstrakte Repräsentation der Bedeutung des Bildes ein, deren Codierung durchaus alle visuellen Attribute verloren haben kann [S. 109]. Nicht interpretierbare Bilder kann man sich deshalb ebenso schlecht merken wie nicht interpretierbare verbale Information. Als Beispiel zeigt Anderson ein Bild, das auf den ersten Blick nur aus Klecksen zu bestehen scheint und das man deshalb schnell vergißt (siehe Bild 3-16). Erst wenn man bei genauerem Hinsehen den Dalmatiner-Hund erkennt, setzt das Erinnerungsvermögen ein. Der Leser möge die Probe aufs Exempel machen und versuchen das LabVIEW Programm aus Bild 3-17 zu memorieren. In Bezug auf die Programmlogik ist die geometrische Struktur der Darstellung unwichtig. Relevant sind ausschließlich die topologische Struktur und die Ausprägung der Symbole. Es fällt jedoch sehr schwer, zugunsten einer effizienten Speicherung die geometrische Struktur zu ignorieren und lediglich Information darüber im Gedächtnis zu behalten, welche Objekte die Darstellung umfaßt, welche miteinander verbunden und welche ineinander enthalten sind. Der äquivalente Programmtext ist viel leichter zu merken, weil es zu keiner visuellen Überladung kommt, wie sie bei dieser Darstellung auftritt. Fazit In der Softwareentwicklung sind die Anforderungen an das Gedächtnis weit gestreut. Zu den Dingen, die ein Programmierer im Kopf behalten muß, gehören u.a. der Aufbau und die Funktionalität des Programms, typische Programm- und Datenstrukturen, Entwurfs- und Codierstrategien, Syntax und Semantik von Programmiersprachen, die Bedienung der Werkzeuge sowie Datei- und Verzeichnisnamen. Nur weniges aus diesen Bereichen läßt sich durch einprägsame Bilder darstellen. Zu den erfolgversprechendsten Visualisierungen gehören Bilder der Systemarchitektur, Entwurfsskizzen und Datenstrukturdiagramme. Die Wirksamkeit von visuellem Programmcode ist hinsichtlich des Erinnerungsvermögens als gering einzuschätzen. Dies läßt sich aus dem zuvor genannten Zusammenhang von Bedeutungsgehalt und Gedächtnisleistung ableiten, der es äußerst zweifelhaft erscheinen läßt, daß bildliche Darstellungen von Programmen besser behalten werden als textuelle Repräsentationen. Die Bedeutung eines Programms anhand einer bildlichen Repräsentation auf einen Blick zu erfassen und zu merken ist wohl unmöglich, da sich die Semantik aus vielen Details ergibt. Wie Anderson zeigt, werden gerade solche Details aber sehr schnell vergessen.

90 Pro und Kontra visuelle Programmierung 80 Bild Sechs Fenster für eine Funktion Mischsortieren in Prograph. Bild Bedeutung und Erinnerung: Ein schnüffelnder Hund (nach Ronald James). Anderson [89 S. 107, Abb. 5.2]

91 3.4 Reflexionen über fünf Thesen zur visuellen Programmierung 81 Bild Kann man sich dieses LabVIEW-Programm leicht merken?

92 4. Klassifikationen für visuelle Programmierung In der Vergangenheit wurden mehrere Versuche zur systematischen Erfassung visueller Programmiersprachen und Programmierumgebungen unternommen. Das Studium dieser Arbeiten zeigt, daß die Autoren sehr unterschiedliche Aspekte als Grundlage für ihre Klassifikationen heranziehen. Das Spektrum reicht von Einteilungen anhand allgemeiner Merkmale, wie»die Art, in der Benutzer den Computer programmieren«(vgl. Glinert [90 S. 146]) bis hin zu Übersichten, die ganz spezielle Anwendungsbereiche umfassen, etwa Multimediawerkzeuge und intelligente Zeichenprogramme (vgl. Poswig [96 S. 6]). In den folgenden Abschnitten werden drei geläufige und häufig zitierte Taxonomien von Shu, Chang und Myers vorgestellt, die auf Arbeiten Ende der 80er Jahre zurückgehen. Zudem wird ein Klassifikationsschema von Burnett und Baker aus dem Jahr 1994 präsentiert, das zwar noch keine weite Verbreitung gefunden hat, aber neuere Entwicklungen berücksichtigt und Schwachpunkte der anderen Taxonomien vermeidet. Manche Klassifikationen enthalten Rubriken, die nicht zu visueller Programmierung im Sinne der definierten Terminologie passen. Ein Beispiel dafür ist die Rubrik»Visualisierung von Daten oder Informationen über Daten«der Klassifikation von Shu, die strenggenommen nichts mit visueller Programmierung zu hat. Darauf wird im Einzelfall hingewiesen. Auf eine detaillierte Bewertung der Nützlichkeit des jeweiligen Klassifikationsschemas wird verzichtet, da dazu der Kontext der Klassifikation berücksichtigt werden müßte, was aus Platzgründen nicht möglich ist. Nur vereinzelt werden Vor- und Nachteile angesprochen. Der eilige Leser kann die ersten Abschnitte dieses Kapitel überspringen, und sich Abschnitt 4.4, S. 95, zuwenden, der als Grundlage für die Einordnung von Programmierkonzepten in Kapitel 5 dient. 4.1 Klassifikation nach Shu Shu [88 S. 12] unterscheidet zwei Hauptbereiche: visuelle Umgebungen und visuelle Sprachen. Der Bereich visuelle Umgebungen umfaßt Werkzeuge zur Datenvisualisierung, zur Softwarevisualisierung und für visuelles Instruieren. Der Bereich visuelle Sprachen umfaßt Sprachen zur Bearbeitung visueller Information, zur Unterstützung visuelle Interaktion und visuelle Programmiersprachen. Bild 4-1 zeigt den Klassifikationsrahmen von Shu. Für die Charakterisierung visueller Programmiersprachen bedient sich Shu [88 S. 139 ff] eines selbstentwickelten Koordinatensystems, das die Aspekte Niveau, Anwendungsbereich und Visualisierungsgrad einer Programmiersprache auf drei Achsen darstellt (siehe Bild 4-2). Das Zustandekommen der Ausprägung der einzelnen Aspekte ist leider nicht immer klar, was umso schwerer wiegt, da sich bei Shu kein Hinweis darauf findet, wie die einzelnen Aspekte zu messen wären. Sprachprofile, die mit Shus Koordinatensystem erstellt werden, sind deshalb nicht als Basis für aussagekräftige Sprachvergleiche geeignet, sondern können bestenfalls ein grober Anhaltspunkt sein, um die wesentlichen Merkmale einer visuellen Programmiersprache einzuschätzen.

93 4.1 Klassifikation nach Shu Kategorien Im folgenden werden die einzelnen Kategorien der Klassifikation von Shu erläutert. Abschnitt 4.1.2, S. 86, enthält Tabellen mit Systemen und Sprachen, die Shu als Beispiele für die jeweilige Kategorie nennt. Visualisierung von Daten oder Informationen über Daten Shu gliedert Systeme für die Visualisierung von Daten oder Informationen über Daten in zwei Teilbereiche; räumliche Datenverwaltungssysteme und Visualisierung von Datenstrukturen. Räumliche Datenverwaltungssysteme (spatial data management systems, SDMS) repräsentieren Daten und Beziehung zwischen Daten in mehrdimensionaler, visueller Form. Der Benutzer kann die benötigten Informationen durch Navigation im grafischen Datenraum abrufen, ohne genau spezifizieren zu müssen, was er sucht, und ohne den genauen Speicherplatz zu kennen. Die Visualisierung von Datenstrukturen umfaßt laut Shu sowohl die Darstellung softwaretechnischer Datenstrukturen, wie Felder, Verbunde und Listen, als auch die Visualisierung von Datenbankschemata. Diese Kategorie bildet somit hinsichtlich der Darstellung von Datenstrukturen einen Teilbereich der in Abschnitt 2.1.5, S. 30, diskutierten Softwarevisualisierung. Visualisierung von Programmen und Programmausführung Shu [88 S. 13] vertritt die Meinung, daß in diese Kategorie nur solche Systeme fallen, die Programme visualisieren, die in herkömmlichen Programmiersprachen geschrieben sind, und schließt damit die Visualisierung von Programmen auf Basis visueller Programmiersprachen aus. Eine solche Einschränkung ist nach Meinung des Verfassers nicht notwendig. Shu verfeinert diese Kategorie hinsichtlich der Aspekte Pretty Printing, Visualisierung mit Diagrammen, Mehrfachsichten eines Programmes und Algorithmenanimation. Diese Kategorie bildet ebenfalls einen Teilbereich der Softwarevisualisierung. Visualisierung von Softwaredesign Shu ordnet in diese Kategorie grafische Softwareentwicklungsumgebungen ein, die den gesamten Softwarelebenszyklus von der Planung bis zur Wartung unterstützen. Diese Kategorie umfaßt also nicht nur Werkzeuge für die Entwurfsphase, sondern auch Systeme für die grafische Darstellung von Anforderungen, Spezifikationen, Systemarchitekturen usw.

94 Klassifikationen für visuelle Programmierung 84 Visuelle Programmierung Visualisierung von Visuelle Umgebungen Visuelles Instruieren (Visual Coaching) Bearbeitung visueller Information Visuelle Sprachen zur Unterstützung visueller Interaktion Programmierung mit visuellen Ausdrücken basierend auf Daten oder Informationen über Daten Programmen und/oder Programmausführung Softwaredesign Diagrammen Piktogrammen Formularen Bild 4-1. Klassifikation der visuellen Programmierung nach Shu. Shu [88 S. 12] Visualisierungsgrad hoch niedrig Anwendungsbereich niedrig spezifisch allgemein hoch Niveau Bild 4-2. Drei Aspekte von Programmiersprachen nach Shu. Shu [88 S. 140] Das Niveau einer Programmiersprache (language level) ist ein Maß für die Ausdruckskraft einer Programmiersprache. Das Sprachniveau verhält sich invers zum Formulierungsaufwand, d.h. eine Programmiersprache ist umso mächtiger und liegt damit auf einem umso höheren Niveau, je weniger Einzelheiten angegeben werden müssen, um eine Problemlösung zu implementieren. Der Anwendungsbereich (scope) ist ein Maß für die Generalität einer Programmiersprache. Der Anwendungsbereich ist umso allgemeiner, je mehr Problembereiche durch eine Programmiersprache erfaßt werden. Anwendungsbereich und Niveau einer Programmiersprache sind gegenläufig. Das Niveau einer Programmiersprache ist meist umso höher, je spezifischer der Anwendungsbereich ist, und umso niedriger, je allgemeiner die Sprache einsetzbar ist. Der Visualisierungsgrad (visual extent) ist ein Maß für die Anzahl visueller (grafischer) Konstrukte einer Programmiersprache. Je mehr Sprachelemente eine visuelle Ausprägung besitzen, desto höher ist der Visualisierungsgrad der Sprache. Für rein verbale Programmiersprachen ist dieser Aspekt nicht anwendbar.

95 4.1 Klassifikation nach Shu 85 Visuelles Instruieren (Visual Coaching) Mit Systemen für visuelles Instruieren meint Shu interaktive Umgebungen für die beispielorientierte Programmierung (siehe Abschnitt 5.7, S. 124). Sie verwendet dafür den Ausdruck Visual Coaching. Bei dieser Art des Programmierens werden durch den Benutzer entweder Aktionen einmal vorgezeigt, die der Computer später mehrfach genauso ausführt, wie sie gezeigt wurden, oder Aktionen mehrfach in unterschiedlichen Kombinationen vorgezeigt, aus denen der Computer ein allgemeines, parameterisierbares Programm ableitet. Shu spricht insbesondere die zweite Variante der beispielorientierten Programmierung an. Alle von Shu erwähnten Systeme sind Prototypen, mit denen keine professionelle Programmierung möglich ist. Sprachen für die Bearbeitung visueller Information In diese Kategorie fallen laut Shu verbale Sprachen, die entweder Bildbearbeitung erlauben oder für die Manipulation von Bilddatenbanken geeignet sind [S. 109]. Um den breiten Bereich solcher Sprachen einzuschränken, läßt Shu jene traditionelle Sprachen außer acht, die prinzipiell für allgemeine Anwendungen geeignet sind, jedoch um spezielle Konstrukte oder Bibliotheken für die Bildverarbeitung erweitert wurden, z.b. Fortran, PL/I und Pascal. Sie betrachtet vor allem Sprachen für die Speicherung und Abfrage von Bildern in Datenbank-Managementsystemen. Etliche der von Shu erwähnten Arbeiten beschäftigen sich mit geographischen Informationssystemen. Nach der Terminologie dieses Buches sind verbale Sprachen für die Bearbeitung visueller Information keine visuelle Sprachen. Sprachen zur Unterstützung visueller Interaktion Shu ordnet in diese Kategorie verbale Sprachen ein, die zum Definieren, Erzeugen und Manipulieren von Piktogrammen gedacht sind und somit visuelle Repräsentation und Interaktion unterstützen [S. 14 f]. Nach der Terminologie dieses Buches sind die Sprachen dieser Kategorie keine visuelle Sprachen. Visuelle Programmiersprachen basierend auf Diagrammen In dieser Kategorie befinden sich Sprachen, die auf der klassischen imperativen Programmierung beruhen und mit Steuerfluß- bzw. Nassi-Shneiderman-Diagrammen notiert werden. Darüber hinaus werden Sprachen für die Implementierung interaktiver Systeme beruhend auf Zustandsüberführungsdiagrammen erwähnt. Zudem ordnet Shu hier das Datenflußmodell und Datenflußdiagramme ein [S. 173 ff]. Dabei verwundert, daß sie visuelle Datenflußsprachen jedoch nicht im Rahmen dieser Kategorie beschreibt, sondern in der Kategorie»Piktogrammsprachen«. Dort scheinen sie fehl am Platz zu sein, denn visuelle Datenflußsprachen werden immer in Form von Graphen notiert, also als Knoten-Kanten-Diagramme. Dabei sind zwar die Knoten als Piktogramme darstellbar, aber dieser Aspekt spielt im Vergleich zur dominierenden Diagrammform eine untergeordnete Rolle. Die unterschiedlichen Diagrammtechniken dieser Kategorie, die kaum logische Gemeinsamkeiten aufweisen, lassen ein grundsätzliches Problem von Shus Klassifikation erkennen, das bereits in der Einleitung angeschnitten wurde: die Gliederung visueller Programmiersprachen nach dem Erscheinungsbild der Sprachkonstrukte (in diesem Fall der Diagrammelemente) verdeckt einen weitaus interessanteren Gesichtspunkt, nämlich

96 Klassifikationen für visuelle Programmierung 86 das konzeptionelle Modell der Programmiersprache. Die zwiespältige Einordnung der Datenflußsprachen unterstreicht dieses Dilemma und legt eine Klassifikation nach Programmierparadigmen nahe, wie sie Burnett und Baker vornehmen (siehe Abschnitt 4.4, S. 95). Visuelle Programmiersprachen basierend auf Piktogrammen Shu räumt Programmiersprachen basierend auf Piktogrammen viel Platz in ihrem Klassifikationsschema ein. Sie motiviert solche Sprachen mit den Vorzügen der chinesischen Schrift, deren ideographische Symbole ihrer Meinung nach oft interessanter und»spannender«sind als Worte in Buchstabenschriften und deshalb einen hohen Lernanreiz bieten. Diese didaktischen Vorteile kommen laut Shu auch beim Programmieren mit Piktogrammen zum Tragen [S. 194]. Shu präsentiert eine Vielzahl von Sprachvarianten, die wie die Sprachen der Kategorie»Diagramme«zwar Ähnlichkeiten im Erscheinungsbild aufweisen, aber weiter keine Gemeinsamkeiten besitzen. Unter den vorgestellten Sprachen befinden sich u.a. Notationen für Lisp-Programme, eine visuelle Sprache für Horn-Klauseln sowie diverse Datenflußsprachen. Einige dieser Sprachen, etwa Lisp auf Basis von Venn-Diagrammen und eine frühe Version der Datenflußsprache Prograph, könnten ebensogut in der Kategorie»Diagramme«eingeordnet werden, da Piktogramme in diesen Sprachen keine erkennbare Rolle spielen. Zudem beschreibt Shu auf mehreren Seiten die Benutzungsschnittstelle des Xerox-Star-Systems, das als Vorläufer heutiger Desktop-Oberflächen wie Microsoft-Windows gilt. Es bleibt unklar, warum sie das Xerox-Star-System in ihre Klassifikation aufnimmt, denn dieses System verfügt zwar über Piktogramme, um Dokumente und Funktionen darzustellen, bietet aber in der ursprünglichen, von Shu beschriebenen Form keine Möglichkeit, mit diesen Piktogrammen zu programmieren. Eine Erweiterung des Xerox-Star-Systems um Programmiermöglichkeiten ist das System Smallstar von Halbert, das bereits in der Rubrik»Visuelles Instruieren«vorgestellt wurde. Visuelle Programmiersprachen basierend auf Formularen Die von Shu genannten visuellen Programmiersprachen auf Grundlage von Formularen sind zum Großteil einfache Benutzungsschnittstellen zu Datenbankanwendungen [S. 239 ff]. Es können damit Abfrageanweisungen durch Ausfüllen von Tabellen oder Formularen verfaßt werden, ohne daß Kenntnisse in einer bestimmten Datenbanksprache notwendig wären. Bilder kommen bei den von Shu vorgestellten Systemen nicht zum Einsatz. Die Formulierung der Suchbegriffe und Verknüpfungen geschieht rein verbal, und somit beschränkt sich der visuelle Aspekt dieser Systeme auf Formularstrukturen bzw. die zweidimensionale Tabellenform. Aktuelle Programmierwerkzeuge der vierten Generation (4GL-Werkzeuge), wie 4th-Dimension und Microsoft-Access, gehen über den Funktionsumfang der von Shu präsentierten Systeme weit hinaus und verfügen auch über bessere grafische Möglichkeiten Systeme und Sprachen Dieser Abschnitt enthält Tabellen mit Systemen und Sprachen, die Shu als Beispiele für die Kategorien ihres Klassifikationsschemas nennt und in ihrem Buch näher beschreibt. Zu jedem Eintrag wird eine Erklärung in Stichworten sowie ein Literaturverweis ange-

97 4.1 Klassifikation nach Shu 87 geben. Die angeführten Systeme sind zum Großteil durch moderne Weiterentwicklungen überholt und somit eher von historischem als aktuellem Interesse. Insbesondere die Möglichkeiten der Computergrafik haben seit Shus Untersuchungen starken Aufschwung genommen und entsprechende Verbesserungen bei den Benutzungsoberflächen bewirkt. Dennoch ist eine überblicksweise Aufstellung der von Shu genannten Systeme gerechtfertigt, weil damit einerseits die Wurzeln heutiger Systeme dargestellt werden und andererseits Shus Klassifikationsschema sonst nur schwer verständlich wäre. Eine Anwendung des Schemas von Shu für neuere Systeme und Sprachen findet sich bei Poswig [93 S. 7 ff] und Poswig [96 S. 5 ff].

98 Klassifikationen für visuelle Programmierung 88 SYSTEM KURZBESCHREIBUNG LITERATUR Visualisierung von Daten oder Informationen über Daten Shu [88 S ] INCENSE Visualisierung von Datenstrukturen. Myers [83] ISIS Schnittstelle für semantische Informationssysteme. Goldman et al. [85] KAESTLE Grafikeditor für LISP Datenstrukturen. Boecker et al. [86] Video Graphic Multimediaabfrage von Inventardatenbanken. McDonald [84] Query Facility View System Räumliches Datenverwaltungssystem. Friedell et al. [82] Visualisierung von Programmen und/oder Programmausführung Shu [88 S ] BALSA Brown Algorithm Simulator and Animator. Brown und Sedgewick [85] Interlisp Entwicklungsumgebung für LISP. Teitelman und Masinter [81] PECAN Visualisierung von Pascal-Programmen (Steuerung Reiss [85] und Daten). SEE Pretty Printing von C-Programmen. Baecker und Marcus [86] Visible Pascal Pascal mit Turtle-Grafik. Hughes und Moshell [86] Visualisierung von Software Design Shu [88 S ] PegaSys Programming Environment for the Graphical Analysis of Systems; Spezifikation und Analyse von Beziehung zwischen Komponenten großer Programme. Moriconi und Hare [85] PV Prototype Programmvisualisierung auf Implementierungsund Architekturebene. Brown et al. [85] Tabelle 4-1. Visualisierungssysteme. SYSTEM KURZBESCHREIBUNG LITERATUR Visuelles Instruieren (Visual Coaching) Shu [88 S ] Autoprogrammer Allgemeine beispielorientierte Programmierung. Biermann und Krishnaswamy [76] Peridot Programming by Example for Real-time Interface Myers [87] Design Obviating Typing; Konstruktion von Benutzungsschnittstellen. PiP Programming in Pictures; funktionale, beispielorientierte Raeder [84] Programmierung. Programming by Smalltalk-Programmierung für Anfänger. Finzer und Gould [84] Rehearsal Pygmalion Die Pionierarbeit für beispielorientierte Systeme. Smith [75] Smallstar Makroprogrammierung für das Xerox-Star- Halbert [84] System. ThinkPad Beispielorientierte Programmierung mit Regelwerken (Constraints). Rubin et al. [85] Tabelle 4-2. Visuelles Instruieren.

99 4.1 Klassifikation nach Shu 89 SYSTEM KURZBESCHREIBUNG LITERATUR Sprachen für die Bearbeitung visueller Information Shu [88 S ] GRAIN PSQL Graphics-oriented Relational Algebraic Interpreter; Speicherung und Abfrage großer Bilddatenbestände. Pictorial SQL; strukturierte Abfragen für geographische Datenbanken. Lin und Chang [80] Roussopoulos und Leifker [84] Sprachen zur Unterstützung visueller Interaktion Shu [88 S ] ICDL Icon Class Description Language; Beschreibung von Piktogrammen für ein räumliches Datenverwaltungssystem. Herot [80] HI-VISUAL Squeak Definition, Erzeugung und Manipulation von Piktogrammen. Programmierung von Zeigerinstrumenten (Maus, Joystick). Hirakawa et al. [86] Cardelli und Pike [85] Tabelle 4-3. Allgemeine visuelle Sprachen. SYSTEM KURZBESCHREIBUNG LITERATUR Programmiersprachen basierend auf Diagrammen Shu [88 S ] FPL Pascal/ HSD PIGS Programming Support System State Transition Language for Visual Programming USE Fortsetzung nächste Seite First Programming Language; Darstellung von Pascal-Programmen mit Flußdiagrammen. Cunniff et al. [86] Hierarchical structured diagrams; Ähnlich FPL. Diaz-Herrera und Flude [80] Programming with Interactive Graphical Support; direkt ausführbare Nassi-Shneiderman- Diagramme für eine Teilmenge von Pascal. Nassi-Shneiderman-Diagramme mit Präprozessor für eine Teilmenge von PL/I. Zustandsdiagramme für kommandoorientierte Dialoge, ähnlich USE. User Software Engineering; formale Spezifikation von kommandoorientierten Benutzungsschnittstellen mit direkt ausführbaren Zustandsdiagrammen. Pong und Ng [83] Frei et al. [78] Jacob [85] Wasserman et al. [86]

100 Klassifikationen für visuelle Programmierung 90 SYSTEM KURZBESCHREIBUNG LITERATUR Programmiersprachen basierend auf Piktogrammen Shu [88 S ] Dialog.I Logische Programmierung mit Horn-Klauseln. Kurita und Tamura [84] Extended HI- Datenflußsprache primär für Bildverarbeitung. Hirakawa et al. [87] VISUAL IDEOSY Ideographic and Interactive Program Description System; formale Semantik auf Basis von Milners»Calculus of Communicating Systems«. Giacalone et al. [84] Pict Prograph Imperative, visuelle Programmierung ohne Tastatur. Frühe Version des heute kommerziell verfügbaren, objekt- und datenflußorientierten VP- Systems Prograph CPX. Glinert und Tanimoto [84] Matwin und Pietrzykowski [85] Show and Tell Datenflußprogrammierung für Schulkinder. Kimura et al. [86] Tinkertoy Darstellung von Lisp-Programmen in Form von Edel [86] verketteten Piktogrammen. VennLisp Notation von Lisp Ausdrücken mit ausführbaren Venn-Diagrammen. Lakin [86] Xerox-Star- System Grafische Benutzungsschnittstelle für Xerox-Star- Arbeitsstationen. Smith et al. [82] Programmiersprachen basierend auf Formularen Shu [88 S ] FORMANAGER Einfaches 4GL-Werkzeug zum Entwurf von Formularen Yao et al. [84] und zur Datenbankabfrage. FORMAL Weiterentwicklung von QBE für breitere Anwendungsbereiche. Shu [85] QBE/OBE Query by Example / Office Procedures by Example; tabellenorientierte, zweidimensionale Abfragesprache für relationale Datenbanken erweitert um Konstrukte für Büroautomatisierung. Zloof [81] Tabelle 4-4. Visuelle Programmiersprachen.

101 4.2 Klassifikation nach Chang Klassifikation nach Chang Chang [87] in Glinert [90-P&S S. 7 f] spricht in seiner Taxonomie nicht von visueller Programmierung, sondern nur von visuellen Sprachen. Eine visuelle Sprache ist in seiner Diktion jede Sprache, die entweder die Bearbeitung visueller Information erlaubt oder über visuelle Sprachkonstrukte verfügt. Durch Kombination dieser Merkmale erhält Chang vier Kategorien visueller Sprachen: 1. Sprachen zur Unterstützung visueller Interaktion 2. Visuelle Programmiersprachen 3. Sprachen zur Verarbeitung visueller Information 4. Piktogrammsprachen zur Verarbeitung visueller Information Seine Klassifikation entspricht somit grundsätzlich dem Schema von Shu, mit Ausnahme der vierten Kategorie, die bei Shu nicht explizit vorkommt. Diese Kategorie umfaßt jedoch keine besondere Klasse von Sprachen, sondern ganz einfach jene visuellen Programmiersprachen, mit denen auch Bilder verarbeitet werden können. Ein Beispiel dafür ist die Sprache Extended HI-VISUAL, die Shu in die Rubrik»visuelle Programmiersprachen basierend auf Piktogrammen«einordnet. Wegen der großen Ähnlichkeit der Taxonomien von Chang und Shu wird auf die einzelnen Kategorien nicht näher eingegangen. Chang stellt fest, daß in allen vier Sprachkategorien sogenannte»generalisierte Piktogramme«(generalized icons) zum Tragen kommen [S. 8]. Er unterscheidet zwischen Objekt- und Prozeßpiktogrammen. Objektpiktogramme sind bildliche Repräsentationen der Objekte, auf die eine visuelle Sprache angewandt wird, während Prozeßpiktogramme die Konstrukte der visuellen Programmiersprache selbst darstellen. Beide Arten von Piktogrammen bestehen aus einem logischen Teil (der Bedeutung) und einem physischen Teil (dem Bild), der je nach Kontext unterschiedlich ausgeprägt ist. Chang erwähnt, daß visuelle Sprachen und das Konzept der generalisierten Piktogramme unter verschiedenen Aspekten erfolgreich studiert werden können, etwa aus dem Blickwinkel der Computergrafik, der Theorie formaler Sprachen, der Kognitionspsychologie und des visuellen Designs [S. 17]. Solche interdisziplinären Studien sollten zum Ziel haben, eine effektive Methodik für den Entwurf einer neuen Generation visueller Sprachen zu schaffen. Die bislang eher bescheidenen Ergebnisse sind wohl nicht zuletzt darauf zurückzuführen, daß das Konzept der generalisierten Piktogramme bei weitem nicht alle Aspekte visueller Sprachen abdeckt. 4.3 Klassifikation nach Myers Myers [94] präsentiert in der Encyclopedia of Software Engineering drei aktualisierte Klassifikationen für visuelle Programmierung und Softwarevisualisierung, die auf seine Arbeiten aus den Jahren 1986 und 1988 zurückgehen. VP-Systeme betrachtet Myers unter zwei verschiedenen Gesichtspunkten: in der Haupttaxonomie [S. 879 ff] werden VP-Systeme in erster Linie hinsichtlich des Kriteriums»Beispielorientierte Programmierung«eingeordnet, in der nachgeordneten Klassifikation [S. 884 f] steht die Notation der Programme im Vordergrund. Für Systeme zur Softwarevisualisierung (die hier nicht weiter behandelt werden) wählt Myers eine Einteilung nach statischer bzw. dynamischer Visualisierung von Code, Daten und Algorithmen [S. 885 ff].

102 Klassifikationen für visuelle Programmierung 92 Myers beschreitet mit seiner Haupttaxonomie einen grundlegend anderen Weg als Shu und Chang. Er hebt weder die Art der verarbeiteten Daten hervor, noch berücksichtigt er Anwendungsgebiete oder die Art der Programmdarstellung. Statt dessen bildet er aus den drei Merkmalen 1. Beispielorientierte oder nicht-beispielorientierte Programmierung 2. Visuelle oder nicht-visuelle Programmierung 3. Kompilierte oder interpretierte Programme einen Raster mit acht Kategorien in den er ca. 40 Systeme einordnet (siehe Tabelle 4-5). Myers erklärt nicht, warum er gerade diese drei Merkmale gewählt hat und stellt seine Klassifikation auch keinen anderen Ansätzen gegenüber. Die auf den ersten Blick unverständliche Differenzierung nach visueller und nicht-visueller Programmierung ist deshalb notwendig, weil Myers beispielorientierte Programmierung und visuelle Programmierung als orthogonale Ansätze betrachtet und drei beispielorientierte Systeme anführt, die er nicht zu visueller Programmierung zählt. Problematisch erscheint die Einordnung von Tabellenkalkulationen (Spreadsheets), die Myers pauschal als visuelle Programmiersprachen auf hohem Niveau einstuft [S. 881]. Er stellt fest, daß Tabellenkalkulationen grundsätzlich auf grafischen Repräsentationen beruhen. Diese Aussage steht im Widerspruch zur Tatsache, daß in allen gängigen Tabellenkalkulationsprogrammen textuelle Formeln für Werteberechnungen herangezogen werden. Solche Formeln können für komplizierte Berechnungen einen beachtlichen Umfang annehmen, weshalb die uneingeschränkte Zuordnung von Tabellenkalkulationen zu visueller Programmierung unangebracht ist. Andererseits darf aber die Eigenschaft»Beispielorientierte Programmierung«für Tabellenkalkulationsprogramme nicht ausgeschlossen werden (wie dies Myers tut), weil die zum Teil beachtlichen Makrorekorder-Funktionen solcher Applikationen die beispielorientierte Programmierung auf klassische Weise unterstützen. Ein weiterer Schwachpunkt von Myers Taxonomie ist die Unterscheidung nach Systemen, die Programme interpretieren bzw. kompilieren, weil diese Differenzierung keine aufschlußreichen Informationen liefert. Moderne VP-Systeme unterstützen meist sowohl Interpretation als auch Kompilation. In diesen Fällen ist eine eindeutige Zuordnung gar nicht möglich. Zudem verschwimmen die Unterschiede in der Handhabung interpretierender und kompilierender Systemen durch schnelle Übersetzer und flexible Laufzeitsysteme. Die Frage, ob ein VP-System interpretiert oder kompiliert, verliert demzufolge immer mehr an Bedeutung.

103 4.3 Klassifikation nach Myers 93 Nichtbeispielorientierte Programmierung Beispielorientierte Programmierung Tabelle 4-5. KOMPILIERT INTERPRETIERT Nicht-VP VP Nicht-VP VP 1 Pascal, Fortan etc. 5 I/O Pairs 2 Grail, AMBIT/G/L, QBE, FORMAL, GAL, FPL, IBGE, MOPS-2, OPAL, Proc-BLOX, HiGraphs, Miro, StateMaster, MPL 6 Traces 3 Lisp, APL etc. 7 Tinker, Editing by Example 4 Graphical Program Editor, Spreadsheets, PIGS, Pict, Prograph, State Transition UIMS, PLAY, Action graphics, Forms, VERDI, LabVIEW, SIL-ICON 8 Pygmalion, Smallstar, Rehersal World, Graphical Thinglab, Music System, HI- VISUAL, ALEX, Peridot, InterCONS, Fabrik Myers Klassifikation von Programmiersprachen und -systemen in acht Kategorien. Myers [94 S. 880] Die Rubriken 1 und 3 umfassen konventionelle Programmiersprachen und sind deshalb im Zusammenhang mit visueller Programmierung irrelevant. Die Rubriken 5, 6 und 7 enthalten insgesamt nur vier Systeme und sind somit ebenfalls von geringer Bedeutung. Typische VP-Systeme befinden sich in den Rubriken 2, 4 und 8, die insgesamt 35 Systeme umfassen. Die (exemplarische) Aufzählung der Systeme erfolgt in chronologischer Reihenfolge. Eine kurze Beschreibung aller Systeme samt Literaturreferenzen findet sich im Originalartikel. Bei genauer Betrachtung bleibt schließlich nur der Aspekt»Beispielorientierte Programmierung«als wesentliches Merkmal von Myers Klassifikation erhalten. Selbst hinsichtlich dieses Kriteriums ist die Zuordnung einzelner Systeme nicht immer klar. So führt Myers die Datenflußsysteme InterCONS von Smith [88] und Fabrik von Ludolph et al. [88] als Vertreter für beispielorientierter Programmierung an, obwohl beide Systeme beispielorientierte Programmierung nur rudimentär unterstützen. Wie immer kommt es auch bei Myers Klassifikation auf die Definition und Interpretation der zugrundeliegenden Begriffe an, die gerade hinsichtlich der beispielorientierten Programmierung nicht immer eindeutig sind. Bezüglich der Darstellungsart von Programmen in VP-Systemen unterscheidet Myers [94 S. 884 f] vierzehn Kategorien (siehe Tabelle 4-6). Er nennt seine Einteilung eine»klassifikation nach Spezifikationstechnik«, ohne jedoch zu erläutern, was er in diesem Zusammenhang unter»spezifikation«versteht. Aus den Beispielen läßt sich ableiten, daß damit primär verschiedene Notationen für Programmcode gemeint sind.

104 Klassifikationen für visuelle Programmierung 94 Spezifikationstechnik Textuelle Sprache Steuerflußdiagramme Varianten von Steuerflußdiagrammen Petrinetze Datenflußdiagramme Gerichtete Graphen Varianten von Graphen Matrizen Puzzleteile Formulare Piktogrammsätze Tabellenkalkulation Beispielhaft Keine Sprache Systeme Pascal, Ada, Fortran, Lisp, etc. Tinker, Smallstar Grail, Pict, FPL, IBGE, OPAL GAL, PIGS, SchemaCode, PLAY MOPS-2, VERDI Graphical Program Editor, Prograph, Graphical Thinglab, Music System, HI-VISUAL, LabVIEW, Fabrik, InterCONS AMBIT/G/L, State Transition UIMS, Traces HiGraphs, Miro, StateMaster ALEX, MPL Proc-BLOX Query by Example, FORMAL SIL-ICON VisiCalc, Lotus 1-2-3, Action graphics, Forms Pygmalion, Rehersal World, Peridot I/O Pairs, Editing by Example Tabelle 4-6. Myers Klassifikation von Programmiersprachen und -systemen aufgrund der Spezifikationstechnik. Myers [94 S. 880] Die meisten Kategorien sind selbsterklärend, einige Rubriken bedürfen jedoch der Erläuterung. Die Notation mit Puzzleteilen beruht auf der BLOX-Methode von Glinert (vgl. Abschnitt»C2: Visuelle Programmierung mit Anweisungssequenzen«S. 132). Piktogrammsätze sind laut Myers visuelle Ausdrücke mit Piktogrammen, bei denen die Positionen der Piktogramme eine wesentliche Rolle spielen. Mit Beispielhaften Notationen werden Programme durch dynamische Sprachmittel definiert, für die keine direkt darstellbare statische Form existiert. Zu solchen dynamischen Sprachmitteln gehört etwa der Drag-und-Drop-Mechanismus, mit dem ein grafisches Element über ein anderes Element gezogen werden kann, um auf diese Weise eine bestimmte Operation auszulösen. Was unter der Kategorie»Keine Sprache«zu verstehen ist, erläutert Myers nicht. 4.4 Klassifikation nach Burnett und Baker Die Klassifikation von Burnett und Baker [94] ist der aktuellste Beitrag zu den Bemühungen, die Arbeiten über visuelle Programmierung systematisch zu erfassen. Der Zweck ihres Klassifikationsrahmens ist eine übersichtliche Darstellung der Literatur zu visuellen Programmiersprachen. Damit verfolgen sie zwar scheinbar ein anderes Ziel als Shu, Chang und Myers, die konkrete Systeme und Sprachen einordnen, letztlich sind die Ergebnisse jedoch ähnlich, denn ob ein Aufsatz klassifiziert wird, der die Beschreibung einer Programmiersprache enthält, oder die Programmiersprache selbst erfaßt wird, ist dann unerheblich, wenn die Einordnung des Aufsatzes anhand der Eigenschaften der beschriebenen Sprache erfolgt.

105 4.4 Klassifikation nach Burnett und Baker 95 Burnett und Baker gehen vom ACM Computing Review Classifications System (ACM- CRC-System) aus, das zur vollständigen Erfassung der Informatikliteratur dient. Sie zeigen, daß die Struktur des ACM-CRC-Systems aus mehreren Gründen ungeeignet ist, Arbeiten über visuelle Programmiersprachen aufzunehmen und schlagen deshalb ein maßgeschneidertes Schema vor, das in Tabelle 4-7 dargestellt wird. Manche Kategorien des ACM-CRC-Systems wurden übernommen, andere weggelassen, und neue wurden hinzugefügt. Die genaue Bedeutung der Bezeichnungen der einzelnen Kategorien ist nicht definiert. Damit soll den Autoren die Freiheit gegeben werden, ihre Arbeiten so einzuordnen, wie es ihrem Begriffsverständnis entspricht. Eine Kategorie»Sonstiges«existiert nicht. Statt dessen ist die Einordnung von Literatur auf jeder Ebene gestattet. So könnte man etwa eine Arbeit, die den weiten Bereich des Themas»Sprachimplementierung«behandelt, direkt bei VPL-IV plazieren und müßte sie nicht in einen der Unterpunkte A bis D zwängen. Zudem ist es möglich, eine Arbeit in mehreren Rubriken einzuordnen. Burnett und Baker haben selbst keine Einordnung von Publikationen in die einzelnen Rubriken ihres Klassifikationsrahmens vorgenommen. Sie überlassen diese Tätigkeit den Autoren, weil sie der Meinung sind, daß nur die jeweiligen Verfasser in der Lage sind, die zur Einordnung ihres Werkes notwendige Interpretation der Begriffe des Klassifikationsrahmens vorzunehmen. Durch die Beschränkung auf visuelle Programmiersprachen wird nicht das gesamte Gebiet der visuellen Programmierung erfaßt. Burnett und Baker sehen ihre Klassifikation im Kontext des»visual Computing«und führen andere bedeutende Teilbereiche dieses Fachgebiets an, für die vergleichbare Taxonomien möglich sind, etwa visuelle Datenbanksysteme, Sprachen zur Bildverarbeitung, visuelle Umgebungen für textuelle Sprachen, virtuelle Realität und Visualisierung [S. 288]. Die Klassifikation von Burnett und Baker ist bei weitem besser zur systematischen Erfassung von visueller Programmierung geeignet als die zuvor genannten Ansätze. Das Schema ist einerseits flexibel genug, um dem wissenschaftlichen und technischen Fortschritt gerecht zu werden und orientiert sich andererseits an grundsätzlichen Fragestellungen, die weitgehend unabhängig von kurzfristigen Entwicklungen sind. Die Klassifikation von Burnett und Baker dient daher als Grundlage für die Darstellung der Konzepte visueller Programmiersysteme im nächsten Kapitel.

106 Klassifikationen für visuelle Programmierung 96 VPL: VISUELLE PROGRAMMIERSPRACHEN VPL-I. Umgebungen und Werkzeuge für visuelle Programmiersprachen VPL-II. Sprachklassifikationen A. Paradigmen 1. Sprachen für Parallelprogrammierung 2. Constraintbasierte Sprachen 3. Datenflußsprachen 4. Formularbasierte und tabellenbasierte [Spreadsheet-basierte] Sprachen. 5. Funktionale Sprachen 6. Imperative Sprachen 7. Logische Sprachen 8. Multiparadigmen-Sprachen 9. Objektorientierte Sprachen 10. Beispielorientierte Sprachen [Programming-bydemonstration languages] 11. Regelbasierte Sprachen B. Visuelle Repräsentationen 1. Diagrammsprachen 1. Piktogrammsprachen 1. Sprachen basierend auf statischen Bildsequenzen VPL-III. Spracheigenschaften A. Abstraktion 1. Datenabstraktion 1. Prozedurale Abstraktion B. Steuerfluß C. Datentypen und Datenstrukturen D. Dokumentation E. Ereignisbehandlung F. Ausnahmebehandlung VPL-IV. Fragestellungen zur Sprachimplementierung A. Ansätze für Berechnungsmodelle (z.b. bedarfsgesteuert, datengesteuert) B. Effizienz C. Parsen D. Interpreter und Compiler VPL-V. Sprachzweck A. Universalsprachen B. Datenbanksprachen C. Bildverarbeitungssprachen D. Visualisierungssprachen [Scientific visualization languages] E. Sprachen zur Generierung von Benutzungsschnittstellen VPL-VI. Theorie visueller Programmiersprachen A. Formale Definition visueller Programmiersprachen B. Piktogrammtheorie C. Fragestellungen zum Sprachentwurf 1. Fragestellungen zur Kognition und zum Entwurf von Benutzungsschnittstellen (z.b. Benutzbarkeitsstudien, grafische Wahrnehmung) 1. Effiziente Nutzung von Bildschirmplatz 1. Lebendigkeit 1. Anwendungsbereich 1. Typprüfung und Typtheorie 1. Fragestellungen zur visuellen Darstellung (z.b. statische Repräsentation, Animation) Tabelle 4-7. Das Klassifikationsschema für visuelle Programmiersprachen nach Burnett und Baker Burnett und Baker [94 S. 289]

107 5. Konzepte visueller Programmiersysteme Dieses Kapitel präsentiert Konzepte visueller Programmiersysteme (VP-Systeme) anhand der zugrundeliegenden Sprachkonzepte. VP-Systeme können anhand der Klassifikation von Burnett und Baker in drei Gruppen zusammengefaßt werden: 1. VP-Systeme basierend auf verbalen Sprachen: steuerflußorientiert, funktionsorientiert, datenflußorientiert, objektorientiert, constraintorientiert. 2. VP-Systeme basierend auf visuellen Sprachen: regelorientiert, beispielorientiert, formularorientiert. 3. VP-Systeme für spezielle Bereiche: parallelitätsorientiert, multiparadigmenorientiert. Gruppe 1 umfaßt VP-Systeme, deren Programmiersprachen eng an die Konzepte verbaler Sprachen angelehnt sind und die deshalb als grafische Gegenstücke verbaler Programmiersprachen bezeichnet werden können (eine Ausnahme sind Komponenten- und Transitionsnetze für steuerflußorientierte Systeme). Die in diese Gruppe eingeordneten constraintorientierten VP-Systeme schließen logische Sprachen ein. Gruppe 2 enthält VP-Systeme, deren visuelle Sprachen kein Gegenstück in der verbalen Programmierung haben und die somit inhärent visuell sind. Gruppe 3 umfaßt VP-Systeme, die spezielle Ansätze für die parallele Programmierung realisieren oder unterschiedliche Sprachkonzepte vereinen. Aus dieser Gruppe werden nur multiparadigmenorientierte Systeme vorgestellt. Parallelitätsorientierte VP-Systeme sind zu divergent, um die zugrundeliegende Konzepte im Rahmen des verfügbaren Platzes leichtverständlich darstellen zu können. Beiträge zu solchen Systemen finden sich in Glinert und Stotts [92] sowie in VL [92-95]. Andere Klassifikationen für VP-Systeme, beispielsweise die in Kapitel 4 vorgestellten Taxonomien von Chang und Shu oder die Klassifikation von Poswig [96 S. 5 f], legen das Schwergewicht auf die Anwendungsgebiete von VP-Systemen bzw. auf das Erscheinungsbild der zugrundeliegende Sprachen. Die hier gewählte Einteilung nach Spracheigenschaften ist aus zwei Gründen zielführender: (1) Es gibt viele VP-Systeme, die keiner prinzipiellen Einschränkung hinsichtlich ihrer Anwendungsgebiete unterliegen. Solche Allzwecksysteme müßten in einer Kategorie»Allgemeine Systeme«zusammengefaßt werden, wodurch interessante Unterscheidungsmerkmale hinsichtlich der Sprachkonzepte verloren gingen. (2) Forschung und Industrie entwickeln laufend neue Ideen zur Unterstützung der Softwareentwicklung mit visuellen Elementen. Eine auf Anwendungsgebiete bezogene Klassifikation kann deshalb nie auf dem neuesten Stand sein. Die zugrundeliegenden Denkmodelle sind jedoch weitgehend stabil. Für eine Übersicht, die am Erscheinungsbild von visuellen Programmiersprachen orientiert ist, gelten dieselben Nachteile. Der Leser mag sich fragen, warum nicht von vornherein Sprachkonzepte statt Systemkonzepte erklärt werden, wenn es offenbar auf Sprachkonzepte ankommt. Der Grund dafür ist, daß eine visuelle Programmiersprache oder Softwarebeschreibungssprache fast immer auf ein bestimmtes VP-System abgestimmt und mit diesem eng verflochten ist. Oft bildet sogar die Benutzungsschnittstelle des Systems einen Teil der Sprache. Die klassische Trennung zwischen Sprache und Werkzeug ist deshalb nicht möglich, und

108 Konzepte visueller Programmiersysteme 98 eine Beschreibung von Konzepten der visuellen Programmierung muß sinnvollerweise auf VP-Systeme Bezug nehmen. Entsprechend der Bedeutung des Anwendungsbereichs wird ein höherer oder geringerer Detaillierungsgrad bei der Erläuterung der einzelnen Konzepte gewählt. Beispielsweise werden Konzepte für datenflußorientierte VP- Systeme wegen ihrer vielfältigen Einsatzmöglichkeiten ausführlicher erklärt als die vorwiegend auf den akademischen Bereich beschränkten formularorientierten Konzepte. 5.1 Steuerflußorientierte VP-Systeme Diese VP-Systeme beruhen auf dem imperativen Programmierparadigma. Die Bezeichnung»steuerflußorientiert«stammt daher, daß in solchen Systemen die Befehlsaktivierung durch die Programmsteuerung ausgelöst wird. Objektorientierte VP-Systeme enthalten ebenfalls Steuerflußkonstrukte, werden aber wegen ihrer großen Bedeutung und weitergehenden Konzepte in einem eigenen Abschnitt behandelt. Die Festlegung des Steuerflusses kann auf drei Arten erfolgen: mit Anweisungssequenzen, Komponentennetzen und Transitionsnetzen Anweisungssequenzen Eine Anweisungssequenz ist eine Folge von Operationen, die in der Reihenfolge der Aufschreibung ausgeführt werden, falls nicht Anweisungen zur Ablaufsteuerung (Sprunganweisungen, Schleifen, Verzweigungen und Unterprogrammaufrufe) die lineare Ausführung modifizieren. Eine Anweisungssequenz entspricht dem Quelltext verbaler Programmiersprachen. In manchen Fällen sind zusätzlich Konstrukte zur parallelen Ausführung von Anweisungen vorgesehen. In der visuellen Programmierung werden Anweisungssequenzen meist als Ablaufpläne oder Blockdiagramme dargestellt. Dazu gehören Flußdiagramme, wie bei FPL (vgl. Shu [88 S. 151 ff], Pascal/HDS von Diaz-Herrera und Flude [80] sowie PICT von Glinert und Tanimoto [84]; Nassi-Shneiderman-Diagramme, wie bei Graphics-Based Programming Support System von Frei et al. [78] und PIGS von Pong und Ng [83]; Puzzlediagramme, wie bei Visual Programming Language for Novices von Bonar und Liffick [90] und C 2 von Kopache und Glinert [88]. Eine ausführliche Studie über verschiedene Diagrammarten für Anweisungssequenzen findet sich bei Tripp [88]. Visuelle Programmierung mit Anweisungssequenzen hat nur geringe Bedeutung, weil sie gegenüber imperativen Programmiersprachen keine neuen Konzepte bietet Komponentennetze Ein Komponentennetz ist ein Verbund gekapselter Softwarekomponenten (Funktionsbausteine oder Objekte), die durch Kanäle miteinander verbunden sind. Über die Kanäle werden Tokens transportiert, die externe und interne Ereignisse repräsentieren. Ex-

109 5.1 Steuerflußorientierte VP-Systeme 99 terne Ereignisse stammen aus der Umgebung und werden über eine Eingangsschnittstelle eingespeist. Interne Ereignisse werden von Komponenten des Netzes ausgelöst. Die Anbindung der Kanäle an Komponenten geschieht an Anschlußpunkten. Erreicht ein Token eine Komponente, so wird diese aktiviert. Es beginnt ein Verarbeitungsprozeß, der meist weitere Token emittiert, was wiederum zur Aktivierung von Komponenten führt. Tokens, die für die Umgebung bestimmt sind, verlassen das Netzwerk über eine Ausgangsschnittstelle. Die Emission von Token durch Komponenten kann sequentiell oder parallel geschehen. Bei paralleler Emission können mehrere Tokens gleichzeitig durch ein Komponentennetz fließen. Ein Programm besteht meist aus mehreren Komponentennetzen, die entweder für Reaktionen auf externe Ereignisse zuständig sind oder innerhalb anderer Komponentennetze wie Unterprogramme verwendet werden. Der Steuerfluß ergibt sich aus dem Fluß der Tokens durch diese Netze. Bild 5-1 zeigt die schematische Darstellung eines Komponentennetzes, das in dieser Form in Vista realisiert ist (siehe Kapitel 7). Komponentennetze anderer VP-Systeme basieren auf im Detail abweichenden Notationen und Ausführungsmodellen, der konzeptionelle Aufbau ähnelt jedoch der hier gezeigten Struktur. Bei der Definition des Steuerflusses durch Komponentennetze treten algorithmische Aspekte in den Hintergrund und reaktive Gesichtspunkte in den Vordergrund. Anstatt festzulegen, welche Operationen in welcher Reihenfolge auszuführen sind, um ein bestimmtes Berechnungsverfahren durchzuführen, definiert man, welche Programmkomponenten auf welche Ereignisse reagieren sollen, um ein bestimmtes Programmverhalten zu realisieren. Dadurch wird das Abstraktionsniveau erhöht. Zudem sind Komponenten lose gekoppelt und damit flexibel kombinierbar. Grundsätzliche Überlegungen zu visueller Programmierung mit Komponentennetzen finden sich bei Mey [94], wo auch ein Framework und eine prototypische Entwicklungsumgebung für visuelle, komponentenorientierte Softwareentwicklung beschrieben wird. Eingangsschnittstelle Komponente Anschlußpunkt Kanal Token Ausgangsschnittstelle Bild 5-1. Schematische Darstellung eines Komponentennetzes.

110 Konzepte visueller Programmiersysteme Transitionsnetze Transitionsnetze beschreiben Automaten und Petrinetze. Diese mathematischen Modelle können zur Implementierung reaktiver Systeme verwendet werden, die kontinuierlich auf Ereignisse reagieren und deren Verhalten zeitlichen Bedingungen unterworfen ist. Transitionsnetze ermöglichen die exakte Spezifikation von Systemeigenschaften, erlauben beweisbare Aussagen über das Systemverhalten und sind ein zweckmäßiges Mittel, um den Ablauf und das Zusammenwirken von Prozessen zu definieren. Anwendungsgebiet für die Programmierung mit Transitionsnetzen sind Problemstellungen aus dem Bereich der Systemtechnik und Simulation, z.b. die Entwicklung von Telefonvermittlungsanlagen, Verkehrsleiteinrichtungen, Fertigungsstraßen und integrierter Schaltkreise, aber auch Bereiche der Informationstechnik, z.b. Client-Server- Anwendungen, Datenbanken und Applikationen für die Büroautomatisierung. Das Transitionsnetz eines Automaten ist ein gerichteter Graph, mit Zuständen als Knoten und Zustandsübergängen als Kanten. Die visuelle Darstellung eines Transitionsnetzes wird meist als Zustandsdiagramm bezeichnet. Je nachdem, um welchen Automatentyp es sich handelt, tragen Kanten und Knoten entsprechende Attribute. Meist sind die Knoten mit den Namen von Zuständen versehen und die Kanten mit dem Namen von Ereignissen. Das Transitionsnetz eines Automaten wird durchlaufen, indem beim Eintreffen eines Ereignisses der Zustand gewechselt wird. Konventionelle Automaten können sich immer nur in einem Zustand befinden, sind flach und werden sequentiell ausgeführt. Neuere Ansätze, z.b. Statecharts von Harel [88] und erweiterte Zustandsdiagramme von Drusinsky [94] ergänzen die ursprünglichen Transitionsnetze um Zustandshierarchien, Möglichkeiten zur Spezifikation paralleler Prozesse, bedingte Zustandsübergänge und andere Konstrukte. Bild 5-2 zeigt ein erweitertes Zustandsdiagramm in BetterState zur Steuerung einer Verkehrsampel. Ein Petrinetz ist ein gerichteter Graph mit zwei Arten von Knoten - Stellen und Transitionen (Anmerkung: Ein Petrinetz ist per Definition ein Transitionsnetz, deshalb wird der Ausdruck»Transitionsnetz eines Petrinetzes«nicht verwendet). Die Stellen von Petrinetzen entsprechen den Zuständen von Automaten, die Transitionen den Zustandsübergängen. Die Kanten verbinden Knoten unterschiedlicher Art, d.h. Stellen mit Transitionen und Transitionen mit Stellen. Eine oder mehrere Stellen sind mit Marken belegt. Ein Petrinetz wird ausgeführt, indem Transitionen schalten. Eine Transition kann dann schalten, wenn alle mit der Transition verbundenen Eingabestellen eine oder mehrere Marken aufweisen. Beim Schalten entfernt die Transition von jeder Eingabestelle eine Marke und legt auf jeder Ausgabestelle eine neue Marke ab. Transitionen, deren Eingabestellen zur gleichen Zeit belegt sind, schalten auch gleichzeitig. Die Ausführung von Petrinetze ist somit inhärent parallel.

111 5.1 Steuerflußorientierte VP-Systeme 101 Bild 5-2. Zustandsdiagramm in BetterState. Vgl. BetterState [94] Das Bild zeigt die oberste Ebene eines hierarchischen Transitionsnetzes auf Basis von Statecharts zur Steuerung einer Verkehrsampel. Rechtecke mit durchgezogenem Rahmen repräsentieren Zustände, Rechtecke mit gestricheltem Rahmen stellen Prozesse dar, Pfeile sind Zustandsübergänge, und die Balken dienen zur Prozeßsynchronisation. Die erwähnten Eigenschaften gelten für einfache Arten von Petrinetzen. Erweiterte Petrinetze verfügen über zusätzliche Attribute, die eine feinere und flexiblere Modellierung erlauben. Die höhere Ausdrucksstärke erweiterter Petrinetze erschließt neue Anwendungsgebiete und gestattet eine kompaktere Darstellung. Solche Petrinetze können auch für Datenflußprogrammierung eingesetzt werden, was aber von gängigen VP-Systemen nicht unterstützt wird. Bild 1-2 zeigt ein Petrinetz in PACE zur Simulation eines Informationssystems. Der an Details interessierte Leser findet eine umfassende Darstellung von Automaten und Petrinetzen bei Peterson [77], Hopcroft und Ullman [79], Murata [89], Reisig [91] sowie Jensen und Rozenberg [91]. Zu visueller Programmierung mit Transitionsnetzen gehören auch Systeme auf Basis von SDL-Prozeßdiagrammen. Näheres dazu findet man bei Stˆger [93]. In Lewerentz und Lindner [95] werden Methoden und visuelle Notationen zur formalen Entwicklung reaktiver Systeme beschrieben.

112 Konzepte visueller Programmiersysteme 102 Kunden Terminals Antworten (e) Erzeugung der Kundenanfragen delay := e next Erzeugte Terminal- Anfragen Rechner Hilfsstelle für die Erzeugung der Ankunftsintervalle der Kunden (Exponential mean: 0.15) Bild 5-3. Petrinetz in PACE. Vgl. Dähler [89] Das Bild zeigt die oberste Ebene eines erweiterten Petrinetzes zur Simulation eines Informationssystem, das aus einem Zentralrechner und Terminals besteht. Das Petrinetz enthält eine Transition (Quadrat), zwei auf tieferer Ebene verfeinerte Module (graue Quadrate) und vier Stellen (Kreise). Die Doppelpfeile bedeuten, daß eine Marke beim Schalten einer Transition von der Stelle entfernt und sofort zurückgelegt wird. Beim Schalten der Transition»Erzeugen der Kundenanfragen«wird der Smalltalk-Code delay := e next ausgeführt. Die Variable delay ist eine reservierte Variable, die das Schalten der Transition um diese Zeit verzögert. Die Variable e referenziert ein Objekt, das von jener Marke mitgeführt wird, die von der Hilfsstelle für die Erzeugung der Ankunftsintervalle der Kunden stammt. Beim Starten der Simulation wird durch den Smalltalk-Code Exponential mean: 0.15 ein Objekt erzeugt, das der Anfangsmarke zugewiesen wird. Dieses Objekt repräsentiert einen Zufallszahlengenerator mit exponentieller Verteilung, der auf die Nachricht next die nächste Zufallszahl liefert. 5.2 Datenflußorientierte VP-Systeme Datenflußorientierte VP-Systeme beruhen auf dem Datenflußmodell (vgl. Sharp [92]), in dem die Verfügbarkeit von Daten die Ausführungsreihenfolge von Operationen bestimmt und nicht der Wert eines Befehlszählers, wie in steuerflußorientierten Systemen. Zwischen datenflußorientierten und funktionsorientierten VP-Systemen besteht eine enge Verwandtschaft, weil beide Systemklassen denselben theoretischen Unterbau besitzen. Das Datenflußmodell repräsentiert eine spezielle Beschreibungsform und einen speziellen Ausführungsmechanismus für funktionale Programme. Datenflußorientierte Systeme sind in der visuellen Programmierung weit verbreitet und verzeichnen auch kommerzielle Erfolge. Hils [92] stellt in einer Studie fünfzehn datenflußorientierte VP-Systeme aus unterschiedlichen Anwendungsbereichen vor, darunter Systeme zur Steuerung von Musiksynthesizern, Werkzeuge zur Bildverarbeitung und für technisch-wissenschaftliche Visualisierungen sowie eine Reihe von Allzwecksystemen.

113 5.2 Datenflußorientierte VP-Systeme 103 Die Beliebtheit des Datenflußmodells bei Entwicklern und Anwendern von VP- Systemen hat mehrere Ursachen: Bestimmte Aspekte der physikalischen Welt werden besonders gut auf die Welt der Programmierung abgebildet. Beispielsweise lassen sich elektronische Schaltungen ausgezeichnet emulieren. Schwierige Konzepte der imperativen Programmierung, wie Variablen und dynamische Datenstrukturen, kommen kaum zum Tragen, wodurch der Lernaufwand gering ist und die Konstruktion einfacher Datenflußprogramme leicht gemacht wird. Die Top-Down-Zerlegung von Datenflußprogrammen gelingt mühelos, weil Programmteile verbunden und getrennt werden können, ohne auf Querbeziehungen achten zu müssen. Diese Eigenschaft erleichtert strukturiertes Programmieren. Die Programmausführung kann parallel erfolgen, ohne daß der Programmierer dafür besondere Anweisungen vorsehen müßte. In Anwendungsbereichen, wo die Parallelverarbeitung großer Datenmengen eine wesentliche Rolle spielt, etwa in der numerischen Mathematik und der Physik, ist damit eine hohe Rationalisierung der Programmentwicklung verbunden. Die Visualisierung der Programmausführung ist auf illustrative Art möglich, was das Verständnis für komplexe Programmabläufe erhöht und das Testen erleichtert. Die ersten Programmierkonzepte auf Basis des Datenflußmodells finden sich in Arbeiten von Karp, Miller und Adams, die bereits Mitte bis Ende der 60er-Jahren entstanden (vgl. Gurd [91 S. ix] und Sharp [92-2 S. 4]). Mitte der 70er-Jahre legte Dennis [74] mit seinem Aufsatz»First Version of a Data Flow Procedure Language«die Basis für weitere Aktivitäten auf diesem Gebiet. Anfang der 80er-Jahre waren die Forschungsergebnisse so weit gediehen, daß die Programmierung mit Datenflußsprachen als ernstzunehmende Alternative zur imperativen Programmierung ins Auge gefaßt werden konnte. Eine interessante Zusammenfassung zum damaligen Stand der Technik findet sich in Computer [82], einen Überblick über neuere Entwicklungen geben Gaudiot und Bic [91] sowie Ungerer [93]. Das Datenflußmodell kann nicht nur für die Implementierung von Software, sondern auch zur Systemanalyse und zum Systementwurf dienen (vgl. Pomberger und Blaschek [96 S. 37 f]). Diese Anwendungen werden hier nicht behandelt. Wegen der großen Bedeutung datenflußorientierter VP-Systeme, wird dem Datenflußmodell mehr Platz eingeräumt als anderen Ansätzen. Zudem bildet das Datenflußmodell die Grundlage für den transformativen Teil des Systems Vista, das in Kapitel 7 beschrieben ist. Bei der Beschreibung von Vista werden die hier angeführten Erläuterungen vorausgesetzt Darstellung von Datenflußprogrammen Ein visuelles Datenflußprogramm wird als gerichteter Graph dargestellt, mit Datenquellen, Datensenken und Operationen als Knoten und Datenkanälen als Kanten. Ein solcher Graph wird Datenflußdiagramm genannt. Über die Datenkanäle eines Datenflußprogramms fließen Daten, die konzeptionell auf einem Trägermedium, dem sogenannten Token transportiert werden. Datenquellen, Datensenken und Operationen sind mit Eingängen und Ausgängen versehen, die als Anschlußpunkte für die Datenkanäle dienen. Bild 5-4 und Bild 5-5 zeigen die schematische Darstellung und konkrete Ausprägung eines Datenflußprogramms. Neben der grafischen Darstellung von Da-

114 Konzepte visueller Programmiersysteme 104 tenflußprogrammen ist auch eine textuelle Darstellung möglich. Beispiele dafür sind VAL, Id, LUCID und verschiedene»manchester Sprachen«(vgl. Herath et al. [92]). Folgende Regeln gelten für die Verknüpfung von Datenquellen, Datensenken und Operationen: 1. An einen Eingang darf nur ein Kanal angeschlossen sein. 2. An einen Ausgang dürfen mehrere Kanäle angeschlossen sein. 3. Eine Datenquelle hat nur Ausgänge, eine Datensenke hat nur Eingänge. Mindestens ein Kanal muß angeschlossen sein. 4. Eine Operation hat mindestens einen Eingang und null oder mehrere Ausgänge. 5. Jeder Eingang einer Operation muß durch einen Kanal versorgt werden, andernfalls kann die Operation nicht aktiviert werden. 6. Eine Operation ohne Ausgang bzw. ohne Anschlüsse von Kanälen an Ausgängen produziert einen Nebeneffekt oder ist wirkungslos. Datenquellen können Wertegeneratoren sein oder konstante Werte repräsentieren. Operationen innerhalb von Datenflußprogrammen können selbst wiederum Datenflußprogramme sein. In diesem Fall bilden die Datenquellen die Eingänge der Operation und die Datensenken die Ausgänge. Eingänge und Ausgänge einer Operation können als Eingangs- und Ausgangsparameter im funktionalen Sinne betrachtet werden. In manchen VP-Systemen gilt Regel 5 nicht. In diesen Systemen wird für Eingänge ohne angeschlossenen Kanal ein Standardwert generiert. Arithmetische und logische Ausdrücke sowie Programmstücke ohne Ablaufstrukturen können sehr einfach in Datenflußprogramme transformiert werden. Für Berechnungsverfahren, die Schleifen und Verzweigungen aufweisen (also eine großen Klasse von Algorithmen), ergeben sich einige Probleme, die später behandelt werden. A B C P P Q R S D T E F Bild 5-4. Schematische Darstellung eines Datenflußprogramms. Die Knoten A bis D repräsentieren Datenquellen, E und F Datensenken, P bis T Operationen, die Pfeile stellen Datenkanäle dar. Der Knoten P kommt zweimal vor, d.h. er repräsentiert dieselbe Operation.

115 5.2 Datenflußorientierte VP-Systeme 105 Datei A Datei B Satznummer Sortieren Sortieren Satzselektion Mischen Feldselektion Feldnummer Filtern Datei C Liste Dateifilterung a b c cos cos + * / d - e f Formelberechnung Bild 5-5. Beispiele für konkrete Ausprägungen eines Datenflußprogramms. Das Bild zeigt zwei Beispiele für konkrete Ausprägungen des schematisch dargestellten Datenflußprogramms aus Bild 5-4. Die Beispiele unterstreichen die Anwendbarkeit von Datenflußprogrammen auf verschiedenen Abstraktionsstufen. Daten und Operationen sind in Beispiel Dateifilterung auf hohem Niveau angesiedelt, in Beispiel Formelberechnung hingegen auf elementarer Ebene. Das Ausführungsmodell ist in beiden Fällen dennoch dasselbe. Dateifilterung: Die beiden Dateien A und B werden zunächst sortiert und dann gemischt. Das Resultat der Operation Mischen wird zum einen in die Datei C geschrieben und zum anderen der Operation Filtern übergeben. Die Operation Satzselektion entnimmt anhand von Satznummer einen bestimmten Satz aus Datei B. Die Operation Feldselektion entnimmt diesem Satz anhand von Feldnummer ein bestimmtes Feld. Das selektierte Feld wird in die Operation Filtern eingespeist, die aus den sortierten und gemischten Daten alle Sätze entnimmt, die zu diesem Feld passen. Die ausgewählten Sätze werden auf Liste geschrieben. Formelberechnung: Das Datenflußprogramm repräsentiert die Zuweisung an die Variablen e und f folgender (bedeutungsloser) arithmetischer Ausdrücke: e := cos a * cos b und f := e - (b + c) / d.

116 Konzepte visueller Programmiersysteme Ausführung von Datenflußprogrammen Datenflußorientierte VP-Systeme unterscheiden sich hinsichtlich der Aktivierung von Operationen grundlegend von steuerflußorientierten VP-Systemen. Während in steuerflußorientierten Systemen das Fortschreiten eines Befehlszählers die Ausführungsreihenfolge von Operationen festlegt, bestimmt in datenflußorientierten VP-Systemen der Fluß der Daten durch das System, wann eine Operation aktiviert wird. In steuerflußorientierten VP-Systemen sind Daten passive Elemente. Sie sind im Hauptspeicher abgelegt und warten sozusagen darauf, von Operationen verarbeitet zu werden. In datenflußorientierten VP-Systemen sind Daten aktive Einheiten. Sie bestimmen, welche Operationen wann zur Ausführung gelangen. Eine Operation wird dann ausgeführt, wenn alle Eingabedaten zur Verfügung stehen. Eingabedaten stammen von Datenquellen oder von anderen Operationen. Für die Berechnung der Ausgabedaten konsumiert die Operation alle Eingabedaten. Nach der Berechnung wird auf jedem der Ausgangskanäle genau ein Datenwert plaziert und in weiterer Folge an die angeschlossenen Operationen bzw. Datensenken weitergeleitet. Wichtig ist, daß jeder Ausgangskanal nur einen Datenwert erhält. Damit ist sichergestellt, daß alle Daten verarbeitet werden. Würde ein Kanal mehrfach belegt, dann könnte die nachfolgende Operationen die»überschüssigen«daten nicht berücksichtigen, weil das die Synchronisation der Eingangsdaten nicht zuläßt. Das Ausführen einer Operation wird auch Schalten genannt. Spezialoperationen, die für Ablaufstrukturen verwendet werden, können auch dann schalten, wenn nur ein Eingangskanal belegt ist (vgl. Ungerer [93 S. 36]). Bild 5-6 illustriert das Ausführungsmodell von Datenflußprogrammen anhand der schematischen Darstellung aus Bild 5-4. Operationen, zwischen denen keine Datenabhängigkeiten bestehen, können parallel ausgeführt werden. Datenflußprogramme weisen eine Reihe von Eigenschaften auf, die ein grundsätzliches Umdenken bei der Programmierung erfordern, wenn man das imperative Denkmodell gewohnt ist. Die wesentlichen Merkmale sind Implizite Ausführungsreihenfolge und Parallelität Keine Nebeneffekte Keine Variablen Spezielle Behandlung strukturierter Daten Spezialkonstrukte für Ablaufstrukturen In den folgenden Abschnitten wird jeder Punkt kurz beleuchtet. Weitere Erläuterungen findet man bei Ackerman [82] und Gajski et al. [82] Implizite Ausführungsreihenfolge und Parallelität Bei der Datenflußprogrammierung bestimmt der Programmierer, welche Daten in welche Operationen einfließen, statt anzugeben, welche Operationen wann auf welche Daten zugreifen. Er definiert Datenabhängigkeiten zwischen den Operationen, statt die Ausführungsreihenfolge der Operationen festzulegen. Dazu verbindet er Datenquellen bzw. datenproduzierende Operationen mit Datensenken bzw. datenkonsumierenden Operationen. Die Sequenz der Operationsaktivierung ist damit implizit gegeben: Operationen, die Daten produzieren, müssen vor Operationen ausgeführt werden, die diese Daten konsumieren.

117 5.2 Datenflußorientierte VP-Systeme 107 A B C P P Q S D 1. Schritt A B C P P Q R S D 2. Schritt A B C P P Q R S D T E F 3. Schritt A B C P P Q R S D T E F 4. Schritt Bild 5-6. Ausführung eines Datenflußprogramms. Das Bild zeigt die Ausführung des Datenflußprogramms aus Bild 5-4. Nach der Aktivierung der Datenquellen im ersten Schritt werden die sechs Operationen des Programms in drei weiteren Schritten ausgeführt. Zur besseren Unterscheidung sind die Knoten unterschiedlich gefärbt: datenkonsumierende Knoten weiß, datenproduzierende Knoten hellgrau und inaktive Knoten dunkelgrau. Daten, die im jeweiligen Schritt zwischen den Knoten fließen, werden als Kreise auf den Datenkanälen illustriert. Das Bild läßt erkennen, daß in den Schritten 2 und 3 mehrere Operationen gleichzeitig aktiv sind. Dies ist deshalb möglich, weil zwischen den aktiven Operationen keine Datenabhängigkeit besteht. Eine Synchronisation der parallel ausgeführten Operationen, etwa R und S in Schritt 3, ist nicht notwendig, da die nachfolgende Operation T erst dann aktiv wird, wenn alle Eingangsdaten vorliegen.

118 Konzepte visueller Programmiersysteme 108 Die implizite Ausführungsreihenfolge verursacht in jenen Fällen Probleme, wo eine bestimmte Sequenz von Operationen zwingend erforderlich ist, jedoch keine Datenabhängigkeiten zwischen den beteiligten Operationen bestehen. Möchte man etwa die Zeitdauer einer Operation messen, so ist in folgenden Schritten vorzugehen 1. aktuelle Zeit t bestimmen 2. Operation ausführen 3. aktuelle Zeit t bestimmen 4. Differenz aus t und t bilden Da zwischen der Zeitmessung und der Operation keine Datenabhängigkeit besteht, sondern nur ein zeitlicher Zusammenhang, würde der Steuermechanismus des Datenflußprogramms die Aktionen der Schritte 1, 2 und 3 in undefinierter Reihenfolge aktivieren. Lediglich Schritt 4 hätte die Ausführung von 1 und 3 zur Vorbedingung. Für solche Fälle sind in einigen VP-Systemen spezielle Sprachkonstrukte vorgesehen, die eine sequentielle Ausführung erzwingen, etwa künstliche Datenkanäle zwischen den zu sequentialisierenden Operationen oder besondere Sequentialisierungsanweisungen. Es können grundsätzlich alle Operationen parallel ausgeführt werden, zwischen denen keine Datenabhängigkeit existiert, d.h. zwischen denen weder direkt noch indirekt ein Datenaustausch stattfindet. Der Programmierer muß sich um Parallelisierung nicht kümmern. Man spricht in diesem Zusammenhang von feingranularer Parallelität, weil die Parallelverarbeitung auf der Ebene elementarer Operationen geschieht. Beispielsweise können nicht nur zwei komplexe Berechnungen parallel ausgeführt werden, sondern innerhalb der Berechnungen auch Teile eines arithmetischen Ausdrucks (siehe Bild 5-5, S. 107) Keine Nebeneffekte Ein Nebeneffekt (side effect) ist jede nicht-lokale und zeitabhängige Wirkung einer Operation, d.h. jede Wirkung mit Ausnahme der Produktion eines Resultats. Das reine Datenflußmodell ist frei von Nebeneffekten. Die Wirkung von Operationen ist immer auf den lokalen Kontext und auf die aktuelle Ausführung beschränkt. Die Zusicherung der von Aufruf zu Aufruf bei gleichen Eingabedaten invarianten Resultate bildet die Grundlage für implizite Ausführungsreihenfolge und Parallelität. Leider ist der Verzicht auf Nebeneffekte eine große Beschneidung der Ausdrucksmöglichkeiten bei der Programmierung. So schließt Nebeneffektfreiheit beispielsweise Zustandsvariablen aus, wie sie etwa für objektorientierte Programme benötigt werden und unterbindet in vielen Fällen die Nutzung globaler Systemressourcen, wie sie etwa zur Interprozeßkommunikation eingesetzt werden. Aus diesen und anderen Gründen wird bei der überwiegenden Anzahl der datenflußorientierten VP-Systeme die Nebeneffektfreiheit in bestimmten Fällen aufgegeben, was die Programmgestaltung zwar flexibler macht, die implizite Ausführungsreihenfolge und Parallelität jedoch einschränkt. Dadurch werden wieder manche Nachteile der steuerflußorientierten Programmierung eingeschleppt.

119 5.2 Datenflußorientierte VP-Systeme Keine Variablen In visuellen Datenflußprogrammen ist es nicht notwendig, die Daten in Variablen abzulegen, weil die Daten konzeptionell auf den Datenkanälen gespeichert werden. Jedes Ergebnis einer Operation wird über die angeschlossenen Ausgangskanäle direkt an andere Operationen oder Datensenken weitergeleitet, ohne daß dazu ein Zwischenbehälter in Form einer Variablen benötigt würde. Durch das Fehlen von Variablen ist die Nebeneffektfreiheit im Zusammenhang mit der impliziten Ausführungsreihenfolge sichergestellt. Die Verwendung von Variablen würde nämlich unsichtbare Datenabhängigkeiten zwischen Operationen herstellen, wodurch die deterministische Berechnung von Resultaten nicht mehr gewährleistet wäre. Zwei scheinbar voneinander unabhängige Operationen A und B, zwischen denen zwar keine Datenkanäle existieren, die aber auf eine gemeinsame Variable V zugreifen, wären über diese Variable gekoppelt, wenn A auf V schreibt und B von V liest. Es wäre in diesem Fall nicht mehr möglich, die Ausführungsreihenfolge nur anhand der Datenabhängigkeiten zu bestimmen, wodurch der datenflußorientierte Steuerungsmechanismus nicht mehr funktionieren würde. In textuellen Datenflußsprachen, wo es keine Datenkanäle gibt, ist es oftmals notwendig, die Resultate von Operationen zwischenzuspeichern, um Mehrfachberechnungen zu vermeiden. Für diese temporäre Speicherung und für Schleifenindizes werden Variablen benötigt. Für die Verwendung von Variablen gilt das Einmalzuweisungsprinzip, d.h. jeder Variablen darf nur einmal während der Aktivierung einer Operation (bei Laufvariablen einmal während eines Schleifendurchlaufs) ein Wert zugewiesen werden. Die Zuweisung muß erfolgen, bevor die Variable das erste Mal verwendet wird. Alle anderen Zugriffe haben lesend zu erfolgen. Zuweisungen an Variablen haben demzufolge keine andere Wirkung als einen bestimmten Wert an einen Namen zu binden. Mit anderen Worten: eine Variable repräsentiert in Datenflußsprachen einen Wert, nicht eine Speicherstelle. Dieser Wert überall dort eingesetzt werden, wo die Variable auf der rechten Seite eines Ausdrucks vorkommt. Dadurch ist wiederum die Nebeneffektfreiheit garantiert. Das Fehlen von Variablen wird allgemein als großer Vorteil datenflußorientierter Systeme angesehen, da der Programmierer nicht darüber nachdenken muß, welche Auswirkungen die Zuweisung an eine Variable an jenen Programmstellen hat, wo diese Variable verwendet wird. Zudem ist der Programmierer von Überlegungen zur Speicherverwaltung befreit, da Speicheranforderungen von elementaren Operationen selbsttätig vorgenommen werden und eine automatische Speicherbereinigung nicht länger benötigte Daten freigibt. Schwierig zu erkennende Fehlerquellen sind somit von vornherein ausgeschlossen Spezielle Behandlung strukturierter Daten Bei gleichzeitiger Verwendung desselben strukturierten Datums in mehreren Operationen, sind besondere Vorkehrungen zu treffen, um die vom Datenflußmodell geforderte Nebeneffektfreiheit zu garantieren. Bei elementaren Daten, wie Zahlen und Zeichen, gibt es keine Schwierigkeiten, weil elementare Daten prinzipiell nicht modifizierbar sind (eine Zahl oder ein Zeichen steht immer für sich selbst). Aus diesem Grund kann die Verwendung eines elementaren Da-

120 Konzepte visueller Programmiersysteme 110 tums in einer Operation niemals Einfluß auf eine andere Operation haben, die auf ein Datum mit demselben Wert zugreift. Anders ist die Situation bei strukturierten Daten, wie Feldern und Verbunden, die aus mehreren elementaren oder wiederum strukturierten Daten bestehen. Solche Datenstrukturen sind Element für Element modifizierbar. Im Sinne einer effizienten Verarbeitung werden meist nur Zeiger auf strukturierte Daten von Operation zu Operation weitergeleitet. Solange über diese Zeiger nur lesend auf die Daten zugegriffen wird, treten keine Probleme auf. Eine Modifikation löst jedoch einen Nebeneffekt bei allen Operationen aus, die auf dasselbe Datum zugreifen. Es könnte etwa vorkommen, daß eine Operation ein Feldelement modifiziert, das in einer parallel ausgeführten Operation gelesen wird. In diesem Fall wären die Resultate nicht mehr eindeutig, weil es darauf ankäme, welche Operation zuerst ausgeführt wird. Ein weiteres offensichtliches Beispiel sind Ein- und Ausgabeoperationen auf Dateien. Um die Nebeneffektfreiheit zu gewährleisten und ein nicht-deterministisches Verhalten zu vermeiden, muß das Laufzeitsystem vor Ausführen einer Operation, die strukturierte Daten modifiziert, diese zuerst kopieren. Für große Datenstrukturen, wie sie etwa in der Bildverarbeitung vorkommen, kann dies mit massiven Laufzeiteinbußen und beachtlichem Speicherbedarf verbunden sein. Bei manchen Datentypen kann die Nebeneffektfreiheit grundsätzlich nicht garantiert werden. Dazu gehören globale Systemressourcen, wie Dateien und andere Betriebssystemobjekte. Wird etwa eine Dateireferenz parallel an mehrere Operationen weitergeleitet, so kann das Laufzeitsystem die Nebeneffektfreiheit nicht aufrechterhalten, da ein Kopieren der Datei nicht in Frage kommt Spezialkonstrukte für Ablaufstrukturen Verzweigungen, Fallunterscheidungen und Schleifen sind in Datenflußprogrammen schwer zu realisieren. Sie erfordern spezielle Operationen, die Einführung von Zyklen im Datenflußdiagramm, die Erweiterung der Schaltregeln und das Konzept der Vorbelegung von Datenkanälen mit bestimmten Werten. Ein Beispiel für die Notwendigkeit solcher Erweiterungen ist die Berechnung der Nullstelle einer Funktion nach dem Newtonschen Verfahren. Bild 5-7 zeigt das dazugehörende Datenflußprogramm. Es enthält zwei spezielle Operationen, die Auswahl (selector) und den Verteiler (distributor). Die Auswahl selektiert anhand eines booleschen Wertes einen der beiden Eingänge und stellt das dort anliegende Datum auf den Ausgang. Diese Operation schaltet auch dann, wenn nur ein Eingang belegt ist. Der Verteiler funktioniert umgekehrt. Er selektiert anhand eines booleschen Wertes einen der beiden Ausgänge und stellt das am Eingang anliegende Datum auf den selektierten Kanal. Wie Bild 5-7 illustriert, führen Ablaufstrukturen zu schwer verständlichen Diagrammen. Es ist nicht länger auf einen Blick klar, unter welchen Umständen ein Kanal belegt wird und wann eine Operation aktiviert wird. Zudem wird es schwieriger die Datenflußkorrektheit eines Programms zu garantieren, d.h. sicherzustellen, daß jeder Kanal zu jedem Zeitpunkt nur ein Datum transportiert. Die Erweiterung der Schaltregeln durch die Auswahloperation macht dies besonders schwierig. Wegen dieser und anderer Gründe hat man versucht, datenflußorientierte VP-Systeme mit besonderen Strukturierungsmechanismen auszustatten. Besonders gut ist dies in LabVIEW gelungen. Bild 5-8 zeigt das Newtonsche Verfahren aus Bild 5-7 als strukturiertes LabVIEW-Diagramm.

121 5.2 Datenflußorientierte VP-Systeme 111 abs (x k - x k+1 ) < eps x 0 eps F distributor T C < T selector F C T abs x k X k+1 - / x f f' x k+1 = x k - f(x k ) / f (x k ) Bild 5-7. Das Newtonsche Verfahren als Datenflußprogramm. Beim Newtonschen Verfahren zur näherungsweisen Bestimmung der Nullstelle x einer Gleichung f(x) = 0 wird die Ableitung f (x) gebildet und eine erste Näherung durch x 1 = x 0 - f(x 0 ) / f (x 0 ) erreicht, wobei x 0 ein Schätzwert für die Nullstelle ist. Dieses Verfahren läßt sich mit der Iterationsvorschrift x k+1 = x k - f(x k ) / f (x k ), k = 0, 1, 2,... iterativ auf x 1 und alle weiteren Näherungen anwenden, wodurch x k+1 gegen die gesuchte Nullstelle konvergiert. Das Verfahren wird abgebrochen, wenn zwei aufeinanderfolgende Näherungswerte nur noch um weniger als einen bestimmten Betrag eps voneinander abweichen, d.h. abs(x k - x k+1 ) < eps erfüllt ist. Das Diagramm enthält die Datenquellen x 0 und eps, die Datensenke x und zwei Operationen distributor und selector, die spezielle Schaltregeln besitzen. Die Operation distributor leitet das am Eingangskanal anliegende Datum x k+1 in Abhängigkeit des booleschen Wertes C (control) entweder an den Ausgangskanal T (true) oder an F (false) weiter. Die Operation selector leitet das an einem der Eingangskanäle liegende Datum x 0 bzw. x k+1 an in Abhängigkeit des booleschen Wertes C an den Ausgangskanal weiter. C muß mit True vorbelegt werden, damit zu Beginn der Operation x 0 durchgereicht wird. Bei allen anderen Iterationen mit Ausnahme der letzten, liegt an C der Wert False an. Bei der letzten Iteration schaltet selector jedoch nicht mehr, da an keinen der Eingänge ein Datum anliegt.

122 Konzepte visueller Programmiersysteme 112 Bild 5-8. Das Newtonsche Verfahren als Datenflußdiagramm in LabVIEW. Das Bild zeigt ein strukturiertes Datenflußdiagramm in der Notation von LabVIEW zur näherungsweisen Bestimmung der Nullstelle einer Gleichung nach dem Newtonschen Verfahren (vgl. Bild 5-7). Die Notation und das Diagramm werden in Abschnitt 6.3.3, S. 140, näher erklärt. 5.3 Funktionsorientierte VP-Systeme Die Konzepte funktionsorientierter VP-Systeme gehen auf Backus [78] zurück, der die funktionalen Programmiersysteme (kurz FP-Systeme) entwickelte. In seiner berühmten Turing-Awards-Rede kritisierte er imperative Programmiersprachen in vielerlei Hinsicht, und dies obwohl er gerade wegen seiner Verdienste um die Entwicklung solcher Sprachen (insbesondere von Fortran) ausgezeichnet wurde. Vor allem die Zuweisungsoperation (assignment statement) identifizierte er als Ursache struktureller Defizite von imperativer Programmen [S. 616]. Als Alternative zu imperativen Sprachen, schlug Backus die erwähnten FP-Systeme vor. Ein FP-System besteht aus einer Menge von Objekten, einer Menge von Funktionen, die Objekte auf Objekte abbilden, einer Menge von funktionalen Formen zur Kombination von Funktionen oder Objekten, um daraus neue Funktionen zu erzeugen, und einer Menge von Definitionen, die Symbole an Funktionen binden. Variablen und Wertzuweisungen gibt es nicht. FP-Systeme können als einfache Programmiersprachen gesehen werden und eignen sich gut dafür, eine Algebra von Programmen zu definieren, mit der etwa bestimmte Eigenschaften eines Programms bewiesen werden können. FP-Systeme und andere Ansätze, etwa das Lambda-Kalkül (vgl. Sethi [89 S. 423 ff]), bilden den theoretischen Unterbau sowohl von funktionsorientierten als auch von datenflußorientierten VP-Systemen. Bei funktionsorientierten VP-Systemen bleiben die Eigenschaften datenflußorientierter Systeme erhalten, werden jedoch meist strenger interpretiert und um Konzepte ergänzt, mit denen die Vorteile des klassischen funktionalen Paradigmas nutzbar gemacht werden können. Dazu gehören (vgl. Poswig [93 S. 38 ff, S. 49 ff und S. 166 ff]): Funktionen höherer Ordnung, die Funktionen als Argumente haben. Polymorphe Funktionen, die mit parametrischen oder spontanem Polymorphismus arbeiten. Beim parametrischen Polymorphismus akzeptiert eine Funktion Argumente unterschiedlichen Typs und verhält sich für jede Typvariante gleicht. Beim spontanen Polymorphismus (Ad-hoc-Polymorphismus, Überladung) wird derselbe Bezeichner für Funktionen mit unterschiedlichen Parametertypen vergeben, wodurch für jede Typvariante ein anderes Verhalten definiert werden kann.

123 5.3 Funktionsorientierte VP-Systeme 113 Implizite Typsysteme, mit denen der Typ jedes Ausdrucks automatisch anhand von Annahmen und Regeln abgeleitet wird. Implizite Typsysteme verbinden die Flexibilität dynamischer Typisierung mit der Sicherheit statischer Typisierung. Poswig [96 S. 53] nennt als Beispiele für visuelle Programmierung auf Grundlage funktionaler Programmierung u.a. PiP von Raeder [84], Tinkertoy von Edel [88], Enhanced- Show-and-Tell von Najork und Golin [90] sowie die auf dem Lambda-Kalkül beruhende visuelle Sprache viz von Holt [90]. Weitere von Poswig in diesem Zusammenhang angeführte Systeme zählen bei genauerer Betrachtung eher zur datenflußorientierten als zur funktionalen Programmierung. Das Studium der Literatur zeigt, daß außer den von Poswig genannten Systemen und seines eigenen Systems VisaVis kaum weitere funktionsorientierte VP-Systeme existieren. Dies verwundert nicht, da die funktionale Programmierung aus dem Bedürfnis nach mathematischer Formalisierung entstand und textuelle Notationen dafür bedeutend besser geeignet sind als grafische Darstellungen. Ein funktionales Programm kann visuell als Funktionsdiagramm dargestellt werden (siehe Bild 5-9). Ein Funktionsdiagramm ist ein gerichteter Graph mit Parametern, Resultaten und Funktionen als Knoten sowie Wertekanälen als Kanten. Verzweigungen werden durch Prädikatsfunktionen dargestellt. Es gibt kein Konstrukt für Schleifen. Diese müssen durch rekursive Funktionsaufrufe nachgebildet werden. Rein funktionale Sprachen leiden an denselben Schwächen wie reine Datenflußsprachen: Sie sind ineffizient und für die Programmierung interaktiver Systeme unbrauchbar. Die für einen breiteren Anwendungsbereich notwendigen Erweiterungen um imperative Konzepte untergraben wiederum die mathematischen Eigenschaften und somit die Grundidee funktionaler Ansätze. Die Stärken funktionaler Sprachen liegen vor allem im algorithmischen Bereich, der jedoch durch konventionelle Funktionsbibliotheken ebenfalls gut abgedeckt ist. Der Anreiz, funktionsorientierte VP-Systeme zu entwickeln, ist deshalb gering.

124 Konzepte visueller Programmiersysteme 114 Bild 5-9. Funktionsdiagramm in VisaVis. Vgl. Poswig [96 S. 71 f und S. 92] Das Bild zeigt den Quicksort-Algorithmus als Funktionsdiagramm des VP-Systems VisaVis. Das Symbol unsorted repräsentiert einen Parameter (eine unsortierte Liste), das Symbol sorted ein Resultat (eine sortierte Liste). PredicateBox ist eine Verzweigung. Sie stellt mit Hilfe der Prädikatsfunktion IsEmpty fest, ob die Eingabe leer ist oder nicht und leitet das Ergebnis je nachdem an das Resultat sorted oder die Funktionen Rest und First weiter. FilterWithArg ist eine Funktion zweiter Ordnung mit einer Funktion erster Ordnung als Parameter. FilterWithArg selektiert aufgrund der Prädikatsfunktion LessThan bzw. GreaterOrEqual Elemente der unsortierten Teillisten und leitet die selektierten Elemente an den rekursiven Aufruf von Quicksort weiter. Die Notation von VisaVis wird in Abschnitt 6.4.3, S. 150, näher erklärt. 5.4 Objektorientierte VP-Systeme Diese Systeme beruhen auf Variationen der Konzepte objektorientierter Programmierung (OOP). In objektorientierten VP-Systemen wird Software meist auf zwei eng verbundenen Ebenen erstellt: (1) zur Entwicklung von Programmbausteinen verwendet man eine verbale Programmiersprache und Klassenbibliotheken; (2) zur Entwicklung von Applikationen verwendet man die verbal erstellten Bausteine und verbindet sie visuell zu komplexeren Einheiten. Ein Programmbaustein ist eine spezielle Form eines Objekts. Struktur und Teile des Verhaltens sind in einer Klasse beschrieben. Zusätzlich kann mit Skriptsprachen exemplarspezifisches Verhalten definiert werden. Ein Baustein verfügt über eine Schnittstelle zur Kommunikation mit anderen Bausteinen, die Attribute, Ereignisse und Nachrichten umfaßt. Attribute sind Werte wie Größe, Position und Farbe. Ereignisse signalisieren Benutzeraktionen bzw. Zustandsänderungen. Nachrichten lösen Operationen aus, lesen Attribute und verändern Attribute. Bausteine werden über Verbindungen zueinander in Beziehung gesetzt. Verbindungen sind gerichtete Daten- und Kommunikationskanäle. Ereignisverbindungen verknüpfen Ereignisse mit Nachrichten. Resultatverbindungen verknüpfen Ergebnisse von Nachrichten mit Nachrichten. Argumentverbindungen verknüpfen Argumente einer Nachricht mit dem Resultat einer Nachricht. Attributverbindungen gleichen die Attribute von Objekten ab. Bausteine sind in Katalogen organisiert. Von dort kann man sie mit Drag-

125 5.4 Objektorientierte VP-Systeme 115 und-drop entnehmen und auf einer Arbeitsfläche plazieren, wo man mit ihnen die Benutzungsschnittstelle baut und die Programmlogik erstellt (siehe Bild 5-10). Bild Objektorientiertes Programm in PARTS. Das Bild zeigt ein objektorientiertes Programm zur Umwandlung von Fahrenheit nach Celsius- Werten in der Notation von PARTS. Die Notation wird in Abschnitt 6.5.3, S. 164, näher erklärt. Das objektorientierte Denkmodell leistet durch seine methodischen und technischen Konzepte einen bedeutenden Beitrag zur Produktion von Qualitätssoftware. Es verbessert insbesondere die Erweiterbarkeit, Wiederverwendbarkeit und Wartbarkeit von Software. Die problemgerechte Art der Modellierung, die imaginäre Sachverhalte oder Ausschnitte der realen Welt in Form von kooperierenden Objekten erfaßt, erlaubt eine bessere Umsetzung der Aufgabenstellung in eine softwaretechnische Realisierung, als dies etwa mit funktionalen Ansätzen möglich ist. Die computergestützte Simulation ist ein klassisches Beispiel für ein Anwendungsgebiet, wo die Stärken der OOP deutlich zum Tragen kommen. So sind etwa für die Simulation einer einfachen Fließbandfertigung die benötigten Programmkomponenten leicht zu identifizieren: Maschinen, Transportvorrichtungen, Produkte usw. können als Objekte modelliert werden, die einen bestimmten Teilbereich der Simulation abdecken. Das Zusammenspiel dieser Objekte ist durch einen überschaubaren Satz an Nachrichten verhältnismäßig einfach zu beschreiben. So könnte etwa ein Maschinenobjekt, das ein Teilprodukt X»gefertigt«hat, dieses an ein Fließbandobjekt mit der Nachricht Transportiere X übergeben, worauf das Fließbandobjekt das Produkt X nach einer gewissen Zeitverzögerung an die nächste Maschine mit der Nachricht Bearbeite X weiterleiten würde. Selbstverständlich sind Entwurf und Implementierung einer kompletten Fertigungssimulation auch mit OOP keine leichten Aufgaben, doch die realitätsnahe Modellierung und die besonderen Konzepte objektorientierter Programmiersprachen

126 Konzepte visueller Programmiersysteme 116 führen meist zu einer deutlich höheren Produktivität als bei konventioneller Softwareentwicklung. Die bei OOP gegebene enge Verbindung von Problem und Lösung legt eine visuelle Repräsentation von Objekten nahe. Geeignete grafische Darstellungen und visuelle Interaktionsmechanismen können die Problemmodellierung unterstützen und die Softwarekonstruktion erleichtern, indem sie eine metaphorische Korrespondenz mit der realen oder imaginären Problemwelt herstellen (siehe Abschnitt»Kognitive Aspekte«, S. 48). Kommerzielle, objektorientierte VP-Systeme, wie PARTS und VisualAge, bieten eine Fülle von vorgefertigten, anschaulich visualisierten Objekten, die interaktiv zu neuen Objekten kombinierbar sind. Komfortable Benutzungsschnittstellen-Editoren, die nahtlos in die Programmierumgebung integriert sind, unterstützen den Konstruktionsprozeß zusätzlich. Für die programmtechnische Verwendung der Benutzungsschnittstellen-Objekte stehen die gleichen Hilfsmittel zur Verfügung wie für alle anderen Objekte. Dadurch wird ein konzeptioneller Bruch zwischen Implementierung der Benutzungsschnittstelle und Implementierung der Programmlogik vermieden. Die Vorteile der visuellen Repräsentation und direkten Manipulation objektorientierter Programme werden jedoch durch einige Nachteile eingeschränkt, die im folgenden exemplarisch angeführt sind. Tendenz zur Unübersichtlichkeit. Der meist komplexe Nachrichtenfluß zwischen Objekten führt bei gängigen Notationen, die Nachrichten als Pfeile zwischen Objekten darstellen, zu einer großen Zahl von Linienzügen und unvermeidlichen Überkreuzungen. Zudem ist die Kenntnis der Namen von Nachrichten unverzichtbar, um das Zusammenwirken der Objekte verstehen zu können. Linien, die mit Nachrichtenamen versehen sind, vergrößern die optische Konfusion jedoch zusätzlich. Das Verständnis für die Struktur des Programms geht dadurch verloren. Keine Methoden und keine Vererbung. Objektorientierte VP-Systeme bieten oft keine Möglichkeit, visuelle Codestücke zu Methoden zusammenzufassen und Objekteigenschaften zu vererben. In diesen Systemen gibt es für visuell konstruierte Objekte nur die Enthalten-Sein-Beziehung (A ist ein Teil von B) aber nicht die Subtyp-Beziehung (A ist eine Spezialisierung von B). Die Wartbarkeit und Erweiterbarkeit wird dadurch stark eingeschränkt. Um dieses Problem abzuschwächen, erlauben einige objektorientierten VP-Systeme die Erstellung von textuellem Programmcode mit Hilfe von Skriptsprachen. Probleme mit Objekterzeugung und Polymorphismus. Der konstruktive Charakter der visuellen Programmierung widerspricht zwei wesentlichen Eigenschaften der OOP: der Erzeugung von Objekten zur Laufzeit und dem Polymorphismus. Als Polymorphismus bezeichnet man die Fähigkeit einer Variablen, Objekte verschiedenen Typs zu referenzieren. Dadurch ist es möglich, Programmcode zu schreiben, der unabhängig von Objekten eines bestimmten Typs funktioniert. Bei der visuellen Programmkonstruktion arbeitet der Programmierer jedoch in aller Regel mit konkreten Objekten und verknüpft diese zu Programmen mit einer fixen Anzahl von Objekten und festen Verbindungen zwischen den Objekten. Polymorphismus ist für solche Programme nicht möglich. Um Objekte dynamisch erzeugen und den Polymorphismus nützen zu können, braucht man spezielle Konstrukte, etwa Objektgeneratoren und Objektvariablen. Durch solche Hilfsmittel entsteht jedoch eine Diskrepanz zwischen dem, was der Programmierer sieht (die Variable), und dem, was sich hinter dem Gesehenen verbirgt (das Objekt). Diesen Verlust von Anschaulichkeit sollte visuelle Programmierung aber gerade vermeiden und

127 5.5 Constraintorientierte VP-Systeme 117 deshalb passen Objekterzeugung und Polymorphismus mit visueller Programmierung schlecht zusammen. Eine Einführung in die objektorientierte Denkweise und Softwareentwicklung geben Meyer [88, deutsch 90], Budd [90], Korson und McGregor [90] sowie Pomberger und Blaschek [96]. Ein Überblick über die Grundlagen der visuellen objektorientierten Programmierung findet sich bei Burnett et al. [94]. 5.5 Constraintorientierte VP-Systeme In constraintorientierten VP-Systemen gibt es keine algorithmischen Programmkonstrukte, wie Wertzuweisungen, Prozeduren oder Ablaufstrukturen. Ein Programm besteht aus einer Menge von Objekten (Werten, Variablen) und eine Menge von Beziehungen zwischen den Objekten, die ständig gelten müssen. Diese Beziehungen nennt man Constraints. Ein automatischer Mechanismus, der Constraint-Satisfier, sorgt dafür, daß die Constraints bestehen bleiben, wenn sich Objektattribute ändern. Anders als bei Funktionen wird bei Constraints zwischen Eingabe- und Ausgabedaten nicht unterschieden: Constraints sind ungerichtet, d.h. man braucht nicht zu definieren, welche Größe der Ausgangspunkt für die Berechnung einer anderen Größe ist. Bild 5-11 zeigt Constraints in ThingLab von Borning [81] zur Umrechnung von Temperaturwerten in Fahrenheit und Celsius anhand der Formel f = c * 1, Weil Constraints ungerichtet sind, wird nicht nur die ursprüngliche Gleichung erfaßt, sondern auch die Umformung c = (f - 32) / 1,8. Der Constraint-Satisfier aktualisiert automatisch den entsprechenden Gegenwert. Die Ankersymbole unter 32 und 1,8 bedeuten, daß der Constraint-Satisfier diese Werte nicht verändern darf. f = 212 c = ,8 Bild Constraints in ThingLab. Vgl. Borning [81] in Glinert [90-P&S S. 430] Das erste System zur grafischen Darstellung von Constraints war Sketchpad von Sutherland [63]. Dieses Programm zum Zeichnen von Vektorgrafiken berücksichtige geometrische Beziehungen (z.b. Größenverhältnisse) und andere Zusammenhänge (z.b. topologische Relationen) zwischen grafischen Elementen. Sutherland führt verschiedene Anwendungsbereiche für Sketchpad an, u.a. den Entwurf von Gestängen und Brückenkonstruktion. Auch Borning et al. [87] in Glinert [90-P&S S. 470] nennen eine Vielzahl von Einsatzgebieten für constraintorientierte Programmierung, darunter Lösungsverfahren für geometrische Probleme, die Simulation physikalischer Prozesse, die Konstruktion von Benutzungsschnittstellen, die Formatierung von Dokumenten, die

128 Konzepte visueller Programmiersysteme 118 Animation von Algorithmen und den Entwurf elektronischer Schaltkreise. Über die mit Constraints zu bewältigende Problemkomplexität machen sie jedoch keine Aussage. Die von Borning [81] in Glinert [90-P&S S. 418] angeführten Beispiele für constraintorientierte Programme, die mit dem experimentellen VP-System ThingLab erstellt wurden, deuten jedoch darauf hin, daß damit eher einfache als schwierige Probleme zu bewältigen sind. Er erwähnt u.a. eine Linie, die immer horizontal bleibt; ein Dreieck, das immer doppelt so groß ist wie ein anderes Dreieck; ein Rechteck, dessen Höhe mit einem Zahlenwert in einer Tabelle korrespondiert; einen Widerstand, der dem Ohm schen Gesetzes gehorcht und einen Rahmen am Bildschirm, der sich in der Größe einem Textstück anpaßt. Maloney et al. [94 S. 125] weisen darauf hin, daß auch die Nachfolgeversion ThingLab II keinem Praxistest unterzogen wurde und das mit dieser Version angestrebte Ziel, eine Entwicklungsumgebung für vollwertige Benutzungsschnittstellen zu bieten, noch nicht erreicht werden konnte. Maloney et al. erwähnen außerdem die Definition von Mehrfachsichten auf Daten als eine typische Aufgabenstellung für die Anwendung von Constraints bei der Konstruktion von Benutzungsschnittstellen [S. 115]. Ein Beispiel für Mehrfachsichten ist eine Zahl, die sowohl in einem Eingabefeld als auch durch einen Schieberegler dargestellt wird. Wenn sich die Zahl ändert, sei es durch die Programmlogik oder durch eine Benutzereingabe, sollen sowohl der Wert im Eingabefeld als auch die Position des Schiebereglers automatisch angepaßt werden. Maloney et al. meinen, daß sich Constraints als ein Ansatz erweisen könnten, der bequemer und verläßlicher ist als der dafür gewöhnlich verwendete Change-Update-Mechanismus auf Basis der MVC-Architektur (vgl. Leibs und Rubin [92]). Die Praxis zeigt jedoch, daß sich für diesen Anwendungsfall der Change-Update-Mechanismus klar durchgesetzt hat. Die Programmierung mit constraintorientierten VP-Systemen entspricht konzeptionell der logischen Programmierung, deren Denkmodell sich von der imperativen und funktionalen Programmierung grundlegend unterscheidet. Zur Berechnung von gesuchten Größen aus gegebenen Größen verwendet man in der logischen Programmierung sogenannte Relationen. Diese unterscheiden sich von Funktionen u.a. dadurch, daß sie wie Constraints ungerichtet sind, d.h. Argumente und Resultate gleich behandeln (vgl. Sethi [89 S. 297]). Relationen definieren einen Satz von Regeln, die auf die zu bestimmenden Größen anwendbar sind. Bei einer Anfrage in Form eines Prädikats bestimmt ein generischer Algorithmus eine Lösung unter Zuhilfenahme dieser Regeln. Constraints entsprechen den Relationen und Regeln der logischen Programmierung. Das Finden einer Kombination für Objektattribute, die alle Constraints erfüllt, ähnelt der Ableitung einer Lösung für ein Prädikat. So wie bei logischer Programmierung definiert man auch bei constraintorientierter Programmierung nur was gemacht werden soll, aber nicht wie es gemacht werden soll. Man nennt diese Art der Programmierung deshalb deklarative Programmierung. Ein offensichtliches Problem bei der constraintorientierten Programmierung sind Unterund Überspezifikationen, die zu wenige bzw. zu viele Constraints umfassen. In diesen Fällen findet der Constraint-Satisfier keine oder mehrere Lösungen (vgl. Borning et al. [87] in Glinert [90-P&S S. 470]. Ein Beispiel für Unterspezifikation ist eine Linie, deren Mittelpunkt markiert sein soll. Dafür kann man folgendes Constraint angeben:»zwischen einer Markierung und einer Linie besteht die Beziehung, daß die Markierung immer am Mittelpunkt der Linie liegt«. Wenn der Benutzer die Linie an einem Endpunkt selektiert und den Bildschirmzeiger bewegt, so kann der Constraint-Satisfier auf drei Arten reagieren. (1) Der selektierte Endpunkt bewegt sich, der andere Endpunkt

129 5.6 Regelorientierte VP-Systeme 119 bleibt fix, und die Markierung des Mittelpunkts wird angepaßt. (2) Der Mittelpunkt bleibt fix, und die Endpunkte passen sich an. (3) Die ganze Linie verschiebt sich samt Mittelpunkt, ohne Winkel und Länge zu verändern. Der Benutzer wird die erste Reaktion am ehesten erwarten, die letzte wohl kaum. Borning et al. sprechen in diesem Zusammenhang vom»prinzip des geringsten Erstaunens«, das der Constraint-Satisfier zu berücksichtigen hat. Ein Beispiel für Überspezifikation ist, wenn ein Endpunkt einer Linie immer an derselben Position bleiben müßte, die Linie immer horizontal sein müßte und der Benutzer den anderen Endpunkt in vertikaler Richtung zu bewegen versucht. In diesem Fall könnte der Constraint-Satisfier keine Lösung finden, und die Linie bliebe unbewegt. Da sich die geschilderten Wechselwirkungen zwischen Constraints nicht immer ausschließen lassen, muß definierbar sein, welche Constraints aufzugeben sind, wenn eine Lösung sonst nicht möglich ist. Auf diese Weise entstehen Constraint-Hierarchien mit absteigender Priorität von einer Ebene zur nächsten. Weitere Probleme ergeben sich, wenn die Constraints zeitliche Bedingungen erfassen sollen. In diesem Fall ist die Gleichwertigkeit von Objekten bei der Constraint-Lösung nicht mehr gegeben, da die Zeit monoton fortschreitet und etwa das Vor- oder Zurücksetzen einer Uhr zu ungültigen Zuständen führen könnte. Duisberg [88] schlägt deshalb Erweiterungen des ursprünglichen Modells um temporale Constraints und andere Konstrukte vor. Ein nicht unerheblicher Schwachpunkt von constraintorientierten VP-Systemen sind die langen Laufzeiten von gängigen Algorithmen für den Constraint-Satisfier. Maloney et al. [94 S. 123 f] führen Messungen für den in ThingLab II verwendeten DeltaBlue- Algorithmus an, die zeigen, daß für eine kleine interaktive Anwendung mit 50 Constraints beinahe eine Sekunde vergeht, bis das System auf Benutzeraktionen reagiert. Selbst unter Berücksichtigung der geringen Leistung der damals verwendeten Hardware und der interpretierenden Ausführung, scheint dieser Wert hoch. Mit kompilierenden Constraint-Systemen könnten hinsichtlich der Laufzeiten eventuell Verbesserungen erzielt werden. Borning et al. [87] in Glinert [90-P&S S. 470] sprechen als weitere offene Punkte die Notwendigkeit von bedingten und iterativen Constraints an, um gewisse Problemstellungen überhaupt bewältigen zu können. Wenn die Idee auch verlockend erscheinen mag, Probleme nur zu spezifizieren, aber nicht algorithmisch zu lösen, so zeigen diese Beispiele, daß die deklarative Programmierung mit Constraints doch schnell an Grenzen stößt. 5.6 Regelorientierte VP-Systeme In regelorientierten VP-Systemen werden Programme als Folge von Bildtransformationen beschrieben. Typische Anwendungsgebiete sind z.b. Simulationen aus dem Bereich der Biologie, Chemie und Elektronik. Auch für Kinder sind solche Systeme geeignet. Ein Beispiel dafür ist das VP-System LEGOsheets von Gindling et al. [95], mit dem physikalische Artefakte, wie Fahrzeuge und Roboter, regelorientiert programmiert werden können. Mit LEGOsheets kann man beispielsweise ein fahrbares Gerät bauen, das in einem Raum nach der hellsten Stelle sucht [S. 174]. Ein regelorientiertes Programm besteht aus einer Menge von grafischen Transformationsregeln mit optionalen Bedingungen und Aktionen. Eingabe für das Programm ist eine umzuformende Grafik. Eine Transformationsregel besteht aus einer linken und

130 Konzepte visueller Programmiersysteme 120 rechten Grafik. Links wird ein Bildausschnitt vor der Transformation dargestellt (Muster), rechts der umgeformte Ausschnitt (Resultat). Bei der Ausführung eines Programms versucht das VP-System durch Mustervergleich (unter Berücksichtigung der Bedingungen) eine der linken Regelseiten in der umzuformenden Grafik zu finden. Gefundene Ausschnitte werden durch die Darstellung der rechte Seite ersetzt, wobei eventuell zusätzliche Aktionen ausgeführt werden. Der Mustervergleich wird ständig wiederholt und kontinuierlich visualisiert, wodurch gewissermaßen ein Film abläuft. Das Programm endet, wenn das System keinen Ausschnitt mehr findet, der zu einer Regel paßt, oder der Benutzer das Programm abbricht. Bild 5-12 zeigt zwei Regeln des VP-Systems ChemTrains von Bell und Lewis [93] für die Definition eines Und-Gatters. Durch die flexible Mustererkennung des Systems genügt nur eine Regel für das Resultat 0. Ähnliche Regeln sind für andere Gatter und Schaltelemente definierbar, die man zu Schaltnetzen verknüpfen und interaktiv simulieren kann. Muster Resultat 0 & 0 1 & 0 Regel 1: Und-Gatter mit Resultat & & 1 Regel 2: Und-Gatter mit Resultat 1 Bild Transformationsregeln in ChemTrains. Vgl. Bell und Lewis [93 S. 188] Bell und Lewis erwähnen einige Probleme, die mit regelorientierten VP-Systemen verbunden sind [S. 192 u. 194 f]. Dazu gehört insbesondere die Behandlung von Konflikten, falls mehrere Regeln auf einen Bildausschnitt zutreffen. Dieses Problem kann in einigen Fällen durch eine Reihung der Regeln gelöst werden. Für bestimmte Simulationsanwendungen muß es zusätzlich die Möglichkeit geben, Regeln mit Wahrscheinlichkeitswerten zu versehen. Wenn Wahlfreiheit zwischen mehreren Regeln besteht, dann bestimmt in diesem Fall ein Zufallsgenerator anhand der Wahrscheinlichkeitswerte, welche Regel auszuführen ist. Weiters sollte die Beschreibung von Mustern durch Angabe von geometrischen und topologischen Relationen möglich sein. Spezifikationen wie»45 mm links davon«,»direkt unterhalb«oder»eingeschlossen von«können zu flexibleren Regeln führen. Zudem ist es in einigen Systemen nicht möglich, das Fehlen von Bildelementen zu spezifizieren, wodurch komplizierte Behelfskonstrukte notwendig sind.

131 5.6 Regelorientierte VP-Systeme 121 Start Start Condition False Condition False True True False Condition True False Condition True Action Action Action Action End End Bild Wohlgeformtes und unstrukturiertes Flußdiagramm. Vgl. Schürr et al. [95 S. 327, Fig. 1] Das linke Flußdiagramm besteht aus einer While-Schleife und einer If-Anweisung. Dieses Diagramm ist wohlgeformt im Sinne der strukturierten Programmierung. Das rechte Flußdiagramm enthält eine Sprunganweisung. Es ist unstrukturiert. Schürr et al. beschreiben eine Graphgrammatik, die beide Diagramme schrittweise auf einfachere Formen reduziert. Links ist eine Reduktion auf den leeren Graph möglich, woraus folgt, daß es sich um ein wohlgeformtes Diagramm handelt. Rechts bleiben Teile übrig, was bedeutet, daß ein unstrukturiertes Diagramm vorliegt. Repenning [95 S. 229] weist auf die kombinatorische Explosion der Regelanzahl hin, wenn realistische Szenarien zu definieren sind. Für die Beschreibung der simulierten Fahrt eines Autos entlang einer Straße errechnet er für den schlechtesten Fall 4096 Regeln. Diese Anzahl ergibt sich aus 4 möglichen Richtungen, 4 Fahrtmöglichkeiten und 2 mal 16 Arten von Straßenstücken, auf denen sich das Auto befinden und auf die es hinfahren kann. Er schlägt verschiedene konzeptionelle Erweiterungen vor, um dieses Problem in den Griff zu bekommen. Dazu gehören beispielsweise semantische Interpretationen der Regeln durch den Ausführungsmechanismus sowie die Wiederverwendung von Regeln durch die Spezifikation von Analogien, etwa in der Art»ein Zug folgt einer Schiene wie ein Auto einer Straße«. Andere Ansätze für regelorientierten VP-Systeme beruhen auf Graphgrammatiken und Graphtransformations-Systemen (vgl. Schürr et al. [95]). Zur Programmierung mit solchen Systemen benutzt man Techniken des Übersetzerbaus. Die im Übersetzerbau üblichen Grammatiken beschreiben, wie Zeichenketten erzeugt oder erkannt werden können, die einer bestimmten Sprache genügen. Analog dazu bestehen Graphgrammatiken aus einer Menge von Regeln zur Erzeugung oder Erkennung von Graphen, die einer bestimmten Sprache angehören. Ein Graphtransformations-

132 Konzepte visueller Programmiersysteme 122 System (graph rewriting system) ist eine Menge von Regeln, die einen Graph in einen anderen Graph derselben Sprache überführt. Solche Systeme werden oft als visuelle und ausführbare Spezifikationen von abstrakten Datentypen und Werkzeugen zur Manipulation von Diagrammen verwendet. Die formale Grundlage von graphenbasierten VP- Systemen und der professionelle Anwendungsbereich läßt interessante Entwicklungen auf diesem Gebiet erwarten. Das von Schürr et al. [95 S. 326] entwickelte VP-System PROGRES ist eine der auf Basis von Graphgrammatiken am weitesten entwickelten Programmierumgebungen. Es wurde u.a. für folgende Anwendungen eingesetzt: Spezifikation von Werkzeugen und Datenstrukturen für integrierte Softwareentwicklungsumgebungen; Prozeßmodellierung, Versionskontrolle und Konfigurationsmanagement in CIM-Umgebungen; Definition der Semantik einer visuellen Datenbankabfragesprache. Bild 5-13 zeigt eine Anwendung von PROGRES zur Erkennung wohlgeformter Ablaufdiagramme. 5.7 Beispielorientierte VP-Systeme Beispielorientierte VP-Systeme beruhen auf dem Gedanken, daß in manchen Fällen die beispielhafte Durchführung einer Aufgabe am Computer genügt, um daraus ein Programm abzuleiten. Die Grundidee ist einfach: Der Benutzer führt dem System in einzelnen Schritten vor, wie eine Aufgabe zu lösen ist, das System beobachtet den Benutzer, zieht Schlußfolgerungen und generiert ein Programm, das diese Aufgabe wiederholt ausführen kann. Das Programmieren durch Vorzeigen von Beispielen ist auch unter dem Begriff Programming by Demonstration bekannt. In Myers [94 S. 878] werden zwei Ansätze unterschieden:»mache, was ich mache«(»do what I did«) und»mache, was ich meine«(»do what I mean«). Die erste Art bezeichnet man als Programmierung mit Beispielen, die zweite Art nennt man Programmierung durch Beispiele. Bei Programmierung mit Beispielen zeichnet das System die einzelnen Benutzeraktionen auf und wiederholt sie später. Das VP-System versucht nicht, die Absicht des Benutzers zu erkennen, sondern dient im wesentlichen als ein Übersetzer, der Aktionen am Bildschirm in internen Programmcode überführt. Die Flexibilität solcher Systeme ist gering, weil bereits kleine Abweichungen vom ursprünglichen Szenario zu Fehlfunktionen des Programms führen. Ein typischer Anwendungsbereich für diese Art der Programmierung ist die Erstellung von automatisierten Abläufen mit Makrorekordern (siehe Bild 5-14). Bei Programmierung durch Beispiele demonstriert der Benutzer anhand typischer Szenarien, wie aus gegebenen Daten das gewünschte Resultat zu erzeugen ist. Das VP- System versucht die Aktionen des Benutzers zu verallgemeinern und leitet aus den gezeigten Beispielen ein Programm ab, das nicht nur auf die vorgezeigten Fälle, sondern auch auf ähnliche Situationen anwendbar ist. Die Realisierung solcher VP-Systeme ist schwierig. Zum einen sind die Ausdrucksmöglichkeiten des Benutzers meist auf visuelle Interaktion beschränkt, müßten aber durch verbale Erläuterungen ergänzbar sein, um die Bedeutung einer Aktion zu erklären und Mehrdeutigkeiten auszuschließen; zum anderen sind Verzweigungen und Schleifen in den Aktionen des Benutzers nur schwer erkennbar. Insbesondere sind die Gründe für eine alternative oder wiederholte Aktion für das VP-System kaum einsichtig.»automa-

133 5.7 Beispielorientierte VP-Systeme 123 tische Programmierung«, wie die Programmierung durch Beispiele auch bezeichnet wird, ist deshalb ein Teilgebiet der Forschung zu künstlicher Intelligenz. Ein generelles Problem bei beispielorientierten VP-Systemen, ist die Diskrepanz zwischen der Interaktion des Benutzers und dem vom System generierten Programm. Manche Systeme bieten keine Möglichkeit zur Modifikation von Programmteilen auf der Interaktionsebene. Bei diesen Systemen ist der Benutzer gezwungen, für Änderungen auf die Systemebene abzusteigen. Die Sprache der Systemebene ist aber eine andere Sprache als jene der Interaktionsebene und von dieser durch eine kaum überbrückbare semantische Lücke getrennt. Beispielsweise erzeugt das VP-System Metamouse von Maulsby und Witten [93] beim Vorzeigen eines Sortiervorgangs den in Bild 5-15 gezeigten Programmcode. Dieser Programmcode ist kaum verständlich, und eine partielle Änderung des Programms auf textueller Ebene wäre deshalb praktisch unmöglich. In Metamouse besteht deshalb die Möglichkeit, einzelne Schritte selektiv zur korrigieren, indem die entsprechenden Aktionen nochmals vorgezeigt werden. Dabei kann allerdings das Problem auftreten, daß spätere Schritte ungültig werden. In diesem Fall müssen ganze Programmzweige nochmals erstellt werden. Mit Ausnahme von Makrorekordern sind beispielorientierte VP-Systeme auf den akademischen Bereich beschränkt, da ihre praktische Anwendbarkeit zur Zeit noch an den Schwierigkeiten der Programmdeduktion scheitert. Aus Beispielen die Absichten eines Benutzers abzuleiten und daraus ein korrektes Programm zu generieren ist beim derzeitigen Stand der Forschung nur für ganz spezifische Anwendungsbereiche möglich, etwa für einfache Aufgaben aus der Textverarbeitung. In Cypher [93] werden 18 Systeme für beispielorientierte Programmierung vorgestellt und die damit verbundenen Möglichkeiten und Probleme ausführlich diskutiert. Der an akademischen Ansätzen interessierte Leser findet in diesem Werk einen systematischen Überblick über den Stand der Technik auf diesem Gebiet.

134 Konzepte visueller Programmiersysteme Bild Programmierung mit Beispielen mit Script Editor. Das Bild zeigt die Definition eines AppleScript-Programms mit Hilfe des Makrorekorders Script Editor. Aufgezeichnet wird der Vorgang»Dokument in einen Ordner legen«. 1: Der Benutzer startet den Makrorekorder. 2-5: Der Benutzer zieht ein Dokument in einen Ordner. 6: Der Benutzer stoppt den Makrorekorder, worauf der Programmcode angezeigt wird. Das erzeugte Programm kann beliebig oft durch Drücken der Schaltfläche Run wiederholt werden, vorausgesetzt, die Ausgangsbedingungen sind die selben. operator: drag grasping : line-01.midpoint postconditions: position (145, 93) distance (145, 11) heading (0x,+y) touch (line-01.? : box-17.left.midpt)... touch (line-01.? : box-91.right.?) Aktion des Programmierers Interne Darstellung Bild Programmierung durch Beispiele mit MetaMouse. Vgl. Maulsby und Witten [93 S. 158 und S. 163] Der Benutzer zeigt dem VP-System Metamouse, wie Rechtecke der Höhe nach sortiert werden, indem er Linien am unteren und oberen Rand von Rechtecken plaziert, schrittweise verschiebt und mit anderen Hilfsmitteln die Sortierung darstellt. Die im Bild links gezeigte Aktion ist der dritte von zwölf Schritten. Das System beobachtet den Benutzer und leitet daraus den Sortieralgorithmus ab.

135 5.8 Formularorientierte VP-Systeme Formularorientierte VP-Systeme Formularorientierte VP-Systeme beruhen auf den Konzepten der Tabellenkalkulation. Die Tabellenkalkulation mit Programmen wie MS-Excel oder Lotus ist weit verbreitet und beliebt. Das ist vor allem darauf zurückzuführen, daß man Formulare und Tabellen aus dem Alltag kennt und deshalb mit den Funktionen dieser Programme sowie den zugrundeliegenden Datenstrukturen schnell vertraut ist. Der große Erfolg von Tabellenkalkulationsprogrammen erweckte die Hoffnung, daß formularbasierte Ansätze auch die Programmierung erleichtern könnten. Diese Erwartungen haben sich nicht erfüllt. Für die Konstruktion von Softwaresystemen ist das formularorientierte Paradigma u.a. deshalb ungeeignet, weil es sequentielle Abläufe nicht unterstützt, über keine adäquaten Konzepte zur Datenabstraktion verfügt, keine algorithmischen Konstrukte kennt und nur zustandslose Berechnungen unterstützt. In formularorientierten VP-Systemen werden Programme durch Ausfüllen von Programmblättern (Formularen bzw. Tabellen) erstellt. Zellen in den Programmblättern enthalten entweder Daten oder Formeln. Daten können skalar oder strukturiert sein. Die Programmierung geschieht deklarativ. Der Programmierer definiert keine Algorithmen, sondern gibt in den Formeln an, welche Daten zur Berechnung anderer Daten benötigt werden und mit welchen Operationen die Daten zu verknüpfen sind. Ein eingebauter Mechanismus sorgt für die automatische Nachberechnung von Daten, die von anderen Daten abhängig sind. Variablen werden nicht benötigt. Formularorientierte VP-Systeme haben sich vor allem für Datenbanksysteme bewährt. Die Pionierarbeit auf diesem Gebiet ist Query by Example von Zloof [81], ein VP- System mit dem Datenbankrelationen und Datenbankabfragen mit tabellarisch angeordneten Ausdrücken definierbar sind. Ansätze für andere Anwendungsgebiete blieben bisher auf den akademischen Bereich beschränkt. Dazu gehört beispielsweise das VP- System Forms/3 von Burnett und Ambler [92], das u.a. für Aufgaben in der Büroautomatisierung und zur Lösung algorithmischer Probleme gedacht ist. Bild 5-16 zeigt eine Anwendung von Forms/3 zur Berechnung des Durchschnitts einer Zahlenfolge. An diesem Beispiel sind zwar jene Möglichkeiten von Forms/3 nicht ersichtlich, die über gewöhnliche Tabellenkalkulationsprogramme hinausgehen, z.b. das inkrementelle Typsystem und die Behandlung interaktiver Ereignisse (vgl. Burnett [94 S. 163 f]), dennoch läßt das Beispiel erkennen, daß diese Art von VP-Systemen bei Standardaufgaben keinen Vorteil gegenüber modernen Tabellenkalkulationsprogrammen bietet, sondern im Gegenteil einen unpraktischen Eindruck macht.

136 Konzepte visueller Programmiersysteme 126 Numbers 1 n function avg (v: Vector, size: integer): integer; Totals 1 + n var i, total: integer; begin total := 0; for i := i to size do total := total + v[i]; avg := total div size; end; Mean / n Bild Formularorientierte Programmierung mit Forms/3. Vgl. Pandey und Burnett [93 S. 346] Zu berechnen ist der ganzzahlige Durchschnitt von ganzzahligen Werten eines Vektors. Das Bild zeigt links die Implementierung in Forms/3, rechts ein äquivalentes Pascal-Programm. Bei der Lösung in Forms/3 ist sind die Zahlen im Vektor Numbers abgelegt. Zellen werden durch Muster unterschieden. Zellen enthalten Objekte, die durch Formeln berechnet werden. Der Vektor Totals enthält die laufende Gesamtsumme. Er ist in zwei Bereiche geteilt. Der linke Bereich besteht aus einer einzigen Zelle, die der ersten Zelle in Numbers entspricht. Im rechten Bereich ist jede Zelle die Summe aus der vorhergehenden Zelle in Totals und der korrespondierenden Zelle in Numbers. Der Durchschnitt ergibt sich durch Division der letzten Zelle aus Totals und der Anzahl der Elemente. In einigen formularorientierten VP-Systemen sind Konzepte der constraintorientierten und logischen Programmierung zu finden. Poswig [96 S. 35] nennt als Beispiel das System PERPLEX von Spenke [93], wo die Abhängigkeit zwischen Zellen einer Tabelle durch Prädikate ausgedrückt wird. Der Unterschied solcher Systeme zu herkömmlichen Tabellenkalkulationsprogrammen liegt primär darin, daß keine Unterscheidung zwischen konstanten und variablen Zellen notwendig ist. Jede Zelle kann Werte liefern und Werte berechnen.

137 5.9 Multiparadigmenorientierte VP-Systeme Multiparadigmenorientierte VP-Systeme Multiparadigmenorientierte VP-Systeme fassen mehrere der zuvor genannten Programmierparadigmen zusammen. Ein wesentliches Merkmal solcher Systeme ist die nahtlose Integration der unterstützten Konzepte. Dadurch kann der Programmierer jenes Denkmodell und Werkzeug wählen, das dem jeweiligen Teilproblem am besten entspricht, ohne einen konzeptionellen oder technischen Bruch bei der Implementierung des Gesamtsystems in Kauf nehmen zu müssen. Beispiele für multiparadigmenorientierte VP-Systeme sind Prograph (vgl. Ga Côté [95]), Visual ToolSet von Borges und Johnson [90] sowie Vista, das in Kapitel 7 beschrieben wird. Prograph ist ein kommerziell verfügbares VP-System, das objektorientierte Programmierung mit Datenflußdiagrammen erlaubt (siehe Bild 5-17). Visual ToolSet integriert vier Werkzeuge zur steuerflußorientierten, datenflußorientierten, beispielorientierten und formularorientierten Programmierung und stellt zusätzlich ein Werkzeug zur Definition von Datentypen zur Verfügung. Vista vereinigt steuerflußorientierte, datenflußorientierte und objektorientierte Programmierung auf Basis von Softwarekomponenten und bietet für alle Paradigmen einen Satz von aufeinander abgestimmten Werkzeugen. Der Einsatzbereich multiparadigmenorientierter VP-Systeme ergibt sich aus den Anwendungsgebieten der unterstützten Paradigmen und dem Bedarf an einer engen Integration von unterschiedlichen Konstruktionsmethoden auf der Entwurfs- und Implementierungsebene. Ein Beispiel für die sinnvolle Anwendung multiparadigmenorientierter Programmierung ist die Realisierung eines Verkehrsleitsystems, das den Verkehrsfluß analysiert und steuert. Für die Entwicklung des Subsystems zur Datenanalyse bietet sich der Einsatz eines datenflußorientierten VP-Systems an, für das Subsystem zur Verkehrssteuerung ein steuerflußorientiertes VP-System auf Basis von Transitionsnetzen. Die starke Verflechtung von Analyse und Steuerung legt den Einsatz eines multiparadigmenorientierten VP-Systems nahe. Dieses System könnte beispielsweise für die Definition der Datenstrukturen eine subsystemübergreifende Notation vorsehen und für die Festlegung der Programmlogik eine subsystemspezifische Beschreibungsform. Für die Kooperation der Subsysteme könnte das VP-System standardisierte Mechanismen anbieten. Ein Nachteil multiparadigmenorientierter VP-Systeme ist die Tendenz zu konzeptioneller Überladung. Wenn die integrierten Paradigmen unbereinigt übernommen werden, dann besteht die Gefahr, daß der Programmierer nicht mehr in der Lage ist, aus der Vielzahl der angebotenen Konzepte und dazugehörenden Werkzeuge das richtige zu wählen. Die Vorteile multiparadigmenorientierter Programmierung werden dadurch zunichte gemacht. Es können Programme entstehen, die bedeutend schwerer verständlich sind, als solche, die nur mit einem Paradigma erstellt wurden, selbst wenn dieses nicht alle Problembereiche gleich gut abdeckt. Um die Komplexität multiparadigmenorientierter VP-Systeme auf beherrschbarem Niveau zu halten, sollten solche Systeme auf einfachen visuellen Sprachen aufbauen. Die angebotenen Werkzeuge sollten eine einheitliche Benutzungsschnittstelle aufweisen und den Austausch softwaretechnischer Objekte (Komponenten, Prozeduren, Datenstrukturen usw.) erlauben. Zudem ist ein Kompromiß zwischen den Stärken der einzelnen Paradigmen und der Qualität des Gesamtsystems anzustreben. In Prograph wurde beispielsweise auf die Nebeneffektfreiheit des Datenflußmodells zugunsten der Möglichkeit verzichtet, zustandsbehaftete Objekte über Datenkanäle fließen zu lassen.

138 Konzepte visueller Programmiersysteme 128 Bild Multiparadigmenorientierte Programmierung mit Prograph. Das Bild zeigt einige Fenster des multiparadigmenorientierten VP-Systems Prograph. Links oben ein Fenster mit der Hierarchie von Klassen für grafische Objekte. Darunter ein Fenster mit den Namen universeller Methoden, die für alle Objekte dieser Klasse aufgerufen werden können. In der Mitte sind zwei Fenster mit einigen Methodennamen der Klasse Graphic und Text zu sehen. Ausgewählt ist die Methode Draw, die in Graphic als leere Methode definiert und in Text überschrieben wird (Fenster rechts daneben). Die Methode Draw der Klasse Text ist als Datenflußdiagramm implementiert. Sie hat drei Eingänge (Parameter). Der linke Eingang liefert das zu zeichnende Textobjekt, der mittlere den Zeichenbereich und der rechte einen booleschen Wert, der angibt, ob das Textobjekt aktiv ist.

139 6. Beispiele für visuelle Programmiersysteme Dieses Kapitel präsentiert typische Beispiele für steuerflußorientierte, datenflußorientierte, funktionsorientierte und objektorientierte VP-Systeme. Bei der Wahl der Systeme wurde eine Mischung aus akademischen und kommerziell verfügbaren Entwicklungsumgebungen angestrebt. Nicht in Betracht gezogen wurden VP-Systeme, bei denen die Programmlogik auf verbalen Programmiersprachen beruht (z.b. Visual Basic, Visual C++ und VisualWorks), weil in solchen Systemen fast alle interessanten Aspekte der visuellen Programmierung wegfallen. Folgende Systeme werden dargestellt: C 2 ist ein steuerflußorientiertes VP-System auf Basis von Anweisungssequenzen, das den Versuch zeigt, eine verbale Programmiersprache in eine visuelle Programmiersprache zu transformieren, ohne an den Sprachkonzepten etwas zu ändern. Wie das Beispiel zeigt, bringt eine solche Transformation keine Vorteile. SERIUS ist ein steuerflußorientiertes VP-System auf Basis von Komponentennetzen, das visuelle Programmierung auf einer mit 4.-Generationswerkzeugen vergleichbaren Ebene erlaubt. Der Anwender soll damit in der Lage sein, maßgeschneiderte Applikationen für seinen Aufgabenbereich schnell zu entwickeln. LABVIEW ist ein datenflußorientiertes VP-System, das für die Programmierung virtueller Instrumente eingesetzt wird. Die zugrundeliegende Metapher ist der Entwurf elektronischer Schaltkreise. Das System ist kommerziell erfolgreich und wurde bereits in vielen Anwendungsbereichen eingesetzt. VISAVIS ist ein funktionsorientiertes VP-System aus dem akademischen Bereich, das als Musterbeispiel für die gelungene Abbildung eines schwierigen Formalismus in eine visuelle Programmiersprache gesehen werden kann. VisaVis zeigt besonders gut, welche Möglichkeiten und Grenzen sich für die Programmierung mit Funktionsdiagrammen ergeben. PARTS ist ein objektorientiertes VP-System für die Programmierung mit Softwarekomponenten. Es war das erste VP-System, das eine objektorientierte Programmiersprache (Smalltalk) und einen Benutzungsschnittstelleneditor auf visueller Ebene nahtlos integrierte. 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 ergänzenden Abbildungen sind mit detaillierten Erläuterungen versehen, um den an Einzelheiten interessierten Leser die zum Verständnis der visuellen Notationen notwendigen Informationen zu vermitteln. Der eilige Leser kann diese Erläuterungen ohne Beeinträchtigung des Gesamtverständnisses überspringen, da im Haupttext darauf nicht Bezug genommen wird. Die einzelnen Systeme werden in unterschiedlicher Breite und Tiefe behandelt. Die Eigenschaften von C 2 und Serius werden nur skizziert, weil C 2 über die Möglichkeiten verbaler Sprachen nicht wesentlich hinausgeht und Serius tragfähige softwaretechnische Konzepte vermissen läßt. Ausführlich dargestellt werden LabVIEW und VisaVis, weil sich an diesen Systemen gut zeigen läßt, welche Auswirkungen das von imperativen

140 Beispiele für visuelle Programmiersysteme 130 Programmiersprachen abweichende Denkmodell auf die Programmiertechnik hat. PARTS wird wegen der großen Bedeutung der objektorientierten Programmierung ebenfalls breiter behandelt, jedoch muß wegen der umfangreichen Konzepte auf eine tiefgehende Betrachtung verzichtet werden. 6.1 C 2 : Visuelle Programmierung mit Anweisungssequenzen C 2 von Kopache und Glinert [88] ist ein steuerflußorientiertes VP-System basierend auf Anweisungssequenzen (siehe Abschnitt 5.1.1, S. 99). Das System unterstützt visuelle und verbale Programmierung für eine Teilmenge der Programmiersprache C. Es läuft auf Sun-Workstations unter dem Betriebssystem Unix. C 2 ist weniger wegen seiner Konzepte als vielmehr aus historischen Gründen interessant. Das System stammt aus der Frühzeit der visuellen Programmierung und verdeutlicht den damals vielfach praktizierten Ansatz, eine textuelle Programmiersprache grafisch zu verpacken. Wie C 2 zeigt, ist dieser Ansatz problematisch, weil dadurch nicht die Stärken, sondern eher die Schwächen von textuellen und grafischen Notationen zur Geltung kommen Anwendungsbereich C 2 ist ein allgemeines Programmiersystem, das prinzipiell denselben Anwendungsbereich wie die zugrundeliegende Programmiersprache C abdeckt. Die Entwickler betonen ausdrücklich, daß C 2 kein»spielsystem«ist [S. 232]. Die zitierte Publikation enthält allerdings keinen Hinweis auf Einsätze des Systems in größeren Projekten außerhalb des universitären Bereichs Konzepte C 2 beruht auf der BLOX-Methodik von Glinert [87], in der Programmkonstrukte in der Art von Puzzleteilen zusammengefügt werden (siehe Bild 6-1). BLOX unterstützt durch hierarchische Darstellung von Programmkonstrukten eine Top-Down-Vorgehensweise bei der Programmentwicklung nach dem Prinzip der schrittweisen Verfeinerung. Durch Verzicht auf grafische Elemente für Sprunganweisungen erzwingt BLOX strukturierte Programmierung Sprache C 2 unterstützt eine Untermenge der Programmiersprache C. Spezielle Sprachkonstrukte sind nicht vorhanden Interaktion Bild 6-2 zeigt ein mit C 2 erstelltes Programm zum binären Suchen. Es zeigt den Programmcode sowohl in textueller Form als auch in Form eines Puzzlediagramms. Das System arbeitet dual: es liest zunächst textuellen Code ein und generiert daraus die gra-

141 6.1 C2: Visuelle Programmierung mit Anweisungssequenzen 131 fische Repräsentation. Ändert der Benutzer danach das Programm im Grafikfenster, in dem er neue Programmteile durch Zusammenstecken von Programm-Puzzleteilen erstellt, so führt das System nach syntaktischer Prüfung den Inhalt des Textfensters nach und achtet dabei auf richtige Einrückung entsprechend der Programmstruktur. C 2 ist somit sowohl ein SV-System, weil es textuellen Programmcode visualisiert, als auch ein VP-System, weil man direkt mit grafischen Bausteinen programmieren kann. Programmkomponenten werden als Puzzleteile dargestellt, die entweder Anweisungsblöcke repräsentieren oder einzelne Anweisungen. Der Benutzer kann Blöcke expandieren, um das Innere darzustellen, und kollabieren, um das Innere zu verbergen. Programmkomponenten können vertikal und horizontal zusammengesteckt werden. Die vertikale Komposition ist für sequentielle Programmstrukturen gedacht, die horizontale Komposition für Verzweigungen und Schleifen. Für die Deklaration von Variablen und Prozedurparametern sind gemischt grafisch/textuelle Symbole vorgesehen. Bild 6-1. Schematische Darstellung eines Programms in der Proc-BLOX-Notation. Glinert [90-A&I S. 550, Abb. 3] Programmkonstrukte werden in der Proc-BLOX-Notation durch verschieden geformte Puzzleteile dargestellt. Neben Teilen für Ablaufstrukturen, wie WHILE und IF existieren Teile für Anweisungsblöcke, wie DO, THEN und ELSE sowie Teile für allgemeine Anweisungsfolgen (im Bild mit S n bezeichnet). Die im Bild mit Ellipsen umrandeten Teile wurden für das bessere Verständnis der Illustration gemeinsam hervorgehoben, sollten aber im Normalfall einzeln expandiert werden, um den Überblick zu bewahren.

142 Beispiele für visuelle Programmiersysteme 132 Bild 6-2. Definition einer Funktion für die binäre Suche in C 2. Kopache und Glinert [88 S. 236, Abb. 4] C 2 stellt Programme sowohl textuell als auch grafisch dar. Das Textfenster enthält eine C-Funktion für binäres Suchen. Im Grafikfenster ist dieselbe Funktion in Form von aneinandergesteckten Programm- Puzzleteilen zu sehen. In diesem Fenster befindet sich an der rechten Seite das BLOX-Menü mit allen verfügbaren Programmkonstrukten. Die Erstellung eines Programms geschieht durch Auswahl und Aneinanderfügen von Komponenten aus diesem Menü. Eine Funktionsleiste am unteren Rand des Grafikfensters enthält Schaltflächen für allgemeine Bearbeitungsfunktion von Programmkomponenten (Add, Delete, Change und Copy), für das Expandieren und Kollabieren von Komponenten (View) sowie zur Syntaxprüfung und Codegenerierung (Syntax). 6.2 SERIUS: Visuelle Programmierung mit Komponentennetzen Serius ist ein steuerflußorientiertes VP-System basierend auf Komponentennetzen (siehe Abschnitt 5.1.2, S. 100). Serius wurde Anfang der 90er Jahre von Joe Firmage, einem damals 20jährigen College-Abbrecher aus Salt Lake City entworfen und implementiert. Mehrere Zeitungsartikel feierten Firmage anläßlich der ersten Präsentationen von Serius als neues Wunderkind der Computerbranche. Man hielt die in Serius verwirklichten Ideen der grafischen Programmierung für ähnlich revolutionär wie etwa die Erfindung des Macintosh Computers. Mit Serius sollte jedermann in kürzester Zeit hochwertige Applikationen bauen können. Zitat aus San Francisco Examiner vom [OZ 43]:»Er wurde als der nächste Bill Gates angekündigt. [...] Er glaubt, daß seine Software eine ganze Industrie verändern kann. [...] Wenn man ein Microsoft-Excel-Spreadsheet-Programm in sieben Tagen für die Bedürfnisse der eigenen Kunden nachbauen kann, dann verlieren die Industriegiganten an Macht bei Forschung und Entwicklung für Software.«

143 6.2 Serius: Visuelle Programmierung mit Komponentennetzen 133 Inzwischen ist es wieder stiller geworden. Die hochgesteckten Erwartungen haben sich nicht erfüllt. Auch mit Serius ist es nicht möglich, komplexe Applikationen wie eine Tabellenkalkulation innerhalb weniger Tage zu realisieren. Eine neuere Version von Serius mit dem Namen AppBuider ist Bestandteil der Novell Produktlinie GroupWare und läuft unter MS-Windows (vgl. Olympia [94 S. 92]). Die neuste Version von Serius wird unter dem Namen Microbrew von Network Multimedia, Inc. vertrieben. Die folgenden Ausführungen beziehen sich auf Serius Version 3.0 für Macintosh (vgl. Serius [92]; für die aktuelle Version siehe AppBuilder [WWW] und Microbrew [WWW]) Anwendungsbereich Serius richtet sich sowohl an Anwender als auch an professionelle Programmierer. Der Einsatzbereich entspricht im wesentlichen jenem von 4GL-Werkzeugen, d.h. Serius ist für kleine bis mittelgroße Datenbankanwendungen, Büroapplikationen, Multimediaprogramme und ähnliche Software konzipiert. Serius besteht aus zwei Paketen: Serius Programmer, einem Werkzeug für den Anwender, der damit für seine Zwecke maßgeschneiderte Applikationen unter Zuhilfenahme von grafischen Bausteinen aus der Objekt- und Funktionsbibliothek erstellt, und Serius Developer, einem Werkzeug für den Bausteinentwickler, der damit die Objekt- und Funktionsbibliothek unter Zuhilfenahme von klassischen Programmiersprachen wie Assembler, C oder Pascal erweitert. Im folgenden wird nur auf Serius Programmer eingegangen, weil nur mit diesem Teil der Softwareentwicklungsumgebung visuell programmiert werden kann Konzepte Serius unterstützt einfache Mechanismen zur Kapselung von Programmteilen. Damit kann ein bescheidenes Maß an Abstraktion und Wiederverwendung erzielt werden. Die Möglichkeiten der modularen oder objektorientierten Programmierung sind mit Serius jedoch nicht erreichbar. Der zentrale Kapselungsmechanismus von Serius ist das Subject, das einem Komponentennetz entspricht. Ein Subject realisiert eine Teilaufgabe innerhalb eines Programms und enthält Objekte und Funktionen, die zu sogenannten Funktionsketten zusammengefaßt sind. Objekte produzieren Ereignisse, die über Signalkanäle an Funktionsketten weitergeleiteten werden und diese aktivieren. Bild 6-3 zeigt ein Subject für eine Stoppuhr. Anders als in objektorientierten Sprachen, wo Klassen zur Konstruktion anderer Klassen dienen, können Subjects nicht in anderen Subjects verwendet werden. Die einzige Möglichkeit der Wiederverwendung von Subjects besteht darin, für gewisse Objekte das Attribut shared zu vergeben. Die so markierten Objekte werden exportiert und stehen allen Subjects einer Applikation zur Verfügung. Die Wiederverwendung geschieht also nicht auf Ebene einer modularen Einheit (eines Subjects), sondern auf Ebene der atomaren Teile dieser Einheit (den Objekten). Die Eingangsschnittstelle eines Subjects bildet die Menge aller Ereignisse, die von allen im Subject enthaltenen Objekten produziert werden kann, die Ausgangsschnittstelle bildet die Menge aller Ereignisse der exportierten Objekte.

144 Beispiele für visuelle Programmiersysteme 134 Die geringe Zahl von benötigten Objekten und Funktionen zur Realisierung der Stoppuhr aus Bild 6-3 weist darauf hin, daß Serius Bausteine mit hoher Funktionalität zur Verfügung stellt. Tatsächlich können mit der mitgelieferten Bausteinbibliothek sehr schnell kleine Applikationen erstellt werden. Serius stellt eine Bibliothek von mehr als 50 Objekten und mehr als 400 Funktionen zur Verfügung (vgl. Serius [92 S. 1-5]). Die Bibliothek umfaßt Elemente für grafische Benutzungsschnittstellen diverse Ablaufstrukturen einfache und komplexe Datentypen externe Datenbestände und Datenbanken Multimedia-Applikationen Interprozeßkommunikation und andere zum Teil sehr spezielle Anwendungsbereiche, wie etwa der Emulation von HyperCard-Funktionen. Die intuitive Bedienung und die einfachen Konzepte ermöglichen es Anfängern bereits nach kurzer Einarbeitungszeit mit der Programmierung zu beginnen. Für die Konstruktion größerer Anwendungen reichen jedoch die softwaretechnischen Möglichkeiten nicht aus. Neben guten Strukturierungs- und Abstraktionsmitteln fehlen vor allem Mechanismen zur dynamischen Erzeugung von Objekten Sprache Die Programmiersprache von Serius ist untrennbar mit der Entwicklungsumgebung verbunden. Eine Notation von Serius-Programmen außerhalb der Entwicklungsumgebung ist nicht möglich. Serius unterstützt zwei Modi für die Repräsentation von Funktionen: ObjecSketch zeigt Funktionen als Piktogramme, ObjecTalk präsentiert Funktionen als Textkästen, in die der Programmierer seine Anweisungen in umgangssprachlicher Form notiert. Der Programmierer kann zwischen diesen Modi wechseln. Zur Erkennung der Semantik von ObjecTalk-Phrasen, wird laut Serius [92 S. 3-77] Fuzzy-Logik eingesetzt. Um ein Fenster mit dem Namen X zu öffnen, könnte der Programmierer eine der folgenden Objec- Talk-Phrasen verwenden: Open X, Open Window X, Show X, Open The Window Named X, Display X usw. Im Serius Benutzerhandbuch liest man dazu folgendes [S f; OZ 44]: Sie könnten sogar ein Wort falsch schreiben oder weglassen ObjecTalk ist»smart«genug herauszufinden, was Sie meinen. In ObjecTalk-Funktionsphrasen sind absolut keine Struktur oder Syntax einzuhalten. Weniger Wert als auf eine»smarte«programmiersprache wurde auf die statische Typprüfung gelegt. Das Typsystem von Serius ist unausgereift und läßt semantisch fragwürdige Operationen zu. So ist etwa die Zuweisung i:=b möglich, wobei i eine Integer- Variable ist und b die Referenz auf eine Schaltfläche (Button). Das Laufzeitsystem interpretiert in diesem Fall die Beschriftung der Schaltfläche als Zahl und weist diese Zahl der Integer-Variablen zu.

145 6.3 LabVIEW: Visuelle Programmierung mit Datenflußdiagrammen Interaktion Der Benutzer benutzt in Serius vor allem die Maus, um Objekte und Funktionen aus Paletten in den Arbeitsbereich zu ziehen und dort miteinander zu verbinden. Bei allen Objekten kann durch Doppelklick ein Dialogfenster geöffnet werden, mit dem die Objektattribute einstellbar sind. Auf diese Weise kann z.b. das Aussehen und der Inhalt von Fenstern festgelegt werden. Der Programmierer kann während des Entwicklungsprozesses jederzeit einen Testlauf der Applikation starten. Nachdem das System die syntaktische Korrektheit des Programms überprüft hat, wird eine temporäre Applikation erzeugt und interpretiert ausgeführt. Der Programmierer hat die Möglichkeit Haltepunkte zu setzen und Objekte während des Testlaufes zu inspizieren. Das fertige Programm wird durch den integrierten Compiler in Maschinencode übersetzt und mit Routinen aus der Serius-Programmbibliothek zu einer unabhängigen Applikation gebunden, die wie jede andere Macintosh-Applikation gestartet werden kann. 6.3 LABVIEW: Visuelle Programmierung mit Datenflußdiagrammen LabVIEW (Laboratory Virtual Instruments Engineering Workbench) ist ein datenflußorientiertes VP-System für softwaretechnische Lösungen im Bereich elektronischer Steuerungs- und Meßsysteme. Wegen der klaren Konzepte und deren konsequenter Umsetzung in eine praxistaugliche Softwareentwicklungsumgebung wird LabVIEW in diesem Buch detaillierter beschrieben als andere VP-Systeme. Die folgenden Ausführungen beziehen sich auf LabVIEW Version 3.0 (vgl. LabVIEW [94-T] und LabVIEW [94-U]; für die aktuelle Version siehe LabVIEW [WWW]). In den 70er Jahren wurde beinahe ausschließlich Basic als Programmiersprache für elektronische Instrumente verwendet. Ingenieure und andere am Entwicklungsprozeß beteiligte Personen waren dadurch gezwungen, für Entwurf und Implementierung von Steuerungs- und Meßsystemen ihr vertrautes Denkmodell der grafischen Blockschaltbilder aufzugeben und Problemlösungen mit den ungewohnten Konzepten einer textuellen Programmiersprache zu realisieren. James J. Truchard und Jeffrey L. Kodosky erkannten, daß im Sinne einer rationellen Softwareentwicklung dieser Paradigmenbruch vermieden werden mußte. Die beiden Manager, Präsident bzw. Vizepräsident von Forschung und Entwicklung bei National Instruments, Austin, Texas starteten 1984 ein Projekt mit dem Ziel, Elektronikern ein ähnlich effizientes Softwarewerkzeug zur Verfügung zu stellen, wie es im administrativen Bereich die Tabellenkalkulationsprogramme sind. Das Ergebnis war LabVIEW, ein VP-System auf Grundlage des Datenflußmodells. Die erste Version aus dem Jahre 1986 lief zwar nur auf einem kleinen Macintosh- Computer sorgte aber dennoch für beträchtliches Aufsehen in der Fachwelt (vgl. Santori [90 S. 39]). Inzwischen ist LabVIEW für gängige Betriebssysteme verfügbar wie MS- Windows, Windows-NT, MacOS, Solaris und HP-Unix. Kontinuierliche Verbesserungen bei Funktionalität und Benutzungsschnittstelle führten zu einer weiten Verbreitung auf dem Sektor der elektronischen Meßinstrumente.

146 Beispiele für visuelle Programmiersysteme 136 Bild 6-3. Das VP-System Serius; oben: Komponentennetz zur Realisierung einer Stoppuhr; unten: Objekt- und Funktionspalette. Das Komponentennetz (Subject in der Terminologie von Serius) besteht aus zwei Bereichen: links befindet sich die Liste der Objekte, rechts das Netz aus miteinander verbundenen Funktionen. Der Programmierer zieht Objekte und Funktionen mittels Drag-und-Drop aus der Objekt- und Funktionspalette in das Komponentennetz. Von Objekten, die relevante Ereignisse auslösen, führen Signalkanäle zu Funktionen. Im folgenden werden die Signalflüsse für die Objekte StopWatchWindow und AlarmClock erläutert. Das Objekt StopWatchWindow repräsentiert das im Bild dargestellte Fenster der Applikation, mit der Zeitanzeige Counter und den zwei Schaltflächen StartStopButton und ResetButton. StopWatchWindow emittiert dann ein Signal, wenn das Ereignis Closed eintritt. Dieses Ereignis tritt dann ein, wenn der Benutzer das Fenster schließt. Der an StopWatchWindow angeschlossene Kanal leitet das Signal an die Funktion Quit weiter, wodurch die Applikation beendet wird. Das Objekt AlarmClock repräsentiert die Systemuhr. AlarmClock emittiert dann ein Signal, wenn das Ereignis Second Changes eintritt. Dieses Ereignis tritt dann ein, wenn sich der Sekundenzähler der Systemuhr erhöht. Der an AlarmClock angeschlossene Kanal leitet das Signal an die Funktion Set? weiter. Diese Funktion überprüft, ob die als Parameter angeführte Schaltfläche Start-Stop- Button aktiv ist. Diese Schaltfläche ist immer dann aktiv, wenn die Stoppuhr läuft. Wenn die Schaltfläche aktiv ist, dann leitet der Kanal If set ein Signal an die Funktion Time - Time weiter, die daraufhin die Zeit LastTime zwischen dem letzten Auftreten des Ereignisses Second Changes und der aktuellen Uhrzeit in Sekunden berechnet und die Differenz dem Integer-Objekt Seconds zuweist. Die Berechnung der Differenz (statt einer einfachen Erhöhung der Anzeige um eins) ist deshalb notwendig, weil unter es unter gewissen Bedingungen (z.b. hohe Systemlast) vorkommen kann, daß das Ereignis Second Changes nicht jede Sekunde gemeldet wird. Nach der Berechnung der Zeitdifferenz werden zwei Signale ausgesandt und über die Kanäle After returning weitergeleitet. Ein Signal aktiviert die Zuweisung der aktuellen Uhrzeit an das Objekt LastTime, das andere Signal aktiviert die Funktion Time + Secs, wodurch die Zeitanzeige Counter um den Wert Seconds erhöht wird. Die Aktivierung der beiden Funktionen könnte parallel geschehen, da die Funktionen voneinander unabhängig sind. Serius Programmer unterstützt Parallelität jedoch nicht. Im konkreten Fall werden aufeinanderfolgend zwei Signale ausgesandt, wobei nicht definiert ist, welcher Kanal zuerst angesprochen wird.

147 6.3 LabVIEW: Visuelle Programmierung mit Datenflußdiagrammen Anwendungsbereich LabVIEW ist für Wissenschaftler und Ingenieure gedacht, die mit der Erfassung, Überwachung, Auswertung und Visualisierung von Meßdaten, der Konstruktion und Simulation elektronischer Steuerungen und allgemeinen wissenschaftlich/technischen Berechnungen befaßt sind. Das System verfügt über eine umfangreiche Programmbibliothek für allgemeine und spezielle Programmieraufgaben, die beispielsweise Funktionen zur Nutzung des standardisierten General Purpose Interface Bus (GPIB) enthält. Der Anwendungsbereich, ursprünglich in der Meßdatenverarbeitung für technische Laboratorien angesiedelt, umfaßt derzeit eine ganze Reihe von High-Tech-Branchen. Poswig [96 S. 48 f] nennt u.a. die Automobil- und Luftfahrtindustrie und medizinische Forschung mit Anwendungsbereichen wie der Laborautomatisierung, Prozeßüberwachung und -steuerung und elektronischen Test- und Simulationssystemen. Jamal und Wenzel [95] berichten über Projekte bei BASF, wo LabVIEW u.a. für ein komplexes Ultraschall-Scanner-System, digitale Waagen, Ofensteuerungen, Audiosysteme und Wanddickenmessungen eingesetzt wurde. In diesem Beitrag finden sich auch zahlreiche Hinweise auf Publikationen zu anderen Projekten, wie Überwachung und Visualisierung von Telemetriedaten, Entwurf und Steuerung digitaler Signalprozessor-Systeme, computerunterstützte Messung und Instrumentierung in der Intensivmedizin sowie Bioreaktorsteuerungen. Baroth und Hartsough [94] zeigen ebenfalls den Einsatz von Lab- VIEW in Praxisprojekten mit hohen Anforderungen wie einen Telemetrieanalysator für die Jupiter Galileo-Mission der NASA Konzepte Erklärtes Ziel der LabVIEW-Entwickler war der Entwurf eines VP-Systems, das die Stärken des Datenflußmodells mit den Prinzipien der strukturierten und modularen Programmierung vereint. Kodosky et al. [91 S. 36 f] sahen dafür hierarchisch strukturierte Datenflußdiagramme vor, die aus einzelnen Programmbausteinen bestehen, wobei für jeden Programmbaustein eine klare Trennung von Schnittstelle und Implementierung existiert. Ein Programmbaustein wird in LabVIEW Virtuelles Instrument (VI) genannt. In seinem Aussehen und seiner Arbeitsweise ähnelt ein VI einem realen elektronischem Instrument. Es ist eine rein transformative Einheit ohne innere Zustände, die von außen zyklisch mit Eingabedaten versorgt wird und diese durch die Programmlogik in Ausgabedaten überführt, wobei Parameter die Verarbeitung beeinflussen können. Obwohl die Bezeichnung VI suggeriert, daß die Programmlogik von VIs die Simulation elektronischer Schaltkreise betrifft, können mit einem VI auch allgemeine Algorithmen realisiert werden. Es ist beispielsweise ohne weiteres möglich, ein Sortierverfahren mit einem VI zu implementieren. Jedes VI besteht aus genau einer Frontplatte (front panel), einem Blockschaltbild (block diagram) und einem Verbinder (connector). Die Frontplatte hat zwei Funktionen: sie ist einerseits Benutzungsschnittstelle für den Anwender und enthält andererseits die Elemente der Programmschnittstelle in grafischer Form. Die Frontplatte kann Drehknöpfe, Schieberegler, numerische und analoge Anzeigen, Dateneingabefelder und sonstige von realen Instrumenten bekannte Elemente enthalten. Elemente für Eingabedaten und steuernde Parameter heißen Steuereinheit (control), Elemente für Ausgabedaten heißen Anzeigeeinheit (indicator).

148 Beispiele für visuelle Programmiersysteme 138 Das Blockschaltbild enthält die Programmlogik, die durch»verdrahtung«von VIs und elementaren Operationen definiert ist. Bestimmte Programmbausteine bilden den Anschluß zu realen Geräten, wie Wandlern, Sensoren, Steuereinheiten und Netzwerkschnittstellen. Der Verbinder bildet die Programmschnittstelle eines VIs. Er besteht aus einem Piktogramm und bis zu 20 Anschlußpunkten (terminals). Das Piktogramm repräsentiert das VI im Blockschaltbild anderer VIs. Die Anschlußpunkte sind quasi die»lötstellen«bei der Verdrahtung einzelner VIs zu Blockschaltbildern. Jedem Anschlußpunkt kann eine Steuer- und Anzeigeeinheit der Frontplatte zugeordnet werden, wodurch die Ein- Ausgabeschnittstelle des VIs definiert wird. Jene Steuerelemente der Frontplatte, die keinem Anschlußpunkt zugeordnet sind, werden entweder vom Benutzer an der Frontplatte interaktiv eingestellt oder fließen als konstante Größen in die Verarbeitung ein. Bild 6-4 zeigt Frontplatte, Blockschaltbild und Verbinder eines LabVIEW-Programms zur Temperaturmessung Sprache LabVIEW beruht auf der visuellen Datenflußsprache G, die alle Merkmale einer höheren Programmiersprache aufweist. G zeichnet sich durch folgende Eigenschaften aus: einfache und zusammengesetzte Datentypen statische Typisierung mit strenger Typprüfung hierarchische und polymorphe Operationen Verzweigungen, Fallunterscheidungen, Schleifen Sequenzen lokale und globale Variablen In den letzten beiden Punkten weicht G entscheidend vom reinen Datenflußmodell ab: Durch Variablen wird die Nebeneffektfreiheit verhindert und durch Sequenzen die implizite Ausführungsreihenfolge. Diese Abweichungen sind jedoch notwendig, um bestimmte Anwendungsfälle abdecken zu können. Sequenzen kommen etwa dann zum Einsatz, wenn ein elektronisches Gerät initialisiert werden muß, bevor Daten gelesen werden können. Da zwischen den Operationen»Initialisieren«und»Lesen«üblicherweise keine Datenabhängigkeiten existieren, muß die Ausführungsreihenfolge explizit definiert werden. Die Sprachkonstrukte von G für Ablaufstrukturen wie Verzweigungen, Fallunterscheidungen und Schleifen fügen sich harmonisch in das generelle Datenflußmodell ein. Ablaufstrukturen verhalten sich wie alle anderen Operationen in einem Blockschaltbild. Sie nehmen Daten über definierte Eingänge entgegen und leiten diese nach innen weiter. Dort verarbeitet ein Sub-Blockschaltbild die Daten, bei Schleifen auch in mehreren Zyklen. Nach der Verarbeitung werden die Resultatdaten über Ausgänge nach draußen transportiert. Da sich Sub-Blockschaltbilder isoliert im Inneren der Ablaufstrukturen befinden und keine Wechselwirkungen mit Elementen außerhalb eingehen, ist die einzige Modifikation des reinen Datenflußmodells die Erweiterungen um diese spezielle Art von Knoten. Bild 6-5 zeigt den grundsätzlichen Aufbau von Ablaufstrukturen. Bild 6-6 und Bild 6-7 illustrieren die Verwendung von Verzweigung und Fallunterscheidung an konkreten Beispielen. Die konsistente Einbindung von Ablaufstrukturen in das Datenflußmodell gilt insbesondere für Schleifen, für die andere Systemen weitaus weniger elegante Konzepte rea-

149 6.3 LabVIEW: Visuelle Programmierung mit Datenflußdiagrammen 139 lisieren. Schleifen nehmen nur zu Beginn der Iteration von außen Daten entgegen und leiten Ergebnisse erst am Ende der Iteration nach draußen weiter. Dies entspricht den Prinzipien der strukturierten, imperativen Programmierung, wo ebenfalls eine wohldefinierte Schnittstelle zwischen der Umgebung von Schleifen und deren Rumpf existiert. Blockschaltbilder bewahren entsprechend der Nebeneffektfreiheit des Datenflußmodells keine Daten zwischen den einzelnen Aktivierungen auf. Es ist deshalb ohne besondere Vorkehrungen nicht möglich, im Sub-Blockschaltbild einer Schleife jene Daten zu verwenden, die beim letzten Schleifendurchlauf generiert wurden. Durch diese Einschränkung wäre eine große Klasse von Algorithmen nicht implementierbar. Bild 6-8 zeigt eine spezielle Konstruktion für Schleifen, die Schieberegister (shift register) genannt wird und dieses Problem löst. Ein Schieberegister kann als Variable gedacht werden, die innerhalb der Schleife aktualisiert wird. Das Schieberegister wird vor dem ersten Schleifendurchlauf meist mit einem von außen herangeführten Wert initialisiert. Nach jedem Durchlauf wird ein Datum, das vom Sub-Blockschaltbild an das Schieberegister weitergeleitet wird, der nächsten Iteration so zur Verfügung gestellt, als würde es von außen einfließen. Bild 6-9 illustriert die Verwendung des Schieberegisters zur Berechnung der Nullstelle einer Funktion nach dem Newtonschen Verfahren. Rekursion ist in G nicht möglich. Ein VI kann nicht Bestandteil eines Blockschaltbildes sein, das direkt oder indirekt im VI selbst enthalten ist. Durch das Fehlen von Rekursion müssen rekursiv definierte Probleme mit iterativen Verfahren gelöst werden, wodurch manche Algorithmen komplizierter als nötig zu formulieren sind. Zudem unterstützt G keine lokalen Blockschaltbilder, weshalb Unterprogramme immer als separate VI definiert werden müssen. Durch diesen Mangel an lokaler Abstraktion werden auch jene Funktionen global bekannt gemacht, die nur im lokalen Kontext verständlich sind. Dies widerspricht dem Prinzip des Information Hidings und führt zu unnötig großen VI- Bibliotheken.

150 Beispiele für visuelle Programmiersysteme 140 Frontplatte mit Verbinder Blockschaltbild mit Hilfefenster für Verbinder Bild 6-4. Frontplatte und Blockschaltbild eines LabVIEW-Programms zur Temperaturmessung; Farbbild im Anhang. Frontplatte mit Verbinder: Die Frontplatte des Programms enthält zwei Steuereinheiten und zwei Anzeigeeinheiten. Steuereinheiten sind der Ein-Ausschalter Power und der Drehregler High Limit zum Einstellen des oberen Temperaturgrenzwertes. Anzeigeeinheiten sind die Warnlampe Warning, die aufleuchtet, wenn der obere Grenzwert überschritten wird und das Temperaturdiagramm Temperature History mit den Kurven für die aktuelle Temperatur, dem gleitenden Durchschnitt der letzten drei Werte und dem visualisierten Grenzwert. Das Symbol in der rechten oberen Ecke stellt den Verbinder dar. Er enthält links zwei Eingänge, die dem Ein-Ausschalter (boolean) und dem Temperaturgrenzwert (double) entsprechen, und rechts einen Ausgang für die Warnung bei Übertemperatur (boolean). In Klammer angeführt wurden die Typenbezeichnungen der Eingänge und Ausgänge. Blockschaltbild mit Hilfefenster für Verbinder: Das Blockschaltbild enthält die Programmlogik. Alle Elemente sind in eine While-Schleife eingebettet, die so lange läuft, bis Power = false gilt (siehe Erläuterungen in Abschnitt 6.3.3»Sprache«). Die Temperaturmeßwerte werden alle 1000 ms erfaßt. Zu erkennen sind die Steuer- und Anzeigeeinheiten der Frontplatte, die im Blockschaltbild als Datenquellen (High Limit und Power) und Datensenken (Temperature History und Warning) dargestellt sind. Temp und 3 pt. Average sind Unterfunktionen (Sub-VIs), die restlichen Elemente sind elementare Operationen. Das Symbol in der rechten oberen Ecke stellt das Piktogramm des Verbinders dar, das zur Repräsentation des VIs in einem anderen Blockschaltbild dient. Das Hilfefenster zeigt dieses Piktogramm mit allen Anschlußpunkten.

151 6.3 LabVIEW: Visuelle Programmierung mit Datenflußdiagrammen 141 Verzweigung Fallunterscheidung For-Schleife While-Schleife Bild 6-5. Ablaufstrukturen in G. Das Bild zeigt die vier Ablaufstrukturen in G. Die Strukturen werden als Kästen mit eingebetteten Sub-Blockschaltbildern dargestellt. Spezielle Steuereingänge sowie Datenquellen bzw. Senken im Inneren bestimmen das Verhalten der Strukturen. Sogenannte Tunnel (tunnels) bilden Eingänge und Ausgänge für Daten der Umgebung. Im Bild sind die Tunnel als schwarze Rechtecke an der Umrandung der Strukturen dargestellt. Bei Schleifen haben die Tunnel eine besondere Funktion: Liegt an einem Eingangstunnel ein Feld an, so werden die einzelnen Feldelemente sukzessive an die Schleife weitergereicht. Umgekehrt werden an einem Ausgangstunnel die bei jedem Schleifendurchlauf erzeugten Werte in ein Feld zusammengefaßt. Verzweigung und Fallunterscheidung: Beide Strukturen beruhen auf demselben Konzept. Die inneren Sub-Blockschaltbilder sind in zwei (bei Verzweigung) oder mehreren (bei Fallunterscheidung) Programmzweigen angeordnet. Die Programmzweige sind überlagert, so daß der Programmierer immer nur einen Zweig sieht. Am oberen Rahmen der Kästchen befindet sich eine Schaltfläche mit der zwischen den Zweigen gewechselt werden kann. Ein Datum am Steuereingang mit dem Fragezeichensymbol? bestimmt, welcher Zweig ausgeführt wird. Bei einer einfachen Verzweigung wird ein boolescher Wert erwartet, bei einer Fallunterscheidung entweder eine Zahl oder ein Enumerationsdatum. Die drei Tunnels der Fallunterscheidung zeigen, daß nicht nur ein Eingang oder Ausgang erlaubt ist, sondern auch mehrere Anschlußpunkte existieren können. Dies gilt für alle Strukturen. For-Schleife: Die For-Schleife führt das Sub-Blockschaltbild so oft aus, wie N (count terminal) angibt, das von außen mit einer Zahl versorgt wird. Der aktuelle Wert des Durchlaufzählers steht über i (iteration terminal) zur Verfügung. While-Schleife: So wie die For-Schleife, verfügt auch die While-Schleife über einen Durchlaufzähler i. Der Fortsetzungsschalter (conditional terminal) bestimmt, wie lange die Schleife durchlaufen wird. Der Fortsetzungsschalter wird vom Sub-Blockschaltbild mit einem booleschen Wert versorgt. Wenn dieser Wert false ist, dann endet die Schleife. Die While-Schleife ist eine Durchlaufschleife, d.h. das Sub-Blockschaltbild im Inneren der Schleife wird mindestens einmal ausgeführt. Es gibt in G keine Schleife, bei der die Abbruchbedingung vor dem ersten Durchlauf geprüft wird.

152 Beispiele für visuelle Programmiersysteme 142 True-Zweig False-Zweig Alternative Implementierung Bild 6-6. Maximumberechnung mit Verzweigung in G. Das Bild zeigt ein G-Programm zur Berechnung des Maximums max zweier Zahlen a und b mit True- Zweig und False-Zweig. In der Programmierumgebung ist immer nur ein Zweig zu sehen. In diesem einfachen Fall beschränken sich die Sub-Blockschaltbilder auf das Durchleiten eines Datenwertes. Dieselbe Funktionalität stellt auch eine spezielle Operation Select zur Verfügung, wodurch die Verzweigung wegfällt. Diese Situation zeigt das Teilbild»Alternative Implementierung«. Fall 1 Fall 2 Fall 3 Bild 6-7. Wortübersetzung mit Fallunterscheidung in G. Das Bild zeigt ein G-Programm, zur Übersetzung der Worte»blood«,»sweat«und»tears«in ein rudimentäres Englisch mit Hilfe einer Fallunterscheidung. Die Fallunterscheidung wird mit dem aktuellen Wert der Variablen word gesteuert. Diese Variable ist ein Enumerationswert und kann blood, sweat oder tears enthalten. Je nachdem welchen Wert word enthält, wird die Variable simple english entweder mit red body water, white body water oder eye body water belegt. LabVIEW gleicht die Beschriftung der einzelnen Fälle automatisch den möglichen Werten von word an, sobald diese Variable mit dem Steuereingang der Fallunterscheidung verbunden wird.

153 6.3 LabVIEW: Visuelle Programmierung mit Datenflußdiagrammen 143 Einfaches Schieberegister Komplexes Schieberegister Bild 6-8. Schieberegister in G. Einfaches Schieberegister: Ein einfaches Schieberegister besteht aus einem linken Eingangspunkt und einem rechten Ausgangspunkt, die auf gleicher Höhe liegen. Der Eingangspunkt wird meist vor dem ersten Schleifendurchlauf explizit initialisiert, der Ausgangspunkt erhält nach jedem Schleifendurchlauf ein Datum. Dieses Datum wird zum Eingangspunkt zurückgeleitet, wo es dem Sub- Blockschaltbild für die nächste Iteration zur Verfügung steht. Komplexes Schieberegister: Ein komplexes Schieberegister besitzt n linke Eingangspunkte für die Daten der n letzten Iterationen. Mit diesem Konstrukt ist es beispielsweise möglich einen Algorithmus für die Fibonacci-Folge f n = f n-1 + f n-2 zu realisieren. Bild 6-9. Das Newtonsche Verfahren in G. Das Bild zeigt die Bestimmung einer Nullstelle der Funktion f(x) = sin(x) mit der ersten Ableitung f (x) = cos(x). Das Schieberegister der Schleife wird mit der ersten Näherung x0 initialisiert. Jeder Durchlauf verbessert die Lösung, bis die gewünschte Genauigkeit eps erreicht ist. Ein Vergleich von eps mit dem Absolutwert der Verbesserung belegt in diesem Fall den Fortsetzungsschalter mit false, und die Schleife terminiert. Der letzte Wert des Schieberegisters wird nach außen geführt und in x abgelegt.

154 Beispiele für visuelle Programmiersysteme Interaktion LabVIEW verfügt über mehrere integrierte Editoren, mit denen der Programmierer eine Applikation konstruieren und testen kann, ohne daß er dazu die Programmierumgebung verlassen müßte. Eine Vielzahl von Hilfsmitteln erleichtern diesen Prozeß. Man kann die Programmausführung animieren und Sonden einbauen, um zu beobachten, wie die Daten durch das Programm fließen, man kann Haltepunkte setzen und das Programm schrittweise ausführen. Ein inkrementeller Syntaxprüfer zeigt zu jedem Augenblick sowohl visuell als auch verbal an, ob das Programm Syntaxfehler enthält und welche Elemente betroffen sind. Die Konstruktion eines VIs beginnt mit dem Entwurf der Frontplatte. Der Programmierer wählt aus einer Palette von Elementen die benötigten Steuer- und Anzeigeeinheiten aus und arrangiert sie entsprechend der Funktionalität des VIs. Wenn das VI eine Hauptkomponente repräsentiert, die mit dem Anwender interagiert, sollte auf eine ansprechende Gestaltung der Frontplatte größerer Wert gelegt werden, als wenn das VI als Programmbaustein auf den unteren Systemebenen zum Einsatz kommt. Für die optische Gestaltung der Frontplatte stehen Werkzeuge zur Verfügung, wie sie auch von Zeichenprogrammen bekannt sind. Man kann Beschriftungen anbringen, Elemente färben, selbst erstellte Grafiken einbinden und vieles mehr. Nach dem Entwurf der Frontplatte bearbeitet der Programmierer das Blockschaltbild. LabVIEW übernimmt alle Einheiten der Frontplatte (mit Ausnahme rein dekorativer Elemente) automatisch in das Blockschaltbild. Dabei werden die Steuereinheiten als Datenquellen und die Anzeigeeinheiten als Datensenken dargestellt. Der Programmierer bedient sich für den Aufbau des Blockschaltbildes wiederum einer Palette, aus der er Operationen und VIs auswählt und mit einem Verdrahtungswerkzeug (wiring tool) miteinander verbindet. Während der Programmierer diese Aktionen ausführt, kontrolliert der Syntaxprüfer von LabVIEW ständig die syntaktische Korrektheit des Programms, zeigt Fehler an, bestimmt den Datentyp der Ein- und Ausgänge von polymorphen Operationen und aktualisiert das Erscheinungsbild von Verbindungen. Zur besseren Unterscheidung werden Verbindungen durch spezifische Farben, Muster und Linienstärken visualisiert, so daß Datentyp, Dimensionalität und numerische Genauigkeit auf einen Blick erkennbar sind. Durch die Trennung von Frontplatte und Blockschaltbild kann das Erscheinungsbild beider Programmebenen unabhängig voneinander optimiert werden. Bei der Gestaltung der Frontplatte werden ergonomische Gesichtspunkte im Vordergrund stehen, beim Blockschaltbild eine klare Programmstruktur. Ein syntaktisch korrektes Programm ist jederzeit ausführbar. Das grafische Programm wird automatisch kompiliert ein Vorgang, der so rasch geschieht, daß kaum eine Verzögerung bemerkbar ist und anschließend je nach gewähltem Modus animiert, schrittweise oder durchlaufend ausgeführt. Die dabei gemachten Beobachtungen können wieder sofort in den Programmierprozeß einfließen und Änderungen sowohl an der Benutzungsschnittstelle als auch an der Programmlogik bewirken. Somit ist eine inkrementelle, prototyping-orientierte Softwareentwicklung möglich, die wegen der unmittelbar verwendbaren Blockschaltbilder nicht in ein Wegwerfprogramm mündet, sondern in ein funktionsfähiges und getestetes Programm. Bild 6-10 zeigt verschiedene Entwicklungsstadien des Temperaturmeßsystems aus Bild 6-4, S. 142.

155 6.3 LabVIEW: Visuelle Programmierung mit Datenflußdiagrammen 145 Fehlerhaftes Blockschaltbild mit Fehlerliste Korrektes Blockschaltbild mit Programmanimation Bild Verschiedene Entwicklungsstadien des Temperaturmeßsystems; Farbbild im Anhang. Fehlerhaftes Blockschaltbild mit Fehlerliste: Das noch unvollständige Blockschaltbild für das Temperaturmeßsystem wurde falsch verdrahtet. Der Programmierer zog mit der Drahtspule eine Verbindung von High-Limit mit Datentyp double (DBL) zum Fortsetzungsschalter mit Datentyp boolean. Dadurch entstand ein Typkonflikt. Der Syntaxprüfer zeichnet die fehlerhafte Verbindung und alle anderen davon betroffenen Verbindungen gestrichelt. Zudem fehlt in der Funktion Bundle der mittlere Anschluß. Die Schaltfläche Run zeigt deshalb einen zerbrochenen, inaktiven Pfeil. Das Programm kann erst gestartet werden, wenn alle Fehler behoben sind. Die Fehlerliste enthält die Beschreibung alle Syntaxfehler samt Erklärungen, worauf diese zurückzuführen sind. Korrektes Blockschaltbild mit Programmanimation: Nach Korrektur der Fehler wurde das Programm im Modus»animierter Programmlauf«gestartet. Die Datenquellen zeigen die aktuellen Werte und auf den Verbindungen fließen Datentoken, dargestellt als Kügelchen. Noch nicht ausgeführte Operationen und noch nicht aktivierte Verbindungen sind abgeschwächt dargestellt.

156 Beispiele für visuelle Programmiersysteme VISAVIS: Visuelle Programmierung mit Funktionsdiagrammen VisaVis ist ein funktionsorientiertes VP-System, das Anfang der 90er Jahre an der Universität Dortmund (BRD) von Poswig [93] entworfen und implementiert wurde. Poswig berücksichtigte bei der Entwicklung von VisaVis nicht nur spezielle Aspekte der Benutzerinteraktion in funktionsorierientierten VP-Systemen, sondern verfolgte auch hinsichtlich der Übersetzung visueller Programme in eine textuelle Metasprache neue Wege, deren Realisierbarkeit er anhand eines lauffähigen Prototypen zeigte Anwendungsbereich Poswig betrachtet VisaVis als experimentelles System und nennt deshalb keinen speziellen Anwendungsbereich [S. 37]. Wegen des funktionsorientierten Paradigmas sind jedoch algorithmische Probleme am ehesten zur Lösung mit VisaVis geeignet. Dies bestätigte auch ein exemplarischer Vergleich visueller Programmiersprachen, im Rahmen der»1994 Visual Language Competition«(vgl. Hansen et al. [94]), wo VisaVis zwar mit der Implementierung eines Primzahlengenerators vertreten war, bei interaktiven Problemstellungen jedoch fehlte. Die geringe Eignung für interaktive Anwendungen zeigt sich auch darin, daß VisaVis keine Möglichkeiten zum Anschluß grafischer Benutzungsschnittstellen vorsieht. Die Ein- und Ausgabe von Daten ist nur über rudimentäre Editoren möglich Konzepte Erste Anstöße zur Entwicklung von VisaVis kamen aus dem Multimediabereich, wo spezielle Algorithmen für die Verarbeitung von Audio- und Videodaten benötigt werden. Diese Verfahren werden in Sachbüchern oft grafisch dargestellt, weil dadurch das Verständnis für ihre Funktionsweise bedeutend gefördert werden kann. Ein klassisches Beispiel ist der Butterfly-Algorithmus für die schnelle Fouriertransformation (vgl. Poswig [96 S. 97]). Seine symmetrische Struktur, die an einen Schmetterling erinnert, prägt sich durch eine visuelle Repräsentation besonders gut ein (siehe Bild 6-11). Bei der Umsetzung in eine verbale Programmiersprache geht die Struktur des Butterfly- Algorithmus allerdings verloren, und dementsprechend schwer sind Implementierungen in Fortran, C, Pascal oder anderen verbalen Sprachen zu verstehen. Poswig wollte solche Brüche zwischen Fachkonzepten und ihrer Umsetzung in Programme vermeiden. Sein Ziel war es, eine visuelle Programmsprache mit hoher Ausdruckskraft schaffen, die einerseits eine intuitive Benutzung erlaubt und andererseits auf einer formalen und damit mathematisch handhabbaren Metasprache beruht. Die intuitive Benutzung wird in VisaVis durch eine spezielle Konstruktionsmetapher, wenige und einfache Grundsymbole, eine kompakte Darstellung, den Verzicht auf komplexe Ablaufstrukturen und ein implizites Typsystem angestrebt (vgl. Poswig [93 S. 33 ff]). Die formale Metasprache auf Basis erweiterter FP-Systeme (kurz FFP-Systeme) weist eine einfache Semantik auf, bietet Funktionen höherer Ordnung, Parallelität, Rekursion und Nebeneffektfreiheit [S. 38 ff]. Zudem zeigt Poswig, daß VisaVis berechnungsuniversell ist, d.h. daß damit beliebige Algorithmen formulierbar sind [S. 110 ff].

157 6.4 VisaVis: Visuelle Programmierung mit Funktionsdiagrammen 147 Bild Der Butterfly-Algorithmus für die schnelle Fourier-Transformation Poswig [96 S. 116] Vom softwaretechnischen Standpunkt aus gesehen ist insbesondere das in VisaVis angedachte Typsystem interessant. Es handelt sich dabei um ein implizites Typsystem, das aufgrund gewisser Annahmen und Regeln den Typ eines visuellen Ausdruck automatisch ableitet und Inkompatibilitäten aufzeigt, ohne daß der Programmierer explizite Deklarationen vornehmen muß. Poswig schreibt dazu [S. 191]: Die Idee impliziter Typsysteme besteht darin, die Flexibilität ungetypter Sprachen, wie z.b. Smalltalk, LISP oder auch VisaVis, mit der Garantie für eine Typsicherheit zu verbinden. Obwohl explizit typisierte Programme, wie z.b. in C oder C++, von den meisten, die schon programmiert haben als völlig selbstverständlich empfunden werden, ist es nicht von der Hand zu weisen, daß Typdeklarationen zeit- und platzaufwendig sind. Da wir bei der Entwicklung einer visuellen Programmiersprache immer einen geringen Formulierungsaufwand, z.b. durch die Realisierung der Substitution und einen hohen Grad der Visualisierung, z.b. durch die Verwendung von Softwareplatinen anstreben, scheidet die Einführung einer expliziten Typisierung in VisaVis für uns aus. Geleitet von speziellen Anforderungen an Typsysteme in visuellen Sprachen, die erstmals von Burnett [91] formuliert wurden, entwickelte Poswig ein inkrementelles Typsystem für spontanen Polymorphismus. Er verfolgt damit laut eigener Aussage einen Ansatz, der bis dato weder für verbale noch für visuelle Sprachen verfolgt wurde und Typsicherheit bei jedem Programmierschritt garantiert (vgl. Poswig [96 S. 192 und S. 195]). Neben den prinzipiellen Vorteilen seines Typsystems (keine speziellen Sprachkonstrukte für Typdeklarationen, Flexibilität durch Polymorphismus, leichte Änderbarkeit der Programme usw.) soll eine enge Integration mit der Programmierumgebung den Benutzer so leiten, daß dieser anhand leicht erfaßbarer Visualisierungen erkennen kann, welche Programmteile kombinierbar sind und welche nicht. Fehlerlisten würden dadurch überflüssig.

158 Beispiele für visuelle Programmiersysteme 148 In Poswig [93] finden sich eingehende theoretische Betrachtungen zum Typsystem von VisaVis und den damit verbundenen Problemstellungen bei der Übersetzung visueller Programme in Ausdrücke der FFP-Metasprache Sprache Der streng funktionale Charakter von VisaVis zeigt sich deutlich daran, daß die Programmiersprache kein einziges typisch imperatives Konstrukt zur Verfügung stellt. Es gibt weder Variablen noch Zuweisungsoperationen noch Schleifen. Die Logik eines VisaVis-Programms besteht ausschließlich aus miteinander verbundenen Funktionen, die jeweils genau ein Resultat zurückgeben. Funktionen mit mehreren Ausgangsparametern, wie sie sowohl in imperativen als auch datenflußorientierten Sprachen häufig vorkommen, sind in VisaVis unbekannt. Diese konsequente Umsetzung funktionaler Konzepte wird durch eine saubere Sprachstruktur und Optimierungsmöglichkeiten belohnt, der Preis dafür ist das beschränkte Anwendungsgebiet. VisaVis umfaßt vier Sprachelemente, mit denen alle Programme formuliert werden können (die folgenden Bezeichnungen wurden von Poswig übernommen): Ein-Ausgabeeinheit (kurz Eingabe und Ausgabe): Parameter bzw. Resultat eines Programms. In der Terminologie der funktionalen Sprachen eine Funktion der Ordnung 0. Repräsentiert als Atom, Sequenz, Polynom oder Matrix. Softwarebaustein (kurz Baustein): Funktion im herkömmlich Sinn mit einer oder mehreren Eingaben als Parameter und genau einer Ausgabe als Resultat. In der Terminologie der funktionalen Sprachen eine Funktion der Ordnung 1. Softwareplatine (kurz Platine): Funktion mit einem oder mehreren Bausteinen als Parameter. In der Terminologie der funktionalen Sprachen eine Funktion der Ordnung 2. Funktionen höherer Ordnung unterstützt VisaVis nicht. Der Begriff»Platine«kommt daher, daß bei der Programmkonstruktion ein Baustein sozusagen in einen Sockel der Platine gesteckt wird, mit anderen Worten, daß eine Funktion 2. Ordnung (Platine) mit einer Funktion 1. Ordnung (Baustein) parameterisiert wird. Verbindung: Kanal zwischen Ein-Ausgaben und Bausteinen bzw. Platinen sowie zwischen Bausteinen bzw. Platinen untereinander. Über Verbindungen fließen Daten. Bild 6-12 zeigt die visuelle Repräsentation dieser Elemente. Jedes Element kann einen Namen tragen. Die Namensräume von Eingaben, Ausgaben, Softwarebausteinen und Platinen sind getrennt, das heißt, eine Eingabe kann genauso benannt werden wie eine Ausgabe. Tragen zwei oder mehrere Eingaben denselben Namen, so beziehen sich benannten Elemente auf dasselbe logische Objekt. Durch Mehrfachbenennungen kann man Liniengewirr vermeiden, in dem man Eingaben mehrfach im Programm plaziert, statt von einer einzigen Eingabe zu allen Benutzungsstellen eine Linie zu ziehen. Die Möglichkeit der Mehrfachbennung besteht auch für Ausgaben. Bild 6-13 zeigt Anwendungen für Bausteine und Platinen mit benannten Elementen.

159 6.4 VisaVis: Visuelle Programmierung mit Funktionsdiagrammen R 2. Gel 1. Gr Ein-Ausgabeeinheit Softwarebaustein Softwareplatine Verbindung Bild Die vier Grundelemente der Sprache VisaVis; Farbbild im Anhang. Vgl. Poswig [96 S. 72] Die Farben der Symbole repräsentieren den Zustand des dargestellten Elements: Grün steht für unspezifiziert, Gelb für spezifiziert und Rot für Resultat bzw. unveränderliche Prädikatfunktion. Baustein Platine Vergleich Bild Filterung Anwendungen von Bausteinen und Platinen; Farbbild im Anhang. Baustein: Eine allgemeine Funktion g der Ordnung 1 mit zwei Parametern x und y und Resultat z. Platine: Eine allgemeine Funktion f(g) der Ordnung 2 bestückt mit einer Funktion (einem Baustein) g der Ordnung 1. Die Parameter u und v sowie das Resultat z stehen nicht notwendigerweise in einem direkten Zusammenhang mit den Parametern der Funktion g, mit anderen Worten, die Ein-Ausgaben von f müssen nicht die Ein-Ausgaben von g sein. Vergleich: Eine konkrete Ausprägung des Bausteins. Die Funktion LessThan prüft, ob a < b gilt und gibt true bzw. false zurück. Filterung: Eine konkrete Ausprägung der Platine. Die Funktion FilterWithArg ist mit der Funktion LessThan bestückt und prüft mit Hilfe dieser Funktion jedes Element e aus list dahingehend, ob e < value gilt. Nur solche Elemente werden durchgereicht. Demnach enthält filteredlist alle Elemente aus list, die kleiner als value sind. Damit LessThan auf jedes Element von list angewendet werden kann, müssen die Listenelemente typkompatibel mit Parameter a von LessThan sein. Dasselbe gilt für value und b.

160 Beispiele für visuelle Programmiersysteme 150 Für Ablaufstrukturen gibt es nur ein einziges Sprachkonstrukt, die PredicateBox. Eine PredicateBox ist eine verallgemeinerte Fallunterscheidung, die man textuell folgendermaßen notieren könnte: PredicateBox(x) = Case1(x,...) if Predicate1(a,b,c,...) = Case2(x,...) if Predicate2(a,b,c,...) = Case3(x,...) if Predicate3(a,b,c,...) =... = CaseN(x,...) if PredicateN(a,b,c,...) = Else (x,...) otherwise Die einzelnen Elemente haben folgende Bedeutung: x ist ein Datum beliebigen Typs. Predicate1 - PredicateN sind boolesche Prädikatfunktionen mit beliebig vielen Parametern a, b, c usw. Alle Prädikate müssen dieselbe Parameteranzahl und denselben Parametertyp aufweisen. Case1 - CaseN sind Fallfunktionen, die mit x und eventuell weiteren Datenwerten als Parameter aufgerufen werden, falls das zugehörige Prädikat den Wert true ergibt. Die Prädikate werden der Reihe nach ausgewertet und jene Fallfunktionen ausgeführt, deren Prädikat als erstes true ergibt. Falls kein Prädikat true ergibt, dann wird Else ausgeführt. Bild 6-14 zeigt die grafische Darstellung der PredicateBox. Die Fallfunktionen Case1 - CaseN und Else sind nicht sichtbar, da sie über die hinausführenden Verbindungspfeile angeschlossen werden. Ist ein Verbindungspfeil an keine Funktion gebunden, so bedeutet dies, daß in diesem Fall der Eingabewert zugleich der Resultatwert ist. Bild 6-15 zeigt eine Anwendung der PredicateBox zur Berechnung des Maximums zweier Zahlen. An diesem Beispiel ist gut erkennbar, daß der rein funktionale Charakter von VisaVis selbst bei einfachen Aufgabenstellungen sehr ungewöhnliche Lösungen herbeiführt. Da die PredicateBox einem Funktionsaufruf entspricht, wird der (einzige) Eingabewert auch dann weitergeleitet, wenn der Else-Zweig keine Bedeutung hat. Das heißt im konkreten Fall, daß die PredicateBox einerseits nur mit einem der zwei Werte a bzw. b verbunden werden kann und andererseits der Else-Zweig auch dann verfolgt werden muß, wenn klar ist, daß a < b gilt. Für diesen Fall wird die Filterfunktion ConstantX benötigt, die a ignoriert und nur b weiterleitet. Man vergleiche diese Darstellung mit Bild 6-6, S. 144, wo die Maximumberechnung mit LabVIEW gezeigt wird. Der Vorteil von LabVIEW ist die weitaus intuitivere und kompaktere Repräsentation; der Vorteil von VisaVis ist die Gesamtdarstellung der Funktion auf einer Fläche, ohne Überlagerungen der einzelnen Programmzweige. Bild 6-16 verdeutlicht die unterschiedlichen Konzepte von LabVIEW und VisaVis nochmals am Beispiel der Fallunterscheidung. Auch hier muß in VisaVis die Filterfunktion ConstantX für den korrekten Datenfluß sorgen. Zudem sind die Vergleiche in den einzelnen Prädikatsfunktionen versteckt und nach außen nicht sichtbar. Es gibt keinen offenkundigen Weg, wie die für den Vergleich herangezogenen Zeichenketten sichtbar gemacht werden könnten, wie dies in LabVIEW ohne weiteres möglich ist (siehe Bild 6-7, S. 144). Wie bereits erwähnt, gibt es in VisaVis keine eigenständigen Sprachelemente für Schleifen. Wiederholungen sind deshalb nur in Form von Rekursionen möglich. Bild 6-17 zeigt ein Beispiel für die rekursive Version des Newtonschen Verfahren in VisaVis, das in LabVIEW mangels Rekursion iterativ implementiert werden mußte (siehe Bild 6-9, S. 145).

161 6.4 VisaVis: Visuelle Programmierung mit Funktionsdiagrammen 151 Für allgemein einsetzbare Schleifenkonstrukte benötigt man eine Platine und mindestens einen Baustein. Die Platine führt den Baustein so lange rekursiv aus, bis eine bestimmte Bedingung erfüllt ist und die Rekursion abbricht. Ist die Abbruchbedingung nicht fix vorgegeben, sondern bei der Bestückung der Platine festzulegen, muß die Bedingung als Prädikatbaustein vorliegen. Die Platine verfügt in diesem Fall über zwei Sockel einen für die Abbruchbedingung und einen für die zu wiederholende Funktion. Bild 6-18 und Bild 6-19 zeigen Beispiele für Schleifen in VisaVis. Ein offensichtlicher Nachteil des Schleifenkonzepts von VisaVis liegt darin, daß für jede mögliche Parameteranzahl der zu wiederholenden Funktion und der Abbruchbedingung eine eigene Platine benötigt wird. Bei statischer Typisierung ist zudem ein implizites Typsystem unverzichtbar, da ansonsten für jeden Parametertyp eine eigene Schleifenplatine vorzusehen wäre, was zu einer kombinatorischen Explosion der Anzahl von Schleifenplatinen führen würde. Zudem erzwingt die Rekursion einen eigenen Baustein für jedes wiederholt auszuführende Codestück, was ebenfalls nicht zur Übersichtlichkeit beiträgt.

162 Beispiele für visuelle Programmiersysteme 152 Fallunterscheidung Verzweigung Bild Ablaufstrukturen in VisaVis. Vgl. Poswig [96 S. 76] Das Bild zeigt die Grundstruktur der PredicateBox von VisaVis, mit der Fallunterscheidungen und Verzweigungen realisiert werden können. Die PredicateBox besitzt genau eine Eingabeverbindung (von links), mindestens zwei Ausgabeverbindungen (nach rechts), beliebig viele Prädikatparameter-Verbindungen (von oben) und beliebig viele Prädikatfunktionen (im Inneren). Die Stelle else ist nicht modifizierbar. Sie repräsentiert jenen Fall, der dann aktiviert wird, wenn kein einziges Prädikat den Wert true liefert. Die PredicateBox reicht den an der Eingabeverbindung anstehenden Datenwert auf genau eine der Ausgabeverbindungen durch. Welche Ausgabeverbindung zu wählen ist, wird anhand der Rückgabewerte der Prädikatfunktionen entschieden. Die Prädikate werden von oben nach unten unter Berücksichtigung der Prädikatparameter ausgewertet. Es wird jene Ausgabeverbindung selektiert, deren zugehöriges Prädikat als erstes den Wert true ergibt. Weitere Prädikatparameter können durch Klick auf den Pfeil am unteren Rand hinzugefügt werden. Fallunterscheidung: Im Beispiel existieren vier Prädikatfunktionen Predicate1 - PredicateN mit jeweils drei Parametern a, b und c. Alle Prädikate werden zur Auswertung mit diesen drei Parametern versorgt. Durchgereicht wird der Wert x. Daß die Eingabe x genauso heißt wie die Ausgabe x spielt keine Rolle, da die Namensräume von Ein- und Ausgaben getrennt sind. Die Fallunterscheidung liefert nur ein einziges Resultat x, das durch Mehrfachbennung angesprochen wird. Verzweigung: Die Verzweigung ist eine Fallunterscheidung mit einem einzigen Prädikat - im Beispiel die Funktion Condition. Zu beachten ist, daß auch hier nicht der Steuerfluß verzweigt, sondern lediglich der Datenwert x an die entsprechende Ausgabeverbindung weitergeleitet wird. Bezüglich der Namensgleichheit von Ein- und Ausgaben sowie der Mehrfachbennung gilt das für die Fallunterscheidung Gesagte.

163 6.4 VisaVis: Visuelle Programmierung mit Funktionsdiagrammen 153 Bild Maximumberechnung mit Verzweigung in VisaVis. Das Bild zeigt ein VisaVis-Programm zur Berechnung des Maximums max zweier Zahlen a und b (siehe auch LabVIEW-Implementierung, Bild 6-6, S. 144). Das Prädikat GreaterThan vergleicht a mit b (das Beispiel zeigt, daß die Eingabe für die Predicate- Box zugleich auch eines der Prädikatargumente sein kann). Wenn dieser Vergleich true ergibt, wird der an PredicateBox anstehende Datenwert a an max weitergeleitet. Ergibt der Vergleich false, dann wird a ebenfalls weitergeleitet, diesmal aber an die Funktion ConstantX. Diese Funktion ignoriert den ersten Parameter in diesem Fall a und leitet nur den zweiten Parameter weiter in diesem Fall b. Auf diese Weise wird max im Else-Zweig mit b belegt.

164 Beispiele für visuelle Programmiersysteme 154 Bild Wortübersetzung mit Fallunterscheidung in VisaVis. Das Bild zeigt ein VisaVis-Programm, zur Übersetzung der Worte»blood«,»sweat«und»tears«in ein rudimentäres Englisch (siehe auch LabVIEW-Implementierung, Bild 6-7, S. 144). Die Prädikate EqualBlood, EqualSweat und EqualTears der Fallunterscheidung vergleichen den Wert des Parameters word mit den Worten»blood«,»sweat«und»tears«. Der Konstruktion der Fallunterscheidung ging die Konstruktion der Prädikate voraus, wo diese Worte als konstante Zeichenketten definiert wurden. Diese Zeichenketten sind im Bild nicht sichtbar. Je nachdem, welcher Zeichenkette word entspricht, wird word zum korrespondierenden Zweig weitergeleitet. Da word selbst als Ergebnis der Fallunterscheidung uninteressant ist, wird wie in Bild 6-15 die Funktion ConstantX benötigt, um word auszufiltern und statt dessen die Übersetzung an simple english weiterzuleiten. Die Zeichenkette für die Übersetzung sind in den Eingaben red body water, white body water und eye body water abgelegt und können mit einem speziellen Editor modifiziert werden.

165 6.4 VisaVis: Visuelle Programmierung mit Funktionsdiagrammen 155 Bild Das Newtonsche Verfahren in VisaVis Das Bild zeigt den Baustein Newton zur Bestimmung einer Nullstelle der Funktion f(x) = sin(x) mit der ersten Ableitung f (x) = cos(x). Newton wird mit einer ersten Näherung x0 aufgerufen. Jeder weitere rekursive Aufruf verbessert die Lösung, bis die gewünschte Genauigkeit eps erreicht ist. Ein Vergleich von eps mit dem Absolutwert des Verhältnisses von f zu f steuert die PredicateBox. Wenn die gewünschte Genauigkeit noch nicht erreicht ist, wird der Newton mit der neuen Näherung noch einmal aufgerufen, sonst endet die Rekursion und das Ergebnis wird in x abgelegt. (siehe auch Lab- VIEW-Implementierung, Bild 6-9, S. 145).

166 Beispiele für visuelle Programmiersysteme 156 Bild Bedingungsschleife in VisaVis. Vgl. Poswig [96 S. 94 f] Die Bedingungsschleife ist eine Platine While mit zwei Bausteinen p und f, einer Eingabe x und einem Resultat z. Der Baustein p ist eine Prädikatfunktion für die Abbruchbedingung. Der Baustein f, der die eigentliche Funktion realisiert, wird solange rekursiv aufgerufen, bis p den Wert false liefert. In jeden rekursiven Aufruf fließt das Ergebnis des vorigen Aufrufs als neues x ein, d.h. innerhalb der Schleife kann nicht auf lokale oder globale Werte zugegriffen werden, sondern nur auf Parameter x. Dieser Parameter ist zudem der einzige Wert, der die Abbruchbedingung steuert. Eine beliebiger logischer Ausdruck kann dazu nicht verwendet werden. Die Flexibilität dieser Schleifenkonstruktion ist demzufolge sehr gering, und es fällt schwer, einen sinnvollen Anwendungsfall zu finden. In Pseudocode notiert realisiert die Bedingungsschleife folgenden Algorithmus: While (p,f,x) if (p(x)) then z := While (p,f,f(x)) else z := x return z Bild Zählerschleife in VisaVis. Vgl. Poswig [96 S. 94 f] Die Zählerschleife ist eine Platine N-Times-Repeat mit einem Baustein f, zwei Eingaben n und x und einem Resultat z. Der Baustein f wird so lange rekursiv aufgerufen, bis n <= 0 ist, wobei n bei jedem Durchlauf um 1 dekrementiert wird. Die Funktion f wird demzufolge genau n-mal aufgerufen. Wie im Beispiel für die Bedingungsschleife, wird auch in diesem Fall der Eingabewert x bei jedem rekursiven Aufruf durch das Ergebnis des vorigen Aufrufs ersetzt. Auch diese Schleifenkonstruktion ist sehr inflexibel. Beispielsweise ist es nicht möglich, auf einfache Weise die Summe aller Zahlen von 1 bis n zu bilden, da die Funktion f den aktuellen Stand des Schleifenzählers nicht kennt. In Pseudocode notiert realisiert die Zählerschleife folgenden Algorithmus: N-Times-Repeat (n,f,x) if n <= 0 then z := x else z := N-Times-Repeat (Decrement(n,f,f(x)) return z

167 6.4 VisaVis: Visuelle Programmierung mit Funktionsdiagrammen Interaktion VisaVis besteht aus mehreren integrierten Komponenten, von denen einige zur Interaktion mit dem System benötigt werden und andere für Aufgaben im Hintergrund vorgesehen sind. Zu den wichtigsten Interaktionswerkzeugen gehören: Visueller Editor: Arbeitsbereich für das Erstellen, Ausführen und Testen von Programmen und Softwarebausteinen. Funktionsspeicher: Bereitstellung und Archivierung von Softwarebausteinen. Hierarchiewerkzeug: Darstellung und Manipulation von Programmbausteinen auf verschiedenen Abstraktionsebenen. Animationswerkzeug: Aufzeichnung und Visualisierung des Programmablaufs. Diese Werkzeuge arbeiten mit folgenden für den Benutzer unsichtbaren Komponenten zusammen: Überwacher: Sicherung der syntaktischen Korrektheit der Benutzereingaben und Typkompatibilität der Bausteinkombinationen zusammen mit visuellem Editor und Inferenzmaschine. Inferenzmaschine: implizite Typbestimmung von visuellen Ausdrücken zusammen mit Überwacher und Klauseldatenbank. Klauseldatenbank: Verwaltung von Typinformationen zu Programmbausteinen. Übersetzer: Transformation visueller Ausdrücke in FFP-Ausdrücke. Interpreter: Auswertung von FFP-Ausdrücken bei der Programmausführung. Bild 6-20 zeigt die für die Interaktion beiden wichtigsten Komponenten, den Funktionsspeicher und den visuellen Editor. Der an Einzelheiten interessierte Leser findet bei Poswig [96] eine ausführliche Beschreibung dieser Komponenten und ihres Zusammenwirkens. In VisaVis werden Programme durch Substitution erzeugt. Die Ersetzung eines Programmelements durch ein anderes Element ist die einzige Möglichkeit zum Erzeugen von Verbindungen und zur Bestückung von Platinen. Bei der Substitution wird ein Element selektiert, über ein anderes Element gezogen und dort»fallengelassen«. Eventuelle Verbindungslinien entstehen automatisch. Spezielle Werkzeuge zum Zeichnen von Verbindungen existieren nicht. Dieser Interaktionsmechanismus vereinfacht die Benutzung des Systems und schließt syntaktische Fehler aus, weil die Überwachungskomponente darauf achtet, daß das System nach der Selektion eines Elements nur gültige Elemente zur Substitution anbietet. Die Substitution beruht auf der Metapher des Schlüssels und der dazu passenden Schlüssellöcher. Besonders anschaulich ist dieses Sinnbild bei der Bestückung von Platinen, wo ein Baustein auf einem Sockel verankert wird. Sowohl die Form des Bausteins (Schlüssel) als auch des Platinensockels (Schlüsselloch) illustriert deutlich die zugrundeliegende Idee. Damit potentielle Kombinationen leicht erkennbar sind, verlieren nach der Selektion eines Programmelements alle ersetzbaren Elemente ihren Schatten. Bei der Bestückung von Platinen, sind dies jene Sockel, deren Bausteine dieselben Anzahl von Ein-Ausgaben aufweisen wie der selektierte Baustein.

168 Beispiele für visuelle Programmiersysteme 158 Bild Funktionsspeicher und visueller Editor von VisaVis. Der Funktionsspeicher (oben) enthält in ungeordneter Form alle verfügbaren Softwarebausteine (Funktionen). Dazu gehören sowohl mit Smalltalk programmierte als auch visuell erzeugte Bausteine. Der visuelle Editor (unten) dient zur visuellen Konstruktion von Bausteinen. Er gliedert sich in drei Bereiche: (1) Im linken oberen Teil befinden sich Schaltflächen zur Manipulation von Bausteinen. Die Beschriftung erscheint und verschwindet, je nachdem, welche Elemente selektiert sind. (2) Rechts neben den Schaltflächen befinden sich sensitive Felder, mit denen unspezifiziert Eingaben, Bausteine und Platinen im Arbeitsbereich erzeugt werden können. Die Pfeilfelder ändern die Anzahl der Eingaben eines Bausteins bzw. die Anzahl der Bausteinparameter für eine Platine. (3) Im unteren Teil des visuellen Editors befindet sich die Arbeitsfläche zur Programmkonstruktion. Das Bild zeigt eine noch unspezifizierte Platine mit drei Eingaben und zwei Bausteinparametern, die mit Hilfe des sensitiven Felds rechts oben durch Drag-und-Drop erzeugt wurde. Spezifizierte Bausteine und Platinen können vom Funktionsspeicher auf die Arbeitsfläche gezogen werden.

169 6.5 PARTS: Visuelle Programmierung mit Objektdiagrammen PARTS: Visuelle Programmierung mit Objektdiagrammen PARTS (Parts Assembly and Reuse Tool Set) ist ein objektorientiertes VP-System. Es kam 1992 auf den Markt und war das erste kommerzielle VP-System, das eine objektorientierte Programmiersprache und einen Benutzungsschnittstelleneditor auf visueller Ebene nahtlos integrierte. PARTS ist in Smalltalk implementiert, und aus den visuell erstellten Applikationen wird ebenfalls Smalltalk-Code generiert. Das Grundkonzept von PARTS die Programmierung mit Softwarekomponenten, findet man in abgewandelter Form auch in anderen Umgebungen etwa in Microbrew (Serius), Notes ViP, VisualAge, und Visual Basic. Man kann PARTS entweder als eigenständige Entwicklungsumgebung einsetzen oder im Rahmen der Smalltalk/V Programmierumgebung von Digitalk verwenden. Die mit Smalltalk/V integrierte Version bietet die Möglichkeit, die eingebaute Klassenbibliothek zu erweitern, was für größere Applikationen auch notwendig ist. Unterstützte Entwicklungsplattformen sind OS/2, MS-Windows und Windows NT. In der Zwischenzeit hat IBM mit VisualAge [95] ein VP-System auf den Markt gebracht, das ebenfalls auf Smalltalk beruht. Andere Varianten von VisualAge unterstützen eine Reihe weiterer Sprachen, wie Basic, C++, Cobol, RPG und Java. Die visuellen Interaktionsmechanismen von VisualAge und PARTS sind einander ähnlich. VisualAge ist PARTS jedoch konzeptionell überlegen. Selinger [95 S. 102] vergleicht in seiner Diplomarbeit PARTS 2.0 und VisualAge 1.0 anhand einer Vielzahl von Merkmalen. Er kommt zum Schluß, daß VisualAge für die professionelle Softwareentwicklung gut geeignet ist, was seiner Meinung nach für PARTS nicht zutrifft. PARTS wurde dennoch in diese Übersicht aufgenommen, weil es vergleichsweise einfach aufgebaut ist und die wesentlichen Konzepte der objektorientierten visuellen Programmierung gut verdeutlicht. Die folgenden Ausführungen beziehen sich auf PARTS Version 2.0 (vgl. PARTS [92]). Eine neuere Version mit dem Namen VisualSmalltalk bietet Mechanismen für die kooperative Softwareentwicklung, und eine Version für Java gibt es inzwischen auch. Für die aktuellen Versionen siehe PARTS [WWW]. Weitere Literatur findet sich u.a. bei LaLonde und Pugh [93], Broer [94], Kratzer [95] sowie Sayles et al. [94] Anwendungsbereich PARTS ist primär für Anwender ohne Programmierkenntnisse gedacht, die aus vorgefertigten Softwarebausteinen (Komponenten) in kurzer Zeit Applikationen mit einer grafischen Benutzungsschnittstelle bauen möchten. Typische Anwendungen sind etwa Front-Ends für Client-Server-Applikationen oder kleine Informationssysteme. Zur Programmkonstruktion stehen mehr als 60 vorgefertigte Komponenten zur Verfügung, von denen ca. 40 für die Gestaltung der Benutzungsschnittstelle vorgesehen sind und ca. 20 für nicht-visuelle Programmieraufgaben, wie Berechnungen, Vergleiche, Dateioperationen und Datenbankabfragen. Digitalk behauptet, daß mit PARTS und einer passenden Komponentenbibliothek die Konstruktion beliebig komplexer Anwendungen möglich ist, ohne daß eine Zeile Programmcode geschrieben werden muß (vgl. PARTS [92 S. 1-4]). Diese Behauptung ist fragwürdig, denn mit zunehmendem Funktionsumfang einer PARTS-Anwendung wird die Programmstruktur überproportional komplexer. Durch die für größere Applikationen notwendige hohe Anzahl von Komponenten und Verbindungen zwischen den

170 Beispiele für visuelle Programmiersysteme 160 Komponenten ist ab einem gewissen Komplexitätsgrad die notwendige Übersicht nicht mehr gegeben, und weitere Programmaktivitäten sind praktisch unmöglich. Selinger [95 S. 102] kommt anhand der Entwicklung eines Dokumentationssystems mit PARTS zum Schluß, daß der geeignete Einsatzbereich für PARTS die Programmierung kleiner Applikationen ist. Typische Anwendungsgebiete sind laut Selinger die Programmierung von Benutzungsschnittstellen und das Zusammensetzen und Konfigurieren von Komponenten, die exakt dem gewünschten Verwendungszweck angepaßt sind. Professionelle Softwareentwicklung mit PARTS ist für Selinger nicht vorstellbar. Die Erfahrungen des Verfassers mit PARTS unterstreichen die Einschätzung Selingers. Für Anwendungen mit hochwertiger Benutzungsschnittstelle und wenig Verarbeitung ist PARTS gut geeignet, weil dafür nur kombinierendes Programmieren, ohne Spezialisierung bestehender Bausteine notwendig ist. Die Entwicklung solcher Applikationen ist für einen begabten Anwender möglich. Bei komplexer Verarbeitungslogik versagen die visuellen Konzepte von PARTS, so daß auf die verbale Smalltalk-Ebene abgestiegen werden muß und ein Konzeptbruch entsteht. Für einen Anwender ist dieser Konzeptbruch schwer zu überwinden, weil die Benutzung von Smalltalk in der Regel zu schwierig ist. Er wird deshalb komplexe Applikationen nicht programmieren können. Ein professioneller Entwickler wird von vornherein auf die visuellen Ausdrucksmöglichkeiten verzichten, um den Wechsel zwischen visueller und verbaler Programmierung zu vermeiden. Er wird mit Ausnahme der Benutzungsschnittstelle alles mit Smalltalk programmieren. Für professionelle Softwareentwicklung sind deshalb die visuellen Sprachelemente von sekundärer Bedeutung Konzepte Bei der Softwareentwicklung mit PARTS wählt der Programmierer Objekte (Parts, Bausteine) aus einer Objektbibliothek (Parts-Katalog, Bausteinkatalog) und kombiniert diese Objekte in einem Arbeitsbereich zu neuen Objekten bzw. zu Applikationen. Ein konzeptioneller Unterschied zwischen Objekt und Applikation existiert nicht. Die einzige Unterscheidung liegt darin, daß eine Applikation über eine grafische Benutzungsschnittstelle verfügt, was für ein Objekt nicht der Fall sein muß. Um die konzeptionelle Einheit von Objekt und Applikation zu betonen, wird im folgenden nur noch von Baustein gesprochen und beides damit gemeint. Ein Baustein weist alle Eigenschaften eines Objektes im Sinne der OOP auf: Er verfügt über eine Schnittstelle zur Kommunikation mit anderen Objekten, reagiert mit einem bestimmten Verhalten auf den Empfang von Nachrichten, hat Attribute wie Größe, Position und Farbe und befindet sich in einem bestimmten Zustand, der sich aus den Attributwerten und den Zuständen der internen Bausteine ergibt. Die wesentliche Abweichung des PARTS-Konzepts vom klassischen objektorientierten Denkmodell besteht darin, daß Struktur und Verhalten von Bausteinen nicht durch Klassen definiert sind, sondern auf den individuellen Eigenschaften eines Bausteins beruhen. Bei herkömmlicher OOP beschreiben Klassen die gemeinsame Struktur und das gemeinsame Verhalten aller derselben Klasse angehörenden Objekte. Eine Änderung dieser Beschreibung, etwa die Modifikation des Programmcodes einer Methode, wirkt auf alle Objekte der Klasse. Für einzelne Objekte können Methoden nicht selektiv verändert werden.

171 6.5 PARTS: Visuelle Programmierung mit Objektdiagrammen 161 Bei PARTS dient ein Baustein aus dem Bausteinkatalog nur als Vorlage für die Erzeugung gleichartiger Bausteine, nicht jedoch als zentrale Stelle, die dafür sorgt, daß sich alle Bausteine der gleichen Art auch gleich verhalten. Wenn ein Baustein dem Bausteinkatalog entnommen wird, entsteht ein neues Exemplar dieses Bausteintyps, das zunächst die gleichen Attribute und das gleiche Verhalten aufweist wie die Vorlage. Diese Aspekte können jedoch modifiziert werden, ohne daß andere Bausteine desselben Typs davon betroffen sind. Man spricht in diesem Fall von exemplarbasierter OOP (vgl. LaLonde und Pugh [93]) bzw. bei einer abgewandelten Form von prototypbasierter OOP (vgl. Weinreich [93 S. 18 ff]). Das Konzept der exemplarbasierten OOP ist nicht auf VP-Systeme beschränkt, sondern auch für verbale Programmiersprachen geeignet. Exemplarbasierte OOP ist aber gerade für visuelle Programmierung ein besonders zweckmäßiger und intuitiver Ansatz, da objektorientierte VP-Systeme die direkte Manipulation einzelner Objekte unterstützen und durch ein Klassenkonzept eine verständnishemmende Abstraktionsschicht eingezogen würde. Ein weiterer Unterschied zu konventioneller OOP ist die in PARTS fehlende Vererbung. Visuelle konstruierte Bausteine können nicht spezialisiert werden, indem einzelne Attribute oder Methoden in einem abgeleiteten Baustein modifiziert oder hinzugefügt werden. Bausteine sind somit zwar ineinander geschachtelt, aber nicht hierarchisch organisiert. Durch die fehlende Vererbung ist es nicht möglich, Frameworks zu programmieren, die ein generisches Programmskelett für eine ganze Problemklasse enthalten und an bestimmten Stellen an das jeweilige Spezialproblem anpaßbar sind. Wie bereits eingangs erwähnt, gibt es zwei Gruppen von Bausteine: visuelle Bausteine für die Gestaltung der Benutzungsschnittstelle und nicht-visuelle Bausteine für die interne Programmlogik. Beide Bausteinarten werden auf einer gemeinsamen Arbeitsfläche bearbeitet und miteinander verknüpft. PARTS verfolgt damit einen anderen Ansatz als LabVIEW, wo Benutzungsschnittstelle und Programmlogik in getrennten Fenstern bearbeitet werden (siehe»konzepte LabVIEW«, S. 162). Als Folge der gemeinsamen Darstellung von Oberfläche und Logik tendieren PARTS-Programme zur Unübersichtlichkeit. Bausteine können jedoch nicht nur visuell, sondern auch durch Smalltalk- Programmierung und durch Einbindung des Codes anderer Programmiersprachen erzeugt werden. Es existieren beispielsweise Schnittstellen für Cobol- und C-Prozeduren, die über DLL-Dateien (Dynamic Link Libraries) integriert werden. Eine DDE- Schnittstelle (Dynamic Data Exchange) dient zum Datenaustausch mit anderen Applikationen. Gemeinsam ist allen Arten von Bausteinen die Schnittstelle. Sie umfaßt Attribute (properties), Ereignisse (events) und Nachrichten (messages). Attribute sind Datenwerte, wie Größe, Position und Farbe, die bei der Programmierung über ein Dialogfenster eingestellt werden. Attributwerte können während der Laufzeit nur dann geändert werden, wenn dafür entsprechende Nachrichten definiert sind. Ereignisse werden von Bausteinen generiert und signalisieren Benutzeraktionen (z.b. Drücken einer Schaltfläche) bzw. Zustandsänderungen eines Bausteins (Ablauf einer Schaltuhr). Nachrichten dienen dazu, von einem Baustein die Ausführung einer Aktion anzufordern oder seinen Zustand bzw. seine Attribute zu ändern oder abzufragen. Nachrichten werden meist aufgrund von Ereignissen versendet. So könnte etwa das Ereignis clicked einer Schaltfläche Cancel die Nachricht close an den Baustein Dialog senden, worauf sich das Dialogfenster schließt. Das Senden einer Nachricht an einen

172 Beispiele für visuelle Programmiersysteme 162 Baustein löst in vielen Fällen eines oder mehrere Folgeereignisse aus. Beispielsweise folgt auf die Nachricht clear gesendet an den Baustein EntryField das Ereignis changed, mit dem der Baustein signalisiert, daß sich der Inhalt des Eingabefeldes geändert hat, d.h. leer ist. Sowohl Ereignisse als auch Nachrichten können Daten mit sich tragen. Manche Nachrichten liefern außerdem ein Resultat, das als Argument in eine weitere Nachricht einfließen kann. Das Konzept der Aktivierung von Nachrichten aufgrund von Ereignissen verbessert die Wiederverwendbarkeit von Bausteinen, da bei der Bausteinkonstruktion nicht bekannt sein muß, mit welchen anderen Bausteinen der neue Baustein kommunizieren wird. Der Bausteinentwickler muß lediglich entscheiden, welche Zustandsänderungen zu welchen Ereignisse führen sollen. Erst der Bausteinbenutzer verbindet diese Ereignisse mit Nachrichten. Dadurch ist eine lose Kopplung zwischen den Bausteinen gegeben, für die bei konventioneller OOP spezielle Frameworks benötigt werden, etwa der Change- Update-Mechanismus. Der Entwickler eines Bausteins legt fest, auf welche von drei Arten der Baustein exportiert und von anderen Bausteinen importiert werden kann: als (1) Linked Packaged Part, (2) Embedded Packaged Part und (3) Ensemble of Parts. Die Export-Import- Mechanismen umfassen nicht nur Bausteine für die Programmlogik, sondern auch Bausteine für die Benutzungsschnittstelle. Jede der Varianten hat Vor- und Nachteile bezüglich der Modularität und der Integriertheit. Varianten 1 und 2 kapseln den Baustein, so daß bei Wiederverwendung in einer anderen Applikation nur die Schnittstelle sichtbar ist, nicht jedoch die interne Struktur. Die Moduläritat ist hoch, die Integriertheit gering. Bei Variante 1 enthält der umschließende Baustein einen Verweis auf den importierten Baustein. Erst bei der Programmausführung wird der importierte Baustein geladen. Dadurch kommen Aktualisierungen des importierten Bausteins bei jeder Programmausführung zum Tragen. Bei Variante 2 wird der importierte Baustein in den umschließenden Baustein kopiert. Spätere Aktualisierungen des importierten Bausteins bleiben wirkungslos. Variante 3 kopiert alle Einzelteile in den umschließenden Baustein. Der importierte Baustein ist nach der Einbettung nicht mehr identifizierbar. Die Modularität ist gering, die Integriertheit groß. Der Benutzer eines mit Variante 3 exportierten Bausteins hat keine Möglichkeit, sich beim Import für Variante 1 oder 2 zu entscheiden. Es ist unklar, anhand welcher Kriterien der Bausteinentwickler Exportvariante 3 auswählen soll, da er die Bedürfnisse des Importierenden nicht kennt Sprache PARTS-Bausteine können auf vier Sprachebenen implementiert werden: (1) mit allen Programmiersprachen, für die eine Erzeugung von DLL-Dateien möglich ist, (2) mit Smalltalk/V unter voller Nutzung der OOP-Konzepte (3) mit PARTSTalk, einer Untermenge von Smalltalk/V und (4) mit den beiden visuellen Bereichen von PARTS, dem Bausteinkatalog und der Arbeitsfläche. Die Sprachebenen 1 bis 3 sind auf verbale Programmierung beschränkt, weshalb auf ihre Darstellung verzichtet wird. Die folgende Erläuterungen beschreiben die visuellen Ausdrucksmittel der Ebene 4. Die visuelle Programmiersprache von PARTS ist stark in die Entwicklungsumgebung integriert. Sie hat keinen eigenen Namen und kann nur in Verbindungen mit den Werk-

173 6.5 PARTS: Visuelle Programmierung mit Objektdiagrammen 163 zeugen der Programmierumgebung verwendet werden. Die visuelle Sprache weist folgende wesentliche Merkmale auf: Homogen objektorientiert: alle Daten sind Bausteine, auch skalare Werte, wie Zahlen und Zeichenketten. Eingeschränkte Typisierung: in eigenen, jedoch nicht in allen Fällen sorgt das System dafür, daß die Typkompatibilität von Ereignissen, Nachrichten und Argumenten gewährleistet ist. Eingeschränkte Ablaufstrukturen: Verzweigungen werden durch Bausteine realisiert. Schleifen sind auf visueller Ebene nicht vorgesehen. Keine Klassen: Bausteine werden bei der Übernahme aus dem Bausteinkatalog in den Arbeitsbereich dupliziert und sind danach unabhängig von allen anderen Bausteinen der gleichen Art. Keine Vererbung: Struktur und Verhalten kann von anderen Bausteinen nicht abgeleitet werden. Keine Exemplargenerierung: Während der Programmausführung können keine neuen Bausteine erzeugt werden. Keine Methoden: visueller Programmcode kann nicht zu Methoden zusammengefaßt werden. Dadurch ist auch keine Rekursion möglich. Bei der Beschreibung der Schnittstelle von Bausteinen wurde bereits auf die Bedeutung von Ereignissen und Nachrichten hingewiesen. Die folgenden Erläuterungen erklären, wie man Bausteine mit Hilfe von Verbindungen verknüpft. Verbindungen (Links) repräsentieren gerichtete Daten- und Kommunikationskanäle. Es gibt drei Arten von Verbindungen: Ereignisverbindungen, Resultatverbindungen und Argumentverbindungen. Eine Ereignisverbindung verknüpft ein Ereignis mit einer Nachricht an denselben oder einen anderen Baustein: Baustein A Ereignis E Nachricht N Baustein B Wenn das Ereignis E bei Baustein A eintritt, dann sendet die Ereignisverbindung A-B die Nachricht N an den angeschlossenen Baustein B. Es ist möglich, mehrere Verbindungen für dasselbe Ereignis zu definieren. Zum Beispiel könnte für das Ereignis E eine zweite Ereignisverbindung erzeugt werden, die eine weitere Nachricht an Baustein B oder an einen anderen Baustein sendet. In diesem Fall kann der Programmierer mit dem Link Sequence Editor die Aktivierungsreihenfolge der Verbindungen festlegen. Bild 6-21 zeigt eine Ereignisverbindung zwischen einer Schaltfläche und einem Fenster.

174 Beispiele für visuelle Programmiersysteme 164 Eine Resultatverbindung verknüpft das Ergebnis einer Nachricht mit einer Nachricht an denselben oder einen anderen Baustein: Baustein A Ereignis E Nachricht N1 Baustein B Nachricht N2 Baustein C Wenn Baustein B das Resultat der Nachricht N1 ermittelt hat, dann sendet die Resultatverbindung B-C die Nachricht N2 (nicht das Resultat von N1) an den angeschlossenen Baustein B. Bild 6-22 zeigt Resultatverbindungen zur Berechnung eines einfachen arithmetischen Ausdrucks. Eine Argumentverbindung verknüpft das Argument einer Nachricht dem Resultat einer Nachricht an denselben oder einen anderen Baustein: Baustein A Ereignis E Nachricht N1: Baustein B Nachricht N2 Baustein C Bevor die Ereignisverbindung A-B die Nachricht N1: an den Baustein B senden kann, ist der Argumentwert für N1: zu ermitteln. Am Doppelpunkt ist erkennbar, daß N1: ein Argument verlangt. Die Argumentverbindung N1:-C holt das Argument durch Senden der Nachricht N2 an den Baustein C. Die Ausführungsreihenfolge der Nachrichten ist demnach N2 gefolgt von N1:. Argumentverbindungen können auch Argumente eines Ereignisses mit Argumenten einer Nachricht verbinden. Baustein A Ereignis E: Nachricht N: Baustein B Das Ereignis E: führt ein Argument mit sich, das in die Nachricht N: einfließt, bevor diese an den Baustein B gesendet wird. Ein Beispiel für ein Ereignisargument ist der Inhalt eines Eingabefeldes. Wenn der Benutzer durch Drücken der Eingabetaste das Ereignis entered: auslöst, wird der Feldinhalt diesem Ereignis als Argument mitgegeben. Bild 6-22 zeigt Argumentverbindungen zur Berechnung eines einfachen arithmetischen Ausdrucks. Bei der Erzeugung von Ereignis- und Resultatverbindungen bietet PARTS nur solche Nachrichten an, die der ausgewählte Baustein versteht. Damit ist eine rudimentäre Typsicherheit gegeben. Für Argumentverbindungen gilt dies nicht, da diese zwischen beliebigen Ereignis- und Nachrichtenargumenten gelegt werden können, ohne daß das Sys-

175 6.5 PARTS: Visuelle Programmierung mit Objektdiagrammen 165 tem eine Typprüfung vornimmt. Zwar existiert ein automatischer Konvertierungsmechanismus, dieser ist jedoch nicht sicher, so daß Laufzeitfehler auftreten können. Zuletzt soll noch ein kurzer Blick auf die Ablaufsteuerung geworfen werden. Die bedingte Verzweigung mit zwei Fällen (If-Then-Else), ist die einzige Ablaufstruktur, die in PARTS zur Verfügung steht. Realisiert wird die Verzweigung durch die Bausteine Comparison und Link Junction. Comparison bietet Nachrichten für relationale Vergleiche von zwei Argumenten an, z.b. is:avalue1 EqualTo:aValue2 für den Vergleich auf Gleichheit. Je nachdem, wie der Vergleich ausfällt, sendet der Baustein das Ereignis true oder false. Bild 6-23 zeigt ein Beispiel für eine Verzweigung mit dem Baustein Comparison. Der Baustein Link Junction verfügt über Nachrichten für Tests mit jeweils einem Argument, z.b. triggeriftrue:aboolean und triggerifnil:avalue. Je nachdem, wie der Test ausfällt, sendet der Baustein das Ereignis triggered: oder triggeredfailed:. Bild 6-24 zeigt ein Beispiel für eine Verzweigung mit dem Baustein Link Junction. Auf spezielle Konstrukte wie Variablen und geschachtelte Bausteine kann aus Platzgründen nicht eingegangen werden. Der interessierte Leser findet nähere Informationen dazu in PARTS [92]. Bild Ereignisverbindung in PARTS. Die Ereignisverbindung verknüpft die Schaltfläche PushButton1 (Beschriftung Open Window) mit dem Fenster Window1 (Beschriftung Untitled). Das Ereignis clicked wird ausgelöst, wenn der Benutzer die Schaltfläche drückt. In diesem Fall sendet die Ereignisverbindung die Nachricht open an das Fenster, worauf dieses am Bildschirm erscheint. Das Dialogfenster zeigt die möglichen Verbindungen zwischen den Ereignissen der Schaltfläche PushButton1 und den Nachrichten des Fensters Window1. Für das Erzeugen der Ereignisverbindung sind clicked und open ausgewählt.

176 Beispiele für visuelle Programmiersysteme 166 Bild Resultat- und Argumentverbindungen in PARTS; Farbbild im Anhang. Dieses PARTS-Programm berechnet nach Drücken der Schaltfläche Calculate den Wert des arithmetischen Ausdrucks (3 + 4) * 5 und weist das Ergebnis dem Ausgabefeld am unteren Bildrand zu. An der Berechnung sind folgende Elemente beteiligt: Die Ereignisverbindung clicked sendet die Nachricht + (plus) an das Objekt 3. Die Nachricht + erwartet ein Argument, das eine Argumentverbindung mit der Nachricht value vom Objekt 4 holt. Nach Berechnung von wird über eine Resultatverbindung die Nachricht * (mal) an das Objekt 5 gesendet. Das Argument der Nachricht * ist das Resultat von 3 + 4, das eine weitere Argumentverbindung holt. Nach der Berechnung von 5 * 7 sendet eine Resultatverbindung die Nachricht setvalue: an das Ausgabefeld. Das Argument der Nachricht setvalue: ist das Resultat von 5 * 7, das eine Argumentverbindung holt. Bild Verzweigung mit dem Baustein Comparison; Farbbild im Anhang. Dieses PARTS-Programm vergleicht nach Drücken der Schaltfläche Compare den Wert 3 mit dem Inhalt der Variablen ValueHolder1 und belegt je nachdem, wie der Vergleich ausfällt, das Ausgabefeld mit der Zeichenkette»3 > ValueHolder«oder»3 <= ValueHolder«. Visuelle Bausteine in diesem Programm sind die Schaltfläche und das Eingabefeld; diese Bausteine sind während der Programmausführung sichtbar. Nicht-visuelle Bausteine sind ValueHolder1, Comparison1, die Zahl 3 und die Zeichenketten; diese Bausteine sind während der Programmausführung nicht sichtbar.

177 6.5 PARTS: Visuelle Programmierung mit Objektdiagrammen 167 Bild Verzweigung mit dem Baustein Link Junction. Dieses PARTS-Programm überprüft nach Drücken der Schaltfläche Test if Nil, ob der Inhalt der Variablen ValueHolder1 gleich nil ist und belegt je nachdem, wie der Test ausfällt, das Ausgabefeld mit der Zeichenkette»ValueHolder is Nil«oder»ValueHolder is not Nil« Interaktion Der Programmierer bedient sich bei der Konstruktion von PARTS-Applikationen des Bausteinkatalog und der Arbeitsfläche. Bild 6-25 zeigt diese beiden Bereiche der Entwicklungsumgebung. Der Programmierer wählt einen Baustein im Bausteinkatalog und zieht ihn mit Drag-und-Drop in die Arbeitsfläche, wo er ihn entsprechend der Bausteinart positioniert. Sogenannte Panes, das sind Fenster, Menüs und bestimmte andere visuelle Elemente, können frei plaziert werden. Die restlichen visuellen Bausteine werden innerhalb von Panes angeordnet und nicht-visuelle Bausteine neben den Panes. Auf diese Weise entsteht ein Ensemble von ineinandergeschachtelten und nebeneinanderliegenden Bausteinen. Nachdem der Programmierer einen ersten Satz von Bausteinen auf der Arbeitsfläche abgelegt hat, verknüpft er diese mit Verbindungen. Er hat dabei die Möglichkeit, Verbindungen sowie deren Beschriftungen selektiv ein- und auszublenden, um den Überblick zu behalten. Unvollständige Verbindungen und unbelegte Argumente markiert das System durch besondere Farben. So weist etwa eine rote Ereignis- oder Resultatverbindung darauf hin, daß Nachrichtenargumente noch unbelegt sind. Die Farbe der Verbindung wechselt auf Grün, sobald alle Argumente versorgt sind. Wenn die Applikation einen Zustand erreicht hat, der ein ersten Testen sinnvoll erscheinen läßt, drückt der Programmierer die Schaltfläche Launch und startet damit die Applikation, ohne daß eine Übersetzung notwendig wäre. Falls gewünscht, protokolliert ein Debugging-Werkzeug, welche Verbindungen wann aktiviert werden, indem es entsprechende Einträge in einem Textfenster vornimmt. Der Programmierer kann Haltepunkte auf bestimmte Verbindungen setzen, Sender- und Empfängerbaustein feststellen, die Argumentwerte und Resultate von Nachrichten ermitteln usw. Der Debugger von PARTS bietet leider nicht jene Möglichkeiten, wie sie in einem VP-System vorstellbar und etwa in LabVIEW realisiert sind. Statt die Abfolge von Ereignissen und Nachrich-

178 Beispiele für visuelle Programmiersysteme 168 ten in einem Textfenster darzustellen, wäre eine direkte Visualisierung im Arbeitsbereich sinnvoll. Damit wäre raschere Fehleridentifizierung und -behebung möglich. Oft reichen die visuellen Konstrukte nicht aus, um die Funktionalität der Applikation zu definieren. Der Programmierer verwendet in diesen Fällen den Skript-Editor, um verbalen Programmcode (Skripts) mit PARTSTalk zu erstellen. Zur Fehlersuche in Skripts steht ein eigener Debugger zur Verfügung, der auf Ebene von Smalltalk-Anweisungen operiert, was vom Programmierer entsprechende Kenntnisse der Smalltalk-Umgebung verlangt. Falls die Applikation als wiederverwendbarer Baustein katalogisiert werden soll, sind die Schnittstelle zu definieren, eine Export-Import-Option zu wählen (siehe S. 164), die Applikation als Baustein abzulegen und in einer Testapplikation nochmals zu überprüfen. Für die Ausführung als eigenständige Anwendung kann das erstellte Programm im plattformspezifischen Binärformat (EXE-Format) abgespeichert werden.

179 6.5 PARTS: Visuelle Programmierung mit Objektdiagrammen 169 Bild Bausteinkatalog und Arbeitsfläche von PARTS; Farbbild im Anhang. Das Bild zeigt links den Bausteinkatalog und rechts die Arbeitsfläche. Im Bausteinkatalog sind einige Elemente zur Gestaltung der Benutzungsschnittstelle zu sehen, die der Programmierer mit Drag-und- Drop in der Arbeitsbereich ziehen und dort plazieren kann. Im Arbeitsbereich verknüpft der Programmierer die Bausteine zu einer Applikation, die er durch Drücken der Schaltfläche Launch jederzeit starten kann. Die anderen Schaltflächen der Werkzeugleiste dienen zum Bearbeiten von Verbindungen und zum Ausrichten und Löschen von Bausteinen. Der gesamte Bereich der Arbeitsfläche repräsentiert selbst einen Baustein, der als wiederverwendbarer Baustein abgelegt werden kann. Die dargestellte Applikation hat folgende Funktionalität: Wenn der Benutzer im Fenster Untitled die Schaltfläche Close drückt, wird das Ereignis clicked ausgelöst, DialogWindow1 mit der Nachricht opentitled: geöffnet und die Zeichenkette»Close Window?«im Fensterbalken angezeigt. Bestätigt der Benutzer mit OK, so führt das Ereignis confirmed dazu, daß das Fenster Untitled die Nachricht close empfängt und sich schließt.

180 7. Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Dieses Kapitel beschreibt Vista, ein experimentelles VP-System, das die Implementierung reaktiver und transformativer Systeme unterstützt. Das Programmiermodell von Vista beruht auf der objektorientierten Programmierung in Verbindung mit Signal- und Datenflußkonzepten; es ist also multiparadigmenorientiert. Die zentralen Einheiten des Programmiermodells sind gekapselte Softwarekomponenten, die Prozessoren genannt werden. Hauptmerkmale von Vista sind die Integration von OOP, Signalfluß und Datenfluß die Programmierung mit»lebendigen«softwarekomponenten die Verwendung von Prototypen und Klassen die Unterstützung paralleler Prozesse die Möglichkeit der Selbstmodifikation von Komponenten zur Laufzeit Vista ist mit VisualWorks/Smalltalk 2.0 [94] implementiert und auf allen von Visual- Works unterstützten Plattformen (Macintosh, Windows und Unix) lauffähig. Die mit Vista erzeugten Applikationen sind ebenfalls Smalltalk-Programme und entsprechen der Anwendungsarchitektur von VisualWorks. Bei der Softwareentwicklung mit Vista können sowohl grafische als auch textuelle Darstellungsformen verwendet werden. Es besteht uneingeschränkter Zugang zur Klassenbibliothek und zu den Entwicklungswerkzeugen von VisualWorks. Der Aufbau dieses Kapitels entspricht der Struktur der Systembeschreibungen aus Kapitel 6. Zunächst 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 einfache Applikation konstruiert. Voraussetzung für das Verständnis dieses Kapitels sind Kenntnisse von Terminologie und Konzepten der datenflußorientierten und objektorientierten Programmierung (siehe Abschnitte»Datenflußorientierte VP-Systeme«, S. 103, und»objektorientierte VP- Systeme«, S. 116). 7.1 Anwendungsbereich Vista ist ein Forschungsprototyp für die experimentelle Entwicklung von Programmsystemen auf Basis visueller Softwarekomponenten. Leitgedanke beim Entwurf von Vista war die Unterstützung einer komponentenbasierten und prototyping-orientierten Systemkonstruktion auf hohem Abstraktionsniveau. Die algorithmische Ebene wird durch die Einbindung von Smalltalk zwar integriert, aber nicht durchgängig unterstützt. Um Vista nutzen zu können, muß man objektorientierte Programmierung und den Umgang mit Klassenbibliotheken beherrschen. Benutzer mit wenig Programmiererfahrung scheiden daher als Anwender aus.

181 7.1 Anwendungsbereich 171 Vista ist für die Implementierung reaktiver (ereignisgesteuerter) und transformativer (datenumformender) Systeme gedacht. Reaktive und transformative Systeme unterscheiden sich grundsätzlich hinsichtlich ihrer dynamischen Eigenschaften. Während reaktive Systeme in ständiger Wechselwirkung mit ihrer Umgebung stehen und aufgrund zeitlicher Randbedingungen auf Ereignisse reagieren, sind transformative Systeme durch eine feste Beziehung von Eingabe und Ausgabe charakterisiert, die von der Einbettung in eine bestimmte Systemumgebung und von zeitlichen Aspekten unabhängig ist. Huizing [91 S. 9; OZ 45] schreibt dazu: Bei der Analyse von Computersystemen ist eine grundsätzliche Zweiteilung festzustellen. Diese Zweiteilung verläuft quer durch sequentielle und parallele Systeme, durch zentrale und verteilte Systeme. Es ist die Trennlinie zwischen transformativen und reaktiven Systemen [...] Transformative Systeme sind durch die Beschreibung der Beziehung zwischen Eingabe- und Ausgabewerten gut zu definieren. Sie lesen einen Eingabewert, erzeugen, eventuell nicht-deterministisch, einen Ausgabewert und terminieren dann. Sie haben eine lineare Struktur, und nur der Initial- und Endzustand sind von Interesse. Reaktive Systeme berechnen keine Funktion, sondern stehen in ununterbrochener Interaktion mit ihrer Umgebung. Während man transformative Systeme mit einer Black-Box vergleichen kann, sollte man reaktive Systeme mit einem Black-Cactus vergleichen (der Begriff stammt von Amir Pnueli), der mehrere Eingabe- und Ausgabekanäle besitzt. Vista ist nicht auf einen bestimmten Anwendungsbereich innerhalb dieser Systemtypen zugeschnitten. Die Unterstützung bei speziellen Problemstellungen ist dadurch erheblich geringer als bei maßgeschneiderten Ansätzen, etwa für reaktive Modelle in der Prozeßautomatisierung oder transformative Modelle in der Bildverarbeitung. Durch die Generalisierung erhöht sich jedoch die Flexibilität beim Systementwurf, was insbesondere durch die speziellen Kopplungsmechanismen für Subsysteme erreicht wird. Eine Integration reaktiver und transformativer Subsysteme ist mit diesen Mechanismen leicht möglich. Für den Einsatz in Praxisprojekten ist die derzeitige Version von Vista nur bedingt geeignet. Zum einen treffen auch auf Vista die grundsätzlichen Nachteile der visuellen Programmierung zu, zum anderen sind Benutzungsschnittstelle und Ausführungsgeschwindigkeit verbesserungsbedürftig und der Ressourcenbedarf zu hoch. Der experimentelle Einsatz von Vista kann dennoch aufschlußreiche Erkenntnisse über verschiedene Aspekte komponentenbasierter Softwareentwicklung vermitteln, etwa bezüglich der asynchronen Kommunikation zwischen Komponenten (siehe Abschnitt»Parallelität«, S. 214) oder hinsichtlich der Konsequenzen, die sich aus der selektiven Modifizierbarkeit von Eigenschaften einzelner Komponenten des gleichen Typs ergeben (siehe Abschnitt»Prototypen«, S. 224). Durch die Offenheit des Vista zugrundeliegenden Entwicklungssystems sind zudem interessante Einblicke in die Architektur und Implementierung eines VP-Systems möglich. Im folgenden werden die charakteristischen Eigenschaften reaktiver und transformativer Systeme knapp umrissen, und es wird dargestellt, in welchem Ausmaß Vista zur Implementierung solcher Systeme geeignet ist.

182 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Reaktive Systeme Reaktive Systeme reagieren permanent auf Ereignisse, die aus der Systemumgebung stammen (externe Ereignisse) oder die sie selbst erzeugen (interne Ereignisse). Durch Ereignisse werden Zustandsänderungen und Aktionen ausgelöst, die in weiterer Folge zu neuen Ereignissen führen. Beispiele für reaktive Systeme sind Telefonvermittlungsanlagen, Verkehrsleiteinrichtungen, Produktionssysteme und integrierte Schaltkreise, aber auch Bereiche der Informationstechnik, z.b. Betriebssysteme, Client-Server- Applikationen, Datenbanken und Anwendungen für die Büroautomatisierung. Harel et al. [90; OZ 46] beschreiben solche Systeme wie folgt: Gemeinsames Konzept [dieser Systeme] ist ein reaktives Verhalten, wodurch ein System durch die Spezifikation einer einfachen funktionalen Beziehung zwischen Ausgabe und Eingabe nicht adäquat beschreibbar ist, sondern es notwendig ist, Ausgabe und Eingabe über deren erlaubte Kombinationen im Zeitverlauf zueinander in Beziehung zu setzen. Solche Beschreibungen umfassen typischerweise komplexe Sequenzen von Ereignissen, Aktionen, Bedingungen und Informationsfluß, oft mit expliziten zeitlichen Rahmenbedingungen, die alle zusammengenommen das Gesamtverhalten des Systems bilden. Methoden und Werkzeuge für die Spezifikation, den Entwurf und die Implementierung von reaktiven Systemen wurden u.a. auf Basis der modulorientierten Programmierung (vgl. Harel et al. [90]) und auf Grundlage der objektorientierten Programmierung entwickelt (vgl. Shlaer und Mellor [92]). Diese Ansätze verfolgen im wesentlichen zwei Ziele: Auf der einen Seite soll das Instrumentarium für Spezifikation und Entwurf eine möglichst direkte Umsetzung der Problemstellung in Software ermöglichen; auf der anderen Seite sollen formal gesicherte Aussagen darüber möglich sein, ob die implementierte Software jene Eigenschaften aufweist, die in der Spezifikation gefordert sind bzw. die ein System generell aufweisen muß. Weil die Software reaktiver Systeme oft zur Maschinensteuerung verwendet wird, kommt Aussagen über ein garantiertes Systemverhalten große Bedeutung zu. Zu notwendigen Systemeigenschaften gehören beispielsweise Sicherheit (safety) und Produktivität (liveness). Ein sicheres System verursacht keine Schäden, und ein produktives System ist frei von Verklemmungen (dead locks) und Leerläufen (live locks). Lewerentz und Lindner [95-2 S. 21 ff] vergleichen 18 Ansätze zur Echtzeitsteuerung einer Roboterpresse, die auf formalen oder semiformalen Spezifikationsmethoden und Programmiersprachen beruhen. Darunter finden sich Sprachen und Methoden wie Esterel, Lustre, Signal, StateCharts, SDL, Spectrum und Modula-3. Lewerentz und Lindner vertreten die Meinung, daß die Anwendung formaler Modelle der einzig gangbare Weg ist, um ein hohes Maß an Systemsicherheit zu erreichen [S. 49]. Vista konkurriert nicht mit solchen umfassenden Ansätzen. Ein Instrumentarium für die Implementierung von Echtzeitsystemen wird nicht zur Verfügung gestellt und die Modellierung von Parallelität und Verteilung mit formalen Methoden ist nicht vorgesehen. Vista ist ein Werkzeug zur prototypischen Realisierung reaktiver Systeme, die aus Softwarekomponenten ohne Einbindung von Hardware bestehen und keinen hohen Anforderungen bezüglich der Laufzeitgeschwindigkeit unterliegen. Mit Vista ist es etwa möglich, einen Prototyp für die Steuerung einer Verkehrsampel zu entwickeln und dafür eine Simulationsumgebung zu bauen.

183 7.1 Anwendungsbereich Transformative Systeme Transformative Systeme beruhen auf dem Datenflußmodell (siehe Abschnitt»Datenflußorientierte VP-Systeme«, S. 103). Sie treten mit ihrer Umgebung nicht in Interaktion, sondern dienen der Umformung von Daten ohne Berücksichtigung von Ereignissen aus der Systemumgebung und zeitlichen Einflüssen. Vista erweitert das reine Datenflußmodell um explizite Synchronisation von Operationen sowie um Konstrukte zur Ablaufsteuerung. Spezielle Werkzeuge erlauben die Definition von hierarchischen Datentypen, wodurch die Implementierung polymorpher Operationen möglich ist. Statische Typisierung verhindert Laufzeitfehler aufgrund von Typverletzungen. Parallelität ist auf Ebene einzelner Operationen realisiert. Vista umfaßt damit alle wesentlichen Aspekte transformativer Systeme und ermöglicht durch das Konzept der hierarchischen Datentypen einen flexiblen Entwurf von Anwendungen auf Basis des Datenflußmodells. Vista eignet sich insbesondere auch für die Untersuchung softwaretechnischer Fragestellungen, die sich aus der im nächsten Abschnitt diskutierten Integration reaktiver und transformativer Systeme ergeben Integration reaktiver und transformativer Systeme In VP-Systemen, die entweder nur reaktive oder nur transformative Systeme gut unterstützen (z.b. BetterState für reaktive Systeme und LabVIEW für transformative Systeme), treten Modellierungsprobleme bei nicht artenreinen Systemen auf. Daraus resultieren meist umständliche Konstruktionen bei Entwurf und Implementierung von Anwendungen mit reaktiven und transformativen Anteilen. Dazu ein Beispiel: ein Verkehrsleitsystem könnte aus zwei Subsystemen bestehen einem reaktiven Ampelsteuerungssystem und einem transformativen Verkehrsanalysesystem. Die Ampelsteuerung reagiert auf Ereignisse, etwa das Drücken der Grüntaste durch Fußgänger, und berücksichtigt zeitliche Bedingungen, etwa die Dauer der Ampelphasen. Die Verkehrsanalyse liest kontinuierlich Verkehrsflußdaten, erstellt daraus Statistiken und ermöglicht Auswertungen. Die Ergebnisse der Verkehrsanalyse fließen wiederum in die Ampelsteuerung ein, wodurch beide Systeme in Wechselwirkung stehen. Wollte man das Ampelsteuerungssystem und das Verkehrsanalysesystem nach demselben Paradigma modellieren, hätte man für eines der Systeme keine adäquaten Ausdrucksmöglichkeiten zur Hand: Zustandsdiagramme, die für die Programmierung der Ampelsteuerung zweckmäßig sind, wären ungeeignet für die Beschreibung transformativer Filterprozesse, wie sie in der Verkehrsanalyse vorkommen, während mit Datenflußdiagrammen, die sich für die Programmierung der Verkehrsanalyse anbieten, das reaktive Verhalten der Ampelsteuerung nur schlecht erfaßbar ist. Eine solche Diskrepanz zwischen Problemstellung und Modellierungssprache kann als Paradigmenbruch oder semantische Lücke bezeichnet werden. Bei Vista wird ein Paradigmenbruch dadurch vermieden, daß die Basiseinheiten des Programmiermodells auf abstrakter Ebene eine einheitliche Struktur und einheitliche Mechanismen aufweisen. Für die besonderen Anforderungen des jeweiligen Systemtyps werden von den allgemeinen Komponenten spezielle Ausprägungen abgeleitet, die durch das gemeinsame Fundament leicht verständlich sind. Beispiel: Aus Prozessoren, den zentralen Verarbeitungseinheiten von Vista, werden Signalprozessoren bzw. Datenprozessoren abgeleitet, deren spezielle Eigenschaften (etwa hinsichtlich der Verarbeitung von Eingaben) auf reaktive bzw. transformative Systeme abgestimmt sind. Die

184 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 174 allgemeinen Eigenschaften eines Prozessors (etwa seine Parameterisierbarkeit) bleiben für diese speziellen Prozessortypen erhalten. In Vista sind reaktive Systeme den transformativen Systemen übergeordnet. Ein transformatives System kann in ein reaktives System eingebettet werden, aber nicht umgekehrt. Dieser Ansatz wurde deshalb gewählt, weil in den meisten Fällen die Sicht auf das Anwendungsgebiet vom Standpunkt der Systeminteraktion zu einem besseren Entwurf führt. Bei der Verwendung objektorientierter Analyse- und Entwurfstechniken ist der sich daraus ergebende Vorteil deutlich zu erkennen: Man kann Objekte als reaktive Minisysteme betrachten, die aufgrund von Ereignissen ihren Zustand ändern, diese Zustandsänderungen ihrer Umgebung bekanntgeben und bei Anfragen die gewünschten Daten mit transformativen Verfahren ermitteln. Dieses Denkmodell entspricht Problemkonstellationen aus den Anwendungsbereichen. Bewährte Entwurfsmuster, wie die MVC-Architektur oder der Change-Update-Mechanismus von Smalltalk (vgl. Goldberg und Robson [83]), korrespondieren mit diesem Ansatz. Wären transformative Systeme den reaktiven Systemen übergeordnet, stünden nicht Objekte im Vordergrund, sondern Funktionen. Dieser Weg wird etwa in Prograph verfolgt, wo Objekte passive Elemente sind, die von Funktion zu Funktion weitergereicht, abgefragt und modifiziert werden. Diese atypische Anwendung des objektorientierten Paradigmas führt jedoch zu einer komplexen Syntax und Semantik der Beschreibungsmittel (in Prograph gibt es fünf verschiedene Arten der Methodenaktivierung). 7.2 Konzeptionelle Grundlagen Die Konzepte von Vista sind auf die prototyping-orientierte Softwareentwicklung (Prototyping) abgestimmt, bei der man bereits in frühen Entwicklungsphasen die Kernteile des zu erstellenden Systems in Form eines ausführbaren Applikationsprototypen realisiert. Dadurch sollen Mängel der Spezifikation rechtzeitig erkannt und beseitigt werden (vgl. Bischofberger und Pomberger [92 S. 15 ff]). Die rasche und kostengünstige Entwicklung von Applikationsprototypen ist Voraussetzung für erfolgreiches Prototyping. Bei Vista wird dies durch einen komponentenbasierten Ansatz angestrebt, der die flexible Kombination von vorgefertigten Programmbausteinen unterstützt und es erlaubt, solche Bausteinkombinationen als wiederverwendbaren Komponenten abzulegen. Alle Komponenten sind»lebendig«in dem Sinne, daß sie bereits während der Programmkonstruktion uneingeschränkt funktionsfähig sind. Die Anpassung des zu entwickelnden Systems an die Bedürfnisse der Benutzer kann deshalb in einem iterativen Prozeß mit kurzen Redesign-Zyklen geschehen, wie das im prototyping-orientierten Vorgehensmodell vorgesehen ist. Im Rahmen dieses Abschnitts werden Prototyping und die komponentenbasierte Softwareentwicklung nicht im Detail vorgestellt, weil dies für das Verständnis der Konzepte von Vista nicht notwendig ist. Es werden lediglich die grundlegenden Begriffe und Ideen erläutert und die zentralen Komponenten des Programmiermodells im Überblick beschrieben.

185 7.2 Konzeptionelle Grundlagen Komponentenbasierte Softwareentwicklung Große Softwaresysteme bestehen aus einer Vielzahl von meist komplexen Teilsystemen, die auf vielfältige Weise gekoppelt sind und miteinander in komplexen Kommunikationsbeziehungen stehen. Mey [94 S. 41 ff] nennt als fünf wesentliche Problemkreise bei der Entwicklung großer Softwaresysteme folgende Punkte: 1. Große Softwaresysteme sind schwierig zu entwickeln. Mehrdeutige, unvollständige und veränderbare Spezifikationen, komplexe funktionale und datenbezogene Zusammenhänge, enge zeitliche und organisatorische Rahmenbedingungen, hohe personelle Anforderungen und andere Faktoren erschweren die Entwicklung großer Softwaresysteme. 2. Große Softwaresysteme repräsentieren sich sowohl flexibel als auch inflexibel. Der Softwareentwickler ist frei in der Gestaltung weiter Bereiche des Softwaresystems, während der Anwender meist mit starrer Funktionalität konfrontiert ist. Mit anderen Worten: der großen Flexibilität des Programmierers bei der Systementwicklung steht eine hohe Inflexibilität des Benutzer beim Systemeinsatz gegenüber, die dieser mangels technischer und konzeptioneller Mängel nicht durchbrechen kann. 3. Große Softwaresysteme sind schwierig zu testen und von Fehlern zu befreien. Kein großes Softwaresystem ist garantiert fehlerfrei. Formale Programmverifikation scheitert wegen der Komplexität großer Systeme. Die Korrektur eines Fehlers bewirkt nicht selten neue Fehler, so daß davon ausgegangen werden kann, daß ab einem gewissen Punkt die Anzahl von Fehlern im Programm konstant bleibt. 4. Große Softwaresysteme bringen hohe Entwicklungsrisiken mit sich. Die hohen materiellen und personellen Aufwände für die Entwicklung großer Softwaresysteme amortisieren sich nur dann, wenn das Produkt den Erwartungen der Benutzer entspricht und gekauft wird. Die Erfahrungen zeigen, daß eine erhebliche Anzahl von Softwareprojekten scheitern und die damit verbunden Investitionen zumindest teilweise verloren sind. 5. Große Softwaresysteme sind schwierig zu verstehen. Schwer abgrenzbare, systeminterne Verflechtungen, komplexe Beziehungen des Systems mit seiner Umgebung und die schiere Menge von Code und Funktionalität überfordern oft sowohl Programmierer als auch Benutzer bei ihrem Bemühen, große Softwaresysteme zu überblicken und zu verstehen. Diese und andere Probleme, haben zur Entwicklung einer Vielzahl von Methoden, Techniken und Werkzeugen geführt, mit denen die Konstruktion großer Softwaresysteme erleichtert werden soll. Mey [S. 13] schlägt wie andere Autoren auch (vgl. Udell [94]), die komponentenbasierte Softwareentwicklung als adäquates Mittel zur Komplexitätsbewältigung, Rationalisierung und Risikominimierung in der Softwarekonstruktion vor. Erste Ansätze dazu wurden bereits Mitte der 80er Jahre von Ledbetter und Cox [85] verfolgt. Sie regten den Bau von Software-ICs an, die ähnlich wie Hardware-Chips (integrated circuits) einsetzbar sein sollten. Solche Software-ICs sollten sich durch eine hohe Standardisierung und damit einen hohen Grad an geprüfter Funktionalität und Wiederverwendbarkeit auszeichnen. Ledbetter und Cox sahen OOP als das geeignetste Mittel für die Konstruktion von Software-ICs. Heute spricht man nicht von Software-ICs, sondern von Softwarekomponenten.

186 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 176 Eine allgemein anerkannte Definition für den Begriff»Softwarekomponente«gibt es noch nicht. Oft versteht man darunter geprüfte und dokumentierte Programmbausteine, deren Funktionalität weitgehend unabhängig von spezifischen Anwendungen ist und die deshalb einen hohen Grad an Wiederverwendbarkeit aufweisen. Eine auf breiter Basis akzeptierte Standardisierung kann ebenfalls als Voraussetzung betrachtet werden, um Programmbausteine als Softwarekomponenten bezeichnen zu können. Sametinger [97] setzt sich umfassend mit Begriffen und Konzepten der komponentenbasierten Softwareentwicklung auseinander und definiert»wiederverwendbare Softwarekomponente«wie folgt [S. 68; OZ 47]: Wiederverwendbare Softwarekomponenten sind in sich geschlossene, klar identifizierbare Teile, die bestimmte Funktionen beschreiben und/oder ausführen und klare Schnittstellen, eine zweckmäßige Dokumentation und einen definierten Zustand hinsichtlich ihrer Wiederverwendbarkeit aufweisen. Mit»in sich geschlossen«meint Sametinger, daß Softwarekomponenten verwendbar sein müssen, ohne dafür weitere Komponenten zu benötigen; unter»definierter Zustand hinsichtlich der Wiederverwendbarkeit«ist zu verstehen, daß Informationen darüber zur Verfügung stehen, wer der Eigentümer der Komponente ist, wer sie wartet, wer bei Problemen zuständig ist und in welchem Qualitätszustand sich die Komponente befindet. Softwarekomponenten existieren grundsätzlich in zwei Ausprägungen: Als nicht ausführbare Schablonen (z.b. in Form von Klassen), die in Komponentenbibliotheken organisiert sind und zur Erzeugung von Exemplaren dienen. Als ausführbare Exemplare (z.b. in Form von Objekten), die Teil von Applikationen sind. Die aus Schablonen erzeugten Exemplare werden bei der Konstruktion einer Applikation entsprechend den Erfordernissen konfiguriert, eventuell in Teilbereichen adaptiert und schließlich mit geeigneten Werkzeugen zusammengefügt. Das Zusammenfügen von Softwarekomponenten kann auf textuelle Weise mit Skriptsprachen erfolgen oder in einer visuellen Programmierumgebung durch direkte Manipulation von grafischen Darstellungen der Komponenten. OOP ist keine Voraussetzung für die Konstruktion und Verwendung von Softwarekomponenten. Auch modulorientierte Ansätze eignen sich gut dafür, wie die weite Verbreitung der Visual Basic Custom Controls (VBXs) zeigt. Ein VBX ist eine gekapselte, parameterisierbare Softwarekomponente mit einer standardisierten Schnittstelle und einer grafischen Benutzungsschnittstelle. Vererbung und Polymorphismus werden nicht unterstützt. VBX sind vor allem für die Implementierung maßgeschneiderter Anwendungen mit kleiner bis mittlerer Komplexität sehr beliebt. Eine Reihe von Firmen hat sich auf die Konstruktion von VBXs für verschiedene Anwendungsgebiete spezialisiert und verkauft diese mit Erfolg. Im Bereich der professionellen Softwareentwicklung unternehmen die großen Hard- und Softwareproduzenten beträchtliche Anstrengungen, komponentenbasierten Technologien durch Industriestandards eine breitere Akzeptanz zu verschaffen. Beispiele sind Standards wie COM (Common Object Model), DSOM (Distributed System Object Model) und CORBA (Common Object Request Broker Architecture). An den Erfolg von VBX könnten Softwarekomponenten anknüpfen, die mit der objektorientierten Programmiersprache Java erstellt sind. Java-Komponenten sind zur Lauf-

187 7.2 Konzeptionelle Grundlagen 177 zeit eines Programms dynamisch über Internetprotokolle ladbar. Sie können auf vielen Hard- und Softwareplattformen ohne Übersetzung ausgeführt werden (Java-Code ist für eine virtuelle Maschine definiert, die plattformunabhängig spezifiziert ist). Die Einhaltung von Kompatibilitätsrichtlinien vorausgesetzt, können Applikationen mit vergleichsweise wenig Aufwand erstellt werden. Java-Applikationen bestehen aus drei Komponententypen: aus Basiskomponenten der Java-Laufzeitumgebung, aus Spezialkomponenten, die via Internet von Softwareherstellern bezogen werden und aus selbstentwickelten Komponenten, die auf lokale Anforderungen zugeschnitten sind. Die mit dieser Kombinationsmöglichkeit verbundenen Produktivitätsgewinne bieten zusammen mit anderen Eigenschaften von Java einen hohen Anreiz, wiederverwendbare Softwarekomponenten mit dieser Programmiersprache zu entwickeln. Bei der komponentenbasierten Softwareentwicklung wird davon ausgegangen, daß die Konstruktion und die Verwendung von Softwarekomponenten unterschiedliche Aktivitäten sind, die divergenten Anforderungen unterliegen und meist verschiedene Personengruppen betreffen. Gebaut werden Softwarekomponenten von Software-Ingenieuren zusammen mit Experten eines Anwendungsgebiets. Aufgabe der Komponentenentwickler ist es, die allgemein gültigen Fachkonzepte des Anwendungsgebietes zu erkennen und in Softwarebausteine umzusetzen. Der Entwurf und die Realisierung wird meist als Component Engineering bezeichnet. Genutzt werden Softwarekomponenten von Anwendungsentwicklern. Ihre Aufgabe ist es, aus den für den Anwendungsbereich zur Verfügung stehenden Bausteinkatalog jene Komponenten auszuwählen, die sich für die zu erstellende Software am besten eignen, und daraus eine funktionsfähige Applikation zu erstellen. Diese Tätigkeit nennt man Application Engineering. Damit die Bausteinauswahl und Bausteinkombination problemlos möglich sind, sollten Softwarekomponenten»steckkompatibel«sein. Steckkompatibel heißt, daß Schnittstellen und Protokolle standardisiert sind und alle Komponenten den definierten Standards entsprechen. Damit soll es möglich sein, Komponenten höherer Funktionalität durch Zusammenstecken von Komponenten einfacherer Funktionalität zu erzeugen. Auch wenn die Idee des Zusammensteckens verlockend klingt, so ist doch zu bedenken, daß komplexe Softwaresysteme kaum durch bloßes Assemblieren produzierbar sind. Vereinfachende Darstellungen, wie jene aus Bild 7-1, verleiten zur Annahme, daß komponentenbasierte Programmierung trivial sein kann, wenn die richtigen Techniken und Werkzeuge zur Verfügung stehen. In diesem Zusammenhang wird die visuelle Programmierung vielfach als besonders gut geeignetes Instrument betrachtet. Tatsächlich ist das bloße Zusammenfügen von Softwarekomponenten jedoch nur für solche Softwaresysteme praktikabel, die eine statische Struktur aufweisen und fest vorgegebene Operationen unterstützen. In den meisten Fällen sind diese Bedingungen vor allem aus zwei Gründen nicht gegeben: (1) Zum einen sind kontinuierliche, strukturelle Veränderungen ein wesentliches Merkmal von Software: Objekte werden zur Laufzeit erzeugt, mit anderen Objekten in Beziehung gesetzt und schließlich wieder zerstört. Softwaresysteme unterscheiden sich in dieser Hinsicht grundsätzlich von Hardwaresystemen, deren Aufbau während des Betriebs unverändert bleibt. Die Softwaretechnik kann deshalb manche Konstruktionsprinzipien der Hardwaretechnik, etwa die Verwendung von Steckverbindungen als Koppelelemente, nicht eins-zu-eins übernehmen. (2) Zur Festlegung des Systemverhaltens werden meist komponentenübergreifende Steuerkonstrukte benötigt, die auf die jeweilige Anwendung abzustimmen sind. Dazu muß man applikationsspezifischen Programmcode schreiben. Auch Frameworks und Entwurfsmuster erleichtern nur solche Anpassungen, machen sie aber nicht überflüssig.

188 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 178 Texteditor -System Bild 7-1. Vereinfachende Darstellung der komponentenbasierten Softwareentwicklung. Diese Abbildung soll suggerieren, daß es prinzipiell genügt, eine»steckverbindung«zwischen einer Komponente für die Manipulation von Texten und einer Komponente für das Versenden und Empfangen von herzustellen, um eine funktionsfähige -Applikation zu erhalten. Tatsächlich sind die Interaktionen zwischen Softwarekomponenten meist zu kompliziert, um mit einfachen Steckverbindungen realisiert zu werden. Mey [94 S. 47 f] nennt eine Reihe von Anforderungen an eine Umgebung zur komponentenbasierten Softwareentwicklung, mit denen die eingangs erwähnten Problemkreise angesprochen werden. Verdichtet dargestellt lauten die Anforderungen wie folgt: Die Umgebung muß Konzepte zur Definition von Komponenten, Verbundkomponenten und Komponentenschnittstellen zur Verfügung stellen. Die Umgebung muß einen Mechanismus für die Speicherung, Organisation und Beschaffung von Komponenten anbieten und unterschiedliche Repräsentationen von Komponenten unterstützen. Die Umgebung muß direkte Manipulation und eine prototyping-orientierte Vorgehensweise unterstützen. Komponenten müssen zugleich offen und geschlossen, wiederverwendbar und ersetzbar sein. Die Regeln und Mechanismen für das Zusammenfügen von Komponenten sollen flexibel sein. Vista erfüllt diese Anforderungen, indem es Konzepte der komponentenbasierte Softwareentwicklung mit bewährten Konstruktionsprinzipien der objektorientierten Softwaretechnik verbindet. In Hinblick auf die zuvor angesprochenen Steckverbindungen heißt das beispielsweise, daß Vista nicht nur adäquate Mechanismen zur Spezialisierung und Konfiguration von Komponenten zur Verfügung stellt, sondern daß diese Mechanismen auch die Konzepte der objektorientierten Programmierung für Abstraktion und Polymorphismus unterstützen Grundstruktur von Vista-Applikationen Bei der Realisierung von Vista wurde größter Wert auf die nachhaltige Nutzung der Infrastruktur von VisualWorks gelegt. Architektur, Design und Implementierung sind auf Struktur, Klassenbibliothek und Entwicklungswerkzeuge dieser Programmierumgebung abgestimmt. Weil Vista der geschichteten Architektur von VisualWorks folgt, können für die Konstruktion von Vista-Applikationen alle Werkzeuge und Klassen von VisualWorks verwendet werden.

189 7.2 Konzeptionelle Grundlagen 179 Vista-Applikationen bestehen aus drei Ebenen: Der Benutzungsschnittstelle (user interface), die aus üblichen Elementen wie Fenstern, Schaltflächen, Listen und Eingabefeldern besteht. Dem Applikationsmodell (application model), das die Wirkung der Benutzereingaben und der Programmlogik koordiniert und die Benutzungsschnittstelle an das Domänenmodell anbindet. Dem Domänenmodell (domain model), das die eigentliche Struktur und das Verhalten der Applikation festlegt und somit die Programmlogik ausmacht. Durch diese Schichtung wird eine klare Trennung der verschiedenen Funktionsbereiche einer Applikation erreicht. Als Konsequenz daraus kann die Implementierung jeder Schicht durch eine andere Implementierung ersetzt oder in einem anderen Kontext wiederverwendet werden, ohne daß ein Umbau des Gesamtsystems notwendig wäre. So ist etwa das Domänenmodell unabhängig von der Datenrepräsentation an der Benutzungsschnittstelle, wodurch die Repräsentation ausgetauscht werden kann, ohne die Programmlogik zu ändern. Umgekehrt können auch Teile der Benutzungsschnittstelle für ein anderes Domänenmodell verwendet werden. Bild 7-2 zeigt die Schichtenstruktur einer VisualWorks-Applikation anhand eines einfachen Beispiels. Die Benutzungsschnittstelle und das Applikationsmodell einer Vista-Applikation werden als Laufzeitumgebung bezeichnet. Die Laufzeitumgebung wird mit Werkzeugen von VisualWorks erstellt. Das Domänenmodell besteht aus einem System von Prozessoren und wird primär mit Werkzeugen von Vista konstruiert Prozessoren Prozessoren sind die zentralen Elemente von Vista-Applikationen. Sie sind gekapselte Funktionsbausteine oder Objektspeicher. Als Funktionsbausteine verarbeiten sie Signale oder Daten; als Objektspeicher halten sie beliebige Smalltalk-Objekte und geben Veränderungen an diesen Objekten durch Signale bekannt. Prozessoren werden anhand von fünf Kriterien klassifiziert: 1. Anbindung an die Laufzeitumgebung: X-Prozessoren (externe Prozessoren) sind Bindeglieder zwischen Laufzeitumgebung und Domänenmodell, I-Prozessoren (interne Prozessoren) sind Teile des Domänenmodells. 2. Konstruktionsweise: Einfachprozessoren sind mit Smalltalk programmierte atomare Komponenten, Verbundprozessoren sind mit Vista konstruierte komplexe Komponenten. 3. Einsatzbereich: Signalprozessoren sind Komponenten für reaktive Systeme, Datenprozessoren sind Komponenten für transformative Systeme. 4. Kommunikationstyp: Aktive Prozessoren sind Prozeßquellen und kommunizieren asynchron, passive Prozessoren sind Durchgangs- bzw. Endstationen für Prozesse und kommunizieren synchron. 5. Sichtbarkeit: Öffentliche Prozessoren sind Teil der Schnittstelle anderer Prozessoren, private Prozessoren sind nach außen unsichtbare Bestandteile von Prozessoren. Jeder Prozessor hat genau eine Merkmalsausprägung in jeder Kategorie. Bei der Erstellung eines Prozessors sind Konstruktionsweise, Einsatzbereich und Kommunikationstyp festzulegen. Eine spätere Anbindung an die Laufzeitumgebung oder der Einsatz als öf-

190 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 180 fentlicher oder privater Prozessor sind nicht zu berücksichtigen, da dafür jeder Prozessor geeignet ist. Benutzungsschnittstelle #Red color Applikationsmodell chooserandomcolor i i := (Random new next * 3 + 1) truncated. self color value:(#(red Green Blue) at: i) Domänenmodell Bild 7-2. Schichtenstruktur einer VisualWorks-Applikation. Das Bild zeigt den Aufbau einer einfachen VisualWorks-Applikation zur Auswahl einer Farbe aus den drei Möglichkeiten Rot, Grün und Blau. Die Pfeile stellen Wechselwirkungen zwischen den einzelnen Elementen dar. Die Benutzungsschnittstelle besteht aus einem Fenster mit drei Auswahlfeldern (oben), einem Auswahlmenü, einem Eingabefeld, einem Farbbalken und einer Schaltfläche für die zufällige Auswahl einer Farbe. Der Benutzer kann sich jeder Eingabemöglichkeit bedienen. Die anderen Elemente werden automatisch der gewählten Farbe angepaßt. Wenn der Benutzer z.b. aus dem Menü Red wählt, wird automatisch das Auswahlfeld Red aktiviert, das Eingabefeld zeigt die Zeichenkette #Red, und der Farbbalken wird rot dargestellt. Für die Koordination der Benutzungsschnittstelle ist das Applikationsmodell zuständig. Es definiert einen Objektspeicher color, der die aktuelle Farbe als Zeichenkette (Smalltalk-Symbol) enthält. Aktionen an der Benutzungsschnittstelle ändern den Inhalt dieses Objektspeichers. Ein automatischer Mechanismus reagiert auf Änderungen von color und aktualisiert alle betroffenen Elemente. Der Programmierer muß sich darum nicht kümmern. Das Domänenmodell enthält die Funktion chooserandomcolor, die vom Applikationsmodell beim Drücken der Schaltfläche Random aktiviert wird. In dieser Funktion wird ein zufälliger Zahlenwert i zwischen 1 und 3 generiert und als Index zum Zugriff auf ein Feld mit den Zeichenketten Red, Green und Blue verwendet. Die selektierte Zeichenkette wird im Objektspeicher color des Applikationsmodells abgelegt, wodurch wiederum die automatische Aktualisierung der Benutzungsschnittstelle veranlaßt wird. In Vista bilden nicht Funktionen oder Smalltalk-Objekte das Domänenmodell, sondern Prozessoren.

191 7.2 Konzeptionelle Grundlagen 181 Unabhängig von den einzelnen Merkmalsausprägungen stellt Vista einheitliche Repräsentationen und Interaktionsmechanismen für die Verwendung von Prozessoren zur Verfügung. Ein Programmierer muß z.b. nicht unterscheiden, ob er einen Einfach- oder einen Verbundprozessor zur Konstruktion eines anderen Prozessors einsetzt. Bild 7-3 verdeutlicht diese Einheitlichkeit: es zeigt die gleichartigen Repräsentationen der Schnittstelle eines Einfachprozessors und eines Verbundprozessors. Bild 7-3. Schnittstellen eines Einfachprozessors (links) und Verbundprozessors (rechts). Vista repräsentiert Einfach- und Verbundprozessoren auf die gleiche Weise. Die Darstellungen zeigen am oberen Rand die Eingangsports zum Tokenempfang und am unteren Rand die Ausgangsports zum Tokenversand. Der obere Balken enthält den Prozessornamen, das Symbol für die Aktivierung eines Menüs zur Auswahl diverser Operationen und das Symbol für den Wechsel in eine erweiterten Darstellung der Schnittstelle (siehe Bild 7-10, S. 194). Das Piktogramm dient zur raschen Wiedererkennung des Prozessors. Der Einfachprozessor Timer arbeitet als Zeitgeber. Das Symbol zeigt an, daß Timer ein aktiver Prozessor ist (siehe Abschnitt»Signalprozessoren«, S. 191). Der Eingangsport countdown ist mit dem Wert 7 parameterisiert, was bedeutet, daß sieben Sekunden nach Eintreffen eines Signaltoken an countdown der Ausgangsport expired ein Signal versendet. Der Verbundprozessor PLP (pedestrianlightsprocessor) steuert eine Fußgängerampel. Im Bild ist nicht zu erkennen, daß Timer ein Einfachprozessor und PLP ein Verbundprozessor ist. Das ist so gewollt, denn die Frage, ob ein Prozessor textuell mit Smalltalk (als Einfachprozessor) oder visuell mit Vista (als Verbundprozessor) konstruiert wurde, spielt bei der Darstellung des Prozessors keine Rolle. Kapselung In einem modularen System kann Kommunikation nur über die Schnittstellen der Systemkomponenten stattfinden. Für die Benutzung einer Komponente muß in einem modularen System deshalb lediglich die Spezifikation der Komponentenschnittstelle bekannt sein. Die Implementierung spielt keine Rolle und braucht zum Zeitpunkt der Systemkonstruktion nicht zur Verfügung zu stehen; es genügt, wenn die Implementierung zur Laufzeit des Systems verfügbar ist. Dieses fundamentale Prinzip der Softwaretechnik nennt man Verbergen von Details (Information Hiding). Die Kapselung von Prozessoren ist durch ein von außen sichtbares Interface und ein verborgenes Interior realisiert. Das Interface ist unabhängig vom Prozessortyp gleichartig aufgebaut und unterscheidet sich nur bezüglich der konkreten Funktionalität. Das Interior besteht entweder als Smalltalk-Code oder aus visuell zusammengesetzten Komponenten. Vista trennt Interface und Interior eines Prozessors nicht nur konzeptionell, sondern auch auf der visuellen Ebene. Ein Prozessor kann verwendet werden, sobald sein Inter-

192 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 182 face definiert ist: Der Programmierer sieht eine visuelle Repräsentation der Schnittstelle, kann den Prozessor auf der Programmierfläche plazieren und mit anderen Prozessoren verbinden. Er kann sogar Tokens an den Prozessor senden, obwohl diese selbstverständlich keine Operationen auslösen, solange das Interior nicht implementiert ist. Die Implementierung der Prozessorfunktionalität kann Schritt für Schritt, nach der Vorgangsweise des evolutionären Prototypings erfolgen (vgl. Bischofberger und Pomberger [92 S. 17 f]). Klassen, Prototypen und Vererbung Die Struktur von Prozessoren beruht auf einem objektorientierten Ansatz, der klassenbasierte und prototypbasierte Programmierung vereint. Einerseits sind Prozessoren typische Smalltalk-Objekte, deren Struktur und Verhalten durch Klassen definiert wird. Änderungen einer Klasse wirken sich auf alle Prozessoren aus, die dieser Klasse angehören. Andererseits sind Prozessoren auch Prototypen, deren Struktur und Verhalten modifizierbar sind, ohne daß dies Auswirkungen auf andere Prozessoren derselben Klasse hat. Der Abschnitt»Prototypen«, S. 224, erklärt diesen hybriden Ansatz im Detail. Prozessoren sind in Hierarchien organisiert, die eine Vererbungsbeziehung ausdrücken. Ein Prozessor kann als Basis zur Ableitung (Subklassenbildung) eines spezialisierten Prozessors verwendet werden. Bei der Ableitung werden die Eigenschaften des Basisprozessors an den spezialisierten Prozessor vererbt und im Kontext des erbenden Prozessors selektiv modifiziert oder erweitert. Dadurch entsteht eine neue Klasse bzw. ein neuer Prototyp. Der Abschnitt»Vererbung«, S. 231, enthält dazu nähere Erläuterungen Kommunikation zwischen Prozessoren Die Kommunikation zwischen Prozessoren geschieht auf zwei Arten: durch Weiterleiten von Tokens und durch Senden von Nachrichten. Zum Empfangen von Tokens verfügen Prozessoren über Eingangsports, zum Senden von Tokens über Ausgangsports. Verbindungen zwischen Ausgangs- und Eingangsports nennt man Känale (siehe Bild 7-4). Wenn ein Token an einem Eingangsport eintrifft, so löst es eine diesem Port zugeordnete Operation aus. Die Kommunikation zwischen Prozessoren beruht auf loser Kopplung. Unter Kopplung von Softwarekomponenten versteht man in modularen Systemen jene Abhängigkeiten zwischen Komponenten, die aufgrund von Kommunikationsbeziehungen bestehen. Datenkopplungen kˆnnen in modularen Systemen nicht auftreten, weil die Daten gekapselt sind und darauf nur über die Kommunikationsschnittstelle zugegriffen werden kann. Bertrand Meyer [90 S. 20] definiert lose Kopplung wie folgt: Wenn zwei Moduln überhaupt miteinander kommunizieren, sollten sie so wenig Information wie möglich austauschen. Er begründet dieses Prinzip durch die für modulare Systeme zu fordernden Eigenschaften»Stetigkeit«und»Geschütztheit«. Diese Eigenschaften sollen gewährleisten, daß eine kleine Änderung an der Schnittstelle eines Moduls nur kleine Änderungen in anderen Teilen des Systems nach sich zieht und somit die Wirkung einer Systemmodifikation lokal begrenzt ist. Zudem sichert lose Kopplung auch die Kombinierbarkeit von Softwarekomponenten: ein schmaler Kommunikationskanal erhöht die Wahrscheinlich-

193 7.2 Konzeptionelle Grundlagen 183 keit, zusammenpassende Komponenten zu finden, aus denen man neue Komponenten bauen kann, wodurch lose gekoppelte Komponenten für unterschiedliche Anwendungen flexibel einsetzbar sind. Ein gutes Beispiel dafür sind Unix-Kommandos. Viele Unix- Kommandos verarbeiten einen einfachen Strom von Bytes: sie lesen Bytes von einem Standard-Eingabekanal, verarbeiten die gelesenen Bytes und schreiben sie auf einen Standard-Ausgabekanal. Ein- und Ausgabekanal bilden eine schmale, wohldefinierte Schnittstelle, die lediglich sequentielle Dateioperationen zum Lesen und Schreiben von 8-Bit-ASCII-Zeichen zuläßt. Aus Unix-Kommandos, die dieser Schnittstelle folgen, kann man Kommandos mit höherer Funktionalität durch einfaches Zusammenfügen erzeugen und zudem eine Vielzahl von Ein- und Ausgabeeinheiten (z.b. Festplatte, Magnetbandgerät, Bildschirm und Drucker) gleichartig ansprechen. Das Beispiel der Unix-Kommandos zeigt, daß nicht nur minimaler Informationsaustausch zwischen Softwarekomponenten ein wesentliches Merkmal loser Kopplung ist, sondern daß bei der Konstruktion einer Softwarekomponente auch keine einschränkenden Annahmen über später anzuschließende Komponenten getroffen werden sollen. Für Vista gelten aufgrund dieser Überlegung folgende Prinzipien, um lose Kopplung zu erreichen: 1. Ein Prozessor, der Signale oder Daten versendet, sollte diese nicht an bestimmte Prozessoren übermitteln, sondern an den Ausgangsports bereitstellen. 2. Ein Prozessor, der Signale oder Daten erwartet, sollte diese nicht von bestimmten Prozessoren abholen, sondern an den Eingangsports entgegennehmen. Der Austausch von Informationen wird hier nicht mehr angesprochen. In Vista verlaufen Kanäle zum Transport von Tokens in nur eine Richtung vom Sender zum Empfänger. Welche Prozessoren miteinander kommunizieren legt nicht der Erbauer von Prozessoren fest, sondern der Benutzer. Für bestimmte Problemstellungen ist durch lose Kopplung auch für solche Prozessoren ein hoher Grad von Kombinierbarkeit zu erwarten, deren Zusammenschluß ursprünglich nicht vorgesehen war. Bild 7-4. Verbindung von zwei Prozessoren mit einem Kanal. Links ein Signalprozessor zur Steuerung einer Fußgängerampel, rechts ein Signalprozessor zur Steuerung einer Verkehrsampel. Ein Kanal verbindet Ausgangsport muststay von pedestrianlightsprocessor mit Eingangsport go von trafficlightsprocessor. Auf dem Kanal ist als Kreis ein Signaltoken sichtbar. Wenn dieses Token bei go eintrifft, schaltet trafficlightsprocessor die Verkehrsampel auf Grün.

194 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Operationen von Prozessoren Bei Einfachprozessoren sind Operationen durch textuellen Smalltalk-Code definiert, bei Verbundprozessoren werden dafür Netzwerke verwendet (siehe Bild 7-5 und Abschnitt»Netzwerke«, S. 203). Operationen werden im allgemeinen durch Tokens ausgelöst. Ein Prozessor empfängt Tokens an Eingangsports, führt die daran gebundenen Operationen durch und leitet die empfangenen oder selbst erzeugten Tokens über Ausgangsports und Kanäle an die Eingangsports anderer Prozessoren weiter. Operationen, die von Tokens ausgelöst werden, informieren den Sender des auslösenden Tokens nicht über das Ergebnis der Operation, es sei denn, der Programmierer sieht eine Rückkopplung vom Empfänger zum Sender über einen zusätzlichen Kanal vor. Operationen können auch von Nachrichten ausgelöst werden. Ein Prozessor, der eine Nachricht empfängt, bildet diese auf eine Methode ab, führt den dazugehörenden Code aus und gibt an den Sender ein Ergebnisobjekt zurück. Anders als bei der Aktivierung von Operationen durch Tokens, wird durch das Senden von Nachrichten keine Tokenemission ausgelöst, außer die Nachricht initiiert Zustandsänderungen, die anderen Prozessoren mitgeteilt werden sollen. Die Aktivierung von Operationen mit Nachrichten eignet sich insbesondere zur Abfrage des Zustands eines Prozessors sowie für numerische und algorithmische Berechnungen. Bild 7-5. Netzwerk aus Prozessoren. Das Netzwerk steuert die Rotphase von pedestrianlightsprocessor aus Bild 7-4. Es empfängt ein Token am Eingangsport stay und führt daraufhin folgende Operationen hintereinander aus: (1) Rücksetzen des Zeitgebers timerpedwalk, (2) Ausschalten der grünen Lampe greenbulb, (3) Einschalten der roten Lampe redbulb und danach Versenden eines Tokens am Ausgangsports muststay. Die Zahlen repräsentieren Kanalprioritäten.

195 7.3 Das Programmiermodell Das Programmiermodell Die folgenden Abschnitte erläutern die Elemente des Programmiermodells hinsichtlich ihrer grundlegenden statischen und dynamischen Eigenschaften. Besprochen werden Tokens, Kanäle, Prozessoren, Ports, Netzwerke und Stellvertreter Tokens Tokens sind Trägermedien für Signale (Signaltoken) oder Daten (Datentoken). Ein Signaltoken zeigt ein Ereignis in einem reaktiven System an, ein Datentoken repräsentiert einen elementaren oder strukturierten Datenwert in einem transformativen System. Tokens werden von Prozessoren oder von der Laufzeitumgebung generiert. Prozessoren erzeugen Tokens aufgrund von empfangenen Tokens, Nachrichten und Zustandsänderungen. Die Laufzeitumgebung erzeugt Tokens aufgrund von Benutzerinteraktion, Betriebssystemaktivitäten und anderen Ereignissen. Tokens aus der Laufzeitumgebung sind immer Signaltokens und werden an die Eingangsports von X-Prozessoren weitergeleitet. Von dort fließen sie in das Domänenmodell, wo Smalltalk-Code oder Netzwerke aus I-Prozessoren die eigentliche Tokenverarbeitung durchführen (zu X- und I-Prozessoren siehe Abschnitt 7.2.3, S. 181). Umgekehrt werden Tokens über die Ausgangsports von X-Prozessoren an die Laufzeitumgebung zurückgeliefert, um an der Benutzungsschnittstelle oder anderweitig wirksam zu werden. Bild 7-6 zeigt diesen Tokenfluß zwischen Vista und der Benutzungsschnittstelle. Tokens werden auf Kanälen transportiert. Der Begriff Signalfluß bezeichnet die Weiterleitung von Signaltoken auf Signalkanälen durch Netzwerke von Signalprozessoren (Signalnetzwerke). Analog dazu ist mit Datenfluß die Weiterleitung von Datentoken auf Datenkanälen durch Netzwerke von Datenflußprozessoren (Datennetzwerke) gemeint. Tokens, die an Eingangsports anliegen heißen Eingangstokens, jene an Ausgangsports nennt man Ausgangstokens. Alle Aktivitäten, die durch die Weiterleitung eines Tokens ausgelöst werden, bilden einen Prozeß. Ein Prozeß entsteht an der Tokenquelle und endet bei der letzten Komponente, die das Token nicht mehr weiterleitet. Im Abschnitt»Parallelität«, S. 214, werden Prozesse genauer erklärt. Tokens können Daten in Form von Smalltalk-Objekten mit sich führen. Ein Datentoken führt immer ein Datum mit sich, weil es Eingabe für einen Datenprozessor ist, der Datenwerte zur Verarbeitung benötigt. Ein Signaltoken hingegen zeigt im allgemeinen nur an, daß»irgend etwas«geschehen ist, ohne dieses Ereignis näher zu benennen. Wenn ein Signaltoken an einem Eingangsport eintrifft, löst es eine Operation aus. Die in Bild 7-4, S. 185, dargestellte Situation verdeutlicht diesen Mechanismus. Eingangsport go von trafficlightsprocessor wird aufgrund eines Signaltokens aktiviert, das Ausgangsport muststay von pedestranlightprocessor sendet. Das Signaltoken zeigt an, daß die Fußgängerampel auf Rot geschaltet hat, worauf die Verkehrsampel auf Grün schaltet. Die Aktivierung von go hätte auch aufgrund eines anderen Ereignisses geschehen können, etwa durch den Beginn des Ampelbetriebs am Morgen und zum selben Ergebnis geführt. Das bloße Eintreffen eines Signaltokens reicht jedoch nicht immer aus, um eine Operation zu aktivieren, weil manche Operationen zur ihrer Ausführung zusätzliche Daten benötigen. Wenn sich etwa die Lufttemperatur verändert, so könnte ein Signalprozessor den neuen Temperaturwert benötigen, um entsprechend reagieren zu kön-

196 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 186 nen. In solchen Fällen führt auch ein Signaltoken ein Datum mit, das bestimmte Attribute des Signals repräsentiert. Bild 7-6. Tokenfluß zwischen Benutzungsschnittstelle und Vista. Das Bild zeigt eine vereinfachte Darstellung des Tokenflusses zwischen Benutzungsschnittstelle und dem Domänenmodell von Vista am Beispiel eines Simulationsprogramms für eine Ampelanlage. Die Schaltflächen Off und Push for Walk der Benutzungsschnittstelle sind mit dem Domänenmodell über die Eingangsports off und walk des X-Prozessors pedestrianlightsprocessor verbunden. Dieser Prozessor steuert die Fußgängerampel. Umgekehrt ist der Ausgangsport canwalk mit einem Tongeber der Benutzungsschnittstelle verbunden. Der von Push for Walk ausgehende Pfeil bezieht sich auf das im folgenden erklärte Szenario, der von Off ausgehende Pfeil ist nur der Vollständigkeit halber dargestellt. Wenn der Benutzer die Schaltfläche Push for Walk betätigt, dann sendet die Laufzeitumgebung ein Token (im Bild ein blauer Kreis) an den Port walk. Dieses Token wird an ein Netzwerk von pedestrianlightsprocessor weitergeleitet (im Bild links dargestellt), wo es eine Umschaltung der Lampen von Rot auf Grün bewirkt. Die Lampen sind durch öffentliche Prozessoren (siehe Abschnitt»Interface«, S. 193) an den Prozessor angeschlossen. Sie werden nicht von der Laufzeitumgebung, sondern vom Prozessor direkt geschaltet. Anders verhält es sich mit dem im Bild rechts dargestellten Tongeber. Wenn die Ampel auf Grün schaltet, soll dieser Tongeber ein akustisches Signal aussenden. Dies wird dadurch bewirkt, daß pedestrianlightsprocessor zum Zeitpunkt der Umschaltung ein Token an Port canwalk sendet, wo es die Laufzeitumgebung entgegennimmt. Aufgrund des Tokenempfangs aktiviert die Laufzeitumgebung den Tongeber. Anmerkung: die konkrete Realisierung der gezeigten Ampelsimulation weicht von dieser Darstellung ab. Aus Platzgründen nicht dargestellt sind das Applikationsmodell, der Prozessor zur Steuerung der Verkehrsampel und andere Komponenten, die für die volle Funktionalität notwendig sind. Konzeptionell müßte zwischen dem Token als Transporteinheit und dem transportierten Datum nicht unterschieden werden. Diese Unterscheidung hat jedoch den technischen Vorteil, daß Parameter und die Historie des Tokens direkt beim Token gespeichert wer-

197 7.3 Das Programmiermodell 187 den können, ohne daß das Datum dadurch betroffen wäre. In Vista werden beispielsweise Daten über den Transport eines Tokens aufgezeichnet. Zu diesen Aufzeichnungen, gehört welche Komponente das Token erzeugt hat, an welche Komponenten das Token weitergeleitet wurde und zu welchem Zeitpunkt das geschehen ist. Andere Angaben betreffen die Steuerung des Tokens auf dem Weg durch die Netzwerke: man kann beispielsweise ein Token so konfigurieren, daß es eine Programmunterbrechung auslöst, wenn es bei einer bestimmten Komponente eintrifft. Mit passenden Werkzeugen kann dann das Programm inspiziert, eventuell modifiziert und schließlich an der Unterbrechungsstelle fortgesetzt oder abgebrochen werden. Bild 7-7 zeigt den Weg eines Tokens durch ein Netzwerk und das Werkzeug Token Tracer, das diesen Weg in einer Liste darstellt. Bild 7-7. Weg eines Tokens durch ein Netzwerk. Links der Weg eines Signaltokens durch ein Netzwerk mit drei Prozessoren. Zunächst wird von Port in ein Signaltoken ohne Daten erzeugt und an den Prozessor prompter weitergeleitet. Dieser Prozessor öffnet ein Dialogfenster (rechts oben), in das der Benutzer eine Zahl eingibt. Mit dieser Zahl (77) wird das Token belegt und an Port set des Objektspeichers number 1 weitergeleitet. Dort wird die Zahl extrahiert und gespeichert. Anschließend belegt Port changed das Token mit dem gespeicherten Wert (immer noch die Zahl 77) und sendet es an Port dec des Objektspeichers number 2. Hier bewirkt das Token, daß die mitgeführte Zahl von der aktuell gespeicherten Zahl (100) abgezogen wird. Der neue Wert von number 2 wird über Port changed an den Port out des Netzwerks transportiert. Der gesamte Weg mit Stempel der aktuellen Systemzeit in Millisekunden und dem jeweiligen Datenwert wird beim Token gespeichert und kann mit dem Werkzeug Token Tracer (rechts unten) angezeigt werden. Hinter jedem Eintrag in der Liste verbirgt sich das entsprechende Objekt. Es kann selektiert und mit Menükommandos manipuliert werden.

198 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Kanäle Kanäle sind Verbindungen zwischen Prozessoren zum Transport von Tokens. Kanäle sind gerichtet und verlaufen von Ausgangsports zu Eingangsports. Vista stellt keine bidirektionalen Kanäle zur Verfügung, d.h. das Versenden von Tokens über Kanäle ist eine Einwegkommunikation, die den Sender eines Tokens keine Informationen über die Behandlung des Tokens beim Empfänger liefert. Kanäle sind mehrprozeßfähig, d.h. sie können Tokens, die verschiedenen Prozessen zugeordnet sind, gleichzeitig transportierten. Wenn mehrere Kanäle an einen Ausgangsport angeschlossen sind, dann besitzt jeder Kanal eine Priorität, das ist eine ganze Zahl zwischen eins und Anzahl der am Port angeschlossenen Kanäle. Beim Erzeugen der Kanäle werden die Prioritäten fortlaufend vergeben, können aber jederzeit geändert werden. Um eine visuelle Überladung zu vermeiden, werden Kanalprioritäten gewöhnlich nicht dargestellt. Wenn es für das Programmverständnis wichtig ist, kann man jedoch eine Visualisierung veranlassen. Gewöhnlich durchläuft ein Signaltoken an Ausgangsports mit mehreren Kanälen jeden Kanal sequentiell aufsteigend nach Kanalpriorität in einer Depth-First-Ordnung: zuerst wird die Kette jener Prozessoren bis zum Ende durchlaufen, die am Kanal mit Priorität 1 ihren Ursprung hat, dann die Kette der Prozessoren des Kanals mit Priorität 2 usw. Wenn die letzte Komponente des letzten Kanals erreicht ist, terminiert der Prozeß (siehe Bild 7-5, S. 186). Datentoken werden standardmäßig parallel weitergeleitet. In diesem Fall ist die Kanalpriorität nicht von Bedeutung. Kanäle sind generisch und untypisiert, d.h. sie transportieren jede Art von Token unabhängig von dessen Typ. Dies gilt auch für Datennetzwerke, wo Kanäle nur typkompatible Ports miteinander verbinden. Die bei der Erzeugung eines Kanals durchgeführte Typprüfung bezieht sich in diesem Fall nicht auf den Kanal, sondern auf die verbundenen Ports Prozessoren Prozessoren sind benannte Funktionsbausteine oder Objektspeicher. Als Funktionsbausteine verarbeiten sie Signale oder Daten, als Objektspeicher halten sie beliebige Smalltalk-Objekte und geben Veränderungen an diesen Objekten durch Signale bekannt. Prozessoren verfügen über eine Schnittstelle (Interface) und ein gekapseltes Inneres (Interior). Ihr Name dient als Empfängeradresse für Nachrichten und zur Unterscheidung von anderen Prozessoren. Wie in Abschnitt 7.2.3, S. 181, bereits erwähnt, werden Prozessoren nach fünf Kriterien klassifiziert: (1) Anbindung an die Laufzeitumgebung: X- und I-Prozessoren; (2) Konstruktionsweise: Einfach- und Verbundprozessoren; (3) Einsatzbereich: Signal- und Datenprozessoren; (4) Kommunikationstyp: aktive und passive Prozessoren; (5) Sichtbarkeit: öffentliche und private Prozessoren. Im folgenden wird zunächst der Unterschied zwischen Einfach- und Verbundprozessoren erklärt. Danach werden Signal- und Datenprozessoren erläutert und auf ihre aktive bzw. passive Ausprägung eingegangen. Der Abschnitt endet mit einer Beschreibung von Interface und Interior, wobei auch öffentliche und private Prozessoren erklärt werden. X- und I-Prozessoren werden nicht erläutert, weil die Unterscheidung hinsichtlich der Anbindung an die Laufzeitumgebung keine konzeptionellen Aspekte betrifft.

199 7.3 Das Programmiermodell 189 Einfachprozessoren Einfachprozessoren programmiert man textuell mit Smalltalk in der VisualWorks- Programmierumgebung. Sie sind atomare Einheiten, d.h. sie sind aus keinen anderen Prozessoren zusammengesetzt. Prozessoren, die als Objektspeicher dienen, sind meist als Einfachprozessoren ausgeführt. Einfachprozessoren haben eine höhere Ausführungsgeschwindigkeit als vergleichbare Verbundprozessoren, weil die interne Weiterleitung von Tokens entfällt. Verbundprozessoren Verbundprozessoren erstellt man visuell mit Werkzeugen von Vista. Sie sind komplexe Einheiten bestehend aus anderen Verbundprozessoren und Einfachprozessoren. Die in Verbundprozessoren enthaltenen Prozessoren sind Teil des umschließenden Prozessors und bilden mit diesem eine Einheit. Beim Kopieren eines Verbundprozessors, werden alle darin enthaltenen Prozessoren ebenfalls kopiert. Vista unterscheidet sich in diesem Punkt von Smalltalk, wo Exemplarvariablen immer Verweise auf Objekte sind und keine Ist-Teil-Von-Beziehung festlegen. Signalprozessoren Signalprozessoren kommen für die Implementierung reaktiver Systeme zum Einsatz. Sie sind entweder Funktionsbausteine oder Objektspeicher und sind zustandsbehaftet. Der Zustand von Signalprozessoren ergibt sich aus den Zuständen der öffentlichen und privaten Prozessoren (siehe Abschnitte»Interface«und»Interior«, S. 193). Ein Signalprozessor sendet Signaltokens in zwei Fällen: (1) ein Token wurde empfangen und durch die internen Netzwerke oder Methoden verarbeitet; (2) der Zustand des Prozessors hat sich geändert und die Umgebung soll darüber informiert werden. Signalprozessoren können nur in Signalnetzwerken, nicht aber in Datennetzwerken eingebunden sein. Zyklische Verbindungen (Rückkopplungen) zwischen Signalprozessoren sind möglich (siehe Bild 7-8). Es wird zwischen aktiven und passiven Signalprozessoren unterschieden. Passive Prozessoren emittieren nur dann Tokens, wenn sie selbst ein Token oder eine Nachricht empfangen. Sie sind Durchgangs- bzw. Endstationen von Prozessen. Aktive Prozessoren können Tokens zu beliebigen Zeitpunkten emittieren. Tokenempfang und Tokenversand geschehen asynchron, d.h. die beiden Vorgänge finden in verschiedenen Prozessen statt. Aktive Prozessoren sind somit Prozeßquellen (siehe auch Abschnitt»Parallelität«, S. 214). Sie werden mit dem Symbol gekennzeichnet. Ob ein Signalprozessor aktiv oder passiv ist, bestimmt bei Einfachprozessoren der Programmierer des Prozessors. Bei Verbundprozessoren kann diese Eigenschaft automatisch festgestellt werden. Ein Verbundprozessor ist dann ein aktiver Prozessor, wenn eines seiner X-Netzwerke (siehe S. 203) einen aktiven Prozessor enthält. Ein Beispiel für einen aktiven Signalprozessor ist der Prozessor Timer aus Bild 7-9. Das Ausgangstoken des Ports expired ist einem anderen Prozeß zugeordnet als das Eingangstoken am Port countdown. Wäre nur ein Prozeß aktiv, so würde die Ausführung des Prozessors, der das Eingangstokens gesendet hat, für die Dauer des Countdowns blockiert; so aber kann mit seiner Ausführung fortgefahren werden, sobald Port countdown das Token entgegengenommen hat.

200 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 190 Bild 7-8. Rückkopplung zwischen Signalprozessoren. Prozessor A empfängt ein Token über Port o und sendet es an Prozessor B weiter. Dort wird in Abhängigkeit des Zustands von B das Token entweder an Port s oder t weitergeleitet. Damit das Token die Rückkoppelungsschleife über s verlassen kann, muß B seinen Zustand im Laufe der wiederholten Aktivierung verändern. Unter welchen Bedingungen dies geschieht ist von außen nicht sichtbar. Bild 7-9. Aktiver Signalprozessor. Der Prozessor Timer arbeitet als Zeitgeber. Das Symbol zeigt an, daß Timer ein aktiver Prozessor ist (siehe Abschnitt»Signalprozessoren«, S. 191). Der Eingangsport countdown ist mit dem Wert 7 parameterisiert, was bedeutet, daß sieben Sekunden nach Eintreffen eines Signaltoken an countdown der Ausgangsport expired ein Signal versendet. Datenprozessoren Datenprozessoren kommen für die Implementierung transformativer Systeme zum Einsatz. Sie sind Funktionsbausteine, keine Objektspeicher und zustandslos. Objektspeicher können Datenprozessoren deshalb nicht sein, weil sie Operationen im Sinne des Datenflußmodells repräsentieren und somit nur Daten verarbeiten, aber nicht speichern können. Zustandslos sind Datenprozessoren deshalb, weil dies Voraussetzung für die im Datenflußmodell geforderte Nebeneffektfreiheit ist. Ein Datenprozessor sendet Datentokens, wenn alle Eingangsports mit Tokens belegt sind und die anliegenden Tokens durch die internen Netzwerke oder Methoden verarbeitet wurden. Datenprozessoren können sowohl in Signalnetzwerke als auch in Datennetzwerke eingebunden sein. Wenn sie in Signalnetzwerke eingebunden sind, so sorgt

201 7.3 Das Programmiermodell 191 ein automatischer Mechanismus dafür, daß Signaltokens in Datentokens umgewandelt werden und umgekehrt. Zyklische Verbindungen zwischen Datenprozessoren sind nicht möglich, da die Ports von Datenprozessoren gekoppelt sind und Verbindungen zwischen Datenprozessoren im Sinne des Datenflußmodells immer Datenabhängigkeiten festlegen. Im Falle eines Zyklus würde das Paradoxon eintreten, daß ein Prozessor ein Token emittieren sollte, dessen Wirkung Voraussetzung ist, um das Token überhaupt senden zu können. Die in Bild 7-8 gezeigte Konstellation wäre für Datenprozessoren nicht erlaubt, weil Prozessor A (als Datenprozessor) erst dann mit der Ausführung beginnen würde, wenn sowohl an Port o als auch an Port p ein Token anliegt. Port p wird aber von Prozessor B versorgt, der seinerseits auf ein Token von A wartet, woraus sich eine zyklische Datenabhängigkeit ergibt. Datenprozessoren sind immer passiv. Sie können von sich aus keine Tokens emittieren, sondern benötigen für ihre Aktivierung entweder Eingabetokens oder einen expliziten Anstoß durch den Ausführungsmechnismus von Datennetzwerken. Interface Das Interface (die Schnittstelle) eines Prozessors dient zur Kommunikation mit anderen Prozessoren. Es besteht aus Eingangs- und Ausgangsports sowie öffentlichen Prozessoren und öffentlichen Methoden. Eingangs- und Ausgangsports dienen zum Empfangen und Senden von Tokens. Sie werden im Abschnitt»Ports«, S. 197, näher beschrieben. Öffentliche Prozessoren sind nach außen sichtbare Prozessoren eines Verbundprozessors. Sie können durch andere Prozessoren mit kompatibler Schnittstelle ersetzt werden. Man kann sich diesen Vorgang wie den Austausch eines Hardware-Chips auf einer Elektronikplatine vorstellen. Durch die Möglichkeit, Teile eines Prozessors durch den Austausch öffentlicher Prozessoren den jeweiligen Anforderungen anpassen zu können, wird der Entwurf von flexiblen Architekturen erleichtert (siehe auch Abschnitt»Substitution«, S. 228). Öffentlichen Methoden sind Funktionen, die der Prozessor seiner Umgebung zusätzlich zur Portschnittstelle anbietet und die von außen durch Nachrichten angesprochen werden können. Bild 7-10 zeigt das Interface eines Verbundprozessors zur Steuerung einer simulierten Fußgängerampel.

202 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 192 Bild Interface eines Verbundprozessors. Das Bild zeigt das Interface des Prozessors PLP, der zur Steuerung einer simulierten Fußgängerampel verwendet werden kann (siehe auch Bild 7-6, S. 188). Links im Bild ist das Interface in der Darstellungsform für die Verwendung in Netzwerken zu sehen. Links oben die erweiterte Ansicht mit den öffentlichen Prozessoren, links unten die kollabierte Darstellung mit dem Piktogramm des PLP- Prozessors. Rechts im Bild sieht man das Interface in der Darstellungsform für die Konstruktion von Verbundprozessoren. Es besteht aus diversen Menüs, drei Listen für Ports, öffentliche Prozessoren und öffentliche Methoden und einer Reihe von Schaltflächen zur Manipulation der in den Listen enthaltenen Elemente. Die Schaltfläche Interior öffnet das Fenster zur Darstellung des Interior. In der erweiterten Ansicht links oben sind die öffentlichen Prozessoren durch konkrete Komponenten ersetzt. Der Prozessor durationwalk ist ein Objektspeicher, der die Dauer der Grünphase in Sekunden angibt. Die ersetzende Komponente kann bei Objektspeichern ein beliebiges Smalltalk-Objekt sein, in diesem Fall die Zahl 5. Die Prozessoren greenbulb und redbulb repräsentieren die grüne und rote Lampe der Ampel. Sie sind durch die Prozessorexemplare g und r ersetzt. Vista stellt die erweiterte und kollabierte Interface-Ansicht von Einfach- und Verbundprozessoren in derselben Art dar. Die Darstellung rechts im Bild ist nur für Verbundprozessoren möglich. Bei Einfachprozessoren werden Interface und Interior mit einem Smalltalk-Browser angezeigt (siehe Bild 7-11, S. 196)

203 7.3 Das Programmiermodell 193 Interior Das Interior (Innere) eines Prozessors ist unterschiedlich ausgeprägt, je nachdem ob es sich um einen Einfachprozessor oder Verbundprozessor handelt. Einfachprozessoren bestehen wie alle Smalltalk-Objekte aus Exemplarvariablen und einer Referenz auf die definierende Klasse, wo die Methoden abgelegt sind. Dies bedarf keiner näheren Erläuterung. Interessanter ist das Interior eines Verbundprozessors, das neben den Elementen des Interface aus Netzwerken, privaten Prozessoren und privaten Methoden besteht: Netzwerke sind Gruppen von Prozessoren und anderen Netzwerken. Sie definieren das Verhalten von Verbundprozessoren. Sie werden im Abschnitt»Netzwerke«, S. 203, näher beschrieben. Private Prozessoren sind interne Prozessoren eines Verbundprozessors. Stellt man sich einen Verbundprozessor als Elektronikplatine vor und die öffentlichen Prozessoren als austauschbare Hardware-Chips, so sind die privaten Prozessoren verlötete Hardware-Chips, die von außen nicht sichtbar sind. Private Prozessoren stehen mit dem umschließenden Prozessor in einer Ist-Teil-Beziehung. In Vista wird die Ist- Teil-Beziehung dadurch ausgedrückt, indem ein Prozessor mit Drag-und-Drop in das Interior eines anderen Prozessors gezogen und somit zu einem Teil dieses Prozessors wird. Für private Prozessoren zur Speicherung von Attributen gilt dasselbe wie für öffentliche Prozessoren. Private Prozessoren dürfen nicht mit I-Prozessoren verwechselt werden. Als I-Prozessoren bezeichnet man alle Prozessoren, die mit der Laufzeitumgebung nicht verbunden sind, d.h. alle Prozessoren, die keine X- Prozessoren sind. Private Prozessoren sind immer I-Prozessoren, aber nicht alle I- Prozessoren sind private Prozessoren, weil auch öffentliche Prozessoren zu den I- Prozessoren zählen. Private Methoden sind Operationen, die nur innerhalb des Prozessors durch Nachrichten angesprochen werden können. Während in Smalltalk alle Methoden eines Objekts öffentlich sind, d.h. von anderen Objekten mit Nachrichten ansprechbar sind, sind in Vista private Methoden nur im definierenden Prozessor sichtbar. Bild 7-11 zeigt das Interior eines Einfachprozessors und eines Verbundprozessors.

204 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 194 Bild Interior eines Einfachprozessors (oben) und eines Verbundprozessors (unten). Das Interior eines Einfachprozessors wird mit einem Smalltalk-Browser dargestellt, der in drei Listen die Klassenhierarchie, die Methodenprotokolle und die Methodennamen anzeigt und darunter den Code der selektierten Methode. Die Einträge in Fettschrift beziehen sich auf Protokolle und Methoden des Einfachprozessors Timer, die anderen Einträge stammen von einer der Oberklassen. Das Interior eines Verbundprozessors wird ähnlich wie sein Interface dargestellt (siehe Bild 7-10). Drei Listen enthalten Netzwerke, private Prozessoren und private Methoden.

205 7.3 Das Programmiermodell Ports Ports sind Teil der Schnittstelle von Prozessoren und Netzwerken. Sie sind benannte und eventuell parameterisierte Anschlußpunkte für Kanäle und für die Anbindung der Laufzeitumgebung. Ports werden nach vier Kriterien klassifiziert, wobei jeder Port genau eine Merkmalsausprägung in jeder Kategorie aufweist: 1. Anbindung an den Prozessor: Eingangsports zum Empfangen von Eingangstokens und Ausgangsports zum Senden von Ausgangstokens. 2. Anbindung von Kanälen: belegte Ports, an denen Kanäle angeschlossen sind und unbelegte Ports ohne Verbindung zu Kanälen. 3. Kommunikationstyp: asynchrone Ports erzeugen einen neuen Prozeß zum Senden eines Tokens, synchrone Ports verwenden denselben Prozeß zum Senden, mit dem sie das Token entgegengenommen haben. Einsatzbereich: Signalports für den Empfang und Versand von Signaltokens, Datenports für den Empfang und Versand von Datentokens, Resetports zur Reinitialisierung von Signalprozessoren und Sequenzports, zur Sequentialisierung von Datenprozessoren. Bild 7-12 zeigt Darstellungen dieser vier Portarten. Jeder Port trägt einen Namen, der zur eindeutigen Identifizierung des Ports innerhalb der Eingangs- und Ausgangsports des zugehörigen Prozessors oder Netzwerkes dient. Bei der Einbindung von Prozessoren in VisualWorks-Applikationen verwendet man Portnamen als Bindeglied zwischen Laufzeitumgebung und Vista, bei Einfachprozessoren dienen Portnamen als Bezeichner von Smalltalk-Methoden. Ein Port kann optional über einen Portparameter verfügen. Portparameter werden für Operationen verwendet, die Daten zu ihrer Ausführung benötigen. Im folgenden werden die einzelnen Portarten und der Zweck von Portparameter näher beschrieben. Bild Darstellung von Ports. Links der Signalprozessor Timer mit Resetport reset, Eingabeport countdown und Ausgabeport expired. Der Port countdown hat einen ganzzahligen Parameter mit dem Wert 7. Rechts der Datenprozessor Get Element mit den Eingabeports array und index, dem Ausgabeport elem und dem Sequenzport seq. Datenports werden unterschiedlich dargestellt, je nachdem, ob sie Felder verarbeiten (Port array ) oder einzelne Datenwerte (Port index ). Der zusätzliche hellgraue (im Original blaue) Rahmen um die Ausgangsports elem und seq, kennzeichnet diese Port als asynchron. Eingangsports Ein Eingangsport nimmt ein anliegendes Token entgegen, führt (falls notwendig) eine Typprüfung und Typanpassung durch und reicht das Token an den Prozessor oder das Netzwerk weiter. Hinsichtlich der Weiterleitung an Prozessoren sind zwei Fälle zu un-

206 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 196 terscheiden: (1) Bei Einfachprozessoren aktiviert das empfangene Token eine Smalltalk-Methode. Bild 7-13 zeigt entsprechenden Smalltalk-Code. (2) Bei Verbundprozessoren wird das Token an die gleich benannten Eingangsports der X-Netzwerke weitergeleitet (siehe Abschnitt»Netzwerke«, S. 203). In jenen Fällen, wo ein Datenport an einen Signalkanal angeschlossen ist (d.h. der zugehörige Prozessor ist in ein Signalnetzwerk eingebettet), nimmt der Port vor der Weiterleitung zusätzlich eine Tokenkonvertierung vor, d.h. das am Eingangsport anliegende Signaltoken wird in ein Datentoken umgewandelt. countdownaction: seconds (seconds <= 0) iftrue: [ ^self expired trigger ]. self countdown lock. p := [ self waitfor: seconds. self countdown unlock. self expired trigger ] newprocess. p resume. Bild Smalltalk-Methode für Eingangsport countdown des Prozessors Timer. Die dargestellte Smalltalk-Methode wird ausgeführt, wenn der Eingangsport countdown des Prozessors Timer aus Bild 7-12 ein Token empfängt. Die Referenz self bezieht sich auf das aktuelle Exemplar von Timer. Vor Aktivierung der Methode hat der Parametermechanismus (siehe Abschnitt»Portparameter«, S. 202) dem Token den Wert seconds entnommen, der die Dauer der Verzögerung in Sekunden angibt. Die Methode prüft zunächst, ob die Verzögerung negativ oder gleich Null ist und löst in diesem Fall sofort ein Token bei Ausgangsport expired aus. Ist dies nicht der Fall, wird zunächst der Eingangsport countdown für weiteren Tokenempfang gesperrt und danach mit der Operation newprocess ein Prozeß p erzeugt, der die Verzögerung realisiert. Die Erzeugung eines parallelen Prozesses ist deshalb notwendig, nur Timer blockiert werden soll, nicht aber jener Prozessor, der Timer aktiviert hat. Der Prozeß wartet zunächst die gegebene Anzahl von Sekunden, entsperrt dann Eingangsport countdown und löst zuletzt an Ausgangsport expired ein Token aus. Der Prozeß p wird mit p resume gestartet. Ausgangsports Ein Ausgangsport leitet Tokens vom Inneren eines Prozessors oder Netzwerks nach außen zu den angeschlossenen Kanälen. Typprüfung wird keine durchgeführt, da aufgrund der schwachen Kopplung die Typkompatibilität der von Tokens transportierten Daten nur durch den empfangenden Prozessor (bzw. dessen Eingangsports) festgestellt werden kann. Datenports, die an einen Signalkanal angeschlossen sind, konvertieren vor der Weiterleitung das anliegende Datentoken in ein Signaltoken. Ein Ausgangsport, an dem mehrere Kanäle angeschlossen sind, kann Tokens an diese Kanäle sequentiell oder parallel weiterleiten. Für Signalports ist die sequentielle Weiterleitung der Standard, für Datenports die parallele Weiterleitung. Der Programmierer kann das Standardverhalten ändern sowie die Reihenfolge bei sequentieller Weiterleitung explizit festlegen.

207 7.3 Das Programmiermodell 197 Sowohl für Signal- als auch für Datenprozessoren genügt es, wenn entweder Eingangsoder Ausgangsports vorhanden sind. Wenn keine Eingangsports vorhanden sind, so wird die Tokenerzeugung bei Signalprozessoren durch interne Prozesse angestoßen; Datenprozessoren ohne Eingangsports werden durch den Ausführungsmechanismus für Datennetzwerke aktiviert. Prozessoren ohne Ausgangsports erzeugen Nebeneffekte, d.h. ihre Operationen wirken nicht über die Schnittstelle, sondern greifen über das Laufzeitsystem auf VisualWorks oder Betriebssystemressourcen zu. Prinzipiell sind auch Prozessoren ohne Ports möglich. Solche Prozessoren können jedoch nur über die Methodenschnittstelle mit Nachrichten kommunizieren, wodurch die Vorteile der schwachen Kopplung verlorengehen. Belegte und unbelegte Ports Ein Port, an dem ein oder mehrere Kanäle angeschlossen sind, wird als belegt bezeichnet, Ports ohne Anschluß an Kanäle heißen unbelegt. Die Unterscheidung von belegten und unbelegten Ports betrifft die Optimierung von Vista-Programmen, bei der unbelegte Ports in manchen Fällen eliminiert werden können. Asynchrone und synchrone Ports Diese Unterscheidung trifft nur auf Ausgangsports zu. Bei synchronen Ports leitet derselbe Prozeß das Token weiter, der es an den Port geliefert hat. Wenn an einen synchronen Ausgangsport mehrere Kanäle angeschlossen sind, so kann ein Token erst dann von einem Kanal übernommen werden, wenn alle direkt oder indirekt am Vorgängerkanal angeschlossenen Prozessoren soweit durchlaufen hat, bis es entweder auf einen aktiven Prozessor oder einen asynchronen Port trifft. Bei asynchronen Ports wird für jeden Kanal ein eigener Prozeß erzeugt. Der Abschnitt»Parallelität«, S. 214, erklärt diesen Mechanismus genauer. Asynchrone Ports sind durch eine blaue Füllung oder einen blauen Rahmen gekennzeichnet (siehe Bild 7-12, S. 197). Der Weiterleitungsmodus von Ports kann jederzeit geändert werden. Signalports Signalports gehören zu Signalprozessoren. Signalports ohne Parameter nehmen Signaltokens unabhängig von den mitgeführten Daten entgegen. Signalports mit Parameter sind typisiert, d.h. die von Signaltokens mitgeführten Daten müssen mit dem Typ des Portparameters kompatibel sein. Ein Portparameter ist eine Konstante oder ein Smalltalk-Ausdruck, dessen Auswertung ein Datum liefert. Bei Signaltokens, die ein falsch typisiertes Datum mitführen, wird dieses Datum durch den Portparameter ersetzt. Die Signalports eines Signalprozessors sind voneinander unabhängig. Gewöhnlich ist jedem Signalport eine Operation zugeordnet. Ein Token, das an einem Signalport eintrifft, löst sofort die dem Port zugeordnete Operation aus, unabhängig davon, ob an anderen Ports ebenfalls Tokens eingetroffen sind. An Signalports können beliebig viele Kanäle angeschlossen werden.

208 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 198 Datenports Datenports gehören zu Datenprozessoren. Sie sind typisiert, d.h. die von Datentokens mitgeführten Daten müssen mit dem Typ des Portparameters kompatibel sein. Die Eingangsdatenports eines Datenprozessors sind miteinander gekoppelt. Allen Eingangsports ist gemeinsam eine einzige Operation zugeordnet. Ein Token, das an einem Datenport eintrifft, löst erst dann diese Operation aus, wenn auch an allen anderen Ports ein Token eingetroffen ist. Eine Ausnahme sind Eingangsports von Datenprozessoren, die in Signalnetzwerke eingebettet sind. In diesem Fall kann der Programmierer wählen, ob die Eingangsports synchronisiert oder autonom sein sollen. Für den Fall, daß die autonome Betriebsweise gewählt wird, löst jedes eintreffende Token die Operation des Datenprozessors aus. Ist an einem Eingangsport noch nie ein Token eingetroffen, wird der im Portparameter festgelegte Standardwert verwendet, ansonsten der Wert des zuletzt eingetroffenen Tokens. An Eingangsdatenports kann nur ein Kanal, an Ausgangsdatenports können beliebig viele Kanäle angeschlossen werden. Die Beschränkung auf einen Kanal pro Eingangsport ergibt sich aus dem Datenflußmodell. Resetports Resetports gibt es nur für Signalprozessoren. Ein Token, das bei einem Resetport eintrifft, setzt den Zustand des zugehörigen Prozessors auf einen Initialwert zurück. Welche Aktionen für das Zurücksetzen des Zustandes im Einzelfall ausgeführt werden, hängt von der Funktionalität des Prozessors ab. Bild 7-14 zeigt die Smalltalk-Methode zur Reinitialisierung des Zustands des Prozessors Timer. resetaction self countdown unlock. p isnil iftrue: [ ^self ]. p terminate. p := nil. Bild Smalltalk-Methode für den Resetport des Prozessors Timer. Die dargestellte Smalltalk-Methode wird ausgeführt, wenn der Eingangsport reset des Prozessors Timer aus Bild 7-12 ein Token empfängt. Zunächst wird der Port countdown freigegeben, so daß er wieder Tokens empfangen kann. Danach wird geprüft, ob ein Verzögerungsprozeß aktiv ist. Wenn das der Fall ist, wird der Prozeß terminiert und der Exemplarvariablen p der Wert nil zugewiesen (siehe auch Bild 7-13). Sequenzports Sequenzports werden verwendet, um eine bestimmte Ausführungsreihenfolge für Datenprozessoren zu erzwingen, die voneinander keine Daten benötigen. Solche voneinander unabhängigen Datenprozessoren würden ohne den Einsatz von Sequenzports automatisch parallel und in undefinierter Reihenfolge ausgeführt werden. Jedem Datenprozessor kann ein Eingangs- und ein Ausgangsport für die Sequentialisierung zugeordnet sein. Die Operation eines Datenprozessors mit einen Sequenzport am Eingang, wird

209 7.3 Das Programmiermodell 199 erst dann aktiviert, wenn an allen Eingangsports und am Sequenzport ein Token eingetroffen ist. Ein Sequenzport am Ausgang versendet erst dann ein Token, wenn alle anderen Ausgangsports ein Token versenden haben, d.h. die Operation abgeschlossen ist. Bild 7-15 zeigt ein Beispiel für die Verwendung von Sequenzports zur Messung der Ausführungsdauer einer Operation. Bild Verwendung von Sequenzports. Es soll die Ausführungsdauer des Datenprozessors get element gemessen werden. Der Ausführungsmechanismus des Datennetzwerks aktiviert zunächst den Prozessor time start, der die aktuelle Uhrzeit liefert und danach get element. Durch die Verbindung der Sequenzports von time start und get element ist diese Ausführungsreihenfolge sichergestellt; ohne die Sequenzports würden die beiden Prozessoren gleichzeitig bzw. in undefinierter Reihenfolge aktiviert werden, weil zwischen ihnen keine Datenabhängigkeit besteht. Nachdem get element ein Ergebnis geliefert hat (das am unbelegten Port elem verworfen wird), wird über den Ausgangssequenzport der Prozessor time end aktiviert und schließlich der Startzeitpunkt vom Endzeitpunkt subtrahiert, um die Ausführungsdauer zu ermitteln.

210 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 200 Portparameter Ein Portparameter ist eine Smalltalk-Konstante oder ein Smalltalk-Ausdruck, dessen Auswertung ein Datum, d.h. ein Smalltalk-Objekt ergibt. Der Parameter wird für Operationen verwendet, die Daten zu ihrer Ausführung benötigen. Wenn ein Port über einen Parameter verfügt, so bedeutet dies, daß alle vom Port empfangenen oder gesendeten Tokens mit Daten belegt sein sollten, die typkompatibel sind mit dem Typ des Parameters. In Vista ist ein Datum immer ein Smalltalk-Objekt. Kompatibel heißt demzufolge, daß die Klasse eines vom Token mitgeführten Objekts gleich der Klasse des Parameters oder einer Subklasse ist. Sind die Typen nicht kompatibel, so tritt automatisch ein Mechanismus zur Tokenbelegung in Kraft. Dieser Mechanismus funktioniert wie folgt: Bevor ein Signaltoken von einem parameterisierten Eingangsport an einen Prozessor weitergeleitet wird, prüft der empfangende Eingangsport, ob das Signaltoken ein Objekt mitführt und ob das Objekt mit dem Portparameter typkompatibel ist. Sind beide Bedingungen erfüllt, so sind keine weiteren Aktionen notwendig und der Eingangsport übergibt das Token unverändert an den Prozessor. Erkennt der Eingangsport jedoch kein Objekt bzw. ein falsch typisiertes Objekt, so belegt er das Token mit einem richtig typisierten Standardobjekt. Der Programmierer kann dieses Standardobjekt ändern, indem er den Portparameter modifiziert. Bei Ausgangsports wird eine Typprüfung nicht vorgenommen, da die Tokenbelegung vom Prozessor selbst durchgeführt wird und jede falsche Belegung auf einen Programmfehler hindeuten würde. Die beschriebene Art der Parameterbelegung fördert die Flexibilität von Vista- Komponenten. Ein Prozessor braucht nicht zwangsläufig ein richtig typisiertes Token zu liefern, um anderswo Operationen zu aktivieren. Solange zur Ausführung einer Operationen entweder keine Parameter notwendig sind (d.h. der Empfang eines Tokens ausreicht, um die Operation zu aktivieren) oder für Parameter geeignete Standardobjekte zur Verfügung stehen, können beliebige Prozessoren miteinander verbunden werden, ohne daß es zu Laufzeitfehlern kommt. Das Kommunikationsmodell für Prozessoren unterscheidet sich in dieser Hinsicht grundsätzlich von der Nachrichtenübermittlung in den meisten objektorientierten Programmiersprachen, wo das sendende Objekt in der Regel die Nachrichtenschnittstelle samt Parametertypen des empfangenden Objekts kennen muß, um mit diesem kommunizieren zu können (eine Ausnahme bilden z.b. Default-Parameter in C++, das ändert aber nichts am grundsätzlichen Kommunikationsmodell in herkömmlichen objektorientierten Programmiersprachen). Portparameter werden in eckigen Klammern neben dem Portnamen dargestellt. Für Signalports sind Parameter optional, da Signaltoken nicht zwangsweise ein Datum mit sich führen müssen. Für Datenports sind Parameter zwingend. Wenn der zugehörige Datenprozessor in ein Signalnetzwerk eingebettet ist, dann wird der Parameter dargestellt. In diesem Fall muß für eintreffende Signaltoken die Umwandlung in ein richtig typisiertes Datentoken möglich sein, was bei Signaltokens ohne Datenwert nur durch die Zuweisung eines Standardwertes möglich ist. Wenn der zugehörige Datenprozessor in ein Datennetzwerk eingebettet ist, dann wird der Parameter nicht dargestellt. In diesem Fall ist garantiert, daß Tokens richtig typisierte Daten mitführen, weil bereits bei Verbindung von Ports eine statische Typprüfung vorgenommen wird.

211 7.3 Das Programmiermodell Netzwerke Netzwerke sind benannte Komponentengruppen, die das Verhalten von Verbundprozessoren bestimmen. Einfachprozessoren verfügen über keine Netzwerke. Ihr Verhalten ist durch Methoden bestimmt. Netzwerke werden als zweidimensionale Diagramme dargestellt und bestehen aus Prozessoren, lokalen Netzwerken sowie Referenzen auf Prozessoren und Netzwerke (Stellvertretern). Netzwerke bestimmen das Verhalten einzelner Prozessoren, nicht das Verhalten von Prozessorklassen. Damit ist gemeint, daß die Änderung des Netzwerks eines Prozessors keine Auswirkung auf das Verhalten von Prozessoren derselben Klasse (desselben Typs) hat. Netzwerke verfügen wie Prozessoren über Eingangsports, um Tokens zu empfangen, und über Ausgangsports, um Tokens zu senden. Die Ports sind in Eingangs- und Ausgangsterminals zusammengefaßt. Diese Terminals bilden die Schnittstelle des Netzwerks. Prozessoren und Netzwerke innerhalb eines Netzwerkes sind entweder lokale Komponenten, die nach außen verborgen sind, oder Stellvertreter von Komponenten, die anderswo definiert sind. Das Netzwerk und alle seine Komponenten tragen Namen. Der Name des Netzwerks dient zur Unterscheidung von anderen Netzwerken desselben Prozessors. Der Name einer Komponente dient zur Unterscheidung von anderen Komponenten desselben Netzwerks und als Empfängeradresse für Nachrichten. Netzwerke werden nach zwei Kriterien klassifiziert, wobei jedes Netzwerk genau eine Merkmalsausprägung in jeder Kategorie aufweist: 1. Anbindung an den Prozessor: X-Netzwerke (externe Netzwerke) sind Bindeglieder zwischen den Eingabe- und Ausgabeports eines Verbundprozessors. I-Netzwerke (interne Netzwerke) können innerhalb von anderen Netzwerken (X oder I) ähnlich wie Unterprogramme verwendet werden. T-Netzwerke (temporäre Netzwerke) dienen für die versuchsweise Kombination von Prozessoren und haben keine Verbindung zu einem Prozessor. 2. Einsatzbereich: Signalnetzwerke für die Verarbeitung von Signaltokens reaktiver Systeme, Datennetzwerke für die Verarbeitung von Datentokens transformativer Systeme. Im folgenden werden die einzelnen Arten von Netzwerken näher beschrieben. Mit dem Begriff»Verbundprozessor«ist dabei immer jener Prozessor gemeint, in dem das Netzwerk enthalten ist. X-Netzwerke Bei der Konstruktion von Verbundprozessoren legt man zunächst die Schnittstelle fest, d.h. die Ports, die öffentlichen Prozessoren und die öffentlichen Methoden. Sobald ein Prozessor über Ports verfügt, kann er mit anderen Prozessoren verbunden werden. Tokens, die an seine Ports gesandt werden, lösen jedoch keine Operationen aus, solange keine Verbindung zum Interior besteht (siehe S. 195). Die Verbindung zwischen den Eingangs- und Ausgangsports eines Verbundprozessors wird durch X-Netzwerke realisiert. Für jeden Prozessorport gibt es einen gleichnamigen Port in einem X-Netzwerk, d.h. die Eingangs- und Ausgangsterminals von X- Netzwerken entsprechen der Eingangs- und Ausgangs-Portschnittstelle des zugehörigen

212 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 202 Verbundprozessors. An die Netzwerkports können Prozessoren und I-Netzwerke angeschlossen werden. Bei Signalprozessoren ist es angebracht, für jeden Eingangsport ein X-Netzwerk vorzusehen, um die Operationen klar zu trennen, die den einzelnen Ports zugeordnet sind. Pro Netzwerk ist bei dieser Vorgangsweise ein Eingangsport belegt, alle anderen sind unbelegt und werden bei der Ausführung des Netzwerks nicht berücksichtigt. Bei Datenprozessoren ist diese Vorgangsweise nicht möglich. Datenprozessoren können nur ein X- Netzwerk enthalten, weil ein Datenprozessor eine einzige transformative Operation repräsentiert, die allen Eingangsports gemeinsam zugeordnet ist. X-Netzwerke spielen bei Konstruktion aktiver Signalprozessoren eine besondere Rolle, weil X-Netzwerke aktive Signalprozessoren als Prozeßquellen enthalten können. Ein X- Netzwerk, das aktive Signalprozessoren enthält, die mit seinen Ausgangsports verbunden sind, kann asynchron Tokens senden, ohne daß zuvor an einem Eingangsport ein Token eingelangt sein muß. Dadurch wird der Verbundprozessor des X-Netzwerks zu einem aktiven Signalprozessor. X-Netzwerke können im allgemeinen nicht wie I-Netzwerke (siehe nächster Abschnitt) aus anderen Netzwerken aktiviert (»aufgerufen«) werden. Dafür gibt es zwei Gründe: (1) die Ports eines X-Netzwerks sind mit den Ports des Verbundprozessors verbunden, und deshalb würden bei jeder Aktivierung die Ausgangstokens sowohl zur aufrufenden Stelle als auch zu den Prozessorports weitergeleitet werden, was unerwünschte Nebeneffekte zur Folge hätte. (2) Die Aktivierung eines Netzwerks entspricht dem Aufruf eines Unterprogramms mit Rückgabewert und muß daher einer Eingangs- Ausgangskausalität folgen, d.h. ein Ausgangstoken darf nur aufgrund eines Eingangstokens, geliefert werden. X-Netzwerke, die aktive Prozessoren enthalten, würden diese Kausalität verletzen, da sie asynchron Ausgangstokens senden, die unabhängig von zuvor empfangenen Eingangstokens sind. Eine Ausnahme ist das Überschreiben von X- Netzwerken in einer Vererbungshierarchie. In diesem Fall kann ein X-Netzwerk einer Unterklasse ein gleichnamiges X-Netzwerk aus einer der Oberklassen referenzieren (siehe Abschnitt»Vererbung von Netzwerken«, S. 231). Bild 7-16 zeigt das X-Netzwerk des PLP-Prozessors aus Bild 7-10, S. 194, für die Steuerung der Grünphase der Fußgängerampel. I-Netzwerke Prinzipiell reichen X-Netzwerke aus, um die Operationen eines Verbundprozessors festzulegen. Gäbe es jedoch nur solche Netzwerke, so könnten keine in mehreren Netzwerken gemeinsam nutzbare Netzwerke definiert werden. Dies wäre ein erheblicher Nachteil im Vergleich zu höheren Programmiersprachen, wo Unterprogramme für die Mehrfachverwendung von Programmcode zur Verfügung stehen. In Vista sind für diesen Zweck I-Netzwerke vorgesehen. I-Netzwerke werden einmal pro Prozessor konstruiert und danach mehrfach in andere I- oder X-Netzwerken desselben Prozessors eingebaut. Auch Rekursion ist möglich, d.h. ein I-Netzwerk kann sich selbst enthalten. Die»Aufrufstelle«bzw.»Einbaustelle«ist eine Referenz auf das originale Netzwerk (siehe Abschnitt»Methoden«, S. 211). I-Netzwerke können nur passive Prozessoren (lokal, privat und öffentlich) und andere I- Netzwerke enthalten. Durch den Ausschluß von aktiven Prozessoren ist die im vorigen Abschnitt angesprochene Eingangs-Ausgangskausalität gewährleistet. In diesem Zu-

213 7.3 Das Programmiermodell 203 sammenhang ist zu betonen, daß ein I-Netzwerk aufgrund eines einzigen Eingangstokens durchaus mehrere Ausgangstokens hintereinander liefern kann, während ein Unterprogramm in einer höheren Programmiersprache bei einem Aufruf nur einmal Rückgabewerte produziert. Bild 7-17 zeigt das I-Netzwerk allbulbsnet, das im X-Netzwerk aus Bild 7-16, zum Ein- und Ausschalten der Lampen des PLP-Prozessors verwendet wird. Bild Ein X-Netzwerk des PLP-Prozessors. Das Bild zeigt das X-Netzwerk walknet, das die Grünphase des PLP-Prozessors schaltet. Zuerst wird das I-Netzwerk allbulbsnet aktiviert, um die grüne Lampe einzuschalten (gon - green on) und die rote Lampe auszuschalten (roff). Wenn die grüne Lampe leuchtet (gson - green switched on), wird zum einen durch Port canwalk der Umgebung signalisiert, daß die Fußgängerampel Grün zeigt und zum anderen der Zeitgeber timerpedwalk aktiviert, der für die Zeit durationwalk die Ausführung des Netzwerks verzögert. Nach dem Ablauf von timerpedwalk wird die grüne Lampe ausgeschaltet (goff), die rote Lampe eingeschaltet (ron) und durch Port muststay der Umgebung signalisiert, daß nun die Fußgängerampel wieder Rot zeigt. Man beachte, daß die Eingangsports off und stay unbelegt sind. Diese Ports werden in anderen Netzwerken verwendet.

214 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 204 Bild Ein I-Netzwerk des PLP-Prozessors. Das Bild zeigt das I-Netzwerk allbulbsnet, das die einzelnen Lampen des PLP-Prozessors schaltet (siehe Bild 7-16, S. 205). T-Netzwerke Für die versuchsweise, temporäre Kombination von Prozessoren stehen T-Netzwerke zur Verfügung. T-Netzwerke sind gewissermaßen die Experimentierfläche des Programmierers, wo er Prozessoren rasch verbinden und ihre Funktionalität und ihr Zusammenwirken prüfen kann. Für T-Netzwerke sind diverse Test- und Visualisierungswerkzeuge verfügbar, mit denen das Verhalten der zu prüfenden Prozessoren beobachtet und analysiert werden kann. Zudem kann jeder Prozessor»an Ort und Stelle«modifiziert und in geänderter Form als Schablone zur Erzeugung neuer Prozessoren gespeichert werden. Bild 7-18 zeigt ein T-Netzwerk zur Prüfung des PLP-Prozessors. Signalnetzwerke Die vorangehenden Abschnitten erklärten die Anbindung von Netzwerken an einen Verbundprozessor. Obwohl die Bildbeispiele durchgehend Signalnetzwerke zeigten, gelten die Aussagen auch für Datennetzwerke. Dieser und der folgenden Abschnitt erläutern die speziellen Eigenschaften von Signal- und Datennetzwerken, insbesondere das Ausführungsmodell und die algorithmischen Konzepte. Signalnetzwerke sind für die Programmierung auf Systemebene gedacht. Mit ihnen legt man fest, wie Komponenten reaktiver Systeme auf Ereignisse reagieren und wie die Komponenten kommunizieren. Die Implementierung von Algorithmen ist nicht vorgesehen. Entsprechende Ablaufkonstrukte fehlen deshalb. Zwar gibt es Prozessoren, die den Signalfluß ähnlich steuern wie eine bedingte Verzweigung, diese Prozessoren sind jedoch nicht für algorithmische Zwecke gedacht, sondern zur selektiven Weiterleitung von Signaltokens. Für algorithmische Problemstellungen sollten Datennetzwerke oder Smalltalk verwendet werden. Die gute Integration von Vista und VisualWorks, erlaubt

215 7.3 Das Programmiermodell 205 den vollen Zugriff auf die reichhaltige Smalltalk-Klassenbibliothek, die Implementierungen für viele Standardalgorithmen enthält. Bild Ein T-Netzwerk zur Prüfung des PLP-Prozessors. Das Bild zeigt ein T-Netzwerk zur Prüfung des PLP-Prozessors. Das Netzwerk verfügt über zwei Eingangsports in1 und in2, die mit den Ports stay und walk des Prozessors verbunden sind. Die Ausgangsports des Prozessors sind mit dem Port out verknüpft. Oberhalb des Netzwerks sind verschiedene Schaltflächen und Menüs zur Benutzerinteraktion angebracht. Im Bild hat der Benutzer die Schaltfläche in1 betätigt, wodurch der gleichnamige Port ein Token an Port stay sendet. Dieser Vorgang ist durch eine gestrichelte blaue Linie visualisiert. Port stay ist mit einem Haltepunkt versehen, wodurch in dem Augenblick, in dem das Token an stay eintrifft, der Smalltalk-Debugger (rechts im Bild) aktiviert wird. Mit dem Debugger hat der Benutzer die Möglichkeit, die Ausführungsreihenfolge der Operationen zu analysieren und alle beteiligten Objekte zu inspizieren. Signalnetzwerke können sowohl passive als auch aktive Prozessoren enthalten. Für die Erstellung von Verbindungen zwischen Prozessoren in Signalnetzwerken gibt keine besonderen Regeln. Zyklen sind ebenso erlaubt wie isolierte Prozessoren, die nicht über Kanäle, sondern über Methoden angesprochen werden. Sowohl Eingangs- als auch Ausgangsports können mehrfach mit Kanälen belegt werden. Signalnetzwerke verfügen über keinen zentralen Mechanismus zur Steuerung des Tokenflusses. Für die Weiterleitung von Signaltokens sind ausschließlich die Ports der im Netzwerk enthaltenen Komponenten zuständig. Weder bei den Eingangs- noch bei den Ausgangsterminals des Netzwerks findet eine Synchronisation statt. Die Komponenten eines rekursiv aktivierten Signalnetzwerks werden nicht auf den Laufzeitstapel gelegt, wie das etwa bei Parametern und lokalen Variablen einer Methode geschieht, sondern existieren nur einmal. Zustandsänderungen einer Komponente werden deshalb auf allen Rekursionsstufen wirksam. Zudem können Signalnetzwerke von mehreren Prozessen parallel durchlaufen werden. Die Koordination dieser Prozesse obliegt dem Programmierer (siehe Abschnitt»Parallelität«, S. 214).

216 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 206 Datennetzwerke Datennetzwerke werden für die Verarbeitung von Datenströmen aufgrund des Datenflußmodells eingesetzt. Dazu gehört die Filterung, Sortierung, Mischung und Transformation von Daten. Wie bei Signalnetzwerken sind die verwendeten Prozessoren meist Softwarekomponenten auf hohem Niveau. In Datennetzwerken können jedoch algorithmische Aspekte nicht ignoriert werden, weil die Selektion von Elementen des Datenstroms und Iterationen über diese Elemente eine wesentliche Rolle spielen. In Datennetzwerken stehen deshalb spezielle Konstrukte für Verzweigungen und Schleifen zur Verfügung. Datennetzwerke können nur passive Prozessoren enthalten. Für die Erstellung von Verbindungen zwischen den Prozessoren gelten die Regeln des Datenflußmodells: Von jedem Port des Eingangsterminals muß mindestens ein Kanal zu einem Eingangsport führen, und jeder Port des Ausgangsterminals muß über genau einen Kanal mit einem Ausgangsport verbunden sein; zu jedem Eingangsport eines Prozessors muß genau ein Kanal von einem Ausgangsport führen; Zyklen sind nicht erlaubt. Datennetzwerke verfügen über einen zentralen Ausführungsmechanismus, die Datenflußmaschine. Sie erfüllt drei Aufgaben: 1. Aktivierung von Prozessoren ohne Eingangsports. Solche Prozessoren sind Datenquellen im Sinne des Datenflußmodells. Sie speichern konstante Werte oder dienen als Datengeneratoren. Alle Prozessoren ohne Eingangsports innerhalb eines Datennetzwerks werden parallel aktiviert, weil zwischen ihnen keine Datenabhängigkeiten bestehen. 1. Synchronisation der Ausgangstokens. Erst wenn an allen Ports des Ausgangsterminals ein Token anliegt, werden die Tokens gemeinsam freigegeben. Diese Synchronisation ist zwar theoretisch nicht notwendig, erleichtert aber die Programmverfolgung, insbesondere bei rekursiv aktivierten Datennetzwerken. 1. Kopieren eines Datennetzwerks, das rekursiv aktiviert wird. Das Datenflußmodell verbietet Mehrfachbelegungen von Kanälen. Beim rekursiven Aufruf eines Datennetzwerks tritt diese Situation jedoch ein. Um Konflikte zu vermeiden, gibt es prinzipiell zwei Möglichkeiten: Man unterscheidet die Tokens der verschiedenen Rekursionsstufen durch einen Rekursionszähler oder man kopiert den Programmcode. In Vista wurde die zweite Möglichkeit gewählt. Diese hat den Vorteil, daß jede Rekursionsstufe für sich visualisiert werden kann. Nachteile sind der hohe Speicherbedarf und verlängerte Laufzeiten. Bild 7-19 zeigt ein Datennetzwerk zur Suche des größten Elements eines Felds. Aus Platzgründen wird dieses Netzwerk nicht unterhalb der Abbildung beschrieben, sondern hier. Zur Suche des größten Elements werden drei Netzwerke benötigt: das links oben dargestellte Hauptnetzwerk, ein darin enthaltenes While-Netzwerk und ein im While- Netzwerk enthaltenes If-Netzwerk. Das Hauptnetzwerk hat einen Eingangsport array, für das Datentoken mit dem Feld und einen Ausgangsport biggest für das Datentoken mit dem größten Element. Der Typ der einzelnen Feldelemente ist unerheblich, da alle Operationen auf Feldern polymorph sind, d.h. für beliebige Elementtypen funktionieren. Port array sendet das Feld parallel an den Datenprozessor get element und das While-Netzwerk while. Der Datenprozessor start liefert den Wert 1 an den Prozessor get element und den Port index des While- Netzwerks. Der Prozessor get element entnimmt das erste Element und sendet es eben-

217 7.3 Das Programmiermodell 207 falls an das While-Netzwerk, wo es Port biggest als vorläufig größtes Element entgegennimmt. Das While-Netzwerk wird im Hauptnetzwerk genauso wie ein Datenprozessor dargestellt. Die von außen sichtbaren Ports sind nicht vordefiniert, sondern werden vom Programmierer nach Bedarf festgelegt. Zu jedem Eingangsport gibt es einen korrespondierenden Ausgangsport. Im Inneren gibt es einen vordefinierten Port loop. Das While- Netzwerk verarbeitet die Eingangstokens entsprechend der internen Logik und sendet sie an die Ausgangsports. An Port loop wird ein boolescher Wert gesendet. Solange dieser Wert true ist, werden die Ausgangstokens an die Eingangsports zurückgestellt, und ein neuer Durchlauf beginnt. Sobald der Wert false ist, werden die Ausgangstokens in das umgebende While-Netzwerk weitergeleitet. Die interne Logik des While-Netzwerks aus Bild 7-19 wird nicht im Detail erklärt, weil sie intuitiv verständlich sein sollte. Lediglich das darin enthaltene If-Netzwerk wird näher beschrieben. Das If-Netzwerk funktioniert als Weiche. Es sendet entweder das alte größte Element oder das aktuelle Element an den Ausgangsport biggest. If-Netzwerke haben wie While- Netzwerke beliebig viele Ports, die der Programmierer nach Bedarf festlegt. Eingangsports und Ausgangsports müssen nicht korrespondieren. Im konkreten Fall werden zwei Ports a und b benötigt, um die Elemente zu vergleichen. Zusätzlich zu den vom Programmierer festgelegten Ports gibt es den vordefinierten Port condition. Wenn an diesem Port der Wert true anliegt, dann werden die Eingangstokens an den True-Zweig des If-Netzwerks weitergeleitet, sonst an den False-Zweig. Jeder Zweig ist ein eigenes Netzwerk, mit den gleichen Ports wie das If-Netzwerk selbst. Im hier dargestellten Fall sind diese Netzwerke sehr einfach definiert. Im True-Zweig wird das am Eingangsport a anliegende Token an den Ausgangsport c weitergeleitet, im False-Zweig geschieht das umgekehrte. Die Aktivierung des jeweiligen Zweiges erfolgt durch den booleschen Wert, den der Datenprozessor a>b liefert. Dieser Prozessor vergleicht das alte grˆßte Element mit dem aktuellen Element.

218 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 208 True-Zweig False-Zweig Hauptnetzwerk If-Netzwerk While-Netzwerk. Bild Datennetzwerk zur Suche des größten Elements eines Felds.

219 7.3 Das Programmiermodell Methoden Methoden sind benannte Folgen von Smalltalk-Anweisungen, die durch Senden einer gleichnamigen Nachricht an den Prozessor aktiviert werden. Sie werden mit Texteditoren in VisualWorks erstellt und unterscheiden sich nicht von Smalltalk-Methoden. Methoden verfügen über uneingeschränkten Zugriff auf Interface und Interior eines Prozessors. Methoden können beispielsweise Ports aktivieren oder den Zustand von Prozessoren abfragen und modifizieren. Vista stellt eine Reihe von Standardmethoden für folgende Zwecke zur Verfügung: Umwandlung einfacher Smalltalk-Objekte (z.b. Zeichen und Zahlen) in Prozessoren und umgekehrt. Zugriff auf generische Prozessorattribute (z.b. Name, Typ und Visualisierung) und Prozessorstruktur (z.b. Ports, öffentliche Prozessoren und angeschlossene Kanäle). Steuerung der Prozessorausführung (z.b. Animation, Haltepunkte und Tokenverfolgung). Der Aufruf von Methoden kann innerhalb anderer Methoden oder auf visueller Ebene erfolgen. Der visuelle Aufruf ist nur innerhalb von Signalnetzwerken möglich. Dafür steht der Prozessor Do zur Verfügung. Dieser Prozessor verfügt einen Parameter Code, der den Quelltext für den Methodenaufruf enthält, über einen Eingangsport execute, der die Ausführung des Quelltextes anstößt und über einen Ausgangsport done, der ein Signaltoken aussendet, wenn die Ausführung beendet ist. Im Quelltext können Komponenten des Netzwerks sowie die Elemente von Interface und Interior des umschließenden Prozessors referenziert werden. Bild 7-20 zeigt eine öffentliche Methode des PLP- Prozessors, die viermal die grüne Lampe der Fußgängerampel blinken läßt. Darunter ist der Aufruf in einem Netzwerk dargestellt Stellvertreter In Vista existiert eine Komponente gewöhnlich dort, wo sie zu sehen ist. Die Manipulationen eines Programmierers an einer Komponente sind deshalb lokal begrenzt und frei von Nebeneffekten. Manchmal ist es jedoch notwendig, daß eine Komponente an mehreren Stellen gleichzeitig verfügbar ist. Beispiele dafür sind: öffentliche Prozessoren, die in der Prozessorumgebung definiert sind, für die es im Interior aber ebenfalls eine Repräsentation geben muß Prozessoren, die in mehreren Netzwerken enthalten sind Netzwerke, die in anderen Netzwerken als»unterprogramme«angesprochen werden. Für diese Fälle sieht Vista spezielle Komponenten vor, die Stellvertreter heißen. Stellvertreter repräsentieren Prozessoren oder I-Netzwerke, die an anderer Stelle definiert sind und können mit Zeigervariablen konventioneller Programmiersprachen verglichen werden. Die von Stellvertretern repräsentierten Komponenten heißen Originale. Das Interface von Stellvertretern ähnelt dem der Originale (ein heller Schatten und eine kursive Beschriftung dienen als visuelles Unterscheidungsmerkmal), sie verfügen jedoch über kein Interior. Statt dessen halten sie eine Referenz auf das Original. Veränderungen des Interface sind nur beim Original möglich und sofort bei allen Stellvertretern sichtbar. Fügt ein Programmierer etwa einen Port zu einem Prozessor hinzu, so zeigen

220 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 210 alle Stellvertreter sofort den neuen Port. Löscht der Programmierer einen Port, so wird der entsprechende Port bei den Stellvertreter gelöscht falls er unbelegt ist, sonst wird er durch ein spezielles Symbol als ungültig gekennzeichnet und deaktiviert (auf diese Weise gehen angeschlossene Kanäle nicht verloren). Ein Stellvertreter leitet jede Nachricht und jedes Eingangstoken an das Original weiter, wo es verarbeitet wird. Für den umgekehrten Weg, die Weiterleitung von Ausgangstokens durch das Original an seine Stellvertreter sind zwei Fälle zu unterscheiden: 1. Stellvertreter von Prozessoren: der Originalprozessor leitet Ausgangstokens an alle Stellvertreter weiter, die sich in einem X-Netzwerk oder im selben I-Netzwerk befinden. Dieser Vorgang wird Rundruf genannt. Stellvertreter, die sich in anderen I- Netzwerken als das Original befinden, sind von der Weiterleitung deshalb ausgeschlossen, weil sonst innerhalb eines I-Netzwerks ein Tokenfluß entstehen würde, ohne daß über die Eingangsports ein Token eingetroffen wäre. Das würde die Eingangs-Ausgangskausalität verletzen (siehe Abschnitt»I-Netzwerke«, S. 204). In manchen Fällen kann es notwendig sein, den Rundrufmechanismus zu deaktivieren. Der Programmierer kann dies selektiv veranlassen. Prozessorstellvertreter, für die der Rundruf deaktiviert ist, verhalten sich wie Stellvertreter von I-Netzwerken: das Original übermittelt an sie nur dann Ausgangstokens, wenn die Eingangstokens von ihnen stammen. 2. Stellvertreter von I-Netzwerken: solche Stellvertreter repräsentieren Aufrufstellen der referenzierten I- Netzwerke. Das Originalnetzwerk leitet Ausgangstokens nur an jenen Stellvertreter weiter, von dem die Eingangstokens stammen. Diese Regel stellt sicher, daß nur die aktuelle Aufrufstelle eines I-Netzwerks Ausgangstokens produziert und nicht auch alle anderen Aufrufstellen. Stellvertreter können nur Originale desselben oder eines umgebenden Sichtbarkeitsbereichs referenzieren. Diese Regel vermeidet schwer nachvollziehbare Querbeziehungen und fördert die Strukturierung eines Vista-Programms. Sichtbarkeitsbereiche werden durch Prozessoren und Netzwerke definiert. Der Sichtbarkeitsbereich eines Prozessors umfaßt das Interface sowie das Interior mit allen Netzwerken und Methoden. Der Sichtbarkeitsbereich eines Netzwerks umfaßt das Netzwerk selbst. Ein Stellvertreter, der in einem Netzwerk enthalten ist, kann deshalb nur Komponenten referenzieren, die im selben Netzwerk bzw. auf Ebene des Prozessors definiert sind. Bild 7-21 zeigt den Tokenfluß für ein Original und zwei Stellvertreter. Das Beispiel ist konstruiert und dient nur der Erläuterung. Die gezeigten Stellvertreter erfüllen keinen sinnvollen Zweck.

221 7.3 Das Programmiermodell 211 Bild Eine Methode des PLP-Prozessors und ihr Aufruf in einem Netzwerk. Das Bild zeigt die öffentliche Methode greenbulbblink des PLP-Prozessors dargestellt mit einem Klassen-Browser der Smalltalk-Umgebung (oben) und ihren Aufruf in einem Netzwerk (unten). Die Methode läßt viermal die grüne Lampe blinken. Die Lampe wird zunächst ausgeschaltet (self greenbulb off) und dann in einer Schleife mit vier Durchläufen im Abstand von 500 ms abwechselnd ein- und ausgeschaltet. Das Netzwerk enthält neben dem PLP-Prozessor den speziellen Prozessor do, mit dem es möglich ist, Smalltalk-Code auszuführen. Bei Eintreffen eines Tokens am Port execute wird die Nachricht greenbulbblink an pedestrianlightsprocessor gesandt, wodurch die gleichnamige Methode aktiviert wird. Weil in Vista alle Methoden dynamisch gebunden sind, wäre es auf diese Weise auch möglich, eine der Standardmethoden von pedestrianlightsprocessor aufzurufen. Beispielsweise könnte Port off mit der Anweisung (pedestrianlightsprocessor portnamed: #off) trigger aktiviert werden.

222 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 212 Bild Original und Stellvertreter. Das Bild zeigt zwei Dialogprozessoren prompter 1 und prompter 2, einen Objektspeicher original und zwei Stellvertreter dieses Objektspeichers mit den Namen alias 1 und alias 2. In der dargestellten Situation wird ein Token, das eine Zahl mit sich führt, von prompter 1 nach original transportiert, wodurch sich die von original gespeicherte Zahl ändert. Diese Änderung führt zu einer Weiterleitung des Tokens an Port changed von original und aufgrund des Rundrufmechanismus auch an Port changed von alias 1. Der Stellvertreter alias 2 wird von der Änderung des Originals nicht berührt, weil der Rundrufmechanismus für alias 2 deaktiviert ist (Symbol ). Eine Aktivierung von alias 2 kann nur durch den direkt angeschlossenen Prozessor prompter 2 erfolgen. Ein Token, das bei Port set von alias 2 eintrifft und eine Änderung der von original gespeicherten Zahl bewirkt, löst allerdings in weiterer Folge ein Token bei Port changed aller drei Prozessoren aus Parallelität Die meisten Programme laufen sequentiell ab. Während der Programmausführung werden die Anweisungen hintereinander ausgeführt, und es ist zu jedem Zeitpunkt klar, welche Anweisung als nächste an die Reihe kommt. In sequentiellen Programmen gibt es nur einen Steuerfluß, der die Aktivierung der Anweisungen bewirkt. Den Steuerfluß zur sequentiellen Ausführung einer Reihe von Anweisungen nennt man Prozeß. Programme, in denen mehrere Steuerflüsse gleichzeitig aktiv sind, d.h. Programme mit mehr als einem Prozeß, heißen parallele Programme. Parallelität kann auf mehreren Ebenen definiert sein. Weinreich [93 S. 61] unterscheidet in Bezug auf objektorientierte Systeme zwischen feingranularer Parallelität auf Ebene von Methoden und Anweisungen und grobgranularer Parallelität auf Ebene von Objekten. Vista unterstützt feingranulare Parallelität, d.h. daß mehrere Prozesse in einem Prozessor aktiv sein können. In Einfachprozessoren können mehrere Methoden gleichzeitig ausgeführt werden, und innerhalb der Methoden einzelne Anweisungen, in Verbundprozessoren einzelne Netzwerke und deren Komponenten. Bild 7-22 zeigt feingranulare Parallelität am Beispiel von zwei Prozessen, die gleichzeitig mehreren Komponenten eines Netzwerks durchlaufen.

223 7.3 Das Programmiermodell 213 Im folgenden wird der Prozeßbegriff schärfer gefaßt, und es werden Mechanismen vorgestellt, die Vista zur Prozeßkommunikation und Prozeßsynchronisation vorsieht. Prozesse Der Prozeßbegriff wird in der Informatik uneinheitlich verwendet. Neben theoretischen Definitionen, die Prozesse als mathematische Abstraktionen der Interaktion zwischen einem System und seiner Umgebung verstehen (vgl. Hoare [85 S. 15]) beziehen sich andere Begriffsbestimmungen auf die konkreten Elemente einer Programmausführung. Tanenbaum [94, S. 34] definiert einen Prozeß als»ein in Ausführung befindliches Programm, einschließlich des aktuellen Wertes des Programmzählers, der Register und der Variablen«. Eine leicht verständliche Erklärung für den Prozeßbegriff findet man bei Rechenberg [94 S. 138 f]: Während des Ablaufs eines sequentiellen Programms gibt es in jedem Augenblick einen einzigen Befehlszähler, der auf den nächsten auszuführenden Befehl zeigt und dadurch den Zustand kennzeichnet, in dem sich das Programm gerade befindet. [...] Es hat sich nun eingebürgert, einen sequentiellen Ablauf, also einen, dessen Zustand durch einen Befehlszähler bestimmt ist, als»prozeß«zu bezeichnen. Ein Prozeß ist also nichts weiter als ein in Ausführung befindliches sequentielles Programm oder sequentielles Teilstück eines parallelen Programms. Dieser Prozeßbegriff ist eigentlich recht einfach, aber leider wird Verwirrung gestiftet, indem man sowohl von»sequentiellen Prozessen«als auch von»parallelen Prozessen«spricht. Beides bedeutet dasselbe. Wer von sequentiellen Prozessen spricht, will betonen, daß ein Prozeß in sich ein sequentieller Ablauf ist, aber die Bezeichnung ist ein Pleonasmus. Wer von parallelen Prozessen spricht, meint den parallelen Ablauf mehrerer in sich sequentieller Prozesse, und das ist vernünftig. Rechenberg erwähnt den Befehlszähler sequentieller Programme und bezieht sich dadurch auf den Steuerfluß eines Von-Neumann-Rechners. Für Datenflußrechner gilt seine Begriffsbestimmung nicht, weil es dort keinen Befehlszähler gibt, sondern die Verfügbarkeit von Daten den Programmfortschritt bestimmt. Eine parallele Ausführung ist bei Datenflußrechnern prinzipiell auf Ebene einzelner Operationen möglich, wodurch der Prozeßbegriff für diese Rechnertypen an Bedeutung verliert bzw. anders interpretiert wird. In Vista ist der Prozeßbegriff einfach bestimmt: Ein Prozeß ist der Fluß eines Tokens von einer Prozeßquelle zu einer Prozeßsenke. Diese Definition gilt sowohl für Signalals auch für Datennetzwerke. Fließen mehrere Tokens zur gleichen Zeit durch die Netzwerke einer Vista-Applikation, dann handelt es sich um parallele Prozesse. Eine Prozeßquelle produziert Tokens. Als Prozeßquellen kommen aktive Signalprozessoren, asynchrone Ports und das Laufzeitsystem in Betracht. Eine Prozeßsenke ist die letzte Komponente auf dem Weg eines Prozesses, die ein Token nicht mehr weiterleitet. Prozeßsenken können das Laufzeitsystem oder die Ausgangsports von Prozessoren und Netzwerken sein. In Signalnetzwerken können sich zwischen Prozeßsenke und Prozeßquelle viele Komponenten befinden. In Datennetzwerken liegt zwischen Prozeßsenke und Prozeßquelle meist nur ein Kanal. Ein Prozeß in Datennetzwerken hat demnach nur die Aufgabe, ein Datentoken von einem Ausgangsport zum nächsten Eingangsport zu transportieren; danach terminiert er. Das heißt, in Datennetzwerken läuft auf jedem Kanal ein Prozeß.

224 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 214 Bild Feingranulare Parallelität in Vista; Farbbild im Anhang. Zwei Prozesse, die durch unterschiedliche Strichlängen und Farben visualisiert sind, bewirken im dargestellten Netzwerk die parallele Ausführung von Einfachprozessoren. In der gezeigten Situation durchlaufen beide Prozesse gleichzeitig die Prozessoren c und e. Die Port execute zugeordnete Methode ist deshalb sowohl bei c als auch bei e gleichzeitig aktiv. Parallele Prozesse laufen in Vista verzahnt ab. Zu einem bestimmten Zeitpunkt ist immer nur ein Prozeß aktiv, während die anderen Prozesse auf ihre Ausführung warten. Der Grund dafür liegt in der Laufzeitumgebung von VisualWorks, die nur quasiparallele Prozesse unterstützt. Bei der Softwareentwicklung mit Vista sind die Einschränkung dieses einfachen Prozeßmodells nicht spürbar, weil Vista das Prozeß- Scheduling übernimmt: Der Programmierer muß sich nicht darum kümmern, die Kontrolle explizit vom aktiven Prozeß auf den ersten wartenden Prozeß zu übergeben. Kon-

225 7.3 Das Programmiermodell 215 zeptionell besteht demnach in Vista kein Unterschied zwischen verzahnt und gleichzeitig ablaufenden Prozessen. Im folgenden wird deshalb immer von Gleichzeitigkeit gesprochen, auch wenn eigentlich Verzahnung gemeint ist. Bild 7-23 zeigt eine Situation, in der drei parallele Prozesse gleichzeitig drei Signalgeneratoren durchlaufen. Prozeßpriorität In Vista besitzt jeder Prozeß eine Priorität, die angibt, welchen Stellenwert der Prozeß gegenüber anderen Prozessen bezüglich der Prozeßausführung hat. Das Prozeß- Scheduling berücksichtigt Prozesse mit hoher Priorität vor jenen mit niedrigerer Priorität. Die möglichen Prozeßprioritäten entsprechen jenen von Smalltalk. Sie sind positive ganze Zahlen zwischen 1 und 100. Kleine Zahlen bedeuten eine niedrige Priorität, große Werte eine hohe Priorität. Bild Parallele Prozesse in Vista; Farbbild im Anhang. Das Bild zeigt drei Signalgeneratoren, an die der asynchrone Port in jeweils ein Token parallel sendet. Die blaue Füllung des Portsymbols weist auf die parallele Weiterleitung hin. Jedes der von in versendeten Tokens wird durch einen eigenen Prozeß transportiert. Die drei Prozesse sind durch drei verschiedene Farben visualisiert. Aufgrund des Eingangstokens an Port generate produziert jeder Signalgenerator sieben neue Signaltokens, die alle von jenem Prozeß transportiert werden, der auch Port generate aktiviert hat. Die Tokens und die an der Tokenweiterleitung beteiligten Ports sind in derselben Farbe dargestellt, wie der zugehörige Prozeß. Die Ausgangsports newsignal versenden Tokens sequentiell, da sie nicht für parallele Tokenversand konfiguriert sind. Wären auch sie als asynchrone Ports konfiguriert, so wären an Stelle von 3 Prozessen insgesamt maximal * 7 = 24 Prozesse parallel aktiv (die tatsächliche Anzahl der gleichzeitig aktiven Prozesse hängt vom Prozeß-Scheduling ab). Die ursprüngliche Priorität eines Prozesses legt die Prozeßquelle fest. In weiterer Folge kann jedes Element, das mit Weiterleitung oder Verarbeitung von Tokens zu tun hat, die Priorität ändern (z.b. Kanäle, Ports und Prozessoren). Solche Elemente werden Token- Handler genannt. Der Programmierer kann Prozeßprioritäten statisch mit einem Dialogfenster oder dynamisch mit Programmcode einzelnen Token-Handlern zuordnen. Pro-

226 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 216 zesse, die diese Token-Handler durchlaufen, erhalten ab ihrem Eintreffen beim jeweiligen Token-Handler die spezifizierte Priorität. Prozeßprioritäten haben nur für Token-Handler in Signalnetzwerken einen Sinn, weil nur dort zeitliche Bedingungen eine Rolle spielen. In Datennetzwerken würde das schnellere Fortschreiten eines Prozesses keine funktionalen Auswirkung haben, weil Datenprozessoren erst dann zu arbeiten beginnen, wenn alle Eingangsports mit Daten versorgt sind, d.h. wenn auch der langsamste Prozeß sein Datentoken abgeliefert hat. Prozeßkommunikation Prozesse arbeiten meist nicht unabhängig voneinander, sondern stehen in Kommunikations- oder Wettbewerbsbeziehungen. Zwei Prozesse kommunizieren, wenn sie Daten austauschen. Sie befinden sich im Wettbewerb, wenn sie zur gleichen Zeit den exklusiven Zugriff auf eine Ressource fordern. Diese beiden Möglichkeiten der Prozeßinteraktion lassen sich anhand von Standardaufgaben aus der parallelen Programmierung gut illustrieren (vgl. Rechenberg [94 S. 148 ff]). Beim Erzeuger-Verbraucher-Problem sind kommunizierende Prozesse beteiligt: ein Prozeß produziert Daten, die ein anderer Prozeß konsumiert. Beim Leser-Schreiber-Problem geht es um konkurrierende Prozesse: Ein Prozeß schreibt Daten, die andere Prozesse lesen. Der schreibende Prozeß darf nicht durch lesende Prozesse unterbrochen werden, weil sonst Inkonsistenzen entstehen könnten, mehrere lesende Prozesse können jedoch gleichzeitig auf die Datei zugreifen. Dieser Abschnitt beschäftigt sich mit Prozessen, die in einer Kommunikationsbeziehung stehen. Konkurrierende Prozesse werden im nächsten Abschnitt behandelt. Alle hier angesprochenen Konzepte beziehen sich ausschließlich auf Signalnetzwerke. In Datennetzwerken gibt es keine Prozeßkommunikation, weil dort Prozesse nur dem Datentransport dienen und die Datenübergabe von einem Prozeß zum anderen nicht durch die Prozesse selbst, sondern durch die Datenprozessoren geschieht. Die Kommunikation zwischen zwei oder mehreren Prozessen kann prinzipiell auf drei Arten erfolgen: über gemeinsam genutzten Speicher, mit Pipes und durch Nachrichtenübertragung (vgl. Mayer [95] S. 20 ff). In weiterer Folge wird nur die Prozeßkommunikation mit Nachrichten betrachtet, weil die anderen Kommunikationsarten in Vista keine Rolle spielen. Der Terminologie von Vista angepaßt, wird die Kommunikation mit Nachrichten als Tokenübertragung bezeichnet. An der Kommunikation sind zwei Prozesse beteiligt: ein Senderprozeß und ein Empfängerprozeß. Der Senderprozeß kopiert die von seinem Token transportierten Daten und sendet die Kopien an den Empfängerprozeß. Dieser nimmt die Daten entgegen und belegt damit sein Token. Übertragen wird demnach nicht das Token selbst, sondern die vom Token mitgeführten Daten. Der Begriff»Tokenübertragung«wird dennoch verwendet, weil»datenübertragung«zu wenig aussagekräftig ist und konzeptionell kein Unterschied darin besteht, ob das Token oder die transportierten Daten übermittelt werden. Die Tokenübertragung kann synchron oder asynchron erfolgen. Bei synchroner Übertragung warten Sender- und Empfängerprozeß aufeinander: Der Senderprozeß wartet bis der Empfängerprozeß empfangsbereit ist, und der Empfängerprozeß wartet, bis der Senderprozeß sendebereit ist. Man spricht in diesem Fall von einem Rendezvous, weil sich beide Prozessoren gewissermaßen an einem Treffpunkt einfinden, um Daten auszutauschen, und jener Prozeß, der zuerst eintrifft, auf den anderen wartet. Bei asynchroner Übertragung muß der Senderprozeß nicht warten, bis der Empfängerprozeß bereit ist,

227 7.3 Das Programmiermodell 217 die gesendeten Daten entgegenzunehmen. Er stellt die Daten in einen Pufferspeicher und läuft sofort weiter. Der Empfängerprozeß kann sie von dort zu einem späteren Zeitpunkt entnehmen. Wenn die Größe des Pufferspeichers begrenzt ist, dann blockiert der Senderprozeß bei vollem Puffer solange, bis der Empfängerprozeß daraus Daten entnimmt. Umgekehrt blockiert der Empfängerprozeß bei leerem Puffer solange, bis der Senderprozeß wieder Daten hineinstellt. Senderprozeß wartet. Empfängerprozeß trifft ein. Beide Prozesse laufen weiter. Bild Prozeßkommunikation mit Hilfe eines Transmitters. Das Bild zeigt drei Stadien einer synchronen Kommunikation zwischen zwei Prozessen, die mit Hilfe eines Transmitter-Prozessors stattfindet. Der Prozessor transmitter besitzt drei Eingangs- und zwei Ausgangsports: Port reset gibt einen eventuell wartenden Prozeß frei und versetzt den Prozessor in den Initialzustand; Port send ist der Eingang für den Senderprozeß; Port receive ist der Eingang für den Empfängerprozeß; Port sent und received sind die korrespondierenden Ausgänge. Der öffentliche Prozessor buffersize gibt die Größe des Kommunikationspuffers an. Kapazität 0 bedeutet ungepufferte, synchrone Kommunikation. Senderprozeß wartet. An Port send trifft der Senderprozeß ein. Er wird von Prozessor transmitter angehalten, weil noch kein Empfängerprozeß eingetroffen ist. Das Symbol bedeutet, daß Port send gesperrt ist und weitere Senderprozesse abweist. Empfängerprozeß trifft ein. An Port receive trifft der Empfängerprozeß ein. Prozessor transmitter überträgt die Daten des Tokens vom Senderprozeß zum Empfängerprozeß. Beide Prozesse laufen weiter. Nach der Datenübertragung können beide Prozesse weiterlaufen. Das Token des Empfängerprozesses transportiert nun dieselben Daten wie das Token des Senderprozesses. In Vista kommt ein einfacher Mechanismus für die Tokenübertragung zum Einsatz: Sowohl für synchrone als auch für asynchrone Übertragung werden Transmitter verwendet, die als Kommunikationskanäle dienen. Transmitter sind Einfachprozessoren mit einem Pufferspeicher und jeweils einem Eingangs- und Ausgangsport für den Sender- und Empfängerprozeß. Die Größe des Pufferspeichers bestimmt die Übertragungsart: eine Kapazität = 0 bewirkt synchrone Übertragung, während eine Kapazität > 0 zu asynchroner Übertragung mit blockierendem Senderprozeß bei vollem Puffer führt. Eine Kapazität = -1 bedeutet eine unbeschränkte Puffergröße, d.h. der Senderprozeß blockiert nie. Der Leserprozeß blockiert in den beiden letztgenannten Fällen bei leerem

228 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 218 Puffer. Bild 7-24 zeigt einen Transmitter, der einen synchronen Kommunikationskanal zwischen zwei Prozessen herstellt. Für asynchrone Prozeßkommunikation müßte man lediglich die Puffergröße ändern. Prozeßsynchronisation Der vorige Abschnitt hat gezeigt, wie kommunizierende Prozesse koordiniert werden können. In diesem Abschnitt geht es um die Prozeßsynchronisation im engeren Sinn, das ist die Koordination konkurrierender Prozesse. In Vista können parallele Prozesse einen Signalkanal zur gleichen Zeit mit Token belegen. Diese Prozesse durchlaufen simultan den Port am Ende des Kanals und in weiterer Folge den zugehörigen Prozessor sowie andere direkt oder indirekt damit verbundenen Prozessoren. Die gleiche Situation liegt vor, wenn an einem Eingangsport mehrere Kanäle angeschlossen sind, auf denen parallele Prozesse aktiv sind. Die simultane Aktivierung einer Kette von Prozessoren ist nicht immer wünschenswert. Wenn eine Prozessorenkette einen kritischen Bereich umfaßt, in dem Wechselwirkungen zwischen Prozessen ausgeschlossen sein sollen, müssen die Prozesse koordiniert ablaufen, d.h. es muß dafür Sorge getragen werden, daß sich zur selben Zeit immer nur ein Prozeß im kritischen Bereich befindet. Kritische Bereiche sind Zugriffsoperationen auf Ressourcen, die Prozesse gemeinsam nutzen, etwa für die Ausgabe auf einen Drucker oder für die Belegung von Speicher (manche Autoren bezeichnen nicht nur die Zugriffsoperationen, sondern auch die gemeinsamen Ressourcen als kritischen Bereich). In kritischen Bereichen sorgt die Prozeßsynchronisation für den gegenseitigen Ausschluß konkurrierender Prozesse. Dazu verwendet man meist spezielle Variablen, die Semaphore heißen. Vista stellt Semaphore in anschaulicher Art als kleine Ampeln dar, die Grün oder Rot zeigen. Eine grüne Ampel bedeutet»kritischer Bereich frei«, eine rote Ampel»kritischer Bereich belegt«. Ein Prozeß, der auf eine grüne Ampel stößt, kann den kritischen Bereich betreten. Sobald dies geschehen ist, schaltet Vista die Ampel auf Rot und der nächste Prozeß muß warten, bis der kritische Bereich wieder frei ist, d.h. die Ampel Grün zeigt. Semaphore können für jeden Token-Handler in Signalnetzwerken aktiviert werden, d.h. für Kanäle, Ports, Prozessoren und Netzwerke selbst. Zur Aktivierung selektiert der Programmierer einen Token-Handler und wählt aus einem Dialogfenster die entsprechende Option. Naheliegend ist der Einsatz von Semaphoren an Eingangsports, wie Bild 7-25 zeigt. Prozesse in Datennetzwerken brauchen nicht explizit durch Semaphore koordiniert zu werden, weil dort die Synchronisation implizit durch den Ausführungsmechanismus geschieht. Abschließend soll gezeigt werden, daß man in Vista nicht auf die eingebauten Mechanismen zur Prozeßsynchronisation beschränkt ist, sondern daß man für besondere Zwecke Spezialprozessoren bauen kann, mit denen Prozeßsynchronisation auf höherer Ebene möglich ist. Ein Beispiel dafür ist der Semaphor-Prozessor. Dieser Prozessor realisiert ein steuerbares Semaphor, das kontrolliert geschaltet werden kann. Während die in Vista eingebauten Semaphore von außen nicht steuerbar sind, sondern zwangsweise auf Rot schalten, wenn ein Prozeß eintrifft und auf Grün, wenn dieser Prozeß den kritischen Bereich wieder verläßt, kann der Semaphor-Prozessor programmgesteuert von Grün auf Rot geschaltet werden. Bild 7-26 zeigt, wie das funktioniert. Für die Implementierung

229 7.3 Das Programmiermodell 219 des Semaphor-Prozessors benötigt man nur etwa 20 Smalltalk-Anweisungen. Unsynchronisierter Prozeßablauf Prozeßsynchronisation mit einem Semaphor Bild Prozeßsynchronisation durch Semaphore; Farbbild im Anhang. Das Bild zeigt einen Zeitgeber ticking timer, der sieben Sekunden lang jede Sekunde ein Token emittiert, einen damit verbundenen Prozessor do, der den Smalltalk-Code self wait: 2 ausführt, wodurch der aktuelle Prozeß für zwei Sekunden angehalten wird, und einen Tongeber speaker, den die eintreffenden Tokens ein- und ausschalten. Der kritische Bereich umfaßt die Prozessoren do und speaker. Unsynchronisierter Prozeßablauf. Port triggered des Prozessors ticking timer erzeugt in Sekunde 1 den ersten Prozeß, der im Bild violett dargestellt ist. Dieser Prozeß transportiert das Token nach Port execute von do. Das Token wird von do zwei Sekunden verzögert, läuft in Sekunde 3 zu Port on von speaker und danach zu Port off, bevor es über Port out das Netzwerk verläßt. Während das Token des ersten Prozesses noch bei execute wartet, trifft in Sekunde 2 das Token des zweiten Prozesses ein, in Sekunde 3 das dritte usw. Prozessor do verzögert die Weiterleitung dieser Tokens ebenfalls um zwei Sekunden und läßt sie danach im ursprünglichen Sekundenabstand weiterlaufen. Der Tongeber wird demnach nicht in Abständen von zwei Sekunden ein- und ausgeschaltet, wie man vermuten könnte, sondern jede Sekunde. In der dargestellten Situation sind sieben Prozesse gleichzeitig aktiv. Das Bild zeigt die Tokens von vier Prozessen, die Tokens der restlichen drei Prozesse sind nicht sichtbar, weil sie sich im Inneren von do oder speaker befinden. Prozeßsynchronisation mit einem Semaphor. An Port execute von do ist ein Semaphor aktiviert (Ampelsymbol im schwarzen Kreis). In (2) zeigt dieses Semaphor Grün, was bedeutet, daß das Token des ersten eintreffenden Prozesses den Prozessor do durchlaufen kann. In dem Moment, wo dieses Token bei Port execute eintrifft, schaltet das Semaphor auf Rot und blockiert alle weiteren Prozesse. Diese Situation ist in (3) dargestellt. Das Token des ersten Prozesses ist bereits auf dem Weg nach out, während die Tokens anderen Prozesse bei execute warten. Der Tongeber speaker wird dadurch exakt im Abstand von zwei Sekunden ein- und ausgeschaltet.

230 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 220 Halt Warten Frei Bild Weiter Semaphor-Prozessor zur programmgesteuerten Aktivierung eines Semaphors. Der Semaphor-Prozessor realisiert ein Semaphor, das durch das Programm gesteuert werden kann. Er besitzt vier Eingangsports und einen Ausgangsport: Port reset versetzt den Prozessor in den Initialzustand; Port in besitzt ein Semaphor und ist der Eingang für den zu kontrollierenden Prozeß; Port go schaltet das Semaphor von in auf Grün; Port stop schaltet es auf Rot; Port out ist der Ausgang für den an Port in anliegenden Prozeß. Halt: an Port stop trifft ein Prozeß ein, der das Semaphor auf Rot schaltet. Warten: an Port in trifft der zu kontrollierende Prozeß P ein. P muß warten. Frei: an Port go trifft ein Prozeß ein, der das Semaphor auf Grün schaltet. Weiter: Prozeß P durchläuft den Semaphor-Prozessor, weshalb Vista das Semaphor automatisch auf Rot schaltet. Ein jetzt an Port in eintreffender Prozeß muß warten bis P das Netzwerk verlassen hat. Sobald P das Netzwerk verläßt, schaltet Vista das Semaphor wieder auf Grün.

231 7.4 Spezialisierung und Konfiguration Spezialisierung und Konfiguration Softwarekomponenten haben den Vorteil, daß der Benutzer ihren Aufbau nicht zu kennen braucht. Er verwendet sie im allgemeinen als Black-Box und ist nur an der Schnittstelle, aber nicht an der Implementierung interessiert. In manchen Fällen ist es jedoch notwendig, Komponenten an ihre Aufgaben in einer bestimmten Umgebung anzupassen. Solche Anpassungen können durch den Komponentennutzer oder durch den Komponentenentwickler vorgenommen werden. Für Komponentennutzer sind Prototypen und Substitution vorgesehen, für Komponentenentwickler stellt Vista den Mechanismus der Vererbung zur Verfügung. Die Fähigkeit von Komponenten zur Selbstmodifikation während der Ausführung kann vom Komponentenentwickler für dynamische Anpassungen an spezielle Laufzeitbedingungen genutzt werden Prototypen In den meisten objektorientierten Programmiersprachen, wie C++, Eiffel und Smalltalk, beschreiben Klassen die Struktur und das Verhalten von Objekten. In diesen Sprachen sind Objekte strikt an die definierende Klasse gebunden: Kein Objekt kann in Struktur oder Verhalten (d.h. in seinen Exemplarvariablen oder Methoden) von anderen Objekten derselben Klasse abweichen. Die Inhalte der Exemplarvariablen können sich wohl unterscheiden, nicht aber ihre Anzahl, ihre Bezeichnung und (in statisch typisierten Sprachen) ihr Typ. Eine Änderung von Struktur und Verhalten ist nur bei der Klasse möglich und betrifft alle Objekte, die dieser Klasse zugeordnet sind. Exemplarbasierte Modifikationen Klassen gewährleisten die Einheitlichkeit der Objekte und begünstigen Überschaubarkeit, Verständnis und Sicherheit objektorientierter Programme. In manchen Fällen kann es jedoch notwendig sein, Modifikationen an Struktur und Verhalten eines bestimmten Objekts vorzunehmen, um das Objekt an seine Aufgabe bestmöglich anzupassen. Klassenbasierte Ansätze bieten diese Flexibilität nicht, weil sie nur generelle aber nicht kontextabhängige Modifikationen erlauben. Änderungen der Eigenschaften einzelner Objekte werden in weiterer Folge exemplarbasierte Modifikationen genannt im Unterschied zur klassenbasierten Modifikationen in herkömmlichen objektorientierten Programmiersprachen. Dazu ein Beispiel für den in diesem Kapitel bereits öfters erwähnten PLP-Prozessor. Angenommen, ein bestimmter PLP-Prozessor soll während der Grünphase einen kontinuierlichen Signalton aussenden, um sehbehinderten Personen die Grünphase akustisch anzuzeigen. Mit einer klassenbasierten Programmiersprache kann diese Funktionalität auf zwei Arten realisiert werden: (1) man bildet eine neue Unterklasse von PLP- Prozessor und überschreibt die Methode walk, die für die Steuerung der Grünphase zuständig ist; (2) man definiert ein boolesches Attribut isacousticplp, das angibt, ob es sich um einen einfachen oder akustischen PLP-Prozessor handelt und durchläuft in walk zwei verschiedene Programmpfade, je nachdem, ob isacousticplp gesetzt ist oder nicht. In Vista sind solche vergleichsweise aufwendigen Konstruktionen nicht notwendig. Es genügt, im Netzwerk walknet des zu adaptierenden PLP-Prozessors einen Tongeber einzubauen (siehe Bild 7-27). Dieser Tongeber wird nur für den adaptierten PLP-

232 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 222 Prozessor wirksam. Andere PLP-Prozessoren sind davon nicht betroffen und funktionieren wie bisher. Ein anderes Beispiel, wo exemplarbasierte Modifikationen sinnvoll sind, ist das Testen eines bestimmten Objekts. Eine häufige Aktion beim Testen ist das Setzen eines Haltepunktes in einer Methode, um beim Erreichen des Haltepunktes den Programmablauf zu unterbrechen. In VisualWorks wirkt sich der Haltepunkt auf alle Objekte aus, denen die Methode zugeordnet ist. Das kann bei Methoden von Basisobjekten zu einer Systemverklemmung führen, weil grundlegende Mechanismen nicht mehr funktionieren. So würde etwa ein Haltepunkt in der Methode für das Zeichnen von Fensterinhalten alle Fenster deaktivieren, einschließlich des Fensters für den Debugger, wodurch das System unbedienbar wird. Um das zu vermeiden, muß es möglich sein, den Haltepunkt nur für interessierende Objekte zu setzen, was exemplarbasierte Modifikation voraussetzt. Bild Exemplarbasierte Modifikation des Netzwerks walknet des PLP-Prozessors. Das Bild zeigt das Netzwerk walknet des PLP-Prozessors aus Bild 7-16, S. 205, das um einen Tongeber erweitert wurde, der während der Grünphase ein akustisches Signal aussendet. Prototypbasierte Programmiersprachen Die für manche Problemstellungen zu starren Mechanismen klassenbasierter Programmiersprachen führten zu Überlegungen, wie Objekterzeugung und Vererbung flexibler

233 7.4 Spezialisierung und Konfiguration 223 gestaltet werden könnten und welche Mechanismen zur dynamischen Veränderung von Struktur und Verhalten geeignet sind. Das Ergebnis waren prototypbasierte Programmiersprachen. Lieberman [86] prägte den Begriff Prototyp für Objekte, die als Schablonen zur Erzeugung neuer Objekte dienen und den Begriff Delegation für den Mechanismus zur gemeinsamen Nutzung von Struktur und Verhalten mehrerer Objekte. Prototypen ersetzen Klassen, Delegation macht die Vererbung flexibler. Eine bekannte Programmiersprache, die auf Prototypen und Delegation beruht, ist Self von Ungar und Smith [87]. Ein besonderes Merkmal von Self sind die dynamischen Mutationsmöglichkeiten von Objekten. Jedes Objekt in Self kann zur Ausführungszeit seine Vererbungsbeziehung, seine Struktur und sein Verhalten ändern. Dadurch wird beim Programmentwurf große Flexibilität gewonnen, allerdings um den Preis von Sicherheit und Verständlichkeit. Weinreich [93 S. 22] vergleicht die Verwendung von Prototypen und Delegation deshalb mit der Verwendung von Goto-Anweisungen und sieht darin eher eine Rückwärtsentwicklung als einen Fortschritt in der objektorientierten Programmierung. Manche objektorientierten Sprachen, wie Omega von Blaschek [94] oder Klassenbibliotheken wie ET++ von Weinand et al. [89], stellen ebenfalls Prototypen zur Verfügung, jedoch ohne das Klassenkonzept aufzugeben. Bei diesen Ansätzen gibt es zu jeder Klasse ein initialisiertes Objekt, von dem weitere Objekte derselben Klasse durch Kopieren erzeugt werden. Die Autoren bezeichnen das als»kopiervorlage«dienende Objekt als Prototyp. Mit Prototypen dieser einfachen Art sind zwei Vorteile verbunden: (1) neue Objekte sind nach ihrer Erzeugung automatisch initialisiert und (2) an den Prototyp können weil er ein Objekt ist Anfragen über die Eigenschaften seiner Klasse gestellt werden, falls er entsprechend modelliert ist. Die Anfragemöglichkeit ist vor allem für Programmiersprachen wie C++ interessant, wo Klassen keine Objekte sind und somit auch nicht auf Nachrichten reagieren können. Der Flexibilitätsgewinn ist durch diesen eingeschränkten Ansatz allerdings gering, verglichen mit den Möglichkeiten, die Prototypen bieten, wie sie in Self zum Einsatz kommen. An dieser Stelle sei darauf hingewiesen, daß die prototyping-orientierte Softwareentwicklung begrifflich nichts mit Prototypen der objektorientierten Programmierung zu tun hat. Die prototyping-orientierte Softwareentwicklung ist ein Vorgehensmodell, während Prototypen ein technisches Konzept sind. Prototypen unterstützen jedoch sehr wohl die prototyping-orientierte Vorgehensweise, weil ihre Flexibilität schnelle Anpassungen der Programmfunktionalität erlaubt. In Vista kommt dies besonders deutlich zum Ausdruck. Wie das zuvor erwähnte Beispiel des akustischen PLP-Prozessors zeigt, ermöglichen die exemplarbasierten Modifikationsmöglichkeiten von Vista die rasche Umsetzung von ad-hoc formulierten Anforderungen, wie sie für prototyping-orientierte Softwareentwicklung typisch sind. Das System reagiert durch seine»lebendigkeit«sofort auf Veränderungen und läßt diese Reaktionen an der Benutzungsschnittstelle unmittelbar wirksam werden. Prototypen und Klassen in Vista Vista stellt Prototypen zur Verfügung, die flexibler sind als Prototypen von Omega und ET++, jedoch eine geringere Wandelbarkeit aufweisen als jene in Self. Das Konzept des Prototypen gibt es in Vista nur für Verbundprozessoren. Struktur und Verhalten von Einfachprozessoren sind durch die zugehörige Klasse festgelegt und nur durch deren Redefinition modifizierbar.

234 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 224 Der Ur-Prototyp einer bestimmte Prozessorklasse wird durch interaktive Konstruktion eines Verbundprozessors erzeugt. Vista generiert daraus eine Smalltalk-Klasse, die zum einen die Vererbungsbeziehung festlegt (siehe nächster Abschnitt) und zum anderen Beschreibungen der Prozessorkomponenten enthält (siehe Bild 7-28). Sobald die Prozessorklasse generiert ist, kann der Ur-Prototyp freigegeben werden, da seine Eigenschaften durch die Klasse vollständig definiert sind. Neue Prozessoren können nun entweder durch die beschreibende Klasse erzeugt werden oder durch Kopieren eines bereits existierenden Prozessors, der als Prototyp dient. Wenn man eine Klasse zur Prozessorerzeugung verwendet, so hat der neue Prozessor die Eigenschaften des Ur- Prototypen; beim Kopieren eines existierenden Prozessors werden dessen Eigenschaften eins-zu-eins übernommen. Die übernommenen Eigenschaften betreffen nicht nur die logische Struktur, sondern alle Attribute des Prozessors. Dazu gehören die visuelle Darstellung, der aktuelle Zustand aller privaten Prozessoren, Haltepunkte in Netzwerke usw. Lediglich Prozesse werden nicht übernommen, d.h. wenn sich zum Zeitpunkt der Kopieroperation, ein Token auf den Weg durch den Prototypen befindet, so werden das Token und der zugehörende Prozeß nicht kopiert. Nach der Erzeugung ist ein Prozessor bezüglich seiner Struktur und des durch Netzwerke definierten Verhaltens völlig unabhängig von der erzeugenden Instanz. Diese Bereiche können beliebig modifiziert werden, ohne daß dies Auswirkungen auf andere Prozessoren hätte. Öffentliche und private Methoden sind jedoch immer an die Klasse gebunden, d.h. die Änderung einer Prozessormethode betrifft alle Prozessoren dieser Klasse. Eine Änderung der Methodenzuordnung würde massive Änderungen von VisualWorks nach sich ziehen, was nicht nur mit großen Laufzeitverlusten verbunden wäre, sondern auch die Integration von Vista und VisualWorks beeinträchtigen würde. Aus dem gleichen Grund können auch Vererbungsbeziehungen nicht geändert werden. Ein Prozessor erbt immer von jener Klasse, von der auch der Ur-Prototyp erbt. Ein Prozessor kann jederzeit zur Neugenerierung der ihm zugeordneten Klasse verwendet werden: Wenn sich während der Programmentwicklung herausstellt, daß die Eigenschaften eines Prozessors P für alle Prozessoren der Klasse von P gelten soll, dann kann der Programmierer die Klasse (oder Teile davon) mit P als Vorlage neu erzeugen. P wird damit zum neuen Ur-Prototyp. Dies bedeutet jedoch nicht, daß bestehende Exemplare von der Klassenänderung berührt sind. Lediglich die von der neu generierten Klasse erzeugten Prozessoren besitzen die Eigenschaften von P. Sollen auch bestehende Prozessoren die Attribute von P übernehmen, so muß dies manuell veranlaßt werden: Der Programmierer selektiert dazu den zu aktualisierenden Prozessor und wählt die Operation Revert. Interface und Interior des selektierten Prozessors werden daraufhin durch Kopien der entsprechenden Komponenten des Ur-Prototypen ersetzt. Eine automatische Aktualisierung ist deshalb nicht möglich, weil durch die Reversion eventuell Kanäle und Stellvertreter betroffen sind, was eine individuelle Anpassung an die neue Situation erfordern kann. Der mit dem Prototypenkonzept von Vista beschrittene Mittelweg zwischen der großen Flexibilität von Self und der vergleichsweisen Starrheit von Smalltalk verspricht adäquate Designmöglichkeiten insbesondere für reaktive Systeme, die wegen der starken Wechselwirkung mit ihrer Umgebung oftmals selektive Anpassungen erfordern. Eine abschließende Beurteilung des mit Vista verfolgten Ansatzes ist allerdings erst nach der Implementierung größerer Applikationen möglich.

235 7.4 Spezialisierung und Konfiguration 225 Bild Klasse des PLP-Prozessors. Das Bild zeigt einen Ausschnitt aus der Klasse des PLP-Prozessors dargestellt mit einem Klassen- Browser der Smalltalk-Umgebung. Ausgewählt ist eine Klassenmethode, die das Netzwerk walknet beschreibt. Die Beschreibung umfaßt sowohl die logische Struktur als auch die visuelle Darstellung. Bei der Erzeugung eines neuen PLP-Prozessors wird für jede Prozessorkomponente die entsprechende Klassenmethode aufgerufen und damit die entsprechende Komponente generiert. Sobald die Komponente existiert, ist sie unabhängig von ihrer Beschreibung. Man beachte den Unterschied zu Bild 7-20, S Während Bild 7-20 die Methoden eines Prozessorexemplars zeigt (Auswahlfeld instance) sind hier die Methoden der Prozessorklasse ausgewählt (Auswahlfeld class links oben). Die Methoden für den Zugriff auf Netzwerke in Bild 7-20 liefern nicht die Beschreibung der Netzwerke, sondern die Netzwerke selbst Substitution Zwischen Funktionalität und Flexibilität einer Softwarekomponente besteht meist ein enger Zusammenhang: je höher die Funktionalität, desto geringer die Flexibilität. Diese Beziehung ergibt sich daraus, daß hohe Funktionalität oft auch hohe Spezialisierung bedeutet. Die Schnittstelle einer Spezialkomponente ist breit und die Kopplung mit anderen Komponenten ist stark. Dies schränkt die Kombinationsmöglichkeiten ein (siehe auch Abschnitt»Kommunikation zwischen Prozessoren«, S. 184). In Vista wird mit dem Mechanismus der Substitution ein Kompromiß versucht: Maßgeschneiderte Funktionalität und hohe Flexibilität sollen sich nicht ausschließen, sondern gemeinsam nutzbar sein. Substitution bedeutet, daß interne Komponenten eines Prozessors durch Komponenten mit kompatibler Schnittstelle ersetzt werden können, ohne dabei die Kapselung zu verletzen, die Schnittstelle zu erweitern oder die Kopplung zu verstärken. Substitution rea-

236 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 226 lisiert die bei komponentenbasierter Softwareentwicklung angestrebten Steckverbindungen und bietet zusätzlich die aus der objektorientierten Programmierung bekannten Konzepte des Polymorphismus und der abstrakten Klassen. Damit ist es möglich Frameworks zu bauen, die gemeinsame Struktur und gemeinsames Verhalten von Prozessoren eines bestimmten Anwendungsbereiches in Generalisierungen fassen, die einen hohen Grad an Wiederverwendbarkeit aufweisen. Ersetzbare Komponenten müssen als öffentliche Prozessoren definiert sein (siehe Abschnitt»Interface«, S. 193). Sie gehören abstrakten oder konkreten Prozessorklassen an. Prozessoren abstrakter Klassen weisen unimplementierte Operationen auf und müssen durch Prozessoren konkreter Klassen ersetzt werden, um den umschließenden Prozessor funktionsfähig zu machen (abstrakte Prozessorklassen werden im nächsten Abschnitt erläutert). Substitution ist mit dem Austausch eines Hardware-Chips auf einer Elektronikplatine vergleichbar. In Signalnetzwerken können damit die Reaktionen eines Prozessors auf Signale modifiziert werden. In Datennetzwerke kann durch Substitution der Transformationssprozeß geändert werden. Prozessoren in Datennetzwerken, die über öffentliche Prozessoren verfügen, entsprechen Funktionen zweiter Ordnung, das sind Funktionen, die Funktionen als Parameter akzeptieren. Sie gleichen damit den Softwareplatinen in VisaVis (siehe S. 150). Substitution kann entweder statisch oder dynamisch erfolgen. Statische Substitution geschieht, wenn ein Programmierer einen Prozessor an die Anforderungen einer bestimmten Umgebung anpaßt. Dabei substituiert er einen oder mehrere öffentliche Prozessoren durch Prozessoren, die diesen Anforderungen genügen. Er verwendet dazu Drag-und- Drop oder schreibt den Namen des Substituts zwischen die eckigen Klammern hinter den Namen des öffentlichen Prozessors (siehe Bild 7-29). Öffentlichen Prozessoren, die Objektspeicher sind, kann ein Smalltalk-Ausdruck zugewiesen werden, der den gespeicherten Wert repräsentiert. Dynamische Substitution geschieht während der Ausführung einer Vista-Applikation. Sie funktioniert im Prinzip wie die statische Substitution, erfolgt jedoch nicht manuell, sondern durch das Senden einer Nachricht, an jenen Prozessor, dessen öffentlicher Prozessor zu ersetzen ist. Die Nachricht trägt denselben Namen wie der öffentliche Prozessor und der einzige Parameter der Nachricht ist das Substitut. Als Substitute eines Prozessors sind alle Prozessoren seiner Klasse oder einer Unterklasse geeignet. Bei statischer Substitution nimmt Vista im allgemeinen sofort eine entsprechende Typprüfung vor und bricht den Substitutionsvorgang bei Typverletzungen ab. Bei dynamischer Substitution oder statischer Substitution eines Objektspeichers mit einem Smalltalk-Ausdruck basiert die Typprüfung auf den Mechanismen von Smalltalk. Typverletzungen können deshalb erst bei der Aktivierung des Substituts entdeckt werden.

237 7.4 Spezialisierung und Konfiguration 227 Bild Substitution von öffentlichen Prozessoren. Das Bild zeigt Prozessor PLP zur Steuerung einer Fußgängerampel sowie die Prozessoren blinkingbulb und bulb, die mit den Lampen der Ampel verbunden sind. Darunter ist das Netzwerk staynet von PLP zu sehen. PLP hat drei öffentliche Prozessoren durationwalk, greenbulb und redbulb. Prozessor durationwalk ist ein Objektspeicher, dem die Zahl 5 zugewiesen wird. Die Prozessoren greenbulb und redbulb werden durch blinkingbulb und bulb substituiert. Diese Prozessoren unterscheiden sich dadurch, daß blinkingbulb vor Abschaltung viermal blinkt, während bulb sofort zu leuchten aufhört. Weil der Prozessor blinkingbulb von einer Unterklasse des Prozessors bulb stammt, ist diese Substitution erlaubt. Im Netzwerk staynet sind die zu ersetzenden Prozessoren zu sehen. Es sind dies Stellvertreter der öffentlichen Prozessoren. Das Netzwerk wurde in dieser Form vom Programmierer des Prozessors PLP erstellt. Zum Konstruktionszeitpunkt mußte nicht darauf geachtet werden, durch welche Prozessoren greenbulb und redbulb später substituiert würden. Durch den Polymorphismus kommen alle Prozessoren in Betracht, die mit greenbulb und redbulb typkompatibel sind, und dazu gehört eben auch blinkingbulb. Die Zuweisung der Farben Grün und Rot geschieht durch Substitution von öffentlichen Prozessoren der Prozessoren blinkingbulb und bulb, wird hier aber nicht gezeigt.

238 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Vererbung Prozessoren sind in Klassenhierarchien angeordnet, die Teil des Smalltalk- Klassenbaums sind. Die Wurzelklasse der Einfachsignalprozessoren ist die Klasse SimpleSignalProcessor, die Wurzelklasse der Verbundsignalprozessoren ist die Klasse CompoundSignalProcessor. Für Datenprozessoren gibt es analoge Hierarchien. Eine Prozessorklasse vererbt alle Elemente eines Prozessors an ihre Unterklassen. Dazu gehören das Interface mit Ports, öffentlichen Prozessoren und öffentlichen Methoden sowie das Interior mit Netzwerken, privaten Prozessoren und privaten Methoden. Bild 7-30 zeigt einen Ausschnitt aus der Vererbungshierarchie für Einfachsignalprozessoren. Vererbung von Ports und Prozessoren Zur Vererbung von Prozessorelementen verwendet Vista den Vererbungsmechanismus von Smalltalk. Dieser arbeitet klassenbasiert und unterstützt einfache Vererbung. Die Möglichkeit der Verwendung des Smalltalk-Mechanismus für die Vererbung von Methoden liegt auf der Hand. Für die Vererbung von Ports sowie öffentlichen und privaten Prozessoren kann deshalb auf Smalltalk zurückgegriffen werden, weil die Beschreibungen dieser Elemente ebenfalls als Smalltalk-Methoden vorliegen. Nachrichten, die sich auf diese Elemente beziehen, werden vom Smalltalk-Laufzeitsystem automatisch an die richtige Methode gebunden. Bild 7-31 zeigt zwei Spezialisierungen des Einfachprozessors Timer mit Ports und Methoden. Vererbung von Netzwerken Wie im vorigen Abschnitt über Prototypen erläutert, können die Netzwerke jedes Prozessorexemplars individuell modifiziert werden, ohne daß dadurch andere Netzwerke betroffen wären. Prozessoren können deshalb die Netzwerkbeschreibungen des Ur- Prototypen bei der Prozessorklasse (siehe Bild 7-28, S. 228) nicht verwenden und somit auch nicht erben. Weil Netzwerke exemplarbasiertes Verhalten definieren, müssen alle Netzwerke einer Vererbungshierarchie beim jeweiligen Prozessorexemplar gehalten werden. Es genügt auch nicht, nur jene Netzwerke beim Prozessor abzulegen, die gegenüber dem Ur-Prototypen verändert wurden, weil einerseits die Komponenten eines Netzwerkes bei der Ausführung kontextabhängige Zustände annehmen (z.b. beim Countdown eines Zeitgebers) und andererseits sich manche Komponenten direkt auf den zugehörigen Prozessor beziehen (z.b. Stellvertreter von privaten Prozessoren). Der Vererbungsmechanismus für Smalltalk-Methoden konnte aus diesen Gründen nicht für Netzwerke übernommen werden, sondern erforderte eine spezielle Implementierung. Bild 7-32 zeigt, wie das Netzwerk walknet aus Bild 7-27, S. 225, realisiert werden kann, wenn statt exemplarbasierter Modifikation eine funktionale Erweiterung durch Unterklassenbildung vorgenommen wird.

239 7.4 Spezialisierung und Konfiguration 229 Bild Vererbungshierarchie für Einfachsignalprozessoren. Das Bild zeigt einen Ausschnitt aus der Vererbungshierarchie für Einfachsignalprozessoren, dargestellt durch den Hierarchie-Browser von Vista. Gleichartige Ansichten existieren für Verbundsignalprozessoren und Einfach- bzw. Verbunddatenprozessoren. Für jede Prozessorklasse in der Vererbungshierarchie kann ein Menü aktiviert werden, das Operationen zur Bearbeitung der ausgewählten Klasse enthält.

240 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 230 countdownaction: seconds (seconds <= 0) iftrue: [ ^self expired trigger ]. self countdownprivate: seconds. countdownprivate: seconds self countdown lock. process := [ self waitfor: seconds. self countdown unlock. self expired trigger ] newprocess. Process resume. waitfor: seconds (SmalltalkDelay forseconds: seconds) wait. waitfor: seconds 1 to: seconds do: [ :s super waitfor: 1. self ticked triggerwith: seconds - s ]. countdownprivate: seconds self countdown lock. self waitfor: seconds. self countdown unlock. self expired trigger. Bild Spezialisierungen der Prozessorklasse Timer. Die Prozessorklasse Timer hat zwei Unterklassen: TickingTimer und Delay. Prozessoren der Klasse TickingTimer verfügen über einen zusätzlichen Port ticked, der während des Countdowns zu jeder Sekunde ein Token emittiert. Diesem Token wird die verbleibende Zeit als Wert mitgegeben. Prozessoren der Klasse Delay verfügen über dieselbe Schnittstelle, wie jene der Klasse Timer. Das Versenden eines Tokens am Port expired erfolgt jedoch synchron zum Empfang eines Tokens am Port countdown, d.h. es wird kein neuer Prozeß erzeugt. Dadurch wird der den Countdown auslösende Prozeß während des Countdowns blockiert. Man beachte, daß das Symbol, das aktive Prozessoren kennzeichnet, bei Delay nicht gezeigt wird, weil die Implementierung von docountdown aus Delay einen passiven Prozessor macht. Die obere Bildhälfte zeigt die Basisklasse Timer mit den Methoden countdownaction, countdownprivate und waitfor. Die öffentliche Methode countdownaction wird ausgeführt, wenn am Port countdown ein Token eintrifft (siehe auch Bild 7-13, S. 198, das diese Methode ohne Optimierung hinsichtlich der Vererbung zeigt). Die private Methode countdownprivate definiert den eigentlichen Countdown-Prozeß. Sie wird in Delay überschrieben, weil dort kein Prozeß zu erzeugen ist, sondern bloß gewartet werden muß. Die private Methode waitfor enthält den Code für den Wartevorgang. Sie wird in TickingTimer überschrieben, weil dort jede Sekunde ein Token zu emittieren ist. Man beachte den Aufruf super waitfor: 1, mit dem für das einsekündige Warten auf die Implementierung von Timer zurückgegriffen wird.

241 7.4 Spezialisierung und Konfiguration 231 Bild Vererbung von Netzwerken. Das im Bild oben gezeigte Netzwerk walknet gehört zur Prozessorklasse AcousticPLP, die eine Unterklasse von PLP ist. Unten im Bild ist das Hierarchy Tool von Vista zu sehen, das Vererbungshierarchien von Verbundprozessoren anzeigt. Die durchgestrichenen Klassen werden im rechts dargestellten Interior-Fenster nicht berücksichtigt. Die Netzwerkliste zeigt beide Implementierung von walknet. Zwei Pfeile weisen auf die Vererbungsbeziehung hin. Die Implementierung von walknet in AcousticPLP bedient sich der Implementierung von walknet in PLP. Dies entspricht in etwa dem Aufruf einer Smalltalk-Methode über die Pseudovariablen super.

242 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 232 Abstrakte Prozessorklassen Vererbung ist ein ausgezeichnetes Mittel zur Konstruktion abstrakter Prozessorklassen. Abstrakte Prozessorklassen definieren gemeinsame Teile von Interface und Interior ähnlicher Prozessoren und vererben diese an ihre Unterklassen. Jene Operationen, deren Funktionsweise für alle Unterklassen gleich ist, werden in der abstrakten Prozessorklasse implementiert. Für Operationen, die in den Unterklassen unterschiedlich zu realisieren sind, erfolgt die Implementierung in den konkreten Prozessorklassen, die von der abstrakten Prozessorklasse abgeleitet sind. Die Definition der Operationsschnittstelle geschieht jedoch ebenfalls in der abstrakten Prozessorklasse. Die Verwendung von abstrakten Prozessorklassen hat den Vorteil, daß die Schnittstellen aller konkreten Prozessorklassen mindestens jene Komponenten umfassen, die in der abstrakten Prozessorklasse definiert sind. Bei der Konstruktion von Prozessoren kann man sich auf diese Standardschnittstelle stützen, ohne sich auf einen bestimmten Prozessortyp festlegen zu müssen. Dazu verwendet man an jenen Stellen in Netzwerken, die flexibel sein sollen, Exemplare von abstrakten Prozessorklassen (abstrakte Prozessoren) und verbindet ihre Ports mit anderen Prozessoren genauso als wären sie konkrete Prozessoren. Damit ein Netzwerk mit abstrakten Prozessoren funktionieren kann, müssen die abstrakten Prozessoren vor der Aktivierung des Netzwerks durch konkrete Prozessoren ersetzt werden. Die Ersetzung kann durch den Substitutionsmechanismus (siehe Abschnitt»Substitution«, S. 228) entweder statisch oder dynamisch erfolgen. Ein Beispiel für eine abstrakte Prozessorklasse ist AlarmDevice zur Steuerung eines Alarmgebers. Die Schnittstelle und Logik zur Aktivierung und Deaktivierung des Alarmgebers ist in AlarmDev definiert, die Anbindung an eine optische oder akustische Einheit erfolgt in konkreten Unterklassen (siehe Bild 7-33). Bild Abstrakte und konkrete Prozessorklassen. Die abstrakte Prozessorklasse AlarmDevice hat zwei konkrete Unterklassen: Flash und Speaker. Beide Unterklassen weisen dieselbe Portschnittstelle auf, repräsentieren jedoch unterschiedliche Alarmgeber. Flash läßt ein Fenster am Bildschirm blinken, während Speaker über Lautsprecher des Computers Pieptöne abgibt.

243 7.4 Spezialisierung und Konfiguration Selbstmodifikation Ein besonderes Merkmal von Prozessoren ist die Fähigkeit, ihre Netzwerke während der Programmausführung selbsttätig zu ändern. Diese Möglichkeit wird Selbstmodifikation genannt. Die Fähigkeit zur Selbstmodifikation ergibt sich aus zwei Gründen: (1) alle an der Ausführung eines Netzwerks beteiligten Komponenten sind Objekte, die dynamisch zueinander in Beziehung gesetzt werden können. Für herkömmlichen Programmcode gilt dies nicht. Dieser ist nach der Übersetzung in Maschinencode nicht mehr modifizierbar. (2) Prozessoren sind als Prototypen realisiert. Änderungen des Verhalten eines bestimmten Prozessors haben keine Auswirkungen auf andere Prozessoren derselben Klasse. Mit Selbstmodifikation können automatische Optimierungen eines Prozessors erreicht werden. Abhängig von den Gegebenheiten einer bestimmten Programmausführung kann ein Prozessor neue Komponenten und Kanäle zu einem Netzwerk hinzufügen und nicht benötigte Komponenten und Kanäle löschen. Diese Vorgänge werden bei der Ausführung eines Netzwerks angestoßen. Wenn etwa ein Prozessor aufgrund eines Signaltokens erkennt, daß bestimmte Teile eines Netzwerks nicht benötigt werden, weil kein Zustand eintreten kann, der zu ihrer Aktivierung führt, so kann er diese Teile löschen. Auch die Neuverlegung von Kanälen ist möglich. Aktionen für die Selbstmodifikation eines Prozessors sind vom Programmierer bei der Implementierung des Prozessors festzulegen. Der Programmierer kann dafür die Smalltalk-Protokolle zur Konfiguration von Netzwerken verwenden oder sich spezieller Prozessoren bedienen. Für Signalnetzwerke sind beliebige Modifikationen möglich, bei Datennetzwerken müssen die Bedingungen des Datenflußmodells berücksichtigt werden (Zyklenfreiheit, nur ein Kanal pro Eingangsport usw.). Bild 7-34 zeigt ein Signalnetzwerk, das ein am Eingangsport eintreffendes Signaltoken wechselweise an einen der beiden Ausgangsports weiterleitet. Dazu wird Prozessor Switcher verwendet, der die Neuverlegung von Kanälen erlaubt. Bild 7-35 zeigt eine alternative Implementierung, die keine Neuverlegung der Kanäle nach sich zieht, dafür aber einen zusätzlichen Prozessor benötigt. Mechanismen zur dynamischen Programmodifikation, wie sie Vista zur Verfügung stellt, sind in herkömmlichen Programmiersystemen unbekannt. Die sich daraus ergebenden softwaretechnischen Konsequenzen sind mangels Erfahrung schwer abzuschätzen. Der Vorteil von Selbstmodifikation ist die Möglichkeit zur Rekonfiguration einer Applikation, die den zur Ausführungszeit geltenden Bedingungen bestmöglich gerecht wird und damit zu schlanken Applikationen führt. Man kann jedoch davon ausgehen, daß die häufige Verwendung von selbstmodifizierenden Komponenten das Verständnis von Programmabläufen erschwert und damit die Erweiterbarkeit, Testbarkeit und Wartbarkeit negativ beeinflußt. Um hohe Qualität zu gewährleisten, empfiehlt es sich daher, im Zweifelsfall auf Effizienzgewinne zu verzichten, die durch Selbstmodifikation erreichbar sind und statt dessen einfache und überschaubare Komponenten zu entwerfen.

244 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Bild Selbstmodifikation eines Signalnetzwerks. Das Bild zeigt vier Phasen eines Signalnetzwerks, das ein an Port in eintreffendes Token wechselweise an Port out1 und out2 weiterleitet. 1: Das Netzwerk befindet sich in der Ausgangsstellung. Ein eintreffendes Token fließt über die Ports in und out von switcher an Port out1 weiter. 2: Dasselbe Token wird auch an Port nextout weitergeleitet. Daraufhin legt switcher den an Port out angeschlossenen Kanal von out1 auf out2 um. 3: Der Kanal wurde neu verlegt, und das nächste Token fließt nach out2. 4: Selbe Situation wie in Phase 2. Nun wird der Kanal wieder nach out1 verlegt. Danach ist die Ausgangsstellung wieder erreicht.

245 7.5 Datentypen Bild Alternative Implementierung des Signalnetzwerks aus Bild : Die Wechselschaltung wird mit Hilfe eines Prozessors condition und eines booleschen Objektspeichers toout1 realisiert. Prozessor toout1 ist anfangs mit true belegt, wodurch das erste Token an out1 weitergeleitet wird. Bei dieser Gelegenheit wird toout1 auf false gesetzt, wodurch das zweite Token an out1 geht. Nun wird toout2 wieder mit true belegt und die Ausgangsstellung ist wieder erreicht. 2: Anwendung der Wechselschaltung in einem Prozessor alternatingswitch. Dieser Prozessor schaltet den Tongeber speaker bei jedem empfangenen Signal abwechselnd ein und aus. 7.5 Datentypen Ein Datentyp in Vista ist eine Smalltalk-Klasse zur Beschreibung der Struktur eines Datums, das von einem Token transportiert wird. Von Datentypen spricht man im Zusammenhang mit Tokens und Ports. Der Datentyp eines Tokens ist der Typ des transportierten Datums. Der Datentyps eines Ports ist der Typ der Daten, die der Port empfängt oder versendet. Datentypen nehmen im reaktiven und transformativen Teil von Vista einen unterschiedlichen Stellenwert ein. In Signalnetzwerken spielen Datentypen eine untergeordnete Rolle, weil Signalprozessoren auch dann arbeiten können, wenn ein Signaltoken keine Daten mit sich führt. Falls ein Signaltoken ein Datum mit sich führt, so ist dies ein gewöhnliches Smalltalk-Objekt, das mit Werkzeugen von VisualWorks definiert werden kann. In Datennetzwerken sind Datentypen essentiell, weil Datenprozessoren nur mit Datentokens eines bestimmten Typs arbeiten können. Die von Datentokens transportierten Daten müssen aufgrund der Eigenschaften des Datenflußmodells unmodifizierbare Werte sein. Man benötigt deshalb spezielle Werkzeuge, um ihre Struktur zu definieren. Die Werkzeuge von VisualWorks zur Definition von Smalltalk-Objekten sind hierfür ungeeignet.

246 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 236 Die folgenden Ausführungen beziehen sich ausschließlich auf Datentypen für Datennetzwerke. Auf Datentypen für Signalnetzwerke wird wegen ihrer geringen Bedeutung nicht eingegangen Arten von Datentypen Das Datenflußmodell verlangt, daß Operationen frei von Nebeneffekten sind. Nur dann ist eine automatische Parallelisierung möglich. Die von Operation zu Operation weitergereichten Daten müssen aus diesem Grund unmodifizierbare Werte sein. Wären sie gewöhnliche Smalltalk-Objekte mit modifizierbaren Attributen, so könnte die parallele Ausführung von Operationen über demselben Objekt zu nicht-deterministischen Ergebnissen führen, weil auf Attribute des Objekts in unbestimmter Reihenfolge lesend und schreiben zugegriffen werden könnte (siehe Bild 7-36). O Read A Write A P Q Bild Nicht-deterministische Ergebnisse bei Operationen über Objekten. Operation O liefert eine Referenz auf ein Objekt an die nachfolgenden Operationen Read A und Write A. Diese Operation lesen bzw. modifizieren das Attribut A des empfangenen Objekts und reichen die Objektreferenz anschließend an die Operationen P und Q weiter. Read A und Write A werden parallel bzw. in unbestimmter Reihenfolge ausgeführt, weil zwischen ihnen keine durch Datenkanäle bestimmte Abhängigkeit besteht. Wenn Read A vor Write A ausgeführt wird, dann erhalten P und Q andere Eingangsdaten als im umgekehrten Fall. Um die Nebeneffektfreiheit zu gewährleisten, werden in Datennetzwerken keine gewöhnlichen Smalltalk-Objekte verwendet, sondern unmodifizierbare Objekte, die im folgenden Daten genannt werden. Für einfache Daten, wie Zahlen, Zeichen und boolesche Werte, sind keine besonderen Maßnahmen zur Aufrechterhaltung der Nebeneffektfreiheit notwendig, weil diese Elemente auch in Smalltalk nicht modifizierbar sind. Strukturierte Daten, wie Verbunde und Felder, bedürfen jedoch einer besonderen Behandlung, weil einzelne Elemente dieser Daten veränderbar sind. In Vista sorgt ein automatischer Mechanismus dafür, daß vor schreibenden Zugriffen auf ein strukturiertes Datum eine Kopie angefertigt wird. Auf diese Weise ist sichergestellt, daß sich parallele Operationen nicht unbeabsichtigt beeinflussen können. Vista stellt drei Arten von Datentypen zur Verfügung: Einfachtypen, Verbundtypen und das Feld. Einfachtypen sind Zahlen, Zeichen, Zeichenketten und boolesche Werte. Sie sind in Smalltalk implementiert und können nur mit Werkzeugen von VisualWorks geändert werden. Einfachtypen sind die Grundelemente zur Erzeugung von Verbundtypen.

247 7.5 Datentypen 237 Verbundtypen bestehen aus einem oder mehreren benannten Elementen beliebigen Typs, die Strukturen in C und anderen Programmiersprachen ähnlich sind. Sie werden mit dem Datentyp-Browser von Vista erstellt. Die Elemente von Verbundtypen sind Einfachtypen oder wiederum Verbundtypen. Während der Ausführung eines Datennetzwerks können Daten mit der Bundle-Operation zu einem Verbundtyp gebündelt und mit der Unbundle-Operationen in einzelnen Elemente zerlegt werden. Felder fassen Einfach- oder Verbundtypen zu geordneten Kollektionen zusammen. Alle Elemente eines Feldes haben denselben Typ. Felder werden erstellt, indem das Feldattribut eines Einfach- oder Verbundtyps gesetzt wird. Die Größe eines Felds wird bei der Erzeugung angegeben und ist fix. Auf Feldelemente kann man mit einem ganzzahligen Index zugreifen, der mit 1 beginnt. Einfach- und Verbundtypen sind in Datentyp-Registern katalogisiert (siehe Bild 7-37). Von dort können sie entnommen werden, um daraus weitere Verbundtypen zu bauen. Bild Datentyp-Register Erzeugung von Datentypen Datentypen sind in Vererbungshierarchien angeordnet. Ein Datentyp vererbt seine Elemente an Subtypen, die weitere Elemente hinzufügen. Ein Typ U ist mit einem Typ T kompatibel, wenn U gleich T oder ein Subtyp von T ist. Durch die Möglichkeit Subtypen zu bilden, können polymorphe Operationen implementiert werden, die über Daten eines Typs T und aller seiner Subtypen arbeiten. Es gibt zwei Vererbungshierarchien: die Hierarchie der Einfachtypen und der Verbundtypen. Die Hierarchie der Einfachtypen besteht aus der Wurzel SimpleType und den davon abgeleiteten Einfachtypen, die in Bild 7-37 dargestellt sind. Diese Hierarchie ist nur auf textueller Ebene mit Werkzeugen von VisualWorks erweiterbar und wird deshalb nicht näher erläutert. Die Hierarchie der Verbundtypen besteht aus der Wurzel CompoundType und den davon direkt und indirekt abgeleiteten Verbundtypen. Diese Hierarchie kann mit grafischen Werkzeugen von Vista um neue Typen ergänzt werden.

248 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 238 Bei der Erzeugung eines neuen Verbundtyps muß man sich zunächst für einen Basistyp entscheiden. Man selektiert den Basistyp in der Typhierarchie, wählt aus einem Menü die Operation create data type subclass und vergibt einen Namen für den neuen Typ. Es entsteht eine Unterklasse der Klasse des Basistyps, die auch im Datentyp-Register eingetragen wird. Bild 7-38 zeigt die Hierarchie der Verbundtypen nachdem der Typ StudentType von PersonType abgeleitet wurde. StudentType erbt alle Elemente von PersonType, besitzt aber noch keine eigenen Elemente. Zur Festlegung der Elemente wird der Datentyp-Browser verwendet (siehe Bild 7-39) Verwendung von Datentypen Datentypen werden eingesetzt zur Erzeugung von Konstanten, zur Typisierung von Ports, zur Definition von Bundle- und Unbundle-Operationen sowie für Typkonvertierungen. Erzeugung von Konstanten In Vista werden Konstanten durch Datenprozessoren realisiert. Konstanten speichern einen Datenwert und besitzen genau einen Ausgangsport zur Weiterleitung des Werts an angeschlossene Prozessoren. Vor der Wertzuweisung an eine Konstante muß man den Typ der Konstanten definieren. Anschließend kann man mit dem Datentyp-Editor den Wert einstellen. Bild 7-40 zeigt eine Konstante string mit der Zeichenkette õhello Worldã. Typisierung von Ports Ports von Datenprozessoren und Datennetzwerken muß ein Typ zugewiesen werden, weil ein Datenprozessor nur dann richtig funktioniert, wenn die eintreffenden Daten typkompatibel mit der Operation sind, die der Datenprozessor realisiert. Die Typisierung der Ports von Verbundprozessoren und Netzwerken geschieht mit dem Eigenschaften-Dialogfenster (siehe Bild 7-40), für Einfachprozessoren wird Smalltalk-Code verwendet. Die Typprüfung geschieht statisch oder dynamisch. Die statische Typprüfung erfolgt bereits beim Aufbau eines Datennetzwerks. Ports können nur dann miteinander verbunden werden, wenn sie typkompatibel sind. Ein Ausgangsport muß vom gleichen oder übergeordneten Typ sein, wie alle mit ihm verbundenen Eingangsports. Damit ist sichergestellt, daß ein Ausgangsport nur Datentokens liefert, die mindestens jene Elemente enthalten, die von den Eingangsports erwartet werden. Beispielsweise kann ein Ausgangsport vom Typ StudentType mit Eingangsports vom Typ PersonType verbunden werden, weil StudentType alle Elemente enthält, die auch PersonType besitzt. Ein Datenprozessor, der Personendaten verarbeitet, wird deshalb bei der Verarbeitung von Studentendaten alle Elemente finden, die er benötigt. Die dynamische Typprüfung ist nur für Datenprozessoren notwendig, die in Signalnetzwerke eingebettet sind. Die Eingangsports solcher Datenprozessoren sind mit Ausgangsports von Signalprozessoren verbunden. Die von diesen Prozessoren gelieferten Signaltokens führen keine Werte mit sich, sondern Smalltalk-Objekte und sind deshalb für Datenprozessoren ungeeignet. Eine statische Typkompatibilität zwischen Datenports und Signalports kann daher nicht bestehen. Statt dessen werden Signaltokens zur Ausführungszeit in Datentokens umgewandelt und es wird dynamisch überprüft, ob das erzeugte Token typkompatibel mit dem jeweiligen Datenport ist. Für den umgekehrten Fall, der Verbindung von Ausgangsports von Datenprozessoren mit Eingangsports von Signalprozessoren, wird ebenfalls eine automatische Tokenumwandlung vorgenommen.

249 7.5 Datentypen 239 Bild Hierarchie der Verbundtypen. Bild Datentyp-Browser. Das Bild zeigt links den Datentyp-Browser bei der Definition des Verbundtyps StudentType. Die Liste Elements enthält die einzelnen Elemente des Verbundtyps. StudentType erbt die allgemeinen Angaben zu einer Person von PersonType. Neue Elemente werden eingefügt, indem man die entsprechenden Datentypen aus dem Datentyp- Register mit Drag-und-Drop in die Liste Elements zieht und ihnen anschließend einen bedeutungsvollen Namen gibt. Für Elemente, die Felder sein sollen, ist das Feldattribut zu setzen und die Feldgröße anzugeben. Im Beispiel ist das Element studies ein Feld der Größe 3, wodurch festgelegt wird, daß ein Student maximal drei Fächer studieren kann. Selektiert man ein Element, so zeigt die Liste Value of Element den aktuellen Wert des Elements. Im Fall von Elementen, die Verbundtypen oder Felder sind, werden die Werte aller Subelemente angezeigt. Die Werte können editiert werden und gelten als Vorgabewerte für weitere Verwendungen des neu definierten Typs.

250 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 240 Bild Erzeugung einer Konstanten. Die Konstante string (links oben) ist ein Datenprozessor mit einem Ausgangsport value, über den der Inhalt der Konstanten an angeschlossene Prozessoren geliefert wird. Die Konstante besitzt keinen Eingangsport. Der von ihr gespeicherte Wert wird bei der Erzeugung mit den Datentyp-Editor (rechts) eingestellt. Dieser Editor hat den gleichen Aufbau wie der Datentyp-Browser, die Bedienungselemente zur Änderung der Struktur des Datentyps sind aber deaktiviert. Der Datentyp einer Konstanten wird mit dem Eigenschaften-Dialogfenster (links unten) eingestellt. Im Beispiel wird festgelegt, daß die Konstante vom Typ StringType ist. Single gibt an, daß der Inhalt ein einzelner Wert ist (Array würde ein Feld bedeuten). Bundle- und Unbundle-Operation Der Zugriff auf einzelne Elemente eines Datums ist mit zwei speziellen Operationen möglich, der Bundle- und Unbundle-Operation. Beiden Operationen ist ein Verbundtyp zugeordnet, dessen Struktur zur Bündelung von Daten (Bundle) oder zur Zerlegung eines Datum in seine Elemente (Unbundle) dient. Das Piktogramm des Verbundtyps wird von den Operationen übernommen, so daß leicht erkennbar ist, für welchen Typ die Operationen arbeiten (siehe Bild 7-41). Die Bundle-Operation hat für jedes Elemente des Verbundtyps einen Eingangsport, der so heißt wie das Element und denselben Typ hat. Die Bundle-Operation bündelt die Daten an den Eingangsports und stellt sie am Ausgangsport value als aggregiertes Datum zur Verfügung. Die Unbundle-Operation funktioniert genau umgekehrt. Sie hat einen Eingangsport value, an dem sie ein Datum entgegennimmt und einen Ausgangsport für jedes Element. Das Datum am Eingangsport wird zerlegt und an den Ausgangsports Element für Element zur Verfügung gestellt. Bild 7-42 zeigt eine Anwendung der Unbundle-Operation.

251 7.5 Datentypen 241 Bild Bundle- und Unbundle-Operation für DateType. Bild Anwendung der Unbundle-Operation. Das dargestellte Datennetzwerk stellt fest, ob eine Person älter ist als 18 Jahre und liefert am Ausgangsport over18 je nachdem true oder false. Die Operation unbundle person liefert die Element des Typs PersonType und leitet das Geburtsdatum weiter an die Operation unbundle birthday, die wiederum die einzelnen Elemente eines Tokens vom Typ DateType liefert. Das Geburtsjahr und die Altersgrenze werden addiert und mit dem laufenden Jahr verglichen. Die bei den Konstanten agelimit und date sichtbaren Werte 19 bzw. 7 March 1997 entsprechen dem Inhalt der Konstanten. Die Konstante agelimit enthält das aktuelle Datum. Das bei den Operationen unbundle birthday und unbundle date gezeigte Datum ist nicht der aktuelle Tokenwert, sondern das Piktogramm von DateType.

252 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 242 Typkonvertierung Wenn ein Signaltoken von einem Signalprozessor an einen Datenprozessor weitergeleitet wird, wird es in ein Datentoken konvertiert und das vom Token mitgeführte Smalltalk-Objekt in ein typisiertes Datum umgewandelt. Bei Verbindungen zwischen einem Datenprozessor und einem Signalprozessor findet die Umwandlung in umgekehrter Richtung statt. Typkonvertierungen sind nur mit Smalltalk möglich. Für die Umwandlung von Smalltalk-Objekten zu Daten ist pro Typumwandlung eine Methode asvistadata zu implementieren, für die Konvertierung von Daten zu Smalltalk-Objekten eine Methode assmalltalkobject. Für die Einfachtypen und häufig benötigte Verbundtypen sind Konvertierungsmethoden vorhanden, für neue Verbundtypen muß sie der Programmierer selbst bereitstellen. Bild 7-43 zeigt die Konvertierungsmethoden für Time und TimeType. Time>>asVistaData ^TimeType new addelement: (self hours asvistadata name: #hours); addelement: (self minutes asvistadata name: #minutes); addelement: (self seconds asvistadata name: #seconds); yourself. TimeType>>asSmalltalkObject ^Time new hours: (self elementnamed: #hours) assmalltalkobject minutes: (self elementnamed: #minutes) assmalltalkobject seconds: (self elementnamed: #seconds) assmalltalkobject. Bild Typkonvertierung für Time und TimeType. 7.6 Beispiel für die Konstruktion einer Applikation Dieser Abschnitt zeigt anhand der Konstruktion einer Applikation, wie die zuvor diskutierten Konzepte und Programmelemente ineinandergreifen, wie man die Werkzeuge der Programmierumgebung einsetzt und wie Vista mit einem externen Benutzungsschnittstelleneditor zusammenspielt. Die Aufgabenstellung wurde bewußt einfach gewählt, um dem Leser den Vergleich mit einer konventionellen Implementierung zu gestatten und die Beschreibung nicht allzu kompliziert zu gestalten. Trotz des einfachen Beispiels hat der Leser nun anstrengende Seiten zu erwarten, weil die schriftliche Darstellung von interaktiven Vorgängen und visuellen Programmelementen, wie sie für ein VP-System typisch sind, in aller Regel zu aufwendigen und manchmal auch umständlichen Konstruktionen führt. Die erklärenden Bildtexte werden in diesem Abschnitt nicht unterhalb der Abbildungen angeführt, sondern im Haupttext belassen, weil der Abschnitt großteils aus Erläuterungen von grafischem Programmcode besteht. Eine Trennung von Haupttext und Bilderklärung würde den Lesefluß unterbrechen. Zudem wird in diesem Abschnitt das Indefinitpronomen»man«verwendet, um ein häufiges Passiv zu vermeiden.

253 7.6 Beispiel für die Konstruktion einer Applikation Aufgabe Es ist ein Signalprozessor TA (thermo alarm processor) zu bauen, der die Temperatur einer externen Einheit überwacht. TA soll folgendermaßen arbeiten: Bei Temperaturänderung der externen Einheit erhält der Prozessor ein Signaltoken, das den aktuellen Temperaturwert mit sich führt, vergleicht diesen Temperaturwert mit einem oberen und unteren Grenzwert und löst einen Alarmgeber aus, wenn die Temperatur außerhalb des zulässigen Bereichs liegt. In diesem Fall ist zusätzlich ein Signaltoken auszusenden, um die Grenzwertverletzung anzuzeigen, und ein weiteres Signaltoken, wenn die Temperatur wieder im Normalbereich liegt. Die Grenzwerte werden von außen eingespeist und können sich jederzeit ändern. TA hat dafür zu sorgen, daß bei Grenzwertänderungen eine Plausibilitätsprüfung vorgenommen wird und der untere Grenzwert niemals den oberen Grenzwert überschreitet. Zudem muß der Alarmgeber austauschbar sein. Für Testzwecke ist zusätzlich eine VisualWorks-Applikation zu implementieren, mit der alle Funktionen von TA überprüfbar sind. Diese Testapplikation soll die Möglichkeit bieten, Temperaturwerte zu verändern, numerisch in Celsius und Fahrenheit anzuzeigen und Abweichungen vom zulässigen Bereich durch einen optischen Indikator zu signalisieren. Bild 7-44 zeigt links das Interface von TA mit den öffentlichen Prozessoren alarmdev (Alarmgeber), max (oberer Grenzwert) und min (unterer Grenzwert). Rechts daneben ist die Testapplikation zu sehen. Die Schieberegler Temp, High und Low verändern die von TA überwachten Werte. Darunter befinden sich die numerischen Anzeigen für Celsius und Fahrenheit. Die mit Alarm beschriftete Fläche blinkt rot, wenn sich die Temperatur außerhalb des eingestellten Bereichs befindet; bei zulässigen Temperaturen ist sie grün gefärbt. Diese Fläche ist unabhängig vom austauschbaren Alarmgeber alarmdev, der in der aktuellen Konfiguration ein Tongeber (speaker) ist. Bild TA-Prozessor (links) und Testapplikation (rechts).

254 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem Konstruktion der Testapplikation Bevor gezeigt wird, wie man TA implementiert, soll zunächst die Konstruktion der Testapplikation skizziert werden. Durch diesen»blick von oben«werden die Zusammenhänge klarer. Auf eine detaillierte Erläuterung des Aufbaus der Testapplikation und ihrer Einbettung in VisualWorks wird aus Platzgründen verzichtet. In Abschnitt»Grundstruktur von Vista-Applikationen«, S. 180, wurde darauf hingewiesen, für die Konstruktion einer Applikation mit Vista die Werkzeuge von VisualWorks verwendet werden können. Damit für den Bau der Testapplikation diese Werkzeuge zum Einsatz kommen können, muß sie der geschichteten Architektur von VisualWorks entsprechen. Insbesondere der Benutzungsschnittstelleneditor verlangt diese Konformität. Bild 7-45 zeigt die Architektur der Testapplikation mit den drei Schichten Benutzungsschnittstelle, Applikationsmodell und Domänenmodell. Die Benutzungsschnittstelle baut man mit dem Editor von VisualWorks, der in Bild 2-1, S. 11, zu sehen ist. Man holt die einzelnen Elemente mit Drag-und-Drop aus einer Palette, zieht sie auf das Fenster der Testapplikation und positioniert sie dort entsprechend. Den Schiebereglern und Eingabefeldern verbindet man mit Objektspeichern des Applikationsmodells, die für die synchrone Aktualisierung dieser Elemente sorgen (siehe auch Bild 7-2, S. 182). Das Applikationsmodell ist in Bild 7-45 nur teilweise dargestellt, um die Übersicht zu bewahren. Es besteht aus den erwähnten Objektspeichern, von denen vier im Bild dargestellt sind (tempc, tempf, lowc und lowf) und Nachrichten, die Verbindungen zwischen Benutzungsschnittstelle und Applikationsmodell herstellen. Die Namen von zwei dieser Nachrichten (onchangedo und ontriggerdo) sind im Bild dargestellt. Die Nachrichten werden bei der Initialisierung des Applikationsmodells an tempc und Ausgangsport alarm gesandt. Das Domänenmodell besteht aus TA selbst und Einfachprozessor für den Tongeber (alarmdev) und die Speicherung der Grenzwerte (high und low). Diese Einfachprozessoren ersetzen die öffentlichen Prozessoren von TA. Bild 7-45 zeigt nur TA und den Prozessor low, der als Objektspeicher für den unteren Grenzwert dient. Wie die Ersetzung der öffentlichen Prozessoren konkret geschieht, wird später erklärt. Zuvor werden die Verbindungspfeile zwischen den drei Schichten erläutert. Das Zusammenwirken der drei Schichten Die roten Pfeile in Bild 7-45 stellen den Steuerfluß für Änderungen des Temperaturwertes dar. Wenn man den Schieberegler Temp betätigt oder die Temperatur mit Hilfe des Eingabefeldes für Celsiuswerte verändert, so wird zunächst Objektspeicher tempc aktualisiert. Unabhängig davon, ob man den Schieberegler oder das Eingabefeld benutzt, werden immer beide Elemente aktualisiert, weil sie über den Change-Update- Mechanismus von Smalltalk gekoppelt sind. Eine ähnliche Kopplung besteht auch zwischen tempc und tempf. Jedesmal wenn sich tempc ändert, wird automatisch eine Funktion aktiviert, die tempf das Resultat der Formel tempc * 9/ zuweist. Zuletzt bewirkt eine ƒnderung von tempc, daß der Blockparameter [... ] der Nachricht onchangedo ausgeführt wird. Dieser Blockparameter enthält die Anweisung ta newtemp: tempc value wodurch Port newtemp von TA mit dem neuen Temperaturwert versorgt wird (die kleingeschriebene Variable ta des Applikationsmodells referenziert ein Exemplar der Klasse TA).

255 7.6 Beispiel für die Konstruktion einer Applikation 245 Aufgrund des neuen Temperaturwertes nimmt TA eine Überprüfung vor und emittiert ein Token an Port alarm, wenn der zulässige Bereich verlassen wurde. Dieses Token bewirkt die Ausführung des Blockparameters der Nachricht ontriggerdo, der die Anweisung alarmregion backgroundcolor: ColorValue red; startblinker enthält. Durch diese Anweisung wird die Alarmfläche rot gefärbt und beginnt zu blinken. Außerdem schaltet TA bei einer Grenzwertverletzung den Tongeber ein. Der dafür nötige Programmcode ist in TA selbst implementiert und betrifft die Testapplikation nicht. Benutzungsschnittstelle tempc -15 onchangedo: [... ] tempf 5 ontriggerdo: [... ] lowc -10 lowf -14 Applikationsmodell TA low Domänenmodell Bild Architektur der Testapplikation; Farbbild im Anhang. Die blauen Pfeile zeigen den Steuerfluß bei Änderungen des unteren Grenzwertes. In diesem Fall wird nicht der Eingangsport des Prozessors low angesteuert, sondern die Aktualisierung erfolgt durch den Change-Update-Mechanismus. Bild 7-46 zeigt die dafür notwendige Beziehung zwischen lowc und low. Der Objektspeicher lowc des Applikationsmodell verfügt über eine Liste von Beobachterobjekten (dependents), die sich für Änderungen des von ihm gespeicherten Wertes interessieren. Eines dieser Beobachterobjekte ist Prozessor low, der ebenfalls als Objektspeicher dient, das zu speichernde Objekt jedoch nicht direkt enthält, sondern über die Variable value referenziert, die auf lowc zeigt. Wenn sich lowc ändert, wird low durch den Change-Update-Mechanismus informiert und kann den neuen Wert über die Variable value abrufen.

256 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 246 value lowc -10 low dependents Bild Change-Update-Beziehung zwischen Objektspeicher lowc und Prozessor low. Initialisierung des TA-Prozessors Um TA und Testapplikation zu verbinden, muß beim Start der Testapplikation ein neues Objekt der Prozessorklasse TA erzeugt und passend initialisiert bzw. konfiguriert werden. Bild 7-47 zeigt den Smalltalk-Code, der dafür zu schreiben ist. 1 ApplicationModel subclass: #TATester 2 3 initializeprocessors 4 5 ta := TA new 6 alarmdev: (Speaker new); 7 max: (highc asprocessor); 8 min: (lowc asprocessor) tempc onchangedo: [ 11 ta newtemp: tempc value ] ta alarm ontriggerdo: [ 14 alarmregion 15 backgroundcolor: ColorValue red; 16 startblinking ] ta ok ontriggerdo: [ 19 alarmregion 20 stopblinking; 21 backgroundcolor: ColorValue green ]. Bild Initialisierung des TA-Prozessors. Zeile 1: Definition der Testapplikation TATester als Unterklasse der VisualWorks- Klasse ApplicationModel. Die Testapplikation enthält u.a. folgende Exemplarvariablen: ta, tempc, highc, lowc und alarmregion. Diese Variablen werden in den nächsten Zeilen referenziert. Zeile 3: Name der Methode zur Initialisierung des Prozessors. Diese Methode wird beim Start der Testapplikation aufgerufen. Zeilen 5-8: Erzeugung eines neuen Objekts der Prozessorklasse TA und Substitution der öffentlichen Prozessoren alarmdev, max und min durch lokal erzeugte Prozessoren. Die Nachricht asprocessor erzeugt aus den Objektspeicher highc und lowc entsprechende Einfachprozessoren und stellt die in Bild 7-46 gezeigte Beziehung her.

257 7.6 Beispiel für die Konstruktion einer Applikation 247 Dem aufmerksamen Leser wird nicht entgehen, daß kein Programmcode zur Benennung der erzeugten Einfachprozessoren existiert. Das ist richtig: tatsächlich sind die Einfachprozessoren unbenannt. Die in Bild 7-45 und Bild 7-46 verwendeten Namen high und low dienen nur der Anschaulichkeit und werden für TA nicht benötigt. Zeilen 10-11: Verbindung des Objektspeichers tempc mit Port newtemp. Die Nachricht onchangedo bewirkt, daß bei jeder Temperaturänderung, Port newtemp mit dem neuen Temperaturwert versorgt wird. Zeilen 13-16: Anschluß des Ports alarm an die Alarmfläche alarmregion. Die Nachricht ontriggerdo bewirkt, daß jedesmal, wenn Port alarm ein Token aussendet, die Alarmfläche rot gefärbt wird und zu blinken beginnt. Zeilen 18-21: Anschluß des Ports ok an die Alarmfläche alarmregion. Das Blinken wird gestoppt und die Alarmfläche grün gefärbt. Nach diesen Erläuterung zum Bau der Testapplikation wird nun erklärt, wie man mit den Werkzeugen von Vista den TA-Prozessor konstruiert Konstruktion des TA-Prozessors Wenn man einen neuen Prozessor konstruiert, so erstellt man damit den Ur-Prototypen für Prozessorexemplare, die später in Applikationen eingebaut werden (siehe Abschnitt»Prototypen«, S. 227). Die erste Entscheidung bei der Konstruktion betrifft die Basisklasse des Ur-Prototypen, d.h. es ist festzulegen, ob der neue Prozessor die Spezialisierung eines bereits bestehenden Prozessors sein soll oder ob seine Struktur und sein Verhalten von anderen Prozessoren unabhängig ist. TA wird von der allgemeinen Wurzelklasse für Signalverbundprozessoren abgeleitet, d.h. TA teilt nur seine generellen Eigenschaften mit anderen Prozessoren und ist ansonsten autonom. Beim Erzeugen einer neuen Prozessorklasse selektiert man im Hierarchie-Browser die Basisklasse und wählt aus einem Menü die Operation create processor subclass und vergibt einen Klassenamen. Bild 7-48 zeigt die Vererbungshierachie von Verbundprozessoren nachdem TA von der Klasse CompoundSignal- Processor abgeleitet wurde. TA erbt alle Eigenschaften dieser Klasse, z.b. auch das generische Piktogramm, das man später mit einem Piktogrammeditor ändern kann. Zugleich mit der Ableitung wird TA auch im Prozessor-Register eingetragen, wo alle Prozessoren nach Kategorien geordnet abgelegt sind. Das Register ist im Bild unten zu sehen. Nachdem die Prozessorklasse erzeugt wurde, selektiert man im Prozessor-Register den neuen Prozessor und wählt die Operation Edit (siehe Bild 7-48) Daraufhin präsentiert Vista zwei leere Schablonen, eine für das Interface und die andere für das Interior des Prozessors, sowie ein T-Netzwerk, mit dem man den neuen Prozessor sofort testen kann. Die Schablonen füllt man mit Ports, Prozessoren, Methoden und Netzwerken, wobei jede Änderung sofort im T-Netzwerk nachgeführt wird. Bild 7-49, S. 254, zeigt die Schablonen und das T-Netzwerk nach der vollständigen Definition von Interface und Interior.

258 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 248 Bild Hierarchie-Browser und Prozessor-Register für die Klassendefinition von TA. Definition des Interface Das Interface eines Prozessors besteht aus Eingabe- und Ausgabeports, öffentlichen Prozessoren und öffentlichen Methoden. Für TA benötigt man einen Eingangsport newtemp vom Typ Number, der den aktuellen Temperaturwert entgegennimmt und zwei Ausgangsports alarm und ok, die untypisiert sind, weil sie ein datenloses Signaltoken emittieren. Nachdem man die Ports erzeugt, benannt und typisiert hat, erscheinen sie sowohl in der Schablone als auch im Netzwerk. Im nächsten Schritt setzt man die benötigten öffentlichen Prozessoren ein. Dazu selektiert man im Prozessor-Register, wo alle Prozessoren nach Kategorien geordnet abgelegt sind, drei Prozessoren des Typs Number aus der Kategorie Values und zieht sie mit Drag-und-Drop über den Bereich Public Processors der Schablone. Nach dieser Aktion haben diese Prozessoren generische Namen und müssen auf alarmdev, min und max unbenannt werden. Öffentliche Methoden werden für TA nicht benötigt, weshalb der dafür vorgesehene Bereich leer bleibt. Das Interface ist nun fertig. Die vorgenommenen Änderungen wurden jedoch noch nicht bei der Prozessorklasse gespeichert. Dazu muß man das Interface installieren, d.h. aus der Schablone entsprechenden Smalltalk-Code generieren. Dieser Vorgang wird über das Menü Installation der Interface-Schablone angestoßen. Es entstehen daraufhin

259 7.6 Beispiel für die Konstruktion einer Applikation 249 Methoden zur Erzeugung der Port und öffentlichen Prozessoren sowie Methoden zum Zugriff auf diese Elemente, die man für die Initialisierung von TA benötigt (siehe auch Bild 7-47, S. 249). Definition des Interior Das Interior von TA ist sehr einfach. Es besteht aus drei X-Netzwerken tempchanged, minchanged und maxchanged, die auf Änderungen der Temperatur und der Grenzwerte reagieren. Ein I-Netzwerk tempcheck enthält die gemeinsame Logik der X- Netzwerke; es prüft, ob die Temperatur innerhalb der Grenzen liegt. Zuletzt benötigt man noch einen privater Prozessor temp, der die aktuelle Temperatur speichert. Bild 7-49 zeigt die Interior-Schablone nachdem alle Netzwerke und der private Prozessor erzeugt wurden. X- und I-Netzwerke sind durch ihre Piktogramme unterscheidbar. Das Symbol für X-Netzwerke ( ) hat gestrichelte Terminals, jenes für I-Netzwerke ( ) weist durchgehende Terminals auf. Zudem können mit dem Menü die verschiedenen Netzwerkarten selektiv angezeigt werden (Auswahl und ). Eine analoge Selektionsmöglichkeit besteht auch für Prozessoren und Methoden. Im folgenden werden die einzelnen Netzwerke näher betrachtet. Das X-Netzwerk tempchanged (siehe Bild 7-50, links) enthält nur einen Stellvertreter des privaten Prozessors temp und des internen Netzwerks tempcheck. Die eckigen Klammern am Eingangsport newtemp bedeuten, daß Signaltoken, die an diesem Port eintreffen, einen Datenwert mit sich führen, nämlich die aktuelle Temperatur. Nachdem die Temperatur in temp gespeichert wurde (Kanal 1), prüft das Netzwerk tempcheck, ob die Temperatur innerhalb der Grenzwerte liegt (Kanal 2). Das I-Netzwerk tempcheck (siehe Bild 7-50, rechts) wird in allen drei X-Netzwerke verwendet. Es enthält den lokalen Prozessor rangechecker und den öffentlichen Prozessor alarmdev. Wenn Port check des Prozessors rangechecker ein Signaltoken empfängt, dann prüft dieser Prozessor, ob der mit diesem Signaltoken mitgeführte Datenwert innerhalb der Grenzwerte liegt. Welche Größen als Grenzwerte heranzuziehen sind, wird durch die öffentlichen Prozessoren max und min des Prozessors rangechecker bestimmt. Im konkreten Fall wurden diese öffentlichen Prozessoren durch die Prozessoren max und min von TA ersetzt (die Namensgleichheit hat nichts zu bedeuten). Man beachte, daß die öffentlichen Prozessoren des Prozessors rangechecker vom Typ Magnitude sind; das Piktogramm weist auf diesen Typ hin. Mit Magnitude sind alle Einfachprozessoren typkompatibel, die Objekte speichern, auf denen eine Ordnungsrelation definiert ist. Der Prozessor rangechecker kann deshalb nicht nur Zahlen miteinander vergleichen, sondern auch Zeichen, Zeichenketten, Zeitwerte usw. Das Ergebnis der Temperaturprüfung löst ein Signal bei einem der Ausgangsports aus. Ein Signal von Port toolow oder toohigh schaltet den Alarmgeber alarmdev ein, ein Signal von Port ok schaltet den Alarmgeber aus. In weiterer Folge wird das Signal an den Ausgangsport loworhigh bzw. tempok des I-Netzwerks weitergeleitet. Damit der Alarmgeber reagieren kann, muß man den abstrakten Prozessor alarmdev durch einen konkreten Prozessor ersetzten. Das geschieht bei der Initialisierung von TA (siehe auch Bild 7-47, S. 249). Die X-Netzwerke minchanged und maxchanged sind in Bild 7-51 dargestellt. Diese Netzwerke werden immer dann aktiviert, wenn sich der Grenzwert min bzw. max ändert. Weil der aktuelle Temperaturwert bei einer Änderung der Grenzwerte den zulässi-

260 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 250 gen Bereich verlassen bzw. wieder dahin zurückkehren kann, müssen die beiden Netzwerke mit den Ausgangsports von TA verbunden sein. Der Eingangsport newtemp ist jedoch ohne Bedeutung, da in diesem Fall newtemp kein Signal liefert, sondern die Prozessoren min bzw. max die Grenzwertänderungen signalisieren. Die Annotation bei Port newtemp weist auf diese Situation hin. Annotationen kann man an beliebigen Elemente anbringen und nach Bedarf ein- und ausblenden. Wenn man annotierte Elemente verschiebt, so werden die Annotationen automatisch repositioniert. Weil die Netzwerke minchanged und maxchanged gleichartig aufgebaut sind, wird im folgenden nur minchanged erklärt. Der Prozessor min meldet Änderungen des unteren Grenzwertes über den Port changed. Der aktuelle Wert -10 wird am Interface dargestellt. Das von changed emittierte Signaltoken, löst bei Prozessor condition die Überprüfung aus, ob min > max gilt. Wenn das der Fall ist, dann wird über den Ausgangsport true der Wert von max = min gesetzt, worauf sich max ändert und somit das Netzwerk maxchanged aktiviert wird. Wenn min <= max gilt, dann wird über den Ausgangsport false und I-Netzwerk tempcheck die Prüfung der Temperatur vorgenommen. In diesem Fall ist zu beachten, daß das Signaltoken den aktuellen Temperaturwert nicht mit sich führt. Deshalb muß man den gespeicherte Wert temp am Eingangsport check als Parameter mitgeben. Der TA-Prozessor ist damit fertiggestellt. Abschließend muß noch das Interior installieren werden, um Smalltalk-Code aus den Netzwerken zu erzeugen. Danach kann man TA mit der Testapplikation prüfen. Zum Test stehen verschiedene Werkzeuge zur Verfügung, wie Animatoren, Objektinspektoren, Debugger und Tokentracer, die so entworfen wurden, daß man jederzeit alle wesentlichen Querbeziehungen zwischen den Programmkomponenten herstellen kann. Dadurch können Fehler schneller gefunden werden und sind kurze Redesignzyklen möglich.

261 7.6 Beispiel für die Konstruktion einer Applikation 251 Bild Interface, Interior und T-Netzwerk von TA.

262 Vista: ein komponentenbasierter Ansatz für ein visuelles Programmiersystem 252 Bild Netzwerke tempchanged (links) und tempcheck (rechts). Bild Netzwerke minchanged (rechts) und maxchanged (links).

263 8. Zusammenfassung In den vorigen Kapiteln wurden Argumente für und gegen visuelle Programmierung angeführt und spezifische Eigenschaften von VP-Systemen untersucht. Trotz der ausführlichen Diskussion kann die Frage, ob visuelle Elemente das Programmieren einfacher machen und zu besseren Programmen führen, nicht mit einem klaren Ja oder Nein beantwortet werden. Zu unterschiedlich sind die intellektuellen Fähigkeiten der Menschen, zu vielfältig die Problemstellungen und Abläufe bei der Programmierung, zu verschieden die Anwendungsgebiete und zu ungenau das Instrumentarium, mit dem gemessen werden kann, was»einfacher«und»besser«heißt. Es gibt nur wenige empirische Studien, die sich mit den Vor- und Nachteilen der visuellen Programmierung beschäftigen. Die existierenden Untersuchungen sind manchmal widersprüchlich und meist zu spezifisch, um allgemeine Aussagen zu erlauben. Kognitionspsychologische Studien zu einfachen grafischen Darstellungen, wie Flußdiagrammen und Struktogrammen, haben wenig Aussagekraft, weil solche Notationen in modernen VP-Systemen keine Rolle spielen (vgl. Brooke und Duncan [80], Veer et al. [86] sowie Cunniff und Taylor [87]). Manche neuere Studien sind ebenfalls nur bedingt brauchbar, weil sie nur die Programmierung kleiner Applikationen betrachten und hier nur einen ausgewählten Anwendungsbereich, der durch die untersuchten Sprachen gut abgedeckt ist. Beispielsweise prüften Pandey und Burnett [93], ob es leichter ist, Programme zur Manipulation von Matrizen visuell oder textuell zu erstellen. Sie kamen nicht unerwartet zum Schluß, daß die (von Burnett mitentwickelte) visuelle Programmiersprache Forms/3 für solche Aufgaben besser geeignet ist als Pascal oder APL. Green und Petre [92] gingen der Frage nach, ob logische Ausdrücke in visuellen Programmen leichter zu lesen sind als in textuellen Programmen. Diese Studie ergab hingegen, daß für die gewählten Beispiele visuelle Darstellungen durchgehend schlechter abschneiden als textuelle Notationen (vgl. auch Petre und Green [93]). Ware [93 S. 92] warnt vor einer zu technokratischen Herangehensweise bei der Erforschung visueller Sprachen. Er meint, daß es zwar gerechtfertigt ist, sich mit visuellen Sprachen in der Mensch-Maschine-Kommunikation auseinanderzusetzen, daß man dabei aber auch soziale Faktoren einbeziehen muß, um nicht am Menschen vorbeizuforschen. Er nennt die technikzentrierten Ansätze auf dem Gebiet der Telekonferenzen als warnendes Beispiel für einen Bereich, wo man die menschliche Komponente lange Zeit nicht angemessen berücksichtigte und deshalb keine signifikanten Erfolge erzielte. Im folgenden werden Potentiale und Grenzen visueller Darstellungen in der Programmierung zusammenfassend bewertet. 8.1 Potentiale visueller Darstellungen in der Programmierung Die Vorteile der Verwendung von Grafiken in der Softwareentwicklung liegen vor allem in jenen Bereichen, wo die Vermittlung von Ideen, die Darstellung komplexer Zusammenhänge und die Gestaltung von Benutzungsschnittstellen im Mittelpunkt stehen.

264 Zusammenfassung 254 Dabei kommen u.a. folgende positive Eigenschaften bildlicher Darstellungen zur Geltung: Effektive Verarbeitung visueller Information im Gehirn Anschaulicher Realitätsbezug Erhöhter Aufmerksamkeitswert Großes Motivations- und Lernpotential Abschwächung syntaktischer Strukturen Betonung semantischer Zusammenhänge Fehlervermeidung durch direkte Manipulation Die nächsten Abschnitte skizzieren, wie diese Vorteile in der Softwareentwicklung genutzt werden können Überblicksbilder und Entwurfskizzen Für die Spezifikation, den Entwurf und die Dokumentation eines Softwaresystems sind anschauliche Grafiken ein bedeutender Faktor zur Verbesserung des Problemverständnisses, zur Förderung des Ideenaustausches und zur Darstellung der Struktur und Funktionalität des Systems. Dies geschieht am besten mit informellen Mitteln. Dabei ist entscheidend, daß sich Zeichnungen und Diagramme auf die essentiellen Aspekte des betreffenden Sachverhalts beschränken und den Betrachter nicht mit irrelevanten Details belasten. Formale Notationen stören eher, weil sie semantische Informationen durch syntaktische Konstrukte überlagern und dadurch den Wahrnehmungsprozeß behindern. In der Vergangenheit wurde zwar immer wieder versucht, strikt definierte und allgemeingültige Entwurfsnotationen zu finden, die Erfahrung aber zeigt, daß dies auch für abgegrenzte Bereiche problematisch ist. Die Kreativität wird dadurch oft in ein zu enges Korsett gezwängt. Darauf verweist auch Denert [93 S. 160] in einer kritischen Auseinandersetzung mit CASE-Werkzeugen: Man schreibt nur noch das auf, wofür das Werkzeug eine passende Schublade hat. Die unausgegorenen, aber möglicherweise besonders guten Ideen werden vielleicht gar nicht mehr festgehalten, denn man hat ja eigentlich nur die Aufgabe, die Datenbasis des Werkzeugs zu füllen. Und das heißt: man kann ungeheuer beschäftigt sein, ohne wirklich voranzukommen. Man sieht sich satt an den vielen gleichartigen Bildern. Im Hinblick auf die Dokumentation von Programmen sind Burnett et al. [95 S. 49] der Ansicht, daß eine ungenaue Dokumentation schlechter sei als gar keine. Sie stehen damit im Gegensatz zu der hier vertretenen Meinung, daß informelle Hinweise in vielen Fällen ausreichen, um ein Programmsystem so zu dokumentieren, daß es gewartet werden kann. Burnett et al. begründen den Wert visueller Programmiersprachen u.a. damit, daß ihres Erachtens visuelle Programme die Dokumentation und den Programmcode optimal verbinden. Sogenannte Ad-hoc-Animationen sollen das Programmverständnis erhöhen und eine separate Dokumentation weitgehend überflüssig machen. Sie schreiben [S. 49; OZ 48]: Die Möglichkeit, jeden Teil des Programms bei Bedarf beobachten zu können, erfüllt das Dokumentationsziel, dem Programmierer beim Verstehen des Programms zu helfen und garantiert gleichzeitig die Konsistenz zwischen dieser Information und der tatsächlichen Funktionsweise des Programmcodes. Der Unterschied zwischen Quelltext und Dokumentation schwindet, weil Programme mit [sichtbar

265 8.1 Potentiale visueller Darstellungen in der Programmierung 255 gemachten] Testwerten einerseits eine»reagierende«dokumentation bilden und andererseits die Dokumentation auch die Programmierung einschließen kann. Diese Aussage ist zweifelhaft. Selbst wenn man die Benutzerdokumentation außer acht läßt und nur die für den Programmierer relevante Systemdokumentation betrachtet, so umfaßt diese laut Sametinger [91 S. 11] u.a.»anforderungen, Entwurfsphilosophie, Entwurfsdetails, Möglichkeiten, Einschränkungen und andere Merkmale eines Systems«. Diese Fülle an Informationen über ein Softwaresystem kann man weder mit rein formalen Mitteln beschreiben noch durch Analyse der Systemstruktur und Beobachten des Systemverhaltens alleine erfassen. Eine informelle und damit zwangsläufig unpräzise Dokumentation gewisser Aspekte ist deshalb oft der einzige Weg, um ein System insgesamt verständlich zu beschreiben Softwarevisualisierung Bildliche Darstellungen von Datenstrukturen und Programmabläufen sind eine wertvolle Ergänzung von Programmcode. Sorgfältige Visualisierungen repräsentieren sowohl die Struktur als auch das Verhalten und die Wirkung eines Programms besser als rein textuelle Anzeigen. Grafische Repräsentationen der dynamischen Programmstruktur sind beim Test, bei der Fehlersuche und bei der Optimierung von Laufzeit- und Speicherbedarf von entscheidendem Vorteil, da sie Zusammenhänge erschließen, die bei einer Inspektion der statischen Struktur verborgen bleiben. Besonders einprägsam sind Animationen, die Änderungen des Programmzustandes in Form von bewegten Bildern visualisieren. Der damit mögliche Einblick in die Programmausführung ist speziell in Systemen mit parallelen Prozessen von größter Bedeutung, da dort oftmals zeitliche Abhängigkeiten zwischen den einzelnen Ausführungseinheiten bestehen und das Zusammenspiel der Programmkomponenten ohne direkte Beobachtung nur schwer nachvollziehbar ist. Einsichten in die Laufzeitkomplexität eines Berechnungsverfahrens können sogenannte»algorithmenrennen«vermitteln. Dabei werden verschiedene Algorithmen für dasselbe Problem und dieselben Eingangsdaten gleichzeitig gestartet und simultan animiert. Durch Beobachtung des»rennens«kann man meist auf Anhieb erkennen, welches Verfahren effizienter ist. Gute Visualisierungen können auch das Verständnis für objektorientierte Systeme bedeutend erhöhen, indem sie den Lebenslauf von Objekten sichtbar machen. Durch Interaktion mit der Applikation und gleichzeitiger Überwachung der Visualisierung kann der Programmierer feststellen, welche Aktionen neue Objekte erzeugen, welche Objekte zu welchen Zeitpunkten intensiv miteinander kommunizieren, welche Auswirkungen der Polymorphismus auf den Steuerfluß hat usw. Dabei kommt es nicht auf eine möglichst konkrete Repräsentation der involvierten Objekte an, sondern auf eine Darstellung, welche die Analyse der interessierenden Vorgänge bestmöglich unterstützt und durchaus abstrakt sein kann. Beispielsweise können Objekte durch Punkte im zweidimensionalen Raum dargestellt werden, die umso enger zusammenrücken, je intensiver die Objekte miteinander kommunizieren.

266 Zusammenfassung Grafische Benutzungsschnittstellen Es ist unumstritten, daß grafische Benutzungsschnittstellen mit ergonomischer Gestaltung die Akzeptanz und Wirksamkeit eines Softwaresystems gegenüber zeichenorientierten Schnittstellen in der Regel um ein Vielfaches erhöhen. Die Interaktion zwischen Benutzer und System erfolgt bei grafischen Schnittstellen über einprägsame Elemente wie Schaltflächen, Optionsfelder, Schieberegler und visuellen Anzeigeneinheiten, die der Anwender zum Teil von technischen Geräten des Alltags kennt. Durch die unmittelbare optische Wirkung und die Möglichkeit der direkten Manipulation verfügen solche Schnittstellen über ein hohes Motivationspotential, wodurch die Bedienung weniger anstrengend empfunden wird als bei Systemen, die auf textueller Kommandoeingabe beruhen. Eine Reihe weiterer Vorteile, wie leichte Erlernbarkeit, intuitive Handhabung, Reduktion von Fehlerquellen und Anpaßbarkeit an persönliche Bedürfnisse, begründen die überragende Stellung grafischer Benutzungsschnittstellen als Mechanismus für die Interaktion zwischen Anwender und Applikation. Die zentrale Rolle der Mensch-Maschine-Kommunikation beim Einsatz von Softwaresystemen verlangt besondere Aufmerksamkeit bei der Gestaltung der Benutzungsschnittstelle. Pomberger und Blaschek [96 S. 78 f] betonen, daß diese Aufgabe mit Papier und Bleistift alleine nicht bewältigt werden kann, weil neben dem Aufbau der Benutzungsschnittstelle auch die Dynamik der Benutzungsinteraktion spezifiziert werden muß. Sie schlagen deshalb den Bau von Prototypen vor. Sowohl für die Erstellung eines Prototypen als auch für die Realisierung der endgültigen Benutzungsschnittstelle bietet sich der Einsatz von VP-Werkzeugen an, die ein visuelles und interaktives Zusammensetzen der Benutzungsschnittstelle ermöglichen. Verglichen mit dem Aufwand, der für die Realisierung von Benutzungsschnittstellen in einer verbalen Programmiersprache nötig ist, sind die Entwicklungszeiten mit VP- Systemen drastisch geringer. Selbst dedizierte Beschreibungssprachen wie UISL (User Interface Specification Language) von Keller [89] erreichen nicht die Effektivität von Werkzeugen für die visuelle Konstruktion von Benutzungsschnittstellen. Die Gründe dafür liegen auf der Hand. Beim Einsatz verbaler Beschreibungsmittel kann man das Aussehen der Benutzungsschnittstelle nur dadurch kontrollieren, indem man wiederholt aus der verbalen Definition eine ausführbare Applikation erzeugt und startet, das Erscheinungsbild überprüft und wenn notwendig Änderungen an der Beschreibung vornimmt. Der Zyklus»Beschreiben-Generieren-Kontrollieren-Beschreiben«ist außerordentlich zeitraubend und behindert die Kreativität. Zudem ist nicht immer klar, welche Änderungen an der Beschreibung vorzunehmen sind, um ein bestimmtes Erscheinungsbild zu erreichen. Beispielsweise kann die exakte Positionierung eines Elements die Spezifikation von Abmessungen und Bildschirmkoordinaten erzwingen, deren Werte nicht offensichtlich sind. Solche verborgenen Informationen führen meist zu einem frustrierenden Herantasten an das gewünschte Ergebnis. Im Unterschied dazu sind die Auswirkungen von Änderungen bei VP-Werkzeugen sofort ersichtlich und korrigierbar. Hilfsfunktionen wie Ausrichten, Verteilen, Vereinheitlichen, Rotieren und Gruppieren von Elementen machen die Gestaltung einer ansprechenden Oberfläche besonders leicht.

267 8.2 Grenzen visueller Darstellungen in der Programmierung Grenzen visueller Darstellungen in der Programmierung Die Nachteile der Verwendung von Grafiken in der Softwareentwicklung liegen vor allem in jenen Bereichen, wo die eindeutige und knappe Darstellung von Sachverhalten, die rasche und bequeme Änderung komplexer Beschreibungen, die werkzeugunterstützte Bearbeitung von Dokumenten sowie die Formalisierung von Methoden und Notationen im Mittelpunkt steht. Dabei wirken sich u.a. folgende Eigenschaften bildlicher Darstellungen nachteilig aus: Fehlende Standards für Symbole, Notationen und Werkzeuge Geringe Darstellungsdichte Geringer Strukturierungsgrad Hoher Erstellungsaufwand Resistenz gegenüber Modifikationen Ästhetische Aspekte Schwierige Formalisierbarkeit Diese Mängel betreffen leider weite Bereiche der Implementierungsphase, wo ein besonders hoher Rationalisierungsbedarf besteht. Auf der Suche nach durchschaubaren und effektiven Techniken zur Implementierung von Qualitätssoftware sind daher visuelle Sprachen wenig erfolgversprechend. Die nächsten Abschnitte skizzieren, wie die erwähnten Schwachstellen in der Softwareentwicklung zum Tragen kommen Fehlende Standards Eine Reihe von Normen und ungeschriebenen Übereinkommen, ohne deren Existenz die wirtschaftliche Herstellung von Software undenkbar wäre, ermöglichen den Austausch und die Weiterverarbeitung von Artefakten, die im Zusammenhang mit der Softwareentwicklung von Bedeutung sind. Gängige Standards umfassen Bereiche wie Zeichenkodierungen, Dokumentstrukturen und Metasprachen. Auch die Festlegung der Schreib- und Leserichtung, die man im Grunde als selbstverständlich empfindet, hat in Verbindung mit der damit einhergehenden Sequentialisierung großen Anteil an der leichten Manipulierbarkeit von Text. Viele Werkzeuge arbeiten als sequentielle Transformatoren, die Zeichenströme lesen, bearbeiten und verändert ausgeben. Solche Transformatoren sind vielfältig kombinierbar, weil sie einfache Schnittstellen besitzen und die Eingabedaten eine homogene Struktur aufweisen. Als Schnittstelle reicht eine Dateiverbindung oder ein Interprozeßkommunikationskanal und als Datenformat genügt eine Folge von Zeilen mit Zeichen eines Standardcodes. Die Unix-Werkzeugsammlung ist ein exzellentes Beispiel für die Nützlichkeit solcher Transformatoren, die man flexibel zu Ketten verbinden und mit beliebigen Texten»füttern«kann. Werkzeuge wie awk, sed, sort und grep sind durch ihre universelle Verwendbarkeit zu De-facto-Standards geworden. Für allgemeine visuelle Notationen im Bereich der Softwaretechnik gibt es kaum Standards, sieht man von Normen für bestimmte Darstellungen ab, zu denen etwa Flußdiagramme oder SDL-Charts gehören. Mangels Normen oder De-facto-Standards für Entwurfsnotationen und visuelle Programmiersprachen gibt es auch kaum Werkzeuge mit einheitlichen Schnittstellen, die visuelle Softwarebeschreibungen und Programme austauschen, interpretieren und verarbeiten können. Jeder Hersteller von VP-Produkten entwickelt ein eigenes grafisches Vokabular und proprietäre Datenstrukturen, auf die alle Werkzeuge der Entwicklungsumgebung abgestimmt sein müssen. Die Werkzeuge

268 Zusammenfassung 258 eines Herstellers bilden somit ein geschlossenes System, das mit keiner anderen Umgebung kommunizieren kann. Eine Übereinkunft zu Darstellungsstandards, Austauschformaten und visuellen Sprachen liegt in weiter Ferne. Der Käufer eines VP-Systems begibt sich damit in eine starke Abhängigkeit vom Hersteller mit allen damit verbundenen Nachteilen. Die Situation in der Softwareentwicklung unterscheidet sich damit grundsätzlich von jener der Hardwaretechnik, wo eine Vielzahl von Normen für grafische Darstellungen existieren, etwa für Schaltpläne von elektronischen Bausteinen oder für Konstruktionspläne von mechanischen Teilen Unökonomische Bildschirmnutzung Ein Schwachpunkt grafischer Notationen ist die unökonomische Nutzung der zur Verfügung stehenden Darstellungsfläche. Nickerson [94 S.195 u. S. 323 f] hat sich um Metriken für die Darstellungsdichte von textuellen und grafischen Notationen bemüht und kommt zum Schluß, daß wegen des begrenzten Auflösungsvermögens von Ausgabeeinheiten und Auge rein textuelle Notationen immer dichter sind als gemischt grafisch/textuelle Repräsentationen. Bild 8-1 zeigt die annähernd flächengleiche Darstellung der textuellen und der grafischen Version des Programms getsline aus Abschnitt Nicht nur die Lesbarkeit unterscheidet sich gravierend zuungunsten der grafischen Darstellung es ist auch unmöglich, eine derart verkleinerte Grafik zu modifizieren. Die Grafik in Originalgröße nimmt ca. 18mal mehr Platz ein als der Text. Selbst wenn der Leerraum zwischen den einzelnen grafischen Elementen reduziert würde, was aus Gründen der Ästhetik und Lesbarkeit nur bedingt möglich ist, ändert sich das Verhältnis beim Platzbedarf nur unwesentlich. Dazu kommt, daß der grafische Programmcode aus Bild 8-1 nicht das gesamte Programm zeigt, weil nur die True-Zweige der Bedingungen sichtbar sind. Die False-Zweige verbergen sich dahinter und müssen vom Programmierer explizit in den Vordergrund gebracht werden, wodurch sie wiederum die True-Zweige verdecken. Green und Petre [94 S. 19] haben vermutlich recht, wenn sie feststellen, daß textuelle Programmiersprachen gewöhnlich eine bessere Sichtbarkeit aufweisen als visuelle Programmiersprachen (so eigenartig das auch klingen mag). Sie messen den Grad der Sichtbarkeit an der Anzahl der Schritte, die notwendig sind, um ein bestimmtes Element einer Darstellung wahrzunehmen. Wegen der schlechten Bildschirmnutzung wird visueller Programmcode meist in kleinen Portionen über mehrere Bildschirmfenster verteilt, um Platz zu gewinnen, oder es wird zu Mechanismen gegriffen, bei denen sich Programmteile überlagern. Eine andere Möglichkeit, den verfügbaren Bildschirmplatz besser zu nutzen, sind Überblicksdarstellungen mit Verzicht auf Details. Gorlick und Quilici [94 S. 140 f] haben für das VP-System Weaves einen Zooming-Mechanismus entwickelt, der eine Fern- und Nahsicht auf Programmstrukturen erlaubt. Alle diese Ansätze erfordern eine Vielzahl von Aktionen, bis ein bestimmtes grafisches Element samt Kontext gut erkennbar am Bildschirm erscheint. Dazu gehören Suchen oder Öffnen des umschließenden Fensters, Verschieben des Bildschirmausschnittes, Vergrößern oder Verkleinern der Darstellung usw. Wegen der geringen Dichte grafischer Notationen ist es entweder unmöglich oder sehr schwierig, einen Gesamteindruck von einem nicht-trivialen Programm zu bekommen. Selbst wenn ein visuelles Programm auf Papier ausgedruckt vorliegt, verbessert sich die Situation nicht. Im Gegenteil: Programmteile, die nicht auf ein einzelnes Blatt Papier

269 8.2 Grenzen visueller Darstellungen in der Programmierung 259 passen, müssen wie ein Puzzle zusammengeklebt werden. Diese äußerst mühevolle und fehleranfällige Prozedur steht dem Bedürfnis nach wirtschaftlicher Softwareentwicklung diametral entgegen. Burnett et al. [95 S. 46 ff] weisen darauf hin, daß noch keineswegs alle Ergebnisse der Forschung zur effektiven Anzeige von grafischen Darstellungen und zur Navigation in grafischen Räumen auf visuelle Programmierung umgelegt wurden. Sie erwähnen aktuelle Ansätze aus der Datenvisualisierung, die mit Hilfe perspektivischer Darstellungen, rotierender Baumstrukturen und Fischaugensichten gleichzeitig Detailreichtum und Kontextinformation ermöglichen. Ob solche Ansätze auch auf visuelle Programmiersprachen anwendbar sind, ist allerdings noch ungeklärt. char *getsline (buf, size, fp) char *buf; unsigned int size; FILE *fp; { register int len; while (fgets(buf, (int) size, fp)!= NULL) { len = strlen (buf); if (len > 0 && buf[len - 1] == \n ) buf[len - 1] = \0 ; /* If it s not a comment, return it, else loop around. */ if (buf[0]!= # ) return (buf); } return (NULL) } Bild 8-1. Annähernd flächengleiche Darstellung von textuellem und grafischem Programmcode der gleichen Funktion. Während die textuelle Repräsentation problemlos lesbar ist, kann die grafische Darstellung bei einer Standard-Bildschirmauflösung von 72 dpi nicht entziffert werden. Die Darstellung des grafischen Programmcodes in Originalgröße nimmt ca. 18mal mehr Platz ein als der textuelle Programmcode Schlechte Skalierbarkeit Die Skalierbarkeit einer Sprache gibt an, inwieweit sie zur Beschreibung einfacher und komplexer Sachverhalte gleichermaßen gut geeignet ist. Eine gute Skalierbarkeit geht Hand in Hand mit einem Formulierungsaufwand, der relativ zur Problemgröße etwa gleich bleibt. Der Formulierungsaufwand ist ein Maß dafür, wie viele Details die Beschreibung einer Problemlösung umfaßt. Sprachen mit hohem Formulierungsaufwand verlangen für die Beschreibung einer Problemlösung umfangreiche und detaillierte Ausdrücke auf einer niedrigen Abstraktionsebene. Sprachen mit geringem Formulierungsaufwand stellen problembezogene Konstrukte auf einer hohen Abstraktionsebene zur Verfügung. Im Vergleich zu Sprachen auf verbaler Basis ist die Skalierbarkeit visueller Sprachen meist gering. Der Grund für den hohen Formulierungsaufwand für visuelle Sprachen ist in den geringen optischen Strukturierungsmöglichkeiten bei gleichzeitig hohen ästhetischen Anforderungen zu suchen und wird durch die Resistenz gegenüber Modifikatio-

270 Zusammenfassung 260 nen zusätzlich verschärft. Durch die schlechte Skalierbarkeit können nur einfache Probleme mit geringem Formulierungsaufwand gelöst werden, die Lösung komplexer Probleme verlangt jedoch unverhältnismäßig große Anstrengungen. Poswig [93 S. 33] weist in diesem Zusammenhang darauf hin, daß bei visuellen Programmiersprachen der Formulierungsaufwand nicht an der Mächtigkeit der Sprache alleine gemessen werden darf, sondern auch die Interaktion mit dem Grafikeditor einbezogen werden muß, der bei der Programmkonstruktion zum Einsatz kommt. Der Zusatzaufwand für das Auswählen grafischer Elemente, ihre exakte Positionierung und Verknüpfung darf nicht unterschätzt werden. Die damit verbundenen Aktionen können sich äußerst störend auswirken, wenn Lösungsideen um vieles rascher entstehen, als sie notiert werden können. In diesem Zusammenhang empfinden Green und Petre [94 S. 16 f] den Zwang zur Vorausschau als besonders kontraproduktiv. Sie verstehen darunter jene unangenehme Situation bei der Erstellung von Grafiken, in der Entscheidungen über die äußere Gestaltung zu treffen sind, bevor man über die nötigen Informationen verfügt. Sie nennen als Beispiel das Skizzieren einer Wegekarte von zu Hause zum Arbeitsplatz [S. 17; OZ 49]: Man beginnt eine Karte der Wegstrecke von zu Hause zum Arbeitsplatz zu skizzieren. Wo soll man den ersten Strich aufs Papier setzen, und wie groß soll man die ersten Objekte einzeichnen? Man muß vorausschauen und im Kopf eine grobe Schätzung durchführen. Wenn zuwenig Platz übrigbleibt, weil es eine Menge kleiner Kurven gibt, auf die man am Anfang vergessen hat, wird man wahrscheinlich ein neues Blatt holen und von vorne beginnen müssen Papier ist kein besonders duldsames Medium beim für das Zeichnen von Karten. In verbalen Sprachen ist eine Vorausplanung der äußeren Form kaum notwendig, weil man jederzeit Text ändern, löschen und einfügen kann, ohne die Anordnung der vorhergehenden und nachfolgenden Teile zu verändern. Hingegen führt in visuellen Sprachen mangelnde Planung unweigerlich zu Überdeckungen und Spaghetticode. Der Zwang zur Vorausschau ist allgegenwärtig und behindert permanent die schöpferische Gedankenfindung. Poswig [93 S. 23] schreibt über seine schlechten Erfahrungen bei Erstellung eines Miniprogramms zur Berechnung des inneren Produkts zweier Vektoren mit sieben grafischen Elementen: Selbst bei diesem kleinen Beispiel ist ein Problem bei der Konstruktion visueller Programme in LabVIEW offenkundig geworden die richtige Dimensionierung der Sprachkonstrukte, die Programmteile umschließen sollen. Umständlich ist nach unserer Meinung, daß zunächst die benötigte Fläche abgeschätzt werden muß, um dann das Innenleben hineinzuschieben. Wehe dem, der sich verschätzt oder etwas vergißt! Nachträgliche Änderungen führen nicht selten zu einer Neukonstruktion. Trotz sorgfältiger Planung ist es in visuellen Sprachen schwierig, ein optisches Wirrwarr zu vermeiden. Leider sorgt die hohe Resistenz gegen Modifikationen zusätzlich für einen hohen Zeitaufwand bei der Beseitigung von Layout-Problemen. Man ist deshalb leicht versucht, die Flinte ins Korn zu werfen und einen negativen optischen Eindruck samt der damit verbunden schlechte Lesbarkeit in Kauf zu nehmen. Glücklich ist man mit solchen Programmen trotzdem nicht, weil das Auge, das an Grafik höhere ästhetische Anforderungen stellt als an Text und durch schiefe Linien, Überkreuzungen, Verdeckungen, Asymmetrien usw. ständig beleidigt wird.

271 8.2 Grenzen visueller Darstellungen in der Programmierung 261 Eine gute Skalierbarkeit verlangt weiters gute Strukturierungsmöglichkeiten. Dies gilt nicht nur für die Definition der Programmlogik, sondern auch für die Gestaltung der äußeren Form. Leicht erfaßbare Beschreibungen komplexer Sachverhalte werden nur dann gelingen, wenn sie auf konsequent eingehaltenen Stilregeln beruhen. Eingangs wurde bereits auf die wichtige Rolle der sekundären Notation hingewiesen, mit der durch gestaltende Maßnahmen wie Gruppierungen, Leerraum und Positionierungen informelle Interpretationshilfen für die formalen Ausdrücke einer Beschreibung gegeben werden können. Verbale Programmiersprachen bieten viele Möglichkeiten für den effizienten Einsatz sekundärer Notation. Dazu gehören die konsistente Gliederung von Programmgruppen, etwa der Schnittstellenbeschreibung eines Moduls (z.b. in der Reihenfolge Typen, Konstanten, Variablen und Prozeduren), die optische Trennung von Deklarationsteil und Anweisungsteil, die Gruppierung von zusammengehörenden Anweisungen zu Absätzen, systematische Einrückungen und andere nützliche Lesehilfen. Green und Petre [94 S. 19] weisen darauf hin, daß gängige visuelle Programmiersysteme den Einsatz sekundärer Notation kaum unterstützen und führen als Beispiele Lab- VIEW und Prograph an. Beiden Systemen fehlen Mechanismen zur Gruppierung von Anweisungen, die ähnlich einfach funktionieren wie das Zusammenstellen von eng gekoppeltem Quelltext zu Absätzen. Bezüglich der Skalierbarkeit visueller Sprachen soll zuletzt noch auf die hohe Resistenz gegenüber Modifikationen eingegangen werden. Green und Petre sprechen in diesem Zusammenhang von Viskosität und meinen damit den Widerstand, den ein Benutzer überwinden muß, um eine bestimmte Änderung zu bewirken [S. 10]. Konventionelle Programmiersprachen besitzen eine hohe Viskosität, wenn es darum geht, globale Änderungen vorzunehmen, weil meist viele versteckte Abhängigkeiten existieren. Beispielsweise kann die Umbenennung einer Variablen zu nicht unerheblichen Schwierigkeiten führen, weil Gültigkeitsbereiche, reservierte Bezeichner und ähnliche Feinheiten zu berücksichtigen sind. Visuelle Programmiersprachen und hier speziell Datenflußsprachen, die keine Variablen kennen, haben diesbezüglich keine Probleme, besitzen jedoch eine extrem hohe Viskosität gegenüber strukturellen Änderungen. Messungen von Green und Petre beim Einfügen einer einfachen zusätzlichen Berechnung in ein kleines Programmstück ergaben für LabVIEW 508 Sekunden, für Prograph 194 Sekunden und für Basic 63 Sekunden [S. 11]. Der Zeitaufwand in der grafischen Programmierumgebung LabVIEW war also ca. achtmal so hoch wie in der textuellen Sprache Basic. Es ist zu erwarten, daß sich das Verhältnis bei größeren Programmen weiter zuungunsten der visuellen Programmiersprachen verschiebt. Der Grund für den hohen Zeitbedarf liegt in der großen Anzahl von Aktionen, die bei Modifikationen an einem visuellen Programm nötig sind. Während es bei Text genügt, den Cursor an eine bestimmte Stelle zu setzen und mit dem Tippen anzufangen, muß bei Grafik die Umgebung der modifizierten Stelle aus optischen Gründen vielfach ebenfalls geändert werden, was schnell zu einem Schneeballeffekt führt Formale Handhabbarkeit Welche Metasprachen geeignet sind, um Grammatiken, semantische Bedingungen und Transformationsregeln für visuelle Sprachen zu definieren, ist trotz einer Vielzahl von theoretischen Arbeiten ungeklärt. Während verbale Sprachen, durch ihre eindimensionale Struktur für Beschreibungen durch Metasprachen gut zugänglich sind, sind solche Beschreibungen für mehrdimensionale, visuelle Sprachen nur schwer möglich. Der Erfolg von Ansätzen aus den Bereich der verbalen Sprachen, wie BNF oder EBNF zur Be-

272 Zusammenfassung 262 schreibung der Syntax und Lambda-Kalkül oder FFP zur Definition einer Algebra für Programme, konnte für visuelle Sprachen bisher nicht wiederholt werden. Das Haupthindernis für geeignete Formalismen liegt vor allem darin, daß visuelle Sprachen durch ihren mehrdimensionalen Charakter eine Vielzahl von Eigenschaften aufweisen. Es ist schwierig, eine Metasprache zu finden, die alle Eigenschaften gleichermaßen gut abdeckt und trotzdem verständlich ist. Während in verbalen Sprachen, die lexikalischen Grundeinheiten aus einfachen Symbolen (Zeichen oder Worte) bestehen und die syntaktische Beziehung zwischen den Symbolen ausschließlich durch die Hintereinanderaufschreibung festgelegt wird, ist die Situation bei visuellen Sprachen vielschichtiger: Bei visuellen Sprachen können verschiedene Klassen von Beziehungen auftreten, etwa geometrische Relationen (z.b. Größenverhältnisse und Positionen) oder topologische Relationen (z.b. Vernetzungen, Berührungen und Schachtelungen), die kaum mit einem einzigen Formalismus abgedeckt werden können. Zudem sind dynamische Aspekte (z.b. Bewegung, Farbänderungen und Blinken), die in VP-Systemen ebenfalls eine große Rolle spielen, mit statischen Beschreibungen prinzipiell schwer zu erfassen. Darüber hinaus sollten effiziente Parsing-Algorithmen existieren. Es ist aber bekannt, daß einige der graphentheoretischen Probleme, die solche Algorithmen zu lösen haben, eine hohe, oftmals sogar exponentielle Laufzeitkomplexität aufweisen und deshalb für praktische Zwecke ungeeignet sind (vgl. Ferrucci et al. [91 S. 107], Marriot [94 S. 121 f u. S. 124] sowie Rekers und Schürr [95 S. 199]). Die schwierige formale Handhabbarkeit behindert die Entwicklung einer Theorie der visuellen Sprachen. Praxisrelevante Grundlagenforschung, wie sie für verbale Sprachen existiert, beispielsweise zu den Themenbereichen Korrektheitsbeweise, Typsysteme, Spezifikation und Entwurfsmuster findet sich bei visuellen Sprachen kaum. Dadurch sind visuelle Sprachen und die darauf basierende Software nicht selten von Ad-hoc- Überlegungen beeinflußt. Zudem ist ohne adäquate Formalisierung die Entwicklung offener Werkzeuge unmöglich, was zu den im Abschnitt»Fehlende Standards«genannten Nachteilen führt. 8.3 Schlußfolgerungen Die Meinungen darüber, ob visuelle Programmiertechniken die Softwareentwicklung einfacher machen und zu besseren Programmen führen, gehen weit auseinander. Zur Erstellung komplexer Programmsysteme ist visuelle Programmierung wegen der schlechten Skalierbarkeit nur bedingt geeignet. Mit Skepsis sollte man deshalb Versprechungen begegnen, daß die Softwareentwicklung damit vereinfacht wird. Die in diesem Zusammenhang gern genannte Natürlichkeit von Bildern kann in der formalen Welt der Programmierung ein Nachteil sein, weil es dort auf eine präzise Beschreibung von abstrakten Sachverhalten ankommt, der das oft mehrdeutige und zu konkrete Erscheinungsbild bildlicher Illustrationen entgegensteht. Anfangs motivierende Interaktionsmechanismen (z.b. direkte Manipulation und ansprechende Symbolbilder) können störend wirken, wenn große und komplexe Komponenten zu erstellen sind. Ohne adäquate Editiermöglichkeiten wird der Aufwand für eine ästhetisch befriedigende Gestaltung von Programmcode schnell inakzeptabel hoch. Stark vernetzte Strukturen, wie sie in der Programmierung der Regelfall sind, scheinen einer produktiven Bearbeitung durch grafische Editoren kaum zugänglich zu sein. Petre [95 S. 42; OZ 50] zitiert einen ernüchterten Programmierer mit folgenden Worten:»Ich verbringe oft ein oder zwei Stunden

273 8.3 Schlußfolgerungen 263 damit, Rechtecke und Linien am Bildschirm zu verschieben, ohne die Funktionalität zu ändern, nur um das Programm verständlicher zu machen«. Auf der Suche nach Ansätzen zur professionellen und rationellen Entwicklung allgemeiner Softwaresysteme ist visuelle Programmierung deshalb als Sackgasse zu beurteilen. Die Stärken der visuellen Programmierung liegen in speziellen Anwendungsgebieten, wo überschaubare und abgegrenzte Problemstellungen durch visuelle Metaphern gut erfaßbar sind. Beispiele dafür sind die Programmierung virtueller Instrumente und Bereiche der Automatisierungstechnik. In Spezialgebieten kann visuelle Programmierung auch Anwender in die Lage versetzen, kleine und überschaubare Programme zu erstellen, die sonst Softwareingenieure schreiben müßten. Ebenfalls von hohem Wert sind grafische Darstellungen softwaretechnischer Sachverhalte in Form von Entwurfsskizzen und Visualisierungen, wenn auf Details zugunsten der Verständlichkeit verzichtet wird. Ob der zugrundeliegende Programmcode verbal oder visuell erstellt wurde, ist in diesem Zusammenhang von untergeordneter Bedeutung.

274 Zusammenfassung 264 Anhang A: Hinweise für die Leser Genus für Personenbezeichnungen Entsprechend der im Deutschen üblichen Verwendung des grammatischen Geschlechts für Personenbezeichnungen, wird die maskuline Form auch dann verwendet, wenn das natürliche Geschlecht unwichtig ist oder sowohl männliche als auch weibliche Personen gemeint sind. In diesem Sinne sind»der Leser«und ähnliche Maskulina ausdrücklich geschlechtsneutral gemeint und sprechen auch weibliche Personen an. Typographie Hervorhebungen und wichtige Begriffe werden durch Kursivschrift gekennzeichnet. Eigennamen (ausgenommen Personennamen) werden bei der ersten Verwendung ebenfalls durch Kursivschrift gekennzeichnet, es sei denn, diese Namen sind allgemein gebräuchlich oder in den Wortschatz der Informatik eingegangen (z.b. Fortran, als Name einer Programmiersprache). Nicht gekennzeichnete Eigennamen berechtigen nicht zur Annahme, daß sie keine geschützten Warenzeichen oder Marken sind. Zitierung Anstelle der weitverbreiteten Form von Literaturreferenzen, bei der sowohl Autor als auch Erscheinungsjahr in eckige Klammern eingefaßt sind (z.b. [Kay 93]), werden in diesem Buch nur Erscheinungsjahr und Seitenangaben in eckige Klammern gesetzt. Der Name des Autors wird in den Text integriert. Diese Form verbessert den Ausdruck und Lesefluß. Beispiel: Ivan E. Sutherland implementierte 1963 das Zeichenprogramm Sketchpad, das Kay [93 S. 71] als erstes brauchbares System mit grafischer Interaktion bezeichnet. 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. Bis zu zwei Autoren werden direkt angeführt, ab drei Autoren wird nur der erste Autor mit dem Zusatz»et al.«genannt. Die in dieser Passage referenzierten Literaturquellen sind im Literaturverzeichnis wie folgt vermerkt: Kay [93] Alan C. Kay: The Early History of Smalltalk; in ACMSP, Vol. 28, No. 2, Mar. 1993, Frei et al. [78] H.P. Frei, D.L. Weller, R. Williams: A Graphics-Based Programming Support System; ACM Computer Graphics (Proceedings SIGGRAPH), Vol. 12, No. 3, August 1978, 43-49; auch in Glinert [90-P&S], Falls die Vornamen der Autoren bekannt sind, werden sie im Literaturverzeichnis ausgeschrieben (z.b. Alan C. Kay), sonst werden nur die Initialien angeführt (z.b. H.P. Frei). Die Referenz»in ACMSP«bei Kay [93] verweist auf die Zeitschrift ACM SIGPLAN Notices. Die abkürzende Schreibweise»in XYZ«wird für Beiträge in oft zitierten Fachzeitschriften, Buchreihen, Tagungsbänden usw. verwendet.»xyz«ist ein Querverweis an jene Stelle im Literaturverzeichnis, wo die genaue Quellenangabe zu finden ist. Der Zusatz»auch in Glinert [90-P&S], «bei Frei et al. [78] bedeutet, daß der Arti-

275 8.3 Schlußfolgerungen 265 kel nicht nur bei ACM Computer Graphics, sondern auch im Sammelband Glinert [90- P&S] im Nachdruck erschienen ist. Die beiden Querverweise sind im Literaturverzeichnis wie folgt vermerkt. ACMSP Glinert [90-P&S] ACM SIGPLAN Notices; Association for Computing Machinery Ephraim P. Glinert (ed.): Visual Programming Environments: Paradigms and Systems; IEEE Computer Society Press 1990 Zusätze hinter dem Erscheinungsjahr (z.b.»-p&s«) unterscheiden Einträge mit derselben Referenz im gleichen Jahr. Literaturquellen werden entweder im ganzen referenziert (z.b. Frei et al. [78]) oder mit Angabe jener Seite, wo die Kernaussage zu finden ist (z.b. Kay [93 S. 71]). Falls mehrere Referenzen derselben Literaturquelle unmittelbar aufeinanderfolgen, so wird ab der zweiten Referenz nur noch die Seite in Klammern gesetzt, das Erscheinungsjahr jedoch nicht mehr wiederholt. Beispiel: Das Bild zeigt ein Programm der funktionalen Sprache VisaVis, die Poswig [93 S. 52 ff] im Rahmen seiner Dissertation entwickelt hat. Poswig begründet die Universalität von VisaVis anhand eines Äquivalenzsatzes aus der Theorie der funktionalen Sprachen, der aussagt, daß die Klasse der auf Turingmaschinen berechenbaren Funktionen gleich der Klasse der partiell rekursiven Funktionen ist [S. 110 ff]. Poswig [93 S. 52 ff] referenziert jene Seite in Poswigs Dissertation, ab der VisaVis beschrieben wird, während [S. 110 ff] auf jene Seiten verweist, wo Poswig die Universalität von VisaVis zeigt. Wenn nur ein Nachdruck, nicht aber der Originalartikel verfügbar war, dann beziehen sich die Seitenangaben auf den Nachdruck. Beispiel: Dem widersprechen Ambler und Burnett [89] in Glinert [90-P&S S. 26], indem sie darauf hinweisen, daß es für»natürliche«visuelle Programmiersprachen, durch die ein neues Programmierparadigma entsteht, möglicherweise keine Einszu-Eins-Abbildung in Textform gibt. Ambler und Burnett verfaßten 1989 einen Artikel, der im Sammelband Glinert [90- P&S] nachgedruckt wurde. Die Aussage zu natürlichen visuellen Programmiersprachen findet sich im Sammelband auf Seite 26. Im Literaturverzeichnis sind Originalartikel und Sammelband wie folgt angeführt: Ambler und Burnett [89] Allen L. Ambler, Margaret M. Burnett: Influence of Visual Technology on the Evolution of Language Environments; Computer, October 1989, 9-22; auch in Glinert [90-P&S], Glinert [90-P&S] Ephraim P. Glinert (ed.): Visual Programming Environments: Paradigms and Systems; IEEE Computer Society Press 1990 Literaturreferenzen werden nachgestellt, wenn ihre Textintegration zu umständlichen Konstruktionen führen würde. In diesem Fall wird die Quellenangabe mit»vergleiche«(abgekürzt»vgl.«) eingeleitet. Beispiel: 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]). Wörtliche Zitate sind immer besonders gekennzeichnet. Kurze Zitate werden unter Apostrophe im Fließtext angeführt, längere Zitate durch Einrückung kenntlich gemacht.

276 Zusammenfassung 266 Wenn möglich, werden Hervorhebungen des Originaltextes (z.b. Kursivschrift) auch im Zitat nachgeführt. Anmerkungen und grammatische Anpassungen werden in eckige Klammern [ ] gesetzt, Auslassungen durch Ellipsensymbole [...] gekennzeichnet. Wörtliche Zitate aus dem Englischen wurden ins Deutsche übersetzt. Die englischen Originalzitate sind im Anhang unter der Nummer zu finden, die bei der deutschen Übersetzung nach der Abkürzung»OZ«(Originalzitat) angeführt ist. Bilder Bilder, die ohne wesentliche Änderungen aus anderen Werken übernommen wurden, werden mit Autor, Seite und (falls vorhanden) Bildnummer referenziert. Bei Bildern aus anderen Werken, die zur besseren Wiedergabe oder Verständlichkeit wesentlich verändert wurden, wird der Quellenangabe das Wort»vergleiche«(abgekürzt»vgl.«) vorangestellt. Abbildungen der Benutzungsschnittstelle von Programmen (Bildschirmabzüge), werden nur dann referenziert, wenn die Bildschirmabzüge einem anderen Werk entnommen wurden. Erläuterungen, die zum besseren Verständnis eines Bildes notwendig sind, werden direkt unterhalb des Bildes angeführt und nicht im Haupttext. Das hat zwei Vorteile: einerseits wird ein direkter Bezug zwischen Bild und Bilderklärung hergestellt, und andererseits kann der eilige Leser die Erläuterungen überspringen. Manche Bilder sind nur in Farbe verständlich. Aus drucktechnischen Gründen werden diese Bilder im Hauptteil in Grautönen dargestellt, jedoch in einem separaten Farbteil samt Erläuterungen wiederholt. Im Hauptteil sind solche Bilder mit»farbbild im Anhang«gekennzeichnet. Die Bildschirmabzüge wurden auf PCs mit MacOS und Windows 95 erstellt. Entsprechend unterscheidet sich das Aussehen der Benutzungsschnittstelle. Das visuelle Programmiersystem Vista wurde mit der Programmierumgebung VisualWorks auf Sun- Sparcstations entwickelt. Auf den Sparcstations wurde unter OpenLook programmiert, die Bildschirmabzüge wurden jedoch auf einem PC mit Windows 95 erstellt. Das Aussehen von Eingabefeldern, Schaltflächen, Menüs usw. entspricht deshalb OpenLook, während die Rahmen der Programmfenster der Darstellung von Windows 95 entsprechen. (Anmerkung für VisualWorks-Experten: die Möglichkeit der plattformspezifischen Darstellung wurde von der verwendeten Version für Windows 95 nicht unterstützt). World Wide Web Verweise auf Ressourcen im World Wide Web (WWW) werden im Text mit [WWW] gekennzeichnet. Beispiel: Die folgenden Ausführungen beziehen sich auf LabVIEW Version 3.0; für die aktuelle Version siehe LabVIEW [WWW]. Im Literaturverzeichnis ist LabVIEW [WWW] wie folgt angeführt: LabVIEW [WWW] National Instruments Home Page; Im allgemeinen wird nur der Verweis auf die Startseite des jeweiligen Anbieters angeführt, weil sich die Struktur der Unterseiten häufig ändert und genaue Angaben deshalb schnell veralten. Ausgehend von der Startseite, ist die referenzierte Ressource meist schnell zu finden.

277 8.3 Schlußfolgerungen 267 In der HTML-Version des Buches auf der beigelegten CD-ROM, sind die Verweise durch Anklicken anwählbar, wodurch bei einer aktiven Internet-Verbindung die entsprechende WWW-Seite geöffnet wird.

278 268 Anhang B: Englische Originalzitate Nr. Übersetzung auf Seite Quelle Text 1 1 Knuth [73 S. 4] An algorithm must be seen to be believed, and the best way to learn what an algorithm is all about is to try it. 2 5 Chang [94-2 S.196] The predecessor of the IEEE Symposium on Visual Languages (VL in short) is the IEEE Workshop on Picture Data Description and Management. The first of the IEEE PDDM workshops, organized by K. S. Fu and me, was held in Chicago in As the title implies, the two themes are the description, and the management, of pictorial data. The two themes later on led to two separate and equally active research areas: visual languages and visual databases. Many of the»old guards«of the VL community were from the image processing and computer vision community. Tad Ichikawa, Stefano Levialdi, Steven Tanimoto and many others from that community were all actively involved in the PDDM workshops. [...] After a few years, many of us realized that the issue is not only the description of pictorial information, but also how to effectively use pictures to communicate. The IEEE Workshop on Languages for Automation was organized by me and first held in The agenda of the LFA workshop included information retrieval languages, pictorial query languages, languages for robotics and specification languages. As a result, information scientists with interests in visualization, such as Bob Korfhage, became actively involved in the LFA workshops. The community of researchers interested in visual-related issues began to grow. In 1983, Tad Ichikawa suggested to organize a new series of workshops with special emphasis on visual languages. [...] Tad worked tirelessly to organize the 1984 workshop in Hiroshima [...] 3 6 Snell [95 S. 9] So if you build a small application and want to scale that up to a department or an enterprise-wide tool, how do you do it? Do you throw away the tool and start developing from scratch? 4 7 Shu [88 S. v] The challenge of this decade is to bring computer capabilities, simply and usefully, to people without special training in programming. Visual Programming represents a conceptually revolutionary approach to meet this challenge. [...] However, even though work on visual-oriented computing is now mushrooming, there is no consensus on what visual programming is, let alone on a way to assess it Chang [90 S. 2] The term visual language means different things to different people. To some, it means the objects handled by the language are visual. To others, it means the language itself is visual. To the first group of people, visual language means language for processing visual information or visual information processing language. To the second group of people, visual language means language for programming with visual expression or visual programming language.

279 Shu [88 S. 136] [...] (1) languages for processing visual information, (2) languages for supporting visual interaction, and (3) languages for programming with visual expressions, i. e., the visual programming languages Lakin [86 S. 45] A visual language is a set of spatial arrangements of text-graphic symbols with a semantic interpretation that is used in carrying out communicative actions in the world Shu [88 S. 9]. We use the term»visual Programming«to mean the use of meaningful graphic representations in the process of programming Chang [90 S. vi] Burnett und McIntyre [95 S. 14] Grafton und Ichikawa [85 S. 7] Myers [94 S. 877] By visual programming we mean the use of visual expressions (such as icons, drawings or gestures) in the process of programming. Visual programming uses visual expressions such as diagrams, free-hand sketches, icons, or even graphical manipulations. When a programming language s syntax includes these expressions, it is called a visual programming language (VPL). A visual programming environment (VPE) provides visual ways of working with a programming language, whether the language is visual or textual. The general notion of graphical programming is that an arrangement of graphical symbols and icons in two (or possible more) dimensions represents the program. Visual programming (VP) refers to any system that allows the user to specify a program in two-(or more)-dimensional fashion. Although this is a very broad definition, conventional textual languages are not considered two dimensional since the compilers or interpreters process them as long, one-dimensional streams Shu [88 S. 138] A visual programming language can be informally defined as a language which uses some visual representations (in addition to or in place of words and numbers) to accomplish what would otherwise have to be written in a traditional one-dimensional programming language Ambler und Burnett [89] in Glinert [90- P&S S. 26] Smith [87-2 S. 11] Myers [94 S. 878] Visual languages are generally subdivided into two categories. The first category, visually transformed languages, includes those visual languages that are inherently nonvisual but have superimposed visual representations. [...] They emphasize facilitating our ability to specify and comprehend programs using existing language paradigms. The second category, naturally visual languages, attempts to develop new programming paradigms whose inherent natural expression is visual and for which there may be no strictly textual equivalent. Some process or algorithm is described; The interface involves graphics displays and pointing devices; The process or algorithm can be executed; The use of text is minimized; in particular the process or algorithm is not described by text. Program visualization (PV) is an entirely different concept from visual programming. In visual programming, the graphics are used to create the program itself, but in program visualization,

280 Price et al. [93 S. 212] Price et al. [93 S. 213] Hoare [85 S. 35] the program is specified in a conventional, textual manner, and the graphics are used to illustrate some aspects of the program or its run-time execution. Unfortunately, in the past, many program visualization systems have been incorrectly labeled visual programming [...] Program visualization systems can be classified using two axes: whether they illustrate the code, data, or algorithm of the program, and whether they are dynamic or static. Program visualization (PV) has been defined by several authors, but the general consensus is that it is the use of various techniques to enhance the human understanding of computer programs, while visual programming (VP) is the use of visual techniques to specify a program in the first place. The problem with the term program visualization is that it becomes ambiguous when considered in the context of its constituent parts. Algorithm visualization (or animation) is understood to be the visualization of a high-level description of a piece of software, which is in contrast to code or data visualization (which are collectively a kind of program visualization) where actual implemented code is visualized. We prefer the term software visualization (hence SV) to include all of these because it eliminates the ambiguity and covers all of the software design process from planning to implementation. It also includes software composed of multiple programs. We define SV as the use of the crafts of typography, graphic design, animation and cinematography with modern humancomputer interaction technology to facilitate both the human understanding and effective use of computer software. Clearly, these two different pictures illustrate exactly the same process [...] It is one of the weaknesses of pictures that proofs of such an equality are difficult to conduct pictorially Petre [95 S. 34] The implicit model behind at least some of the claims that graphical representations are superiour to textual ones is that the programmer takes in a program in the same way that a viewer takes in a painting: by standing in front of it and soaking it in, letting the eye wander from place to place, receiving a gestalt impression of the whole. But one purpose of programs is to present information clearly and unambiguously. Effective use requires purposeful perusal, not the unfettered, wandering eye of the casual art viewer. The aim is not poetic interpretation, but reliable interpretation Kahn und Saraswat [90 S. 8] Raeder [85 S. 12] In many cases it [topological complete visualization, Anm. d. Verf.] is more concise than text and often the same information can be represented much more elegantly. Good pictures that incorporate real-world objects and are used to depict abstractions will help not only the specialist to formulate and communicate thoughts faster and better, but also aid the novice who is groping for a handle of unfamiliar matter Shu [88 S. 7] Graphical representations and pictures have come into play in programming process. This form of programming is stimulated by the following premises: 1. Pictures are more powerful than words as a means of communication. They can convey more meaning in a more concise unit of expression. [...] Glinert [90 S. 173 f] The primary advantage of using visual rather than textual representation is the possibility of an immediateness of understanding

281 Kahn und Saraswat [90 S. 7] Myers [94 S. 878] on the part of an untrained observer. The structure of programs can be captured more effectively by well-designed two-dimensional layouts than is possible with the essentially one-dimensional sequences of lines of code. A welldesigned pictorial syntax enables programmers to visually detect various kinds of program anomalies. Perhaps more importantly, a means of perceiving the dynamic structure of a computation greatly aids in understanding how programs work. This improved understanding will ease the tasks of constructing, debugging, modifying, enhancing, and documenting programs. It seems clear that a more visual style of programming could be easier to understand and generate for humans, especially for nonprogrammers or novice programmers Shu [88 S. 7] Pictures aid understanding and remembering Poswig [93 S. 22] Raeder [85 S. 12] Certainly, the many useful features of LabVIEW, such as the math routines and the graphic displays, can easily be used by the unsophisticated programmer. Similarly, simple diagrams are indeed self-explanatory programs. In our opinion, an inexperienced programmer could construct a much more sophisticated model in LabVIEW than in other high-level languages. However, more elaborate LabVIEW programs can be as difficult to decipher and debug as those in other languages. LabVIEW can demand arcane programming tricks, and the methods that have to be used to store variable values and to branch one particular condition are often not straightforward [...] In conventional programming languages, the only way to refer to objects is by name. This means that all objects are referenced indirectly; they are also invisible to the programmer. Names are not needed when the programmer uses pictures, since these are present, visible object representations. The programmer is relieved from constantly having to refer to invisible objects by name Petre [95 S. 38] The sight of subjects crawling over the screen with mouse or fingers, talking aloud to keep their working memory updated, was remarkable. One of the distinctions between expert and novice behavior was that the experts made better use of their fingers, occasionally using all ten to mark points along a circuit Kimura et al. [90] in Glinert [90-P&S S. 397] Myers [94 S. 889] By the principle of direct object manipulation, a graphic object is more acceptable to school children than text. For the same reason, direct manipulation of values in ad dataflow language, rather than indirect manipulation through variables, reinforces the learning process. The systems discussed in this paper show that some successful areas so far include, for visual programming: Helping to teach programming (FPL, Pict, etc.) [...] Shu [88 S. 9]: Pictures may provide an incentive for learning to program Tanimoto und Glinert [86] in Glinert [90- A&I S. 331] In addition to the lack of theory for system understandability, there has been little study of how a computer can provide a medium of linguistic expression at a more fundamental level, namely how the simplest kinds of predication (juxtaposition of object and action or object and attribute) can be enhanced through the use of computer graphics and structured interaction. Graphical means for such expression can be an important part of the process of learning to program.

282 Kahn und Saraswat [90 S. 8] By removing a reliance upon text the difficulties resulting from transfer of program sources between speakers of different languages is reduced significantly. Only strings and comments remain to be translated Shu [88 S. 9] Pictures do not have language barriers. When properly designed, they are understood by people regardless of what language they speak Suleiman und Citrin [92 S. 143] Tanimoto und Glinert [86] in Glinert [90- A&I S. 330] Glinert [90 S. 148]: Raeder [85 S. 12]: Shu [88 S. 1 und S. 7] Glinert und Tanimoto [84] in Glinert [90- P&S S. 268] An attractive solution to the problem of finding naturallanguage-independent representations of program structures is the use of pictures. Icons are used in a wide variety of situations to facilitate international communications (their use in airports and railroad stations comes to mind), and a number of visual language investigators have noted that visual representation of programs are potentially understandable by speakers of different languages, although it appears that no little work has actually gone into verifying these claims. In addition to the desire to make programming accessible to a wider variety of people than it currently is, a graphical programming system might also provide a medium for the international exchange of programs. Conventional languages, based on text, are locked into using keywords with origins in a particular spoken language, most often English. There are several reasons why it seems reasonable to believe that images can be good for human-computer communication. [...] They are often easily learned and recalled as single»chunks«of information as psychologists call them. Our eyes provide instant, random access to any part of a picture, and to detailed and overall views. [...] Comparison of pictures and text make it clear that pictures generally transfer information faster than text: Both accessing and decoding are more efficient. Remember that the human sensory system is set up for real-time image processing ; text processing is a much more recent phenomenon. Various reasons have been cited for the interest in visual programming. Many of them pertain to the better use of the right half of the brain, which is needlessly at rest and underutilized for the purpose of computing. [...] Pictures aid understanding and remembering. [...] human image memory and processing capabilities are powerful parallel processors. [...] images may provide a high bandwidth for human-machine communication.

283 San Francisco Examiner vom Serius [92 S f] He has been heralded as the next Bill Gates. [...] He believes his software can alter an industry. [...] If you can rebuild a Microsoft Excel (spreadsheet) in seven days for your own customers frameworks, you have shifted the power of software research and development away from the giants. You could even misspell or leave out a word ObjecTalk is smart enough to figure out what you meant. There is absolutely no required structure or syntax in ObjecTalk function phrases Huizing [91 S. 9] There is a fundamental dichotomy in the analysis of computer systems. This dichotomy crosses all borderlines between sequential and parallel systems, central and distributed systems. This is the dichotomy between transformational and reactive systems [...] Transformational systems are well described by a relation between input and output value. They read some input value, then produce, perhaps non-deterministically, an output value and terminate. They have a linear structure, only the initial and final state are of interest. Reactive systems do not compute a function, but perform a continuous interaction with their environment. Whereas a transformational system is compared to a black box, a reactive system should be compared to a black cactus (terminology from Amir Pnueli), having several input and output channels Harel et al. [90] Common to all of these is the notion of reactive behavior, whereby the system is not adequately described by a simple relationship that specifies outputs as a function of inputs, but, rather, requires relating outputs to inputs through their allowed combinations in time. Typically, such descriptions involve complex sequences of events, actions, conditions and information flow, often with explicit timing constraints, that combine to form the system s overall behavior Sametinger [97 S. 68]: Burnett et al. [95 S. 49]: Green und Petre [94 S. 17] Reusable software components are self-contained, clearly identifiable pieces that describe and/or perform specific functions, have clear interfaces, appropriate documentation, and a defined reuse status. The ability to watch any portion of the program on demand fulfills the documentation goals of helping the programmer understand the program, while guaranteeing consistency between this information and the actual workings of code. Thus, because programs with test values can provide responsive documentation and because documentation can include programming, the separation between source code and documentation begins to disappear. You are about to draw a sketch map of the route from home to work. Where should you make the first mark on the paper, and how big should you make the initial marks? You will need to look ahead and work out in your head a rough estimate. If you leave too little room because there are a lots of little turns you forgot about until you started to draw, you will probably have to get some more paper and start again paper is not a very forgiving medium for drawing maps Petre [95 S. 42] I quite often spend an hour or two just moving boxes and wires around, with no change in functionality, to make it that much more comprehensible when I come back to it.

284 274 Anhang C: Literaturverzeichnis Ackerman [82] William B. Ackerman: Data Flow Languages; Computer, Vol. 15, No. 2, Feb. 1982, ACMSP ACM SIGPLAN Notices; Association for Computing Machinery Ambler und Burnett [89] Allen L. Ambler, Margaret M. Burnett: Influence of Visual Technology on the Evolution of Language Environments; Computer, October 1989, 9-22; auch in Glinert [90-P&S], Anderson [89] John R. Anderson: Kognitive Psychologie: Eine Einführung; Spektrum der Wissenschaft Verlagsgesellschaft 1989 AppBuilder [WWW] Novell Home Page; Backus [78] John Backus: Can programming be liberated from the von Neumann style? A functional style and its algebra of programs; in CACM, Vol. 21, No. 8, August 1978, Baecker und Marcus [86] Ronald M. Baecker, Aaron Marcus: Design Principles for the Enhanced Presentation of Computer Program Source Text; Proceedings of CHI '86, Human Factors in Computing Systems, April 1986, Baecker und Marcus [90] Ronald M. Baecker, Aaron Marcus: Human Factors for More Readable Programs; ACM Press 1990 Baroth und Hartsough [94] Ed Baroth, Chris Hartsough: Visual Programming in the Real World; in Burnett et. al [94], Bell und Lewis [93] Brigham Bell, Clayton Lewis: ChemTrains: A Language for Creating Behaving Pictures; in VL [93], BetterState [94] R-Active Concepts: BetterState Version 2.1 for MS-Windows - Users Manual; R-Active Concepts, Inc., 1994 Biermann und Krishnaswamy [76] A.W. Biermann, R. Krishnaswamy: Constructing Programs from Example Computations; in ITSE, Vol. SE-2, No. 3, Sept. 1976, Bischofberger und Pomberger [92] Walter Bischofberger, Gustav Pomberger: Prototyping-oriented Software Development: Concepts and Tools; Springer 1992 Blaschek [94] Günther Blaschek: Object-Oriented Programming with Prototypes; Springer 1994 Blaschek et al. [87] Günther Blaschek, Gustav Pomberger, Franz Ritzinger: Einführung in die Programmierung mit Modula 2; Springer 1987 Boecker et al. [86] H.D. Boecker, G. Fischer, H. Nieper: The Enhancement of Understanding through Visual Representations; Proceedings of the CHI '86 Conference, Human Factors in Computing Systems, Aug. 1986, Bonar und Liffick [90] Jeffrey G. Bonar, Blaise W. Liffick: A Visual Programming Language for Novices; in Chang [90], Borges und Johnson [90] José A. Borges, Ralph E. Johnson: Multiparadigm Visual Programming Language; in VL [90], Borne [93] Isabelle Borne: A Visual Programming Environment for Smalltalk; in VL [93],

285 275 Borning [81] Alan Borning: The Programming Language Aspects of ThingLab, a Constraint-Oriented Simulation Laboratory; ACM Transactions on Programming Languages and Systems, Vol. 3, No. 4, Okt. 1981, ; auch in Glinert [90-P&S], Borning et al. [87] Alan Borning, Robert Duisberg, Bjorn Freeman-Benson, Axel Kramer, Michael Woolf: Constraint Hierarchies; Proceedings OOPSLA, 1987, 48-60; auch in Glinert [90-P&S], Brockhaus [94-20] Brockhaus Enzyklopädie Bd. 20; Brockhaus 1994 Brockhaus [94-22] Brockhaus Enzyklopädie Bd. 22; Brockhaus 1994 Brockhaus [94-23] Brockhaus Enzyklopädie Bd. 23; Brockhaus 1994 Broer [94] H. Broer: Software-Montagetechnik mit Software-Komponenten aus dem Katalog; OBJEKTspektrum, Mai 1994, Brooke und Duncan [80] J.B. Brooke, K.D. Duncan: Experimental studies of flowchart use at different stages of program debugging; Ergonomics, Vol. 23, 1980, Brooks [87] Frederick P. Brooks: No Silver Bullet: Essence and Accidents of Software Engineering; Computer, April 1987, 10-19; auch in DeMarco und Lister [90], Brown et al. [85] Gretchen P. Brown, Richard T. Carling, Christopher F. Herot, David A. Kramlich, Paul Souza: Program Visualization: Graphical Support for Software Development; Computer August 1985, Vol. 18, No. 8, Brown und Kimura [94] Timothy B. Brown, Takayuki Dan Kimura: Completeness of a Visual Computation Model; Software - Concepts and Tools, Vol. 15, No. 1, 1994, Brown und Sedgewick [85] M.H. Brown, R. Sedgewick: Techniques for Algorithm Animation; IEEE Software, Vol. 2, No. 1, Jan. 1985, Budd [90] T. Budd: An Introduction to Object-Oriented Programming; Addison-Wesley 1990 Burnett [91] Margaret M. Burnett: Abstraction in the Demand-Driven, Temporal-Assignment, Visual Language Model; Ph.D. Thesis, University of Kansas, Department of Computer Science, 1991 Burnett [94] Margaret M. Burnett: Seven Programming Language Issues; in Burnett et al. [94], Burnett et al. [94] Margaret M. Burnett, Adele Goldberg, Ted G. Lewis (ed.): Visual Object-Oriented Programming, Concepts and Environments; Manning, Prentice Hall, 1994 Burnett et al. [95] Margaret M. Burnett, Marla J. Baker, Carisa Bohus, Paul Carlson, Sherry Yang, Pieter van Zee: Scaling Up Visual Programming Languages; Computer, Vol. 28, No. 2, March 1995, Burnett und Ambler [92] Margaret M. Burnett, Allen L. Ambler: A Declarative Approach to Event-Handling in Visual Programming Languages; in VL [92], Burnett und Baker [94] Margaret M. Burnett, Marla J. Baker: A Classification System for Visual Programming Languages; in JVLC, Vol. 5, No. 3, Sep. 1994, Burnett und McIntyre [95] Margaret M. Burnett, David W. McIntyre: Visual Programming; Computer, Vol. 28, No. 3, March 1995, CACM Communications of the ACM; Association for Computing Machinery, ISSN

286 276 Cardelli und Pike [85] L. Cardelli, R. Pike: Squeak: A Language for Communication with Mice; Proceedings of ACM SIGGRAPH, July 1985, Chang [87] Shi-Kuo Chang: Visual Languages: A Tutorial and Survey; IEEE Software, January 1987, 29-39; auch in Glinert [90-P&S], 7-17 Chang [90] Shi-Kuo Chang (ed.): Principles of Visual Programming Systems; Prentice Hall 1990 Chang [90-3] Shi-Kuo Chang: Visual Languages and Visual Programming; Plenum Press 1990 Chang [94-2] Shi-Kuo Chang: An Unofficial History of VL; Section in»ten Years of Visual Language Research«, in VL [94], Chang et al. [86] Shi-Kuo Chang, Tadao Ichikawa, Panos A. Ligomenides (eds.): Visual Languages; Plenum Press 1986 Chang et al. [89] S.K. Chang, M.J. Tauber, B. Yu, J.S. Yu: A Visual Language Compiler; in ITSE, Vol. 15, No. 5, May 1989, Computer [82] Special Issue on Data Flow Systems; Computer, Vol. 15, No. 2, Feb Cormen et al. [90] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest: Introduction to Algorithms; MIT Press, 1990 Costagliola et al. [91] Gennaro Costagliola, Masaru Tomita, Shi-Kuo Chang: A Generalized Parser for 2-D Languages; in VL [91], Costagliola et al. [95] Gennaro Costagliola, Genoveffa Tortora, Sergio Orefice, Andrea De Lucia: Automatic Generation of Visual Programming Environments; Computer, Vol. 28, No. 3, March 1995, Cox und Pietrzykowski [88] P.T. Cox, T. Pietrzykowski: Using a Pictorial Representation to Combine Dataflow and Object-orientation in a Language Independent Programming Mechanism; Proceedings International Computer Science Conference, 1988, ; auch in Glinert [90-P&S], Cunniff et al. [86] N. Cunniff, R.P. Taylor, J.B. Black: Does Programming Language Affect the Type of Conceptual Bugs in Beginners' Programs? A Comparison of FPL and Pascal; Proceedings of CHI '86, Apr. 1986, Cunniff und Taylor [87] N. Cunniff, R.P. Taylor: Graphical vs. Textual Representation: An Empirical Study of Novices' Program Comprehension; Empirical Studies of Programmers: Second Workshop, G. Olson, S. Sheppard, E. Soloway (ed.), Ablex Publishing, Norwood, 1987 Cypher [93] Allen Cypher (ed.): Watch What I Do, Programming by Demonstration; MIT Press 1993 Dähler [89] Jaques Dähler: Ein Werkzeug für den Entwurf verteilter Systeme auf der Basis erweiterter Petri-Netze; Dissertation Nr. 8770, ETH Zürich, 1989 DeMarco und Lister [90] Tom DeMarco, Timothy Lister (eds.): Software State-of-the-Art: Selected Papers; Dorset House, 1990 Denert [93] Ernst Denert: Dokumentorientierte Software-Entwicklung; Informatik-Spektrum, Vol. 16, 1993, Dennis [74] Jack B. Dennis: First Version of a Dataflow Procedure Language; Proceedings Programming Symposium, Paris, Apr. 1974, B. Robinet (ed.), in LNCS, No. 19, 1974,

287 277 Diaz-Herrera und Flude [80] Dijkstra [89] Drusinsky [94] J.L. Diaz-Herrera, R.C. Flude: PASCAL/HSD: A Graphical Programming System; IEEE Proceedings COMPSAC 1980, ; auch in Glinert [90-P&S], Edsger W. Dijkstra: On the Cruelty of Really Teaching Computing Science; in CACM, Vol. 32, No. 12, Dec. 1989, Doron Drusinsky: Extended State Diagrams and Reactive Systems; Dr. Dobb's Journal, Oct. 1994, Duden [84] Duden - Grammatik der deutschen Gegenwartssprache; Bibliographisches Institut, Mannheim 1984 Duden [92] Duden - Lexikon A-Z; Dudenverlag 1992 Dudley und Mahling [91] Tim Dudley, Dirk Mahling: Report on Panel: Is Visual Programming a New Programming Paradigm; in VL [91], Duisberg [88] Robert A. Duisberg: Animation Using Temporal Constraints: An Overview of the Animus System; Human-Computer Interaction, Vol. 3, No. 3, 1987/88, ; auch in Glinert [90-P&S], ECS [93] Anthony Ralston, Edwin D. Reilly (ed.): Encyclopedia of Computer Science; Van Nostrand Reinhold, 1993 Edel [86] Mark Edel: The Tinkertoy Graphical Programming Environment; IEEE Proceedings COMPSAC 1986, ; auch in Glinert [90-P&S], Edel [88] Mark Edel: The Tinkertoy Graphical Environment; in ITSE, Vol. 14, No. 8, Aug. 1988, ESE [94] John J. Marciniak (ed.): Encyclopedia of Software Engineering; John Wiley & Sons, 1994 Ferrucci et al. [91] F. Ferrucci, G. Pacini, G. Tortora, M. Tucci, G. Vitiello: Efficient Parsing of Multidimensional Structures; in VL [91], Finzer und Gould [84] William Finzer, Laura Gould: Programming by rehearsal; Byte, Vol. 9, No. 6, June 1984, ; auch in Glinert [90-P&S], Frei et al. [78] H.P. Frei, D.L. Weller, R. Williams: A Graphics-Based Programming Support System; ACM Computer Graphics (Proceedings SIGGRAPH), Vol. 12, No. 3, August 1978, 43-49; auch in Glinert [90-P&S], Friedell et al. [82] M. Friedell, J. Barnett, D. Kramlich: Context-Sensitive Graphic Presentation of Information; ACM Computer Graphics, Vol. 16, No. 3, July 1992, Fröhlich [96] Joachim Hans Fröhlich: Analyse objektorientierter Programme - Stand der Technik; CD-Labor für Software Engineering, Johannes Kepler Universität Linz, Technischer Bericht TR 96.15, 1996 Ga Côté [95] Raymond Ga Côté: Prograph CPX: Purely Visual; Byte, Jan. 1995, Gajski et al. [82] Daniel D. Gajski, David A. Padua, David J. Kuck, Robert H. Kuhn: A Second Opinion on Data Flow Machines and Languages; Computer, Vol. 15, No. 2, Feb. 1982, Gaudiot und Bic [91] Jean-Luc Gaudiot, Lubomir Bic: Advanced Topics in Data-flow Computing; Prentice Hall 1991 Gernet [88] Jacques Gernet: Die chinesische Welt; Suhrkamp 1988

288 278 Gerstendörfer und Rohr [87] Ghezzi und Jazayeri [87] Giacalone et al. [84] Gindling et al. [95] Glinert [87] Glinert [90] Glinert [90-A&I] Glinert [90-P&S] Glinert et al. [91] Glinert und Stotts [92] Glinert und Tanimoto [84] Gloor [92] Goldberg und Robson [83] Goldman et al. [85] Golin und Magliery [93] Golin und Reiss [90] Gorlick und Quilici [94] Gorny und Tauber [86] Grafton und Ichikawa [85] Monika Gerstendörfer, Gabriele Rohr: Which Task in which Representation on what Kind of Interface; Human Computer Interaction - Interact '87, H.-J. Bullinger, B. Shakel (ed.), Elsevier Science Publishers B.V., IFIP 1987, Carlo Ghezzi, Mehdi Jazayeri: Programming Language Concepts; John Wiley & Sons 1987 A. Giacalone, M.C. Rinard, T.W. Doeppner Jr.: IDEOSY: An Ideographic and Interactive Program Description System; in ACMSP, Vol. 19, No. 5, May 1984 Jim Gindling, Andri Ioannidou, Jennifer Loh, Olav Lokkebo, Alexander Repenning: LEGOsheets: A Rule-Based Programming, Simulation and Manipulation Environment for the LEGO Programmable Brick; in VL [95], Ephraim P. Glinert: Out of Flatland: Towards 3-D Visual Programming; IEEE Proceedings 2nd Joint Computer Conference 1987, ; auch in Glinert [90-A&I], Ephraim P. Glinert: Nontextual Programming Environments; in Chang [90], Ephraim P. Glinert (ed.): Visual Programming Environments: Applications and Issues; IEEE Computer Society Press 1990 Ephraim P. Glinert (ed.): Visual Programming Environments: Paradigms and Systems; IEEE Computer Society Press 1990 Ephraim P. Glinert, Meera M. Blattner, Christopher J. Frerking: Visual Tools and Languages: Directions for the '90s; in VL [91], Ephraim P. Glinert, Charles D. Norton: Visual Languages and Concurrent Computing; in JVLC, Vol. 3, No. 2, June 1992, 105 Ephraim P. Glinert, Steven L. Tanimoto: Pict: An Interactive Graphical Programming Environment; Computer, November 1984, 7-25; auch in Glinert [90-P&S], Peter A. Gloor: AACE - Algorithm Animation for Computer Science Education; in VL [92], A. Goldberg, D. Robson: Smalltalk 80 - The Language and its Implementation; Addison-Wesley 1983 K.J. Goldman, S.A. Goldman, P.C. Kanellakis, S.B. Zdonik: ISIS: Interface for a Semantic Information System; Proceedings of ACM SIGMOD International Conference on the Management of Data, May 1985, Eric J. Golin, Tom Magliery: A Compiler Generator for Visual Languages; in VL [93], Eric J. Golin, Steven P. Reiss: The Specification of Visual Language Syntax; in JVLC, Vol. 1, No. 2, ; auch in Glinert [90-A&I], Michael Gorlick, Alex Quilici: Visual Programming-in-the-Large versus Visual Programming-in-the-Small; in VL [94], P. Gorny, M.J. Tauber (ed.): Visualization in Programming; 5th Interdiciplinary Workshop in Informatics and Psychology, Schärding, Austria, May 1986, in LNCS, No. 282, 1986 Robert B. Grafton, Tadao Ichikawa: Visual Programming; Computer, Vol. 18, No. 8, August 1985, 6-9

289 279 Green und Petre [92] Thomas R.G. Green, Marian Petre: When Visual Programs are Harder to Read than Textual Programs; Human-Computer Interaction: Tasks and Organisation, Proceedings ECCE-6 (6th European Conference on Cognitive Ergonomics), G. C. van der Veer, M. J. Tauber, S. Bagnarola, M. Antavolits (ed.), Rome 1992 Green und Petre [94] Thomas R.G. Green, Marian Petre: Usability Analysis of Visual Programming Environments; Unpublished, ftp://ftp.mrcapu.cam.ac.uk/pub/personal/tg/visprogenvs.ps Gurd [91] John Gurd: Foreword to Advanced Topics in Data-Flow Computing; in Gaudiot, Bic [91], ix-xii Gutknecht [95] Christoph Gutknecht: Lauter böhmische Dörfer - Wie die Wörter zu ihrer Bedeutung kamen; Beck 1995 Haeberli [88] Paul E. Haeberli: ConMan: A Visual Programming Language for Interactive Graphics; ACM Computer Graphics (Proceedings SIGGRAPH '88), Vol. 22, No. 4, August 1988, ; auch in Glinert [90-A&I], Halbert [84] Daniel C. Halbert: Programming by Example; Ph.D. dissertation, Computer Science Division, University of California, Berkeley 1984 Halbert [93] Daniel C. Halbert: SmallStar: Programming by Demonstration in the Desktop Metaphor; in Cypher [93], Hansen et al. [94] Wilfried J. Hansen (moderator), Brigham Bell, Greg A. McKaskle, Garth Smedley, Dan Kimura, Jörg Poswig: The 1994 Visual Languages Comparison; in VL [94], Harel [88] David Harel: On Visual Formalism; in CACM, Vol. 31, No. 5, May 1988, ; auch in Glinert [90-P&S], Harel et al. [90] David Harel, Hagi Lachover, Amnon Naamad, Amir Pnueli, Michal Politi, Rivi Sherman, Aharon Shtull-Tauring, Mark Trakhtenbrot: STATEMATE: A Working Environment for the Development of Complex Reactive Systems; in ITSE, Vol. 16, No. 4, April 1990 Herath et al. [92] S. Herath, Y. Yamaguchi, R. Mattingley, J. Herath, N. Saito, T. Yuba: Functional and Logic Languages in Dataflow Computing; in Sharp [92], Herot [80] C.F. Herot: Spatial Management of Data; ACM Transactions on Database Systems, Vol. 5, No. 4, Dec. 1980, Hiebl [94] Bernhard Hiebl: Grundlagen, Modelle und Systeme der Visuellen Programmierung; Diplomarbeit, Johannes Kepler Universität Linz, 1994 Hils [92] Daniel D. Hils: Visual Languages and Computing Survey: Data Flow Visual Programming Languages; in JVLC, Vol. 3, No. 1, Mar. 1992, Hirakawa et al. [86] M. Hirakawa, N. Monden, I. Yoshimoto, M. Tanaka, T. Ichikawa: HI-VISUAL: A Language Supporting Visual Interaction in Programming; in Chang et al. [86], Hirakawa et al. [87] M. Hirakawa, S. Iwata, I. Yoshimoto, M. Tanaka, T. Ichikawa: HI-VISUAL Iconic Programming; in VL [87], Hirakawa und Ichikawa [94] Mashahito Hirakawa, Tadao Ichikawa: Visual Language Studies - A Perspective; Software - Concepts and Tools, Vol. 15, No. 1, 1994, 61-67

290 280 Hoare [85] Hoare und Jones [89] Holt [90] Hopcroft und Ullman [79] Horton [94] Hughes und Moshell [86] Huizing [91] Ichikawa et al. [90] Charles A.R. Hoare: Communicating Sequential Processes; Prentice Hall 1985 Charles A.R. Hoare und Cliff B.Jones (ed.): Essays in Computing Science; Prentice Hall 1989 Chris M. Holt: viz: A Visual Language Based on Functions; in VL [90], J.E. Hopcroft, J.D. Ullman: Introduction to Automata Theory, Languages, and the Theory of Computation; Addison-Wesley, 1979 William Horton: The Icon Book - Visual Symbols for Computer Systems and Documentation; John Wiley & Sons 1994 C.D. Hughes, J.M. Moshell: Visible Pascal: A Graphics-Based Learning Environment; Proceedings of Computer Graphics 86, National Computer Graphics Association, May 1986, C. Huizing: Semantics of Reactive Systems: Comparison and Full Abstraction; Ph.D. Thesis, Technische Universiteit Eindhoven, 1991 T. Ichikawa, E. Jungert, R.R. Korfhage (eds.): Visual Languages and Applications; Plenum Press 1990 ITSE IEEE Transactions on Software Engineering; IEEE Computer Society, ISSN Jacob [85] Robert J.K. Jacob: A State Transition Diagram Language for Visual Programming; Computer, August 1985, 51-59; auch in Glinert [90-P&S], Jamal und Pichlik [97] Rahman Jamal, Herbert Pichlik: LabVIEW - Programmiersprache der vierten Generation; Prentice Hall 1997 Jamal und Wenzel [95] Rahman Jamal, Lothar Wenzel: The Applicability of the Visual Programming Language LabVIEW to Large Real-World Applications; in VL [95], Jensen und Rozenberg [91] Kurt Jensen, Grzegorz Rosenberg (eds.): High-level Petri Nets - Theory and Application; Springer 1991 JVLC Journal of Visual Languages and Computing; Academic Press, ISSN X Kahn et al. [91] Kenneth M. Kahn, Vijay A. Saraswat, Volker Haarslev: Pictorial Janus: Eine vollständig visuelle Programmiersprache und ihre Umgebung; Proceedings, Fachgespräch Programmieren multimedialer Anwendungen der GI-Jahrestagung 1991, Darmstadt, Oktober 1991 Kahn und Saraswat [90] Kenneth M. Kahn, Vijay A. Saraswat: Complete Visualizations of Concurrent Programs and their Executions; in VL [90], 7-15 Kapolka [90] M. Anthony Kapolka III: A Study in Natural Visual Languages; in Chang [90-3], Kay [93] Alan C. Kay: The Early History of Smalltalk; in ACMSP, Vol. 28, No. 2, Mar. 1993, Keller [89] Rudolf K. Keller: Prototypingorientierte Systemspezifikation - Konzepte, Methoden, Werkzeuge und Konsequenzen; Verlag Dr. Kovac, Hamburg 1989 Kiel und Shepherd [88] J.W. Kiel, A.P. Shepherd: A Graphic Computer Language for Physiology Simulations; Computers in Life Science Education, Vol. 5, No. 7, 1988, 49-56

291 281 Kimura [92] Takayuki Dan Kimura: Hyperflow: A Visual Programming Language for Pen Computers; in VL [92], Kimura et al. [86] T.D. Kimura, J.W. Choi, J.M. Mack: A Visual Language for Keyboardless Programming; Technical Report WUCS-86-6, Dept. of Computer Science, Washington University, St. Louis, MO, 1986 Kimura et al. [90] Takayuki Dan Kimura, Julie W. Choi, Jane M. Mack: Show and Tell: A Visual programming Language; in Glinert [90-P&S], Knuth [73] Donald E. Knuth: Fundamental Algorithms; Addison-Wesley 1973 Knuth [84] Donald E. Knuth: Literate Programming; The Computer Journal, Vol. 27, No. 2, 1984, Kodosky et al. [91] Jeffrey Kodosky, Jack MacCrisken, Gary Rymar: Visual Programming Using Structured Dataflow; in VL [91], Kopache und Glinert [88] Mark E. Kopache, Ephraim P. Glinert: C2: A Mixed Textual/Graphical Environment for C; in VL [88], ; auch in Glinert [90-P&S], Korson und McGregor [90] T. Korson, J.D. McGregor: Understanding Object-Oriented: A Unifying Paradigm; in CACM, Vol. 33, No. 9, Sep. 1990, Kozen et al. [87] D. Kozen, T. Teitelbaum, W. Chen, J. Field, W. Pugh, V.V. Zanden: ALEX - An Alexical Programming Language; in VL [87] Kratzer [95] C. Kratzer: PARTisanen; c't, März 1995, Kurita und Tamura [84] T. Kurita, K. Tamura: Dialog.I: An Iconic Programming System Based on Logic Programming; Bulletin of the Electrotechnical Laboratory, Japan, Vol. 48, No. 12, 1984, LabVIEW [94-T] National Instruments: LabVIEW Tutorial for Macintosh; National Instruments, 1994 LabVIEW [94-U] National Instruments: LabVIEW User Manual for Macintosh; National Instruments, 1994 LabVIEW [WWW] National Instruments Home Page; Lakin [86] Fred Lakin: Spatial Parsing for Visual Languages; in Chang et al. [86], LaLonde und Pugh [93] W.R. LaLonde, J.R. Pugh: Instance-based Programming with PARTS; Journal of Object-Oriented Programming, Mar.-Apr. 1993, Ledbetter und Cox [85] Lamar Ledbetter, Brad Cox: Software-ICs: A Plan for Building Reusable Software Components; Byte Vol. 10, No. 6, June 1995, ; auch in DeMarco und Lister [90], Leibs und Goldberg [93] David Leibs, Adele Goldberg: When Visual is Not Enough; Proceedings of the OOPSLA '93 Workshop on Visual Object Oriented Programming, Washington D.C, October 1, 1993, Leibs und Rubin [92] D. Leibs, K. Rubin: Reimplementing Model-View-Controller; The Smalltalk Report, Vol. 1, No. 6, Mar./Apr. 1992, 1-7 Lewerentz und Lindner [95] Claus Lewerentz, Thomas Lindner (eds.): Formal Development of Reactive Systems - Case Study Production Cell; in LNCS, No. 891, 1995

292 282 Lewerentz und Lindner [95-2] Claus Lewerentz, Thomas Lindner: Comparative Survey - Summary and Evaluation of the Case Study Production Cell; in Lewerentz u. Lindner [95], Lieberman [86] Henry Lieberman: Using Prototypical Objects to Implement Shared Behaviour in Object-oriented Systems; OOPSLA '86 Proceedings, Lieberman [93] Henry Lieberman: Tinker: A Programming by Demonstration System for Beginning Programmers; in Cypher [93], Lin und Chang [80] B.S. Lin, S.K. Chang: GRAIN - A Pictorial Database Interface; Proceedings of the 1980 Picture Data Description and Management Workshop, Aug. 1980, LNCS Lecture Notes in Computer Science; Springer Ludolph et al. [88] Frank Ludolph, Yu-Ying Chown, Dan Ingalls, Scott Wallace, Ken Doyle: The Fabrik Programming Environment; in VL [88], ; auch in Glinert [90-P&S], MacDonald [82] Alan MacDonald: Visual Programming; Datamation, Vol. 28, No. 11, Oct. 1982, Maloney et al. [94] John H. Maloney, Alan Borning, Bjorn N. Freeman-Benson: User- Interface Construction with Constraints; in Burnett et al. [94], ; auch in Proceedings OOPSLA '89, ACM SIGPLAN Notices, Vol. 24, No. 10, 1989, Marriot [94] Kim Marriot: Constraint Multiset Grammars; in VL [94], Matwin und Pietrzykowski [85] S. Matwin, T. Pietrzykowski: PROGRAPH: A Preliminary Report; Computing Languages, Vol. 10, No. 2, 1985, Maulsby und Witten [93] David Maulsby, Ian H. Witten: Metamouse: An Instructible Agent for Programming by Demonstration; in Cypher [93], Mayer [81] R.E. Mayer: The Psychology of How Novices Learn Computer Programming; ACM Computing Surveys, Vol 13., No. 1, March 1981, Mayer [95] Gertrude Mayer: Interprozeßkommunikation unter Microsoft Windows - OLE versus DDE; Diplomarbeit, Institut für Wirtschaftsinformatik, Johannes Kepler Universität Linz, 1995 McDonald [84] Nancy H. McDonald: A Multi Media Approach to the User Interface; Human Factors and Interactive Computer Systems, Y. Vissiliou (ed.), Ablex Publishing 1984, Mey [94] Victoria de Mey: Visual Composition of Software Applications; Ph.D. dissertation, Université de Genève, 1994 Meyer [88] Bertrand Meyer: Object-oriented Software Construction; Prentice Hall 1988 Meyer [90] Bertrand Meyer: Objektorientierte Softwareentwicklung; Hanser/Prentice Hall 1990 Meyer [92] B. Meyer: Pictures Depicting pictures: On the Specification of Visual Languages by Visual Grammars; in VL [92], Meyers-Philosophie [87] Microbrew [WWW] Meyers kleines Lexikon Philosophie; Bibliographisches Institut Mannheim 1987 Network Multimedia Home Page;

293 283 Miller [56] Georg A. Miller: The Psychological Review. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information; Psychological Review, Vol. 63, No. 2, 1956, 81-96; auch in Glinert [90-A&I], Moriconi und Hare [85] Mark Moriconi, Dwigth F. Hare: Visualizing Program Design through PegaSys; Computer, Vol. 18, No. 8, August 1985, Murata [89] Tadao Murata: Petri Nets, Properties, Analysis and Applications; Proceedings of the IEEE, Vol. 77, No. 4, Apr. 1989, Myers [83] Brad A. Myers: INCENSE: A System for Displaying Data Structures; ACM Computer Graphics, Vol. 17, No. 3, July 1983, Myers [86] Brad A. Myers: Visual Programming, Programming by Example and Program Visualization: A Taxonomy; Conference Proceedings, CHI '86: Human Factors in Computing Systems, 1986, 56-66; auch in Glinert [90-P&S], Myers [87] Brad A. Myers: Creating Interaction Techniques by Demonstration; IEEE Computer Graphics and Applications, Sept. 1987, 51-60; auch in Glinert [90-P&S], Myers [90-3] Brad A. Myers: Taxonomies of Visual Programming and Program Visualization; in JVLC, Vol.1, No. 1, ; auch in Myers [94] Myers [94] Brad A. Myers: Program Visualization; in ESE [94], ; auch in Myers [90-3] Najork und Golin [90] Marc A. Najork, Eric Golin: Enhancing Show-and-Tell with a Polymorphic Type System and Higher-Order Functions; in VL [90], Najork und Kaplan [92] Marc A. Najork, Simon M. Kaplan: A Prototype Implementation of the CUBE Language; in VL [92], Nickerson [94] Jeffrey Vernon Nickerson: Visual Programming; Ph.D. Dissertation, New York University, 1994 Novak und Bulko [93] Gordon S. Novak Jr., William C. Bulko: Diagrams and Text as Computer Input; in JVLC, Vol. 4, No. 3, June 1993, Olympia [94] P.L. Olympia: Developing Applications with Novell's Visual AppBuilder; DBMS, Nov. 1994, Pandey und Burnett [93] Rajeev K. Pandey, Margaret M. Burnett: Is It Easier to Write Matrix Manipulation Programs Visually or Textually? An Empirical Study; in VL [93], PARTS [92] Digitalk Inc.: PARTS Workbench, User's Guide; Digitalk Inc., 1992 PARTS [WWW] ParcPlace-Digitalk Home Page; Penz [90] Franz Penz: Die ObjektWelt - ein visuelles, objektorientiertes System zur Entwicklung wiedervendbarer Softwarekomponenten; Dissertation, Technische Universität Wien, Technisch- Naturwissenschaftliche Fakultät Peterson [77] James L. Peterson: Petri Nets; Computing Surveys, Vol. 9, No. 3, Sep. 1977, Petre [95] Marian Petre: Why Looking Isn't always Seeing: Readership Skills and Graphical Programming; in CACM, Vol. 38, No. 6, June 1995, 33-44

294 284 Petre und Green [93] M. Petre, T.R.G. Green: Learning to Read Graphics: Some Evidence that 'Seeing' an Information Display is an Acquired Skill; in JVLC, Vol. 4, No. 1, 1993, Pomberger und Blaschek [96] Gustav Pomberger, Günther Blaschek: Software Engineering - Prototyping und objektorientierte Software-Entwicklung; Hanser 1996 Pong und Ng [83] M.C. Pong, N. Ng: PIGS - A System for Programming with Interactive Graphical Support; Software - Practice and Experience, Vol. 13, 1983, ; auch in Glinert [90-P&S], Poswig [93] Jörg Poswig: Visuelle Programmiersprachen - Die Realisierung und konzeptionelle Weiterentwicklung eines Prototypen; Dissertation, Universität Dortmund, 1994 Poswig [96] Jörg Poswig: Visuelle Programmierung - Computerprogramme auf graphischem Weg erstellen; Carl Hanser, 1996 Price et al. [93] Blaine A. Price, Ronald M. Baecker, Ian S. Small: A Principled Taxonomy of Software Visualization; in JVLC, Vol. 4, No. 3, Sep. 1993, Raeder [84] Georg Raeder: Programming in Pictures; Ph.D. Dissertation, Department of Computer Science, University of Southern California, 1984 Raeder [85] Georg Raeder: A Survey of Current Graphical Programming Techniques; Computer, Vol. 18, No. 8, August 1985, Rechenberg [94] Peter Rechenberg: Was ist Informatik?; Hanser 1994 Reisig [91] Wolfgang Reisig: Petrinetze - Eine Einführung; Springer, 1991 Reiss [85] Steven P. Reiss: PECAN: Program Development Systems that Support Multiple Views; in ITSE, Vol. SE-11, No. 3, March 1985, ; auch in Glinert [90-P&S S ] Rekers und Schürr [95] J. Rekers, A. Schürr: A Graph Grammar Approach to Graphical Parsing; in VL [95], Repenning [95] Alexander Repenning: Bending the Rules: Steps toward Semantically enriched Graphical Rewrite Rules; in VL [95], Robertson et al. [93] Georg G. Robertson, Stuart K. Card, Jock D. Mackinlay: Information Visualization using 3D Interactive Animation; in CACM, April 1993, Vol. 36, No. 4, Rohr [86] Gabriele Rohr: How People Comprehend Unknown System Structures: Conceptual Primitives in Systems' Surface Representations; in Gorny und Tauber [86], Rohr [86-2] Gabriele Rohr: Using Visual Concepts; in Chang et al. [86], Roman und Cox [93] Gruia-Catalin Roman, Kenneth C. Cox: A Taxonomy of Program Visualization Systems; Computer, December 1993, Vol. 26, No. 12 Roussopoulos und Leifker [84] N. Roussopoulos, D. Leifker: An Introduction to PSQL: A Pictorial Structured Query Language; in VL [84], Rubin et al. [85] Robert V. Rubin, Eric J. Golin, Steven P. Reiss: ThinkPad: A Graphical System for Programming by Demonstration; IEEE Software, Vol. 2, No. 2, March 1985, 73-79

295 285 Sametinger [91] Johannes Sametinger: DOgMA: A Tool for the Documentation & Maintenance of Software Systems; Dissertation, Johannes Kepler Universität Linz, 1991 Sametinger [97] Johannes Sametinger: Software Engineering with Reusable Components; Springer 1997 Santori [90] Michael Santori: An instrument isn t really; IEEE Spectrum, Aug. 1990, Sayles et al. [94] Jonathan S. Sayles, Steve Karlen, Peter Molchan, Gary Bilodeau: GUI-based Design and Development for Client/Server Applications, Using PowerBuilder, SQLWindows, Visual Basic, PARTS Workbench; John Wiley & Sons 1994 Schürr et al. [95] A. Schürr, A. Winter, A. Zündorf: Visual Programming with Graph Rewriting Systems; in VL [95], Seiffert [91] Helmut Seiffert: Einführung in die Wissenschaftstheorie 1; Beck 1991 Selinger [95] Wolfgang Selinger: Visuelle Programmierung auf Basis wiederverwendbarer Software-Komponenten; Diplomarbeit, Institut für Informatik, Johannes Kepler Universität Linz, 1995 Selker und Koved [88] Ted Selker, Larry Koved: Elements of a Visual Language; in VL [88], Sengupta et al. [94] Samudra Sengupta, Takayuki Dan Kimura, Ajay Apte: An Artist's Studio: A Metaphor for Modularity and Abstraction in a Graphical Diagramming Environment; in VL [94], Serius [92] Serius Programmer Users Guide; Serius Corporation, 1992 Serius [92-2] Serius Developer Reference Manual; Serius Corporation, 1992 Sethi [89] R. Sethi: Programming Languages - Concepts and Constructs; Addison-Wesley 1989 Sharp [92] John A. Sharp (ed.): Data Flow Computing - Theory and Practice; Ablex Publishing Corporation, 1992 Sharp [92-2] John A. Sharp: A Brief Introduction to Data Flow; in Sharp [92], 1-15 Shlaer und Mellor [92] Sally Shlaer, Steven J. Mellor: Object Lifecycles - Modelling the World in States; Prentice Hall 1992 Shneiderman [83] Ben Shneiderman: Direct Manipulation: A Step Beyond Programming Language; Computer, Vol. 16, No. 8, August 1983, 57-69; auch in Glinert [90-A&I], Shu [85] Nan C. Shu: FORMAL: A Forms Oriented Visual Directed Application Development System; Computer, Vol. 18, No. 8, Aug. 1985, Shu [86] Nan C. Shu: Visual Programming Languages, a Perspective and a Dimensional Analysis; in Chang et al. [86], 11-34; auch in Glinert [90-P&S], Shu [88] Nan C. Shu: Visual Programming; Van Nostrand Reinhold 1988 Smith [75] David C. Smith: Pygmalion: A Creative Programming Environment; Ph.D. Dissertation, Technical Report STAN-CS , Department of Computer Science, Stanford University, 1975

296 286 Smith [87] Randall B. Smith: Experiences with the Alternate Reality Kit: An Example of the Tension Between Literalism and Magic; IEEE Computer Graphics and Applications, September 1987, 42-50; auch in Glinert [90-P&S], Smith [87-2] David N. Smith: Panel P1, Visual Languages: What, Why, and What's the Object? Moderator's Introduction; OOPSLA '87, Addendum to the Proceedings, Smith [88] David N. Smith: Visual Programming in the Interface Construction Set; in VL [88], Smith [93] David C. Smith: Pygmalion: An Executable Electronic Blackboard; in Cypher [93], Smith et al. [82] D.C. Smith, C. Irby, R. Kimball, W. Verplank, E. Harslem: Designing the Star User Interface; Byte, Vol. 7, No. 4, Apr. 1982, Snell [95] Monica Snell: Analysts predict $3.79 billion market for visual development tools by 1999; Computer, Vol. 28, No. 3, March 1995, 8-9 Spenke [93] M. Spenke: PERPLEX: Ein graphisch-interaktives System zur Unterstützung der logischen Programmierung; GMD-Bericht Nr. 207, Oldenbourg 1993 Spoerri [93] Anselm Spoerri: Visual Tools for Information Retrieval; in VL [93], Stasko und Patterson [92] John T. Stasko, Charles Patterson: Understanding and Characterizing Software Visualization Systems; in VL [92], 3-10 Staufer [87] Michael Staufer: Piktogramme für Computer; de Gruyter 1987 Stöger [93] Rudolf Stöger: Modellierung komplexer technischer Systeme mit den Methoden und Werkzeugen AKL und SDL; Diplomarbeit, Institut für Systemwissenschaften, Johannes Kepler Universität Linz, 1993 Suleiman und Citrin [92] Khalid A. Suleiman, Wayne V. Citrin: An International Visual Language; in VL [92], Sutherland [63] Ivan E. Sutherland: Sketchpad, A Man-Machine Graphical Communication System; AFIPS Conference Proceedings, Spring Joint Computer Conference, 1963, 2-19; auch in Glinert [90-P&S], Tanenbaum [94] A.S. Tanenbaum: Moderne Betriebssysteme; Hanser, Prentice- Hall, Tanimoto und Glinert [86] Steven L. Tanimoto, Ephraim P. Glinert: Designing Iconic Programming Systems: Representation and Learnability; in VL [86], 54-60; auch in Glinert [90-A&I], Tanimoto und Runyan [86] Steven L. Tanimoto, Marcia S. Runyan: PLAY: An Iconic Programming System for Children; in Chang et al. [86], ; auch in Glinert [90-P&S], Teitelman und Masinter [81] W. Teitelman, L. Masinter: The Interlisp Programming Environment; Computer, Vol. 14, No. 4, April 1981, Tripp [88] Leonard L. Tripp: A Survey of Graphical Notations for Program Design - An Update; ACM SIGSOFT Software Engineering Notes, Vol. 13, No. 4, 1988, 39-44; auch in Glinert [90-P&S], 60-71

297 287 Tufte [83] Edward R. Tufte: The Visual Display of Quantitative Information; Graphics Press 1983 Tufte [90] Edward R. Tufte: Envisioning Information; Graphics Press 1990 Udell [94] Jon Udell: Componentware; Byte, Vol. 19, No. 5, May 1994, Ungar und Smith [87] David Ungar, Randal B. Smith: Self: The Power of Simplicity; OOPSLA '87 Proceedings, Ungerer [93] Theo Ungerer: Datenflußrechner; Teubner 1993 Veer et al. [86] Gerrit C. van der Veer, John van Beek, Guus A.N. Cruts: Learning Structured Diagrams - Effect of Meathematical Background, Instruction, and Problem Semantics; in Gorny und Tauber [86], VisualAge [95] IBM: VisualAge for Smalltalk, User's Guide, Version 3.0; International Business Machines Corporation, 1995 VisualWorks [94] ParcPlace Systems: VisualWorks User's Guide; ParcPlace Systems 1994 VL [84] Proceedings 1984 IEEE Workshop on Visual Languages, 1984, Hiroshima, Japan; IEEE Computer Society Press, 1984 VL [87] Proceedings 1987 IEEE Workshop on Visual Languages, Aug , 1987, Linkoping, Sweden; IEEE Computer Society Press, 1987 VL [88] Proceedings 1988 IEEE Workshop on Visual Languages, Oct , 1988, Pittsburgh, Pennsylvania, USA; IEEE Computer Society Press, 1988 VL [89] Proceedings 1989 IEEE Workshop on Visual Languages, 1989, Rome, Italy; IEEE Computer Society Press, 1989 VL [90] Proceedings 1990 IEEE Workshop on Visual Languages, Oct. 4-6, 1990, Skokie, Illinois, USA; IEEE Computer Society Press, 1990 VL [91] Proceedings 1991 IEEE Workshop on Visual Languages, Oct. 8-11, 1991, Kobe, Japan; IEEE Computer Society Press, 1991 VL [92] Proceedings 1992 IEEE Workshop on Visual Languages, Sept , 1992, Seattle, Washington, USA; IEEE Computer Society Press, 1992 VL [93] Proceedings 1993 IEEE Symposium on Visual Languages, Aug , 1993, Bergen, Norway; IEEE Computer Society Press, 1993 VL [94] Proceedings 1994 IEEE Symposium on Visual Languages, Oct. 4-7, 1994, St. Louis, Missouri, USA; IEEE Computer Society Press, 1994 VL [95] Proceedings 1995 IEEE Symposium on Visual Languages, Sept. 5-9, 1995, Darmstadt, Germany; IEEE Computer Society Press, 1995 Wang und Lee [93] Dejuan Wang, John R. Lee: Visual Reasoning: its Formal Semantics and Applications; in JVLC, Vol. 4, No. 4, December 1994, Ware [93] Colin Ware: The Foundations of Experimental Semiotics: a Theory of Sensory and Conventional Representation; in JVLC, Vol. 4, No. 1, March 1993,

298 288 Wasserman et al. [86] Weinand et al. [89] Weinreich [93] Wessells [90] Wirth [86] Wittenburg [92] Yao et al. [84] Zloof [81] A.I. Wasserman, P.A. Pircher, D.T. Shewmake, M.L. Kersten: Developing Interactive Information Systems with the User Software Engineering Methodology; in ITSE, Vol. SE-12, No. 2, Feb. 1986, A. Weinand, E. Gamma, R. Marty: Design and Implementation of ET++, a Seamless Object-Oriented Application Framework; Structured Programming, Vol. 10, No. 2, 1989, 1-33 Rainer Weinreich: Concepts and Techniques for Object-Oriented Software Development; Dissertation, Institut für Wirtschaftsinformatik, Johannes Kepler Universität Linz, 1993 Michael G. Wessells: Kognitive Psychologie; Ernst Reinhardt 1990 Niklaus Wirth: Algorithmen und Datenstrukturen mit Modula-2; Teubner 1986 Kent Wittenburg: Early-style Parsing for Relational Grammars; in VL [92], S.B. Yao, A.R. Hevner, Z. Shi, D. Luo: FORMANAGER: An Office Forms Management System; ACM Transactions of Office Information Systems, Vol. 2, No. 3, July 1984, Moshé M. Zloof: QBE/OBE: A Language for Office and Business Automation; Computer, Vol. 14, No. 5, May 1981, 13-22; auch in Glinert [90-A&I],

299 Literaturindex 289

300 290 Ambler und Burnett [89] 14 Anderson [89] 77, 78 Baecker und Marcus [86] 86 Baecker und Marcus [90] 28, 38 Bell und Lewis [93] 118 BetterState [94] 99 Biermann und Krishnaswamy [76] 86 Blaschek [94] 222 Blaschek et al. [87] 68 Boecker et al. [86] 39, 86 Borne [93] 24 Brockhaus [94-20] 16 Brockhaus [94-22] 2 Brockhaus [94-23] 13 Broer [94] 159 Brown et al. [85] 86 Brown und Kimura [94] 44 Brown und Sedgewick [85] 86 Budd [90] 115 Burnett [91] 147 Burnett und Ambler [92] 123 Burnett und Baker [94] 92, 94 Cardelli und Pike [85] 87 Chang [87] 89 Computer [82] 101 Cormen et al. [90] 32 Costagliola et al. [95] 20, 21 Cunniff et al. [86] 87 Dähler [89] 100 Dennis [74] 101 Diaz-Herrera und Flude [80] 87 Dijkstra [89] 68 Duden [84] 18 Duden [92] 15 Dudley und Mahling [91] 26 ECS [93] 9 Edel [86] 88 ESE [94] 9 Finzer und Gould [84] 86 Frei et al. [78] 4, 87, 96 Friedell et al. [82] 86 Fröhlich [96] 39, 42 Gaudiot und Bic [91] 101 Gernet [88] 18 Ghezzi und Jazayeri [87] 23 Giacalone et al. [84] 88 Glinert [90] 6, 50, 80, 129 Glinert und Stotts [92] 95 Glinert und Tanimoto [84] 5, 88, 96 Gloor [92] 31 Goldman et al. [85] 86 Golin und Reiss [90] 19 Gorlick und Quilici [94] 257 Grafton und Ichikawa [85] 22, 267 Green und Petre [92] 64, 66 Green und Petre [94] 260 Gurd [91] 101 Gutknecht [95] 17 Halbert [84] 86 Herath et al. [92] 101 Herot [80] 87 Hirakawa et al. [86] 87 Hirakawa et al. [87] 88 Huges und Moshell [86] 86 Ichikawa et al. [90] 51 Jacob [85] 87 Kahn und Saraswat [90] 20 Kapolka [90] 18 Kay [93] 2 Kimura et al. [86] 88 Kimura et al. [90] 52 Kopache und Glinert [88] 130 Korson und McGregor [90] 115 Kratzer [95] 159 Kurita und Tamura [84] 88 Lakin [86] 17, 88, 267 LaLonde und Pugh [93] 159, 161 Leibs und Goldberg [93] 52 Lin und Chang [80] 87 Ludolph et al. [88] 91 Marriot [94] 19 Matwin und Pietrzykowski [85] 88 Mayer [95] 215 McDonald [84] 86 Meyer [88] 115 Meyer [90] 115, 181 Meyer [92] 19 Meyers-Philosophie [87] 16 Moriconi und Hare [85] 86 Myers [83] 86 Myers [87] 86 Myers [94] 89, 91, 92 Najork und Kaplan [92] 8 Nickerson [94] 257 Olympia [94] 131 Pandey und Burnett [93] 124 PARTS [92] 159, 164 PARTS [WWW] 159 Petre [95] 55, 76 Pomberger und Blaschek [96] 101, 115, 255 Pong und Ng [83] 4, 87, 96 Poswig [93] 85 Poswig [96] 45, 80, 85, 112, 147, 148, 152, 156 Price et al. [93] 2, 33, 34, 35, 268 Raeder [84] 86 Rechenberg [94] 212, 215 Reiss [85] 86 Rekers und Schürr [95] 19 Robertson et al. [93] 34 Rohr [86] 49 Rohr [86-2] 49 Roman und Cox [93] 36, 37, 38 Roussopoulos und Leifker [84] 87 Rubin et al. [85] 86 Sametinger [91] 254 Santori [90] 133 Sayles et al. [94] 64, 159 Schürr et al. [95] 119 Seiffert [91] 15 Selinger [95] 159 Sengupta et al. [94] 16 Serius [92] 132 Serius [92-2] 2 Sethi [89] 110 Sharp [92] 100 Sharp [92-2] 101 Shu [85] 88 Shu [86] 14 Shu [88] 4, 7, 16, 22, 26, 32, 34, 41, 51, 57, 67, 70, 72, 80, 81, 82, 86, 87, 88, 96, 266, 267, 270 Smith [75] 86 Smith [88] 91 Smith [93] 3 Smith et al. [82] 88 Snell [95] 6, 266 Spoerri [93] 34 Stasko und Patterson [92] 34 Staufer [87] 19 Teitelman und Masinter [81] 86 Tripp [88] 96 Tufte [90] 34, 61 Ungerer [93] 101, 104

301 291 Veer et al. [86] 69, 252 VisualAge [95] 159 Ware [93] 73 Wasserman et al. [86] 87 Weinreich [93] 161, 211, 222 Wirth [86] 31 Wittenburg [92] 19 Yao et al. [84] 88 Zloof [81] 4, 88, 123

302 292 Bildverzeichnis Bild 1-1. Pendeluhr und Bildschirmuhr Bild 1-2. Pygmalion Fenster zur Definition der Fakultätsfunktion... 3 Bild 1-3. Ausschnitt eines Pict-Programms; Farbbild im Anhang... 6 Bild 1-4. Die Fakultätsfunktion in CUBE... 8 Bild 2-1. Visuelle Dichtung: Eugen Gomringer»Schweigen«, Bild 2-2. Das VP-System VisualWorks (Ausschnitt) Bild 2-3. Das VP-System LabVIEW (Ausschnitt); Farbbild im Anhang Bild 2-4. Strukturierte Flußdiagramme in VLCC Bild 2-5. Verflechtung von Benutzungsschnittstelle und Programmiersprache: die Fallunterscheidung in Prograph Bild 2-6. Rein verbale Darstellung der Funktion getsline Bild 2-7. Visuell aufbereitete Darstellung der Funktion getsline Bild 2-8. Visuelles LabVIEW-Programm der Funktion getsline; Farbbild im Anhang Bild 2-9. Visualisierung von Lösungsideen Bild Visualisierung von Datenstrukturen: Linksrotation eines binären Suchbaums Bild Bereiche der Softwarevisualisierung nach Price et al Bild Verschiedene Aspekte der Softwarevisualisierung; Farbbild im Anhang Bild Visualisierung von Prozessen und Semaphoren in Vista; Farbbild im Anhang Bild Visualisierung einer LISP-Datenstruktur: der Unterschied zwischen append und nconc Bild Stack Browser des Objekt-Architektur-Analysators Bild Ein Programm, das mit einer visuellen Universalsprache erstellt wurde; Farbbild im Anhang Bild Eine einfache visuelle Softwarebeschreibungssprache für Vererbungsbeziehungen Bild 3-1. Metaphorische Korrespondenz als Basis für eine visuelle Programmiersprache Bild 3-2. Zwei äquivalente Zustandsdiagramme eines Süßigkeitsautomaten Bild 3-3. Dasselbe Bild, vier Betrachter, vier Interpretationen Bild 3-4. Sind Bilder tatsächlich bessere Kommunikationsmittel als Text? Bild 3-5. Ein Lügenfaktor von 14, Bild 3-6. Eindeutige Beschreibung und mehrdeutige Darstellung eines Graphen Bild 3-7. Jahreszyklus des Popillia japonica Newman Bild 3-8. Ein einfaches PARTS-Programm Bild 3-9. Zwei äquivalente logische Ausdrücke als LabVIEW-Programm und in Pseudocode Bild Ein typisches Suchmuster bei der Auswertung des LabVIEW-Programms aus Bild Bild Ein visuelles Programm in der Sprache Mandala; Farbbild im Anhang Bild Bedingte Verzweigung als Steuerflußdiagramm Bild Ausschnitt aus einer Serius-Anwendung Bild Ist internationale Verständlichkeit in der Programmierung durch Verzicht auf Text erreichbar? Diagramm aus Pictorial Janus Bild Sechs Fenster für eine Funktion - Mischsortieren in Prograph Bild Bedeutung und Erinnerung: Ein schnüffelnder Hund (nach Ronald James) Bild Kann man sich dieses LabVIEW-Programm leicht merken? Bild 4-1. Klassifikation der visuellen Programmierung nach Shu Bild 4-2. Drei Aspekte von Programmiersprachen nach Shu Bild 5-1. Schematische Darstellung eines Komponentennetzes Bild 5-2. Zustandsdiagramm in BetterState Bild 5-3. Petrinetz in PACE Bild 5-4. Schematische Darstellung eines Datenflußprogramms Bild 5-5. Beispiele für konkrete Ausprägungen eines Datenflußprogramms Bild 5-6. Ausführung eines Datenflußprogramms Bild 5-7. Das Newtonsche Verfahren als Datenflußprogramm Bild 5-8. Das Newtonsche Verfahren als Datenflußdiagramm in LabVIEW

303 Bild 5-9. Funktionsdiagramm in VisaVis Bild Objektorientiertes Programm in PARTS Bild Constraints in ThingLab Bild Transformationsregeln in ChemTrains Bild Wohlgeformtes und unstrukturiertes Flußdiagramm Bild Programmierung mit Beispielen mit Script Editor Bild Programmierung durch Beispiele mit MetaMouse Bild Formularorientierte Programmierung mit Forms/ Bild Multiparadigmenorientierte Programmierung mit Prograph Bild 6-1. Schematische Darstellung eines Programms in der Proc-BLOX-Notation Bild 6-2. Definition einer Funktion für die binäre Suche in C Bild 6-3. Das VP-System Serius; oben: Komponentennetz zur Realisierung einer Stoppuhr; unten: Objekt- und Funktionspalette Bild 6-4. Frontplatte und Blockschaltbild eines LabVIEW-Programms zur Temperaturmessung; Farbbild im Anhang Bild 6-5. Ablaufstrukturen in G Bild 6-6. Maximumberechnung mit Verzweigung in G Bild 6-7. Wortübersetzung mit Fallunterscheidung in G Bild 6-8. Schieberegister in G Bild 6-9. Das Newtonsche Verfahren in G Bild Verschiedene Entwicklungsstadien des Temperaturmeßsystems; Farbbild im Anhang Bild Der Butterfly-Algorithmus für die schnelle Fourier-Transformation Bild Die vier Grundelemente der Sprache VisaVis; Farbbild im Anhang Bild Anwendungen von Bausteinen und Platinen; Farbbild im Anhang Bild Ablaufstrukturen in VisaVis Bild Maximumberechnung mit Verzweigung in VisaVis Bild Wortübersetzung mit Fallunterscheidung in VisaVis Bild Das Newtonsche Verfahren in VisaVis Bild Bedingungsschleife in VisaVis Bild Zählerschleife in VisaVis Bild Funktionsspeicher und visueller Editor von VisaVis Bild Ereignisverbindung in PARTS Bild Resultat- und Argumentverbindungen in PARTS; Farbbild im Anhang Bild Verzweigung mit dem Baustein Comparison; Farbbild im Anhang Bild Verzweigung mit dem Baustein Link Junction Bild Bausteinkatalog und Arbeitsfläche von PARTS; Farbbild im Anhang Bild 7-1. Vereinfachende Darstellung der komponentenbasierten Softwareentwicklung Bild 7-2. Schichtenstruktur einer VisualWorks-Applikation Bild 7-3. Schnittstellen eines Einfachprozessors (links) und Verbundprozessors (rechts) Bild 7-4. Verbindung von zwei Prozessoren mit einem Kanal Bild 7-5. Netzwerk aus Prozessoren Bild 7-6. Tokenfluß zwischen Benutzungsschnittstelle und Vista Bild 7-7. Weg eines Tokens durch ein Netzwerk Bild 7-8. Rückkopplung zwischen Signalprozessoren Bild 7-9. Aktiver Signalprozessor Bild Interface eines Verbundprozessors Bild Interior eines Einfachprozessors (oben) und eines Verbundprozessors (unten) Bild Darstellung von Ports Bild Smalltalk-Methode für Eingangsport countdown des Prozessors Timer Bild Smalltalk-Methode für den Resetport des Prozessors Timer Bild Verwendung von Sequenzports Bild Ein X-Netzwerk des PLP-Prozessors Bild Ein I-Netzwerk des PLP-Prozessors Bild Ein T-Netzwerk zur Prüfung des PLP-Prozessors Bild Datennetzwerk zur Suche des größten Elements eines Felds Bild Eine Methode des PLP-Prozessors und ihr Aufruf in einem Netzwerk

304 Bild Original und Stellvertreter Bild Feingranulare Parallelität in Vista; Farbbild im Anhang Bild Parallele Prozesse in Vista; Farbbild im Anhang Bild Prozeßkommunikation mit Hilfe eines Transmitters Bild Prozeßsynchronisation durch Semaphore; Farbbild im Anhang Bild Semaphor-Prozessor zur programmgesteuerten Aktivierung eines Semaphors Bild Exemplarbasierte Modifikation des Netzwerks walknet des PLP-Prozessors Bild Klasse des PLP-Prozessors Bild Substitution von öffentlichen Prozessoren Bild Vererbungshierarchie für Einfachsignalprozessoren Bild Spezialisierungen der Prozessorklasse Timer Bild Vererbung von Netzwerken Bild Abstrakte und konkrete Prozessorklassen Bild Selbstmodifikation eines Signalnetzwerks Bild Alternative Implementierung des Signalnetzwerks aus Bild Bild Nicht-deterministische Ergebnisse bei Operationen über Objekten Bild Datentyp-Register Bild Hierarchie der Verbundtypen Bild Datentyp-Browser Bild Erzeugung einer Konstanten Bild Bundle- und Unbundle-Operation für DateType Bild Anwendung der Unbundle-Operation Bild Typkonvertierung für Time und TimeType Bild TA-Prozessor (links) und Testapplikation (rechts) Bild Architektur der Testapplikation; Farbbild im Anhang Bild Change-Update-Beziehung zwischen Objektspeicher lowc und Prozessor low Bild Initialisierung des TA-Prozessors Bild Hierarchie-Browser und Prozessor-Register für die Klassendefinition von TA Bild Interface, Interior und T-Netzwerk von TA Bild Netzwerke tempchanged (links) und tempcheck (rechts) Bild Netzwerke minchanged (rechts) und maxchanged (links) Bild 8-1. Annähernd flächengleiche Darstellung von textuellem und grafischem Programmcode der gleichen Funktion

305 295 Bildreferenzen Pendeluhr: Brockhaus [94-22 S. 526]; Bildschirmuhr: vgl. Serius [92-2 S ff]... 2 Smith [93 S. 43]... 3 Glinert [90-P&S S. 657, g-i]... 6 Najork und Kaplan [92 S. 271, Abb. 2 und Abb. 3]... 8 Vgl. Brockhaus [94-23 S. 382] Costagliola et al. [95 S. 63 Abb. 8, S. 64 Abb. 9.b, S. 65 Abb. 11] Baecker und Marcus [90 S. 205] Konvexe Hülle: Gloor [92 S. 28, Abb. 2]; Sortieren einer Datei: Wirth [86 S. 76, Abb. 2.2] Cormen et al. [90 S. 267, Abb. 14.3] Price et al. [93 S. 213] Vgl. Roman und Cox [93 S. 12 f] Shu [88 S. 30, Fig 2-10] Vgl. Fröhlich [96] Vgl. Poswig [96 S. 71 f und S. 92] Glinert [90 S. 175, Abb. 3-15] Hoare [85 S. 35] Petre [95 S. 34, Abb. 1] Shu [88 S. 8, Abb. 1-4] Tufte [83 S. 57] Hiebl [94 S. 10] Tufte [90 S. 110] Sayles et al. [94 S. 292, Abb. 9.36] Green und Petre [92 S. 13 u. 14] Vgl. Green und Petre [92 S. 13] Shu [88 S. 11, Abb. 1-6] Hoare und Jones [89 S. 358] Kahn et al. [91 S. 6, Abb. 3] Anderson [89 S. 107, Abb. 5.2] Shu [88 S. 12] Shu [88 S. 140] Myers [94 S. 880] Myers [94 S. 880] Burnett und Baker [94 S. 289] Vgl. BetterState [94] Vgl. Dähler [89] Vgl. Poswig [96 S. 71 f und S. 92] Vgl. Borning [81] in Glinert [90-P&S S. 430] Vgl. Bell und Lewis [93 S. 188] Vgl. Schürr et al. [95 S. 327, Fig. 1] Vgl. Maulsby und Witten [93 S. 158 und S. 163] Vgl. Pandey und Burnett [93 S. 346] Glinert [90-A&I S. 550, Abb. 3] Kopache und Glinert [88 S. 236, Abb. 4] Poswig [96 S. 116] Vgl. Poswig [96 S. 72] Vgl. Poswig [96 S. 76] Vgl. Poswig [96 S. 94 f] Vgl. Poswig [96 S. 94 f]