Start
 

Nach oben


 
Impressum

Stefan Schiffer
stefan@schiffer.at
+43 (699) 12547249
 
 

 

 

 

Restexemplare dieses Buches sind günstig direkt beim Autor erhältlich

Europa: EUR 30,-- inkl. Versand (statt EUR 46,-- CHF 78,--)

Das Buch wird mit Nachnahme versandt. Wenn Sie ein Exemplar wünschen, dann wenden Sie sich bitte per E-Mail an den Autor.

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




Bild 1-1
Pendeluhr und Bildschirmuhr.
Pendeluhr: Brockhaus [94-22 S. 526]; Bildschirmuhr: vgl. Serius [92-2 S. 12-1 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 nachzudenken, welche Vorteile sich durch den Einsatz von Grafik in der Programmierung ergeben könnten. 1975 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]

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

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

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




Bild 1-3 Ausschnitt eines Pict-Programms.

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?

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 findet 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]

Previous PageTop Of PageNext Page