Ein visuelles Programmiersystem zur Modellierung deskriptiver Untersuchungen in der Datenanalyse

Keltsch, Carsten

Ein visuelles Programmiersystem zur Modellierung deskriptiver Untersuchungen in der Datenanalyse

Zusammenfassung

Inhaltsangabe:Einleitung:
Die herkömmliche Vorgehensweise, Programme manuell über textuelle Eingaben zu erstellen, ist trotz einiger Unzulänglichkeiten nach wie vor weit verbreitet. Große Probleme ergeben sich beispielsweise bei der strukturierten Darstellung des textuellen Programmcodes und bei einer damit möglicherweise verbundenen Vereinfachung des Programmiervorgangs. Neuere Programmiertechniken versuchen sich dieser und weiterer Mißstände anzunehmen und geben durch neue Konzepte Alternativen zur herkömmlichen Programmerstellung. Visuelle Programmiersysteme unterstützen den Programmierer in dieser Hinsicht bei seiner Arbeit durch visuelle Programmiertechniken, um Softwareprodukte zu implementieren. Der Begriff visuell bezieht sich auf die optische Aufnahme sowie Handhabung von Informationen, die meist in bildlicher Form optisch repräsentiert werden. Visuelle Programmiertechniken erlauben es, solche Informationen optisch miteinander zu kombinieren. Dem Anwender wird so eine visuelle Kommunikation mit dem Programmiersystem ermöglicht, die die Informationsvermittlung durch optisch wahrnehmbare Zeichen bzw. Signale, wie z.B. Schrift und Bild beinhaltet [Mey81].
Auf diese intuitive Art und Weise können komplexe Applikationen schnell visuell modelliert und erstellt werden. Dies geschieht mit Hilfe visueller Objekte, die innerhalb einer Programmierumgebung mit anderen Objekten kombiniert werden und so einen Programmfluß auf Grundlage der verschiedenartigen Programmierparadigmen (vgl. [Sch98]) beschreiben. Dabei kommt diesem Verfahren zugute, daß der Mensch offensichtlich bildliche (visuelle) Informationen sehr viel schneller mit einem sehr viel höheren Informationsgehalt aufnehmen kann, als ein textuelles Äquivalent [And88, BBB+95]. Im Optimalfall wird durch ein visuelles Programmiersystem dabei das Verfahren der Programmentwicklung soweit vereinfacht, daß sogar Nichtprogrammierer in die Lage versetzt werden, ohne Kenntnis der zugrundeliegenden Programmiersprache ihre Ideen und Projekte zu verwirklichen. Typischerweise besteht ein solches Programmiersystem aus zwei wesentlichen Komponenten, einem zwei- oder mehrdimensionalen Editor und einer Übersetzungskomponente, die das im Editor modellierte Programm von der bildlichen Darstellung in ausführbaren Programmcode übersetzt oder direkt interpretiert.
Der Ursprung solcher Systeme findet sich im klassischen Anwendungsgebiet der Systemprogrammierung, wobei sich diese Umgebungen in den letzten Jahren […]

Leseprobe

Inhaltsverzeichnis

ID 6783

Keltsch, Carsten: Ein visuelles Programmiersystem zur Modellierung deskriptiver

Unterscheidungen in der Datenanalyse

Hamburg: Diplomica GmbH, 2003

Zugl.: Oldenburg, Universität, Diplomarbeit, 1998

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2003

Printed in Germany

Inhaltsverzeichnis

1 Einleitung ...1

2 Visuelle Programmierung...5

2.1 Paradigmen visueller Programmierung ...8

2.1.1 Datenfluß...8

2.1.2 Kontrollfluß...11

2.1.3 Weitere ausgewählte Paradigmen...12

2.2 Das Pro und Kontra visueller Programmierung ...13

2.3 Motivation visueller Programmierung in der Datenanalyse...16

2.4 Existierende visuelle Programmiersysteme in der Datenanalyse ...18

2.4.1 Analyseschema ...18

2.4.2 Das visuelle Programmiersystem ViSta ...21

2.4.3 LabVIEW...25

2.4.4 Cantata...29

2.4.5 AVS/Express ...32

2.4.6 Überblick über die vorgestellten Systeme ...35

3 Anforderungsdefiniton für das System viDUMP ...38

3.1 Die EPI-Workbench ...38

3.2 Probleme im Umgang mit der EPI-Workbench ...41

3.3 Anforderungsdefinition für viDUMP...43

3.3.1 Funktionsumfang und Außenverhalten ...43

3.3.2 Entwicklungs- und Einsatzumgebung ...48

3.3.3 Schnittstellen und Nebenbedingungen ...49

4 Entwurf eines visuellen Programmiersystems ...50

4.1 Das Datenmodell von CARESS...51

4.2 Formales Modell der Komponenten von viDUMP ...52

4.2.1 Das IMRA-Modell ...53

4.2.2 Datenfolgen und Ports ...53

4.2.3 Bearbeitungsoperator ...57

4.2.4 Datenquelle und Datensenke ...59

4.2.5 Kontrolloperatoren ...61

4.2.6 Skalierbarkeit ...67

4.2.7 Untersuchungen ...72

4.2.8 Die Komponenten einer Untersuchung im Überblick ...72

4.3 Dynamische Aspekte des Systems ...74

4.3.1 Parallelität ...74

4.3.2 Kommunikationspfade eines Schleifenoperators ...76

4.3.3 Interpretation der Untersuchung ...79

4.4 Konzeption der Benutzungsoberfläche ...83

4.4.1 Symbole zur visuellen Modellierung einer Untersuchung ...83

4.4.2 Der zweidimensionale Editor...85

Inhaltsverzeichnis

5 viDUMP Implementierung des Systems...88

5.1 Entwicklungsumgebung ...88

5.2 Die Architektur des Systems ...89

5.2.1 Die Benutzungsoberfläche von viDUMP ...89

5.2.2 Interne Informationsverwaltung ...90

5.2.3 Verfahren und Anwendbarkeitstests...91

5.2.4 Datenfolge...92

5.2.5 Interpretation ...92

5.2.6 Überblick über die Architektur von viDUMP ...92

5.3 Schnittstellen ...93

5.3.1 Konstanten ...94

5.3.2 Erweiterung des Systems um neue Verfahren ...94

6 Zusammenfassung und Ausblick ...95

Anhang A - Die Klassen von viDUMP...99

Anhang B - Die Klassenhierarchien...103

Literaturverzeichnis...105

Index ...110

Abbildungsverzeichnis

iii

Abbildungsverzeichnis

Abbildung 2.1: Taxonomie für die visuelle Unterstützung in der Programmierung...5

Abbildung 2.2: Schematische Darstellung des Datenflußprinzips ...9

Abbildung 2.3: Ein Beispiel für das Screen-Space-Problem ...15

Abbildung 2.4: Vorgehensweise in der Explorativen Datenanalyse ...17

Abbildung 2.5: Ein Analyseschema für visuelle Programmiersysteme ...21

Abbildung 2.6: Die Ebenen Guidemap, Workmap und CLI in ViSta ...24

Abbildung 2.7: Eine beispielhafte Bedienoberfläche in LabVIEW ...28

Abbildung 2.8: Die Programmlogik als Blockdiagramm in LabVIEW ...29

Abbildung 2.9: Beispielprogramm in Cantata...32

Abbildung 2.10: Beispielapplikation im System AVS/Express ...35

Abbildung 2.11: Überblick über die vorgestellten visuellen Programmiersysteme ...36

Abbildung 3.1: Graphischer Editor der EPI-Workbench ...41

Abbildung 3.2: Trennung von Visualisierung und Funktionalität in viDUMP...45

Abbildung 4.1: Der Aufbau von Ports und ihre Zuordnung...56

Abbildung 4.2: Struktur eines Bearbeitungsoperators...59

Abbildung 4.3: Schematischer Aufbau einer Datenquelle ...60

Abbildung 4.4: Schematischer Aufbau einer Datensenke ...61

Abbildung 4.5: Die verschiedenen Realisierungsmöglichkeiten des Kontrolloperators ...62

Abbildung 4.6: Struktur des d-Operators ...64

Abbildung 4.7: Struktur des b-Operators ...65

Abbildung 4.8: Der schematische Aufbau einer Schleife im Überblick ...66

Abbildung 4.9: Der Aufbau eines Schleifenoperators aus einem d- und einem b-Operator ...67

Abbildung 4.10: Problem der eindeutigen Zuordnung von ein- und ausgehenden Datenfolgen ...68

Abbildung 4.11: Funktionsweise der Aggregations- und De-Aggregationsknoten ...69

Abbildung 4.12: Aufbau eines Aggregationsoperators ...70

Abbildung 4.13: Überblick und Zusammenhänge des statischen Modells von viDUMP...73

Abbildung 4.14: Mögliche Varianten paralleler Verarbeitung innerhalb eines b-Operators...75

Abbildung 4.15: Kommunikationspfade eines Schleifenoperators ...78

Abbildung 4.16: Die Algorithmen _interpreter, start_dq und start als Startpunkt der Interpretation...80

Abbildung 4.17: start_op zur Differenzierung des Folgeoperators...81

Abbildung 4.18: Der Algorithmus start_bo zur Initiierung eines Bearbeitungsoperators ...82

Abbildung 4.19: Die Algorithmen start_db-op, start_aggop und start_deaggop...82

Abbildung 4.20: Die Symbole zur Repräsentation der Bausteine einer Untersuchung...84

Abbildung 4.21: Verwendung des Schleifenoperators...84

Abbildung 4.22: Der grafische Editor von viDUMP ...85

Abbildung 4.23: Parametrisierung eines b-Operators ...87

Abbildung 5.1: Die Architektur des visuellen Programmiersystems viDUMP...93

Abbildung 6.1: Die Klassenhierarchien von viDUMP (a) ...103

Abbildung 6.2: Die Klassenhierarchien von viDUMP (b) ...104

1. Einleitung

1 Einleitung

Die herkömmliche Vorgehensweise, Programme manuell über textuelle Eingaben zu erstellen, ist trotz

einiger Unzulänglichkeiten nach wie vor weit verbreitet. Große Probleme ergeben sich beispielsweise

bei der strukturierten Darstellung des textuellen Programmcodes und bei einer damit möglicherweise

verbundenen Vereinfachung des Programmiervorgangs. Neuere Programmiertechniken versuchen sich

dieser und weiterer Mißstände anzunehmen und geben durch neue Konzepte Alternativen zur

herkömmlichen Programmerstellung. Visuelle Programmiersysteme unterstützen den Programmierer

in dieser Hinsicht bei seiner Arbeit durch visuelle Programmiertechniken, um Softwareprodukte zu

implementieren. Der Begriff ,,visuell" bezieht sich auf die optische Aufnahme sowie Handhabung von

Informationen, die meist in bildlicher Form optisch repräsentiert werden. Visuelle

Programmiertechniken erlauben es, solche Informationen optisch miteinander zu kombinieren. Dem

Anwender wird so eine visuelle Kommunikation mit dem Programmiersystem ermöglicht, die die

Informationsvermittlung durch optisch wahrnehmbare Zeichen bzw. Signale, wie z.B. Schrift und Bild

beinhaltet [Mey81].

Auf diese intuitive Art und Weise können komplexe Applikationen schnell visuell modelliert und

erstellt werden. Dies geschieht mit Hilfe visueller Objekte, die innerhalb einer Programmierumgebung

mit anderen Objekten kombiniert werden und so einen Programmfluß auf Grundlage der

verschiedenartigen Programmierparadigmen (vgl. [Sch98]) beschreiben. Dabei kommt diesem

Verfahren zugute, daß der Mensch offensichtlich bildliche (visuelle) Informationen sehr viel schneller

mit einem sehr viel höheren Informationsgehalt aufnehmen kann, als ein textuelles Äquivalent

[And88, BBB+95]. Im Optimalfall wird durch ein visuelles Programmiersystem dabei das Verfahren

der Programmentwicklung soweit vereinfacht, daß sogar Nichtprogrammierer in die Lage versetzt

werden, ohne Kenntnis der zugrundeliegenden Programmiersprache ihre Ideen und Projekte zu

verwirklichen. Typischerweise besteht ein solches Programmiersystem aus zwei wesentlichen

Komponenten, einem zwei- oder mehrdimensionalen Editor und einer Übersetzungskomponente, die

das im Editor modellierte Programm von der bildlichen Darstellung in ausführbaren Programmcode

übersetzt oder direkt interpretiert.

Der Ursprung solcher Systeme findet sich im klassischen Anwendungsgebiet der

Systemprogrammierung, wobei sich diese Umgebungen in den letzten Jahren auch innerhalb vieler

anderer Anwendungsbereiche immer größerer Beliebtheit erfreuen. Visuelle Programmiertechniken,

abgeleitet von den Umgebungen der Systemprogrammierung, können so vielfältig genutzt werden.

Neben den dafür bekanntesten Beispielen der Anwendungsbereiche Multimedia und Workflow (vgl.

[Kel97]) lassen sich visuelle Konzepte unter anderem auch im Anwendungsbereich der Datenanalyse

einsetzen.

Im Anwendungsbereich der Datenanalyse wird mit sehr großen Datenmengen hantiert, und es wird

versucht, aus diesen durch verschiedene Bearbeitungsverfahren neue Sachverhalte und Informationen

zu gewinnen. Dazu stehen teilweise sehr komplexe Verfahren zur Verfügung, die entsprechend

modelliert und meist auch in verschiedenen Programmiersprachen implementiert werden müssen. Dies

kann je nach Verfahren ein äußerst aufwendiger Prozeß werden, der dann nicht nur Spezialkenntnisse

aus der Datenanalyse erfordert, sondern oft auch Programmierkenntnisse in einer oder mehreren

1. Einleitung

Programmiersprachen voraussetzt. Ein visuelles Programmiersystem, ähnlich zu denen, die in der

Systemprogrammierung zum Einsatz kommen, kann für diesen Anwendungsbereich eine große Hilfe

bei der Modellierung von solchen Datenbearbeitungsverfahren darstellen. Man erhielte eine visuelle

Modellierungsmöglichkeit, die von den Spezialkenntnissen der Programmierung abstrahiert bzw. das

erforderliche Wissen über diese minimiert, so daß sich der Anwender wieder auf den für ihn

wesentlichen Bereich der Datenanalyse konzentrieren kann. Die anschließende Übersetzung und

Ausführung des visuell modellierten Verfahrens übernimmt dann das System, und der Anwender

braucht sich so nur noch der anschließenden Interpretation der Daten widmen.

Im OFFIS entstand im Rahmen des Projektes CARLOS [AFH+97] ein grafischer Editor, die EPI-

Workbench [Wie94], mit dessen Hilfe deskriptive epidemiologische Untersuchungen modelliert und

ausgeführt werden können. Die Workbench bedient sich dabei visueller Programmiertechniken, um

auf intuitive Art und Weise epidemiologische Untersuchungen zu modellieren. Ausgehend von einer

oder mehreren Datenquellen können Datenströme über verschiedene Knoten, die konkrete Verfahren

beinhalten, bearbeitet werden. Der modellierte Datenfluß präsentiert sich somit als ein zyklenfreies

Netz aus Knoten (Verfahren) und gerichteten Kanten (Datenströme). In den einzelnen Knoten können

verschiedene Verfahren ausgewählt und parametrisiert werden, je nach Anforderung und Art des

Verfahrens. Um von vornherein fehlerhafte Berechnungen einzuschränken und auch dem Anwender

eine konkrete Hilfestellung zu geben, werden für jedes Verfahren ein oder mehrere

Anwendbarkeitstests durchgeführt. Diese bewerten das ausgewählte Verfahren in Hinblick auf seine

Anwendbarkeit auf den eingehenden Datenstrom und markieren für den Anwender die einlaufende

Kante farbig, je nach dem, wie gut das Verfahren auf die eingehenden Daten anwendbar ist.

Das System bietet eine einfache Handhabung auch komplexerer Verfahren, jedoch ist dies mit einigen

Einschränkungen verbunden, die sich von einer zu statischen Verwendung der Anwendbarkeitstests,

über fehlende Kontrollstrukturen bis hin zu Darstellungsproblemen größerer Untersuchungen

erstrecken, auf die in Kapitel 3 näher eingegangen werden.

Im Rahmen dieser Arbeit soll das System viDUMP (Ein visuelles Programmiersystem zur

Modellierung deskriptiver Untersuchungen in der Datenanalyse) entwickelt werden. Das System wird

in Anlehnung an die EPI-Workbench bereits realisierte Konzepte übernehmen und zusätzlich

weitestgehend die aufgezeigten Probleme beheben. Im Laufe der nächsten Jahre soll dieses System

dann soweit weiterentwickelt und in CARESS (CARLOS - Epidemiological and Statistical Data

Exploration System) [WGG+97] integriert werden, um dort als Datenanalyseserver unter dessen

Oberfläche zu fungieren. CARESS ist ein epidemiologisches Informationssystem, das eine

Auswertung einer Krebsregister-Datenbank ermöglicht und dabei das Registerstellenpersonal in allen

anfallenden Aufgabenbereichen unterstützt. Als ein Datenanalyseserver hat viDUMP dann die

Aufgabe, deskriptive Untersuchungen zu modellieren und die resultierenden Daten zur Visualisierung

an CARESS ,,hochzureichen", so daß dann auf eigene Visualisierungskomponenten verzichtet werden

kann. Die Spezifikation und Vorgabe der Untersuchung läuft dabei über CARESS selbst, die

Durchführung erfolgt über die Serverebene (viDUMP). Im folgend wird näher darauf eingegangen,

warum die EPI-Workbench diesen Anforderungen nicht genügt.

Der Anwendungsbereich von viDUMP soll die explorative Datenanalyse, im speziellen die deskriptive

Epidemiologie umfassen. Der allgemeine Entwurf von viDUMP ermöglicht prinzipiell die

Erweiterung auf andere, ähnlich geartete Anwendungsbereiche. Der Anwendungsbezug wird jedoch

1. Einleitung

durch die konkreten Verfahren einer Untersuchung hergestellt. Beispielsweise macht sich dies bei den

zu realisierenden Kontrollstrukturen bemerkbar, in denen auf der konkreten Datenstruktur des Systems

gearbeitet werden muß und somit eine starke Einschränkung in Bezug auf die Verwendung innerhalb

anderen Bereiche darstellt. Diese Einschränkung macht sich allerdings aufgrund der Konzeption von

viDUMP erst bei der konkreten Implementierung bemerkbar und ist somit vom Modell des Systems

(vgl. Kapitel 4) unabhängig.

Zunächst sind einige grundlegende Punkte zu klären, wie beispielsweise die Verwendung und

Umsetzung des Datenflußmodells in Kombination mit Kontrollflußelementen. In der EPI-Workbench

wurde ein reines Datenflußmodell realisiert, das aber aufgrund seiner Charakteristik einige

Einschränkungen impliziert. Iterationen und Schleifenkonstrukte sind aufgrund der

Nebeneffektfreiheit nicht ohne weiteres realisierbar, wären aber beispielsweise gerade für die

Erstellung von Jahresberichten wünschenswert. Um solche Berichte zu erstellen, werden immer

wiederkehrende Berechnungsabfolgen mit sich nur geringfügig ändernden Parametern durchgeführt.

Dazu muß bisher der Parameter per Hand modifiziert und die Berechnung erneut durchgeführt werden.

Eine Iterationsmöglichkeit könnte diesen und ähnliche Prozesse automatisieren.

Das Datenflußmodell beinhaltet eine implizite Ausführungsreihenfolge der Operationen, abhängig

vom jeweiligen Ausführungsmodell. Mitunter kann es jedoch hilfreich sein, wenn man die implizite

Ausführungsreihenfolge aussetzen und direkt steuern kann. Beim Monitoring, einem

Anwendungsbereich aus der Datenanalyse, ist es beispielsweise notwendig, abhängig von bestimmten

Zwischenergebnissen die weitere Bearbeitung des Datenstroms zu steuern. Diese Anpassung ist, wie

bei der oben beschriebenen Berichtserstellung, bisher manuell vorzunehmen. Es ist dabei zu

betrachten, welche Werte die Berechnung liefert. Daraufhin werden dann die Anfangsparameter

modifiziert und dann die Untersuchung wiederholt. Kontrollstrukturen, wie sie in imperativen

Programmiersprachen verwendet werden, würden dieses Verfahren wesentlich vereinfachen. Mit

diesen kann bereits zur Laufzeit der Berechnung eine Fallunterscheidung getroffen und die weitere

Berechnungsabfolge gesteuert werden.

Da die EPI-Workbench auf zwei wesentlichen Standbeinen beruht, dem Editor sowie einer eigenen

Datenstruktur, wird eine Neuentwicklung von viDUMP angestrebt, da bei einer Anpassung der EPI-

Workbench auf die Datenstrukturen von CARESS die meisten wesentlichen Teile des Systems neu

implementiert werden müßten. Die EPI-Workbench wurde entwickelt mit dem Hauptaugenmerk auf

den Verfahren einer Untersuchung, während viDUMP den Schwerpunkt auf die visuelle

Programmierumgebung legt. Diese Neukonzeption basiert somit auf visuellen Programmierkonzepten

und soll ebenfalls nach Prinzipien des Datenflußmodells entwickelt werden. Das Modell soll dann

zusätzlich um Aspekte des Kontrollflußmodells ergänzt werden. Die Einbindung einer visuellen

Modellierungshilfe, die die Zusammenfassung mehrerer Knoten zu einem einzigen ermöglicht, ist

ebenfalls vorgesehen. Unter diesen Gesichtspunkten wird so ein formales Modell für eine visuelle

Programmierumgebung entwickelt.

Die konkreten Verfahren, mit denen die Daten innerhalb einer Untersuchung bearbeitet werden,

werden nur beispielhaft implementiert, um die generelle Lauffähigkeit des Systems demonstrieren zu

können. Ebenso wird auch von der Visualisierung der resultierenden Daten sowie einer

Datenbankanbindung Abstand genommen, da aufgrund der Komplexität dieses Themengebiets der

Rahmen dieser Arbeit erheblich überschritten würde. [Bra98] beschäftigt sich als ergänzende Arbeit

1. Einleitung

ausführlich mit der Visualisierung der Daten sowie mit zugehörigen interaktiven Grafiken, die

ebenfalls in viDUMP integriert werden können. Es wird jedoch darauf geachtet, daß viDUMP die

erforderlichen Schnittstellen bereitstellt, um eine nachträgliche Integration solcher Bausteine zu

ermöglichen.

Kapitel 2 stellt zunächst Begriffe und grundlegende Konzepte visueller Programmierung als Basis für

diese Arbeit vor. Anschließend erfolgt eine Evaluierung verschiedener Softwaresysteme, die teilweise

auch in der Datenanalyse Verwendung finden und sich dabei visueller Techniken bedienen. Dazu wird

als ein zentraler Punkt dieser Arbeit eigens ein Analyseschema basierend auf den gängigsten

Klassifikationen visueller Programmiersysteme erarbeitet, anhand dessen die Softwaresysteme

vorgestellt werden. Abschließend werden die einzelnen Kriterien zu jedem System in Form eines

tabellarischen Überblicks gegenübergestellt.

Kapitel 3 setzt sich mit den Problemen der EPI-Workbench auseinander. Es erörtert den

Zusammenhang mit den geänderten Anforderungen und den fehlenden Konzepten im Hinblick auf die

Entwicklung eines neuen Systems an Stelle einer Erweiterung der vorhandenen Umgebung. Als

Grundlage für den Entwurf sowie die Implementierung erfolgt eine genaue Anforderungsanalyse von

viDUMP, das als neues System innerhalb dieser Arbeit entsteht. Wie die Erörterung der EPI-

Workbench erfolgt auch die Anforderungsdefinition anhand des Analyseschemas aus Abschnitt 2.4.1,

um eine Vergleichbarkeit zu den vorgestellten Systemen zu wahren.

In Kapitel 4 werden die zentralen Konzepte von viDUMP im Rahmen des Entwurfs näher beschrieben

und als Grundlage für eine Implementierung ausgearbeitet. Der zentrale Abschnitt des Kapitels

beschäftigt sich mit der formalen Grundlage von viDUMP, in der sämtliche Bausteine des Systems

definiert werden. Daran schließt sich die Ausarbeitung des Ausführungsmodells an, das die

dynamischen Aspekte des Systems behandelt. Das implementierte Modul wird dann in Kapitel 5 in

seiner Architektur und durch die wesentlichen Schnittstellen charakterisiert. Hier findet sich ebenfalls

eine genaue Beschreibung der Implementierung der Benutzerschnittstelle, die über den UI-Builder

ILOG Views realisiert wird.

Nach einer abschließenden Zusammenfassung in Kapitel 6, die die wesentlichen Aspekte dieser Arbeit

in einer Kurzfassung enthält, erfolgt eine Bewertung des entworfenen Systems sowie ein Ausblick, der

auf mögliche Ausbaustufen von viDUMP eingeht.

2. Visuelle Programmierung

2 Visuelle Programmierung

Die visuelle Programmierung entstand u.a. durch die Unzulänglichkeiten klassischer

Programmiersprachen, Programmcode anschaulich darzustellen oder eine einfache, intuitive

Programmentwicklung zu ermöglichen. Die lineare, eindimensionale Darstellung textuellen

Programmcodes ist oft sogar von spezialisierten Programmierern nur sehr schwer nachvollziehbar, so

daß andere Wege zur Visualisierung gefunden werden mußten. Da der Mensch offensichtlich bildliche

Informationen sehr viel einfacher und damit auch schneller erfassen und verarbeiten kann, als rein

syntax- und funktionsorientierten Programmcode, der ohne Beschreibung und Kommentare ohnehin

kaum verständlich ist, liegt es nahe, dies für die visuelle Programmierung nutzbar zu machen [And88].

Der Begriff visuell bezieht sich auf die Erstellung und Darstellung des Programms. Anders als mit

textuellen Programmiersprachen wird bei der visuellen Programmierung das Programm über die

Kombination von grafischen Objekten und Symbolen visuell erstellt (näheres zur Begriffsbildung

erfolgt im Laufe dieses Abschnitts).

Das Ziel der visuellen Programmierung ist vor allem die Erhöhung der Verständlichkeit von

Programmen und die Erleichterung des Programmiervorgangs selbst [Sch98]. Durch diese

Vereinfachung sollen dann im Optimalfall sogar Anwender, d.h. Nichtprogrammierer, in die Lage

versetzt werden, komplexere Applikationen ohne tiefgreifende Kenntnis des zugrundeliegenden

Programmierparadigmas zu erstellen. Ein visuelles Programmiersystem bzw. eine visuelle

Programmierumgebung (im folgenden kurz VP-System genannt) erlaubt im Gegensatz zu textuellen

Programmiersystemen die Erstellung eines Programms in einer zwei- bzw. mehrdimensionalen Art

und Weise [Kel97, KHA97, Sch98]. Abbildung 2.1 zeigt eine Einordnung des Bereichs der visuellen

Programmierung und grenzt zugleich die Begriffe visuelle Programmierung und Visualisierung

voneinander ab.

Visuelle Unterstützung

der Programmierung

Visuelle Programmierung

Grafische

Interaktion

visuelle

Programmiersysteme

Flußdiagramme

Kontrollfluß

Datenfluß

Symbole Tabellen/

Formulare

Sonstige

Visualisierung

Programm-

visualisierung

Daten-

visualisierung

nach [KHA97]

Abbildung 2.1: Taxonomie für die visuelle Unterstützung in der Programmierung

Die visuelle Programmierung unterteilt sich demnach in die Bereiche der grafischen Interaktion sowie

der visuellen Programmiersysteme. Diese können auf Flußdiagrammen basieren, die beispielsweise

2. Visuelle Programmierung

auf dem Kontroll- bzw. Datenflußparadigma aufsetzen (siehe Abschnitte 2.1.2 und 2.1.1), oder

Symbole und Tabellen bzw. Formulare beinhalten, wie es beispielsweise im Programm Microsoft

Excel vorkommt. Der Bereich der Visualisierung läßt sich in die Bereiche Programmvisualisierung,

also der grafischen Darstellung des Programmcodes, und Datenvisualisierung (vgl. [Bra98]) gliedern.

Ein großes Dilemma besteht momentan in den vielen verschiedenen Versuchen, visuelle

Programmierung zu definieren (vgl. [Kel97]). Eine Vielzahl von Veröffentlichungen beschäftigt sich

immer nur mit einem kleinen Teil des Anwendungsgebiets, so daß vereinzelte Definitionen meist nicht

auf das Gesamtgebiet verallgemeinert werden können. Darüber hinaus bleiben die dazu entwickelten

Systeme meist in einer frühen Entwicklungsphase stecken [Sch98]. Aus diesem Grund werden an hier

einige Definitionen formuliert, die für die weiteren Ausführungen dieser Arbeit als Grundlage dienen

werden. Dies geschieht in Anlehnung an Definitionen der einschlägigen Literatur [KHA97, Sch98,

Shu88], weicht aber an einigen Punkten davon ab, um den Ansprüchen dieser Arbeit insbesondere in

Bezug auf die Verwendung des Datenflußmodells gerecht zu werden. Dennoch sind die folgenden

Definitionen allgemein gehalten, so daß sie auch auf andere Systeme angewendet werden können.

Objekte (auch Symbole genannt) repräsentieren in der visuellen Programmierung die

Anweisungen einer visuellen Programmiersprache. Solche Objekte können für sich elementar

oder auch wieder aus mehreren Objekten zusammengesetzt sein. Über Eingänge erhalten sie

die zu verarbeitenden Daten, über ihre Ausgänge werden die bearbeiteten Daten

weitergegeben. Objekte ohne Eingang werden als Quelle, Objekte ohne Ausgänge als Senke

bezeichnet.

Über Operatoren (Prozeßsymbole) werden Objekte zueinander in Beziehung gesetzt. Sie

charakterisieren die Verknüpfung der Operationen, Abhängigkeiten und den

Kommunikationsfluß zwischen den einzelnen Objekten und werden auch als Kanäle

bezeichnet.

Ein Beziehungsgeflecht aus Objekten und Operatoren bildet einen visuellen Satz. Dieser

repräsentiert graphisch einen Teil des Programms oder der Anweisungsfolge, die mit einer

visuellen Programmiersprache als Kombination visueller Sätze erstellt werden kann. Eine

visuelle Programmierumgebung (auch VP-System) unterstützt schließlich die Modellierung

visueller Sätze einer visuellen Programmiersprache.

Visuelle Programmierung bezeichnet somit den Prozeß der Programmerstellung mit Hilfe

einer visuellen Programmierumgebung.

In der Literatur wird weiterhin zwischen visuellen Programmiersystemen mit visueller und textueller

Programmiersprache differenziert. Diese unterscheiden sich insofern, daß grafische Komponenten bei

Systemen auf Grundlage textueller Programmiersprachen meist lediglich zur Erstellung einer

Benutzerschnittstelle dienen [BB94]. Bei VP-Systemen mit einer visuellen Programmiersprache

enthält dagegen der eigentliche Programmcode einen hohen Anteil grafischer Elemente und nur wenig

Text [Cha96, KHA97, Sch98]. Ziel dieser Arbeit ist es, ein System zu erstellen, daß eine Modellierung

über eine visuelle Programmiersprache ermöglicht. Deshalb werden im weiteren Verlauf nur noch

Systeme der letzteren Definition (VP-Systeme) behandelt.

2. Visuelle Programmierung

Unterzieht man diese Definitionen einer genaueren Betrachtung, so stellt sich zwangsläufig die Frage,

wie eine visuelle Programmiersprache syntaktisch aufgebaut ist. Es ist schwer, eine formale Definition

zu finden, wie sie bei textuellen Sprachen üblich ist, denn trotz der verfügbaren Vielfalt visueller

Programmiersprachen und der zahlreichen Arbeiten zu diesem Thema existiert bis heute keine

einheitliche Beschreibungsform dafür. Eine wesentliche Ursache dafür liegt in der Natur der VP-

Systeme selbst, denn es ist aufgrund der Ausführungsart solcher Programme nämlich gar nicht

zwingend notwendig (vgl. [Sch98] - Kapitel 2). Ein wesentlicher Grund dafür ist, daß ein VP-System

immer seine eigene Syntax kennt und somit auch nur zulässige Konstrukte in der Erstellung unterstützt

bzw. zuläßt. So wird auch von vornherein die Fehleranfälligkeit eines solchen Systems in Bezug auf

die Programmerstellung stark reduziert.

Shu [Shu88], Chang [Cha87], Burnett und Baker [BB94], sowie Myers [Mye94] und [KHA97] (siehe

Abbildung 2.1) haben in mehreren Arbeiten Klassifikationsschemata für visuelle

Programmiersprachen und VP-Systeme entwickelt, die in ihrem Aufbau voneinander abweichen.

Shu unterscheidet in zwei Kategorien: visuelle Umgebungen und visuelle Sprachen. Der Bereich

visuelle Umgebungen beinhaltet Werkzeuge zur Datenvisualisierung, zur Softwarevisualisierung und

für visuelles Instruieren. Der Bereich der visuellen Sprachen umfaßt Sprachen zur Bearbeitung

visueller Information, zur Unterstützung visueller Interaktion sowie visuelle Programmiersprachen.

Für die Charakterisierung von VP-Systemen verwendet Shu ein dreidimensionales

Koordinatensystems, deren Achsen die Aspekte Niveau, Anwendungsbereich und Visualisierungsgrad

einer visuellen Programmiersprache darstellen.

Chang unterteilt visuelle Sprachen

in Sprachen zur Unterstützung visueller Interaktion, visuelle

Programmiersprachen, Sprachen zur Verarbeitung visueller Information und Piktogrammsprachen

zur Verarbeitung visueller Information und entspricht in seiner Einteilung im wesentlichen der von

Shu, ausgenommen die letzten Kategorie, welche so bei Shu nicht vorkommt.

Myers geht einen grundlegend anderen Weg als Shu und Chang. Er geht weder auf die Art der

verarbeiteten Daten ein, noch auf die Anwendungsgebiete oder die Art der Programmdarstellung. In

seinen drei Kategorien beispielorientierte oder nicht-beispielorientierte Programmierung, visuelle

oder nicht-visuelle Programmierung und kompilierte oder interpretierte Programme bildet er eine

Matrix mit acht Feldern, in die die einzelnen VP-Systeme eingeordnet werden können. Er unterzieht

seine Klassifikation jedoch keiner Gegenüberstellung zu anderen Schemata und begründet auch seine

Einteilung nicht.

Die Klassifikation von Burnett und Baker versucht, die Arbeiten und Veröffentlichungen über visuelle

Programmierung zu erfassen. Der Zweck ihrer Klassifikation 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. Ob ein Aufsatz klassifiziert wird, der die Beschreibung einer Programmiersprache

enthält, oder ob die Programmiersprache selbst erfaßt wird, ist dann unerheblich, wenn die Einordnung

des Aufsatzes anhand der Eigenschaften der beschriebenen Sprache erfolgt [Sch98].

Chang spricht in seiner Taxonomie nicht von visueller Programmierung, sondern nur von visuellen Sprachen.

2. Visuelle Programmierung

In Abschnitt 2.4.1 wird auf Grundlage der zuvor vorgestellten Klassifikationen mit einem

Schwerpunkt auf der Klassifikation von [KHA97] ein für diese Arbeit angepaßtes Schema zur Analyse

und Einordnung von VP-Systemen erstellt. Somit wird auf die Ausführungen in [KHA97] erst dort

näher eingegangen.

Der folgende Abschnitt 2.1 beschäftigt sich mit den Grundlagen visueller Programmierung, er gibt

Einblick in die grundlegenden Begriffe und Konzepte und stellt die wichtigsten visuellen

Programmierparadigmen vor. Abschnitt 2.2 erörtert kurz die wesentlichen Vor- und Nachteile

visueller Programmierung insbesondere im Hinblick auf die in den Folgekapiteln verwendeten

Konzepte. Da das in dieser Arbeit zu entwickelnde VP-System im Anwendungsgebiet der

Datenanalyse eingesetzt werden soll, gibt Abschnitt 2.3 eine kurze Einführung in das Themengebiet.

Dabei wird insbesondere darauf eingegangen, warum VP-Systeme gerade in der Datenanalyse so

interessant bzw. hilfreich sein können. Bereits existierende Systeme für diesen Anwendungsbereich

werden dann in Abschnitt 2.4 analysiert, um Erkenntnisse für das zu entwickelnde System zu

gewinnen. Abschließend erfolgt dabei eine kurze Bewertung in Form einer Gegenüberstellung der

einzelnen Systeme unter Berücksichtigung ihrer jeweiligen Eigenarten.

2.1 Paradigmen visueller Programmierung

Die in diesem Abschnitt vermittelten Grundlagen sollen lediglich einen kurzen Einblick in die

Paradigmen visueller Programmierung geben. Besonderes Augenmerk liegt dabei auf dem Daten- und

Kontrollfluß, da diese in den folgenden Kapiteln in modifizierter Form eine zentrale Rolle spielen. Für

eine ausführliche Einführung sei allerdings auf die dieser Arbeit vorangegangene Abhandlung (siehe

[Kel97]) und die einschlägige Literatur [HYT+92, Naj94, PS94, Sch98, Sha92] zu diesen Themen

verwiesen. Insbesondere als Ausblick auf weitere Möglichkeiten visueller Programmierung werden

darüber hinaus weitere relevante Konzepte kurz vorgestellt.

2.1.1 Datenfluß

Die meisten visuellen Programmiersysteme basieren auf Flußdiagrammen oder auch Flußgraphen. Sie

geben einen graphischen Überblick über den Daten- und/oder den Kontrollfluß des Programms.

Datenflußorientierten Programmiersystemen liegt das Datenflußmodell [PS94, Sha92] zugrunde, bei

dem die Daten selbst die Ausführungsreihenfolge der Operationen bestimmen. Somit liegt also keine

festgelegte Ausführungsreihenfolge der Anweisungen bzw. Operationen vor und es müssen nicht

notwendigerweise alle definierten Anweisungen bis zur Terminierung des Programms ausgeführt

werden. Systeme, die auf dem Datenflußmodell basieren, werden auch transformativ genannt 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 [Sch98].

Die visuelle Darstellung eines Datenflußprogramms erfolgt als ein gerichteter Graph aus Objekten und

zugehörigen Operatoren. Objekte können gemäß ihrer Definition elementare Anweisungen, aber auch

wiederum andere Datenflußprogramme beinhalten. Operatoren lenken den gerichteten Datenfluß

zwischen den Objekten. Abbildung 2.2 zeigt die schematische Darstellung eines Datenflußprogramms.

Analog zu der bereits in diesem Kapitel getroffenen Definition repräsentieren die Knoten ,,Q1" und

,,Q2" Datenquellen, der Knoten ,,Ausgabe" eine Datensenke und die Knoten ,,OP1" bis ,,OP5" die

2. Visuelle Programmierung

Operationen. Die Pfeile stellen Datenkanäle dar. OP1 bis OP3 sowie OP4 und OP5 werden dabei

zunächst parallel ausgeführt.

OP2

berechnet

OP1

OP3

berechnet

OP4

OP5

Ausgabe

Abbildung 2.2: Schematische Darstellung des Datenflußprinzips

Neben der Möglichkeit der parallelen Verarbeitung von Operationen ist eine weitere wichtige

Eigenschaft des Datenflusses die Nebeneffektfreiheit. Bei der datenflußorientierten Programmierung

ist gemäß dieser Eigenschaft die Wirkung von Operationen immer auf den lokalen Kontext und auf die

aktuelle Ausführung beschränkt [PS94]. Die Zusicherung der von Aufruf zu Aufruf bei gleichen

Eingabedaten invarianten Resultate bildet die Grundlage für implizite Ausführungsreihenfolge und

Parallelität [Sch98]. Ein Effekt dieser Eigenschaft ist der Verzicht auf beispielsweise

Zustandsvariablen, die eine Kommunikation zwischen einzelnen Teilen des Datenflußprogramms

ermöglichen würden. Durch die Nutzung der Kanäle zwischen den einzelnen Objekten werden

ebenfalls Variablen überflüssig, und somit werden Probleme der indirekten Datenabhängigkeit

vermieden, die dann auftreten können, wenn zwei Objekte auf eine gemeinsame Variable zugreifen

können, obwohl diese scheinbar unabhängig voneinander sind.

Als Token bezeichnet man im allgemeinen einen Datenblock, der zwischen Knoten (Datenquellen,

Operationen oder Datensenken) eines Datenflußgraphen verschickt wird. Das Token wird konsumiert,

sobald es am Eingang einer Operation oder Datensenke anliegt und alle weiteren Eingangsdaten des

Knotens verfügbar sind, d.h. die eingehenden Daten werden bearbeitet. Ein Token wird

dementsprechend produziert, wenn Daten an einem Ausgang eines Knotens verfügbar werden. Eine

Datenquelle kann gemäß ihrer Definition nur Token produzieren, eine Datensenke im Gegensatz dazu

nur konsumieren.

Bei Datenflußprogrammen wird unterschieden, auf welche Art und Weise die Ausführungsreihenfolge

der Operationen festgelegt werden soll. Ist die Ausführungsbedingung durch die Verfügbarkeit von

Daten bestimmt (data driven), wird immer diejenige Operation initiiert, für deren Ausführung alle

notwendigen Eingangsdaten vorhanden sind. Dies hat allerdings zum Nachteil, daß auch solche

Operationen ausgeführt werden, die evtl. für das Gesamtergebnis gar nicht notwendig und somit

überflüssig sind. Soll dagegen die Notwendigkeit von Daten die Ausführungsreihenfolge der

Operationen steuern (demand driven), so wird immer stets diejenige Operation ausgeführt, von der

Ausgangsdaten angefordert werden. Vorteil dieser Technik ist, daß nur alle für das Gesamtergebnis

relevanten Operationen ausgeführt werden, überflüssige Berechnungen somit wegfallen. Zu beachten

ist dabei allerdings, daß die einzelnen Operationen ohne sogenannte Nebeneffekte und

Statusinformationen auskommen. Somit kann es passieren, daß eine Operation mehrmals identische

Datensätze produziert, also überflüssige Berechnungen durchführt [AT95, Hyt92, Sha92]. Eine

Illustration dieser beiden unterschiedlichen Ausführungskonzepte zeigt ebenfalls Abbildung 2.2. Ist

die Anweisungsfolge durch die Verfügbarkeit der Daten bestimmt, wird als nächste Operation OP5

2. Visuelle Programmierung

initiiert (da OP2 und OP3 bereits berechnet sind), obwohl diese für das Endergebnis (Ausgabe) nicht

relevant ist. Die Notwendigkeit von Daten würde zunächst OP1 und danach OP4 initiieren. OP5 wird

durch diese Art der Ausführung nicht berechnet.

Die Nebeneffektfreiheit, insbesondere das Fehlen von Variablen, wird allgemein als großer Vorteil

datenflußorientierter Systeme angesehen [Sch98], da der Programmierer nicht darüber nachdenken

muß, welche Auswirkungen die Zuweisung an eine Variable an jenen Programmstellen hat, wo diese

Variable verwendet wird. Darüber hinaus muß sich der Programmierer keine Gedanken zum Thema

Speicherverwaltung machen, da dieses den elementaren Operationen selbst zukommt. Schwierig zu

erkennende Fehlerquellen sind somit von vornherein ausgeschlossen.

Verzweigungen und Fallunterscheidungen sind in Datenflußprogrammen schwer zu realisieren, da hier

ein Eingriff in die Ausführungsreihenfolge (data oder demand driven) des Datenflußmodells

vorgenommen werden muß. Ebenso verhält es sich mit Schleifen und Wiederholungskonstrukten. Sie

erfordern die Einführung von Zyklen im Datenflußdiagramm und ein Konzept zur Vorbelegung von

Datenkanälen mit bestimmten Werten.

Datenflußorientierte Programmiersysteme verzeichnen innerhalb des Bereichs der visuellen

Programmierung die größte Verbreitung, wofür nach [Sch98] folgende Punkte ausschlaggebend sind:

· Bestimmte Aspekte der physikalischen Welt können besonders gut auf die Welt der

Programmierung abgebildet werden. Beispielsweise lassen sich elektronische Schaltungen

mit Hilfe des Datenflusses ausgezeichnet simulieren. Dies hängt unmittelbar mit der

Tatsache zusammen, daß durch das Datenflußmodell eine parallele Ausführung von

Operationen (siehe unten) ermöglicht wird. Dies setzt allerdings ebenfalls eine geeignete

Unterstützung durch die verwendete Hard- und Betriebssystemsoftware voraus.

· Einige anspruchsvolle Konzepte der imperativen Programmierung, wie z.B. Variablen und

dynamische Datenstrukturen, sind in der datenflußorientierten Programmierung nicht

weiter relevant, wodurch der Lernaufwand gering gehalten wird. Dies kommt der

Forderung der visuellen Programmierung nach, einfach zu erlernende Konzepte

bereitzustellen, die eine im Vergleich zu herkömmlichen Programmiertechniken

erleichterte Programmerstellung ermöglichen.

· Eine Top-Down-Zerlegung von Datenflußprogrammen gelingt ohne weitere Probleme, da

Programmteile verbunden und getrennt werden können, ohne auf Querbeziehungen achten

zu müssen. Diese Eigenschaft erleichtert strukturiertes Programmieren und deutet damit

auch indirekt auf eine Verwandtschaft zur funktionalen Programmierung hin, aus der die

Konzepte der Modularisierung von Funktionen genutzt werden können.

· Das datenflußorientierte Programmierparadigma unterstützt durch seine Konzeption eine

parallele Programmausführung, ohne daß der Programmierer dafür besondere

Anweisungen vorsehen müßte.

2. Visuelle Programmierung

· Die Programmausführung ist anschaulich darstellbar und läßt sich somit in eine visuelle

Programmierumgebung sehr gut integrieren. Der Anwender kann direkt den ,,Fluß der

Daten" nachvollziehen.

2.1.2 Kontrollfluß

Die kontrollflußorientierte Programmierung, häufig auch als steuerflußorientierte Programmierung

bezeichnet, beruht auf dem imperativen Programmierparadigma. Im Gegensatz zu

datenflußorientierten VP-Systemen wird bei der Verwendung dieses Prinzips die nächste

auszuführende Operation unmittelbar durch die Programmsteuerung bestimmt und nicht durch die

Daten selbst. Ein Befehlszähler legt fest, welcher Befehl als nächster initiiert werden soll, die

Reihenfolge wird dabei explizit vom Programmierer festgelegt. Diese Festlegung impliziert auch

Konstrukte für Wiederholungen und Fallunterscheidungen, mit deren Hilfe der Programmierer

abhängig von bestimmten Werten den Ablauf des Programms ebenfalls beeinflussen kann.

Programmiersysteme auf Grundlage des Kontrollflußparadigmas sind deshalb bisher innerhalb der

herkömmlich textuellen Programmierung sehr viel weiter verbreitet als Systeme auf Grundlage des

Datenflußparadigmas, weil der Kontrollfluß in seiner Struktur unmittelbar die vorherrschende PC-

Architektur des von Neumann Modells unterstützt [Sha92].

Die Visualisierung des Kontrollflusses kann über verschiedene Wege erfolgen, die gängigsten

Verfahren sind Anweisungssequenzen, Komponentennetze, Transitionsnetze [Sch98] sowie durch

Ansätze der Automatentheorie. Insbesondere für diese Arbeit interessant ist allerdings die

Kombination der Kontrollflußkonzepte mit den Vorteilen des Datenflusses (siehe auch Abschnitt 2.1.1

und Kapitel 4). Anweisungssequenzen werden in VP-Systemen meist als Blöcke von Anweisungen

durch Ablaufpläne oder Blockdiagramme dargestellt. Bekannteste Vertreter dafür sind Flußdiagramme

und auch Nassi-Shneidermann-Diagramme [NS72]. Die visuelle Programmierung über

Anweisungssequenzen alleine hat allerdings keine großen Neuerungen gegenüber den imperativen

Programmiersprachen [Sch98].

Komponentennetze basieren auf der Zerlegung eines Programms in einzelne Komponenten, die dann

über Datenkanäle miteinander kommunizieren bzw. Daten austauschen. Dieser Ansatz stellt im

Gegensatz zu den Anweisungssequenzen das Programmverhalten in den Vordergrund, welches die

Reaktion auf bestimmte Ereignisse und nicht den sequentiellen Ablauf einzelner Operationen definiert.

Eine Fortführung dieses Konzepts findet sich in den Transitionsnetzen, mit deren Hilfe Systeme

spezifiziert werden, die kontinuierlich auf Ereignisse reagieren und deren Verhalten zeitlichen

Bedingungen unterworfen ist [Sch98]. Vorteile finden sich dabei in der Beweisbarkeit von Aussagen

über ein System aufgrund solcher Spezifikationen durch Transitionsnetze. Die Visualisierung eines

Transitionsnetzes ist meist durch ein Zustandsdiagramm realisierbar, wie es auch in der

Automatentheorie zu finden ist. Ausführlichere Beschreibungen der Konzepte in VP-Systemen auf

Grundlage von kontrollflußorientierter Programmierung finden sich in [Mey94, Stö93, Tri88].

2. Visuelle Programmierung

2.1.3 Weitere ausgewählte Paradigmen

Neben den beiden Konzepten des Daten- und Kontrollflusses gibt es natürlich noch weitere, die aber

nicht so weit verbreitet sind, wie die beiden bereits vorgestellten. Dennoch soll in diesem Abschnitt

kurz auf weitere interessante Paradigmen der Programmierung eingegangen werden, um einen kleinen

Überblick über andere mögliche Paradigmen visueller Programmierung zu geben. Eine vollständigere

Aufstellung findet sich in [Sch98].

Funktionsorientierte visuelle Programmierung

Die funktionsorientierte Programmierung wurde von Backus [Bac78] als Alternative zu imperativen

Sprachen entwickelt. Ein funktionsorientiertes Programmiersystem (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

[Sch98]. Variablen und Wertzuweisungen gibt es wie in der datenflußorientierten Programmierung

(vgl. Nebeneffektfreiheit) nicht. Ein funktionsorientiertes Programm wird visuell als

Funktionsdiagramm dargestellt. Dies besteht aus einem gerichteten Graphen mit Parametern,

Resultaten und Funktionen als Knoten sowie Wertekanälen als Kanten [Sch98]. FP-Systeme eignen

sich gut, um eine Algebra von Programmen zu definieren, mit der etwa bestimmte Eigenschaften eines

Programms bewiesen werden können.

Objektorientierte visuelle Programmierung

Objektorientierte VP-Systeme bedienen sich der Konzepte objektorientierter Programmierung (OOP).

Zur Nutzung dieser Konzepte für die visuelle Programmierung wird zwischen Programmbausteinen

und Applikationen unterschieden [BGL95a]. Die Programmbausteine werden auf herkömmlich

textuelle Art und Weise erstellt und stellen die Grundlage für OOP-VP-Systeme dar. Jeder einzelne

Baustein stellt eine Schnittstelle zur Verfügung, die zur Kommunikation mit anderen Bausteinen

genutzt wird. Diese Schnittstelle umfaßt Attribute und Ereignisse, die Werte wie Größe, Position und

Farbe, Benutzeraktionen und Zustandsänderungen beinhalten. Nachrichten, die ebenfalls über die

Schnittstelle zwischen den Bausteinen ausgetauscht werden, können Operationen auslösen, sowie

Attribute lesen und verändern. Die Bausteine werden innerhalb des VP-Systems visuell, beispielsweise

als Bausteine eines grafischen Editors, dargestellt und können dann über gerichtete Kanten (Kanäle) in

Beziehung (Nachrichten) zueinander gesetzt werden. Weiterführende Betrachtungen zu dieser Art der

visuellen Programmierung, die sich auch insbesondere mit den dabei auftretenden Problemen der

Vererbungstechniken bzw. Polymorphismus auseinandersetzen, finden sich in [Sch98, BGL95a].

Beispielorientierte Systeme

Beispielorientierte Systeme sind keine explizite Entwicklung der visuellen Programmierung, sondern

können ebenso in allen anderen Programmierbereichen Anwendung finden. Die Idee eines solchen

Systems besteht darin, eine beispielhafte Durchführung als Programmgrundlage zu verwenden. Der

Benutzer führt mit dem System einmal per Hand eine Lösung des Problems durch, und das System

generiert daraus ein eigenständiges Programm, das dann diese Aufgabe wiederholen kann. Lediglich

2. Visuelle Programmierung

die Benutzeraktionen werden in einen Programmcode überführt. Im Idealfall soll ein solches System

nicht nur gleichgeartete Probleme, d.h. Aufgaben mit gleichem Schema aber evtl. anderen Daten lösen

können, sondern auch die sogenannte ,,Do what I mean"-Anforderung [Mye94] erfüllen, die ein

System die Absicht bzw. den Sinn der Aufgabe erkennen läßt und daraufhin ein entsprechendes

Programm generiert. Die Praxis zeigt jedoch, daß dieses sicherlich sehr interessante Konzept noch

nicht brauchbar realisierbar ist. Schon kleine Abweichungen zwischen der Vorgabe des Anwenders

und den tatsächlich erforderlichen Lösungsschritten lassen schnell ein solches Programm scheitern.

Multiparadigmen VP-Systeme

Multiparadigmenorientierte VP-Systeme enthalten mehrere Programmierkonzepte und Paradigmen

integriert in einem System. Dabei kann dann jeweils für ein bestimmtes Teilprobleme das jeweils

geeignetste Konzept zur Lösung herangezogen werden. Beispiele sind u.a. objektorientierte

Programmiersysteme, die die Programmierung mit Datenflußdiagrammen unterstützen. Ein

kommerzielles Beispiel hierfür ist das System Prograph, das in [BGL95b, Kel97] beschrieben wird.

2.2 Das Pro und Kontra visueller Programmierung

Dieser Abschnitt soll die Vorzüge, aber auch die Probleme verdeutlichen, die sich in Zusammenhang

mit der visuellen Programmierung ergeben. Die zentralen Anliegen von VP-Systemen liegen in der

Vereinfachung des Programmiervorgangs und damit zusammenhängend in der übersichtlichen

Darstellung des eigentlichen Programms zwei Aspekte, bei der die herkömmlich textuellen

Programmiersprachen große Defizite aufweisen.

Vorteile

Die visuelle Programmierung basiert auf der Modellierung mit visuellen Objekten, die sich durch ihre

jeweilige Erscheinungsform voneinander unterscheiden und somit implizit Aussagen über ihre

Funktion beinhalten. Hier macht man sich den Vorteil zunutze, daß der Mensch bildliche

Informationen besser und sehr viel schneller aufnehmen kann als beispielsweise einen Text mit

gleichwertigem Informationsgehalt [And88, Shu88]. Texte werden immer sequentiell erfaßt, während

die Information von Bildern bzw. deren Teile in einem gewissen Maß sogar parallel aufgenommen

werden kann. Zudem ist die menschliche Sensorik naturgemäß auf die Verarbeitung von bildlicher

Information in Echtzeit ausgelegt, was die Aufnahmegeschwindigkeit gegenüber Texten weiter erhöht

[Naj94]. Vorteilhaft wirkt sich die kompakte Kodierung und hohe Transferrate von bildlichen

Informationen auf die Aufnahme aus. Die Visualisierung von Programmabläufen ist eine wichtige

Voraussetzung für das Verstehen eines Programmes. Der Programmierer wird durch die Möglichkeit

entlastet, bildliche Objekte direkt manipulieren zu können, ohne für diese Objekte spezielle Namen

vergeben oder merken zu müssen [Rae85]. Hauptaugenmerk liegt dabei aber nicht in der Vermittlung

von Informationen durch einzelne kleine Objekte, sondern durch die übersichtliche Darstellung der

Gesamtstruktur

eines Programms.

Die visuelle Repräsentation der Struktur ist letztendlich wiederum nichts anderes als ein Bild.

2. Visuelle Programmierung

Der durch ein VP-System angestrebte vereinfachte Programmierprozeß ermöglicht es auch

Nichtprogrammierern, schnell komplexe Programme innerhalb eines Anwendungsgebietes zu

erstellen. Dabei wird idealerweise soweit von einer Programmiersprache abstrahiert, daß spezielle

Kenntnisse darüber überflüssig werden. Der Anwender erstellt das Programm intuitiv auf Grundlage

seines Wissens aus dem Anwendungsgebiet, ohne sich noch in Programmierprinzipien und -konzepte

einarbeiten zu müssen.

Unmittelbar damit zusammenhängend ergeben sich weitere Vorteile der visuellen Programmierung.

Die optimale Unterstützung des Programmierverfahrens durch das VP-System impliziert automatisch

eine Reduzierung möglicher Fehlerquellen im Programm. Auf diese Weise lassen sich automatisch die

Kosten für die Programmentwicklung und -wartung sowie die Entwicklungszeit reduzieren.

Die Vorteile an sich lassen die Vermutung aufkommen, daß die Zukunft der Programmerstellung in

der visuellen Programmierung zu finden ist. Für immer mehr Programmiersprachen und

Anwendungsgebiete werden visuelle Varianten entwickelt, die sich an den Konzepten der visuellen

Programmierung orientieren.

Nachteile

Trotz der augenscheinlich großen Vorteile der visuellen Programmierung gegenüber den

herkömmlichen Programmierverfahren beinhalten aber gerade auch diese Punkte selbst einige

Nachteile, die die visuelle Programmierung im gleichen Zuge problematisch machen.

Bildliche Informationen beispielsweise sind zwar schnell aufnehmbar, aber es ist mitunter sehr schwer,

ein Bild zu erstellen, daß nur die Aussagen beinhaltet, die es haben soll und sonst nichts weiter

suggeriert. Problematisch ist die mögliche Informationsflut dann, wenn das Bild mehrdeutig

interpretierbar ist und somit zur Verwirrung führt. Der Anwender kann dann das Bild oder Symbol im

Programmierprozeß nicht mehr eindeutig zuordnen bzw. einsetzen, zusätzliche Informationen werden

dann benötigt. Der gleiche Effekt stellt sich ein, wenn ein Betrachter das Bild falsch interpretiert und

somit ein Informationsverlust auftritt. Dies kommt oft dann vor, wenn ein Bild spezifische

Informationen symbolisieren soll, deren Interpretation nur von einem Spezialisten des

Anwendungsgebiets oder der Programmierung richtig vorgenommen wird. Eine falsche Interpretation

führt genau wie eine mögliche Mehrfachinterpretation zu Verwirrung und kompliziert wiederum den

Prozeß der Programmentwicklung. Die mathematische Beweisbarkeit bezüglich der Äquivalenz

zweier bildlicher Darstellung (zum Beispiel Zustandsdiagramme) ist darüber hinaus ebenfalls nicht

gewährleistet [Hoa85].

Ein weiterer wesentlicher Nachteil ist der große Platzbedarf, den ein Programm in einem VP-System

beansprucht und der somit wiederum zur Unübersichtlichkeit führt. Fast alle VP-Systeme modellieren

Programme als bildliche Objekte, die über Linien verbunden werden, die den Programmfluß

definieren. Je mehr solcher Linien in dem Programm vorkommen, desto unübersichtlicher wird es

wieder, es kann sogar zur völligen Unlesbarkeit des Programms führen, wie ein Beispiel anhand des

VP-System PARTS in Abbildung 2.3 anschaulich verdeutlicht.

2. Visuelle Programmierung

Den Effekt, daß die Übersichtlichkeit der Darstellung mit zunehmender Größe des Programms

abnimmt, wird als Screen-Space-Problem bezeichnet. Ein großes Ziel der visuellen Programmierung,

die übersichtliche Darstellung von Programmen, ist somit sehr schnell verfehlt. Des weiteren ist in

diesem Zusammenhang durchaus fragwürdig, ob visuell überhaupt geeignete

Darstellungsmöglichkeiten für spezielle Programmierkonzepte, wie z.B. Rekursion, realisierbar sind.

Viele VP-Systeme beschränken sich darüber hinaus meist auf ein eingeschränktes Einsatz- bzw.

Anwendungsgebiet. Ihre Flexibilität ist damit, wenn überhaupt, nur innerhalb dieser Domäne

gewährleistet [CDZ94].

Abbildung 2.3: Ein Beispiel für das Screen-Space-Problem

Ein weiterer, nicht zu unterschätzender Nachteil ist die Ausführungsgeschwindigkeit der meisten VP-

Systeme. Bei diesen handelt es sich überwiegend um Interpreter, die von Natur aus langsamer sind als

gleichwertige übersetzte Programme. Diese verarbeiten die eingehenden Informationen analog zur

Darstellung der visuellen Repräsentation. Ein positiver Nebeneffekt ist, daß die Verarbeitung bei den

meisten Systemen durch die Interpretierung auch grafisch wiedergegeben werden kann. Der

Programmfluß wird animiert und somit verständlicher.

Fazit

Werden die vorigen Ausführungen zu Vor- und Nachteilen von VP-Systemen berücksichtigt, wird

ersichtlich, daß die Verwendung eines solchen Systems von mehreren Faktoren abhängig gemacht

werden muß. Eine optimale Unterstützung des Programmiervorgangs ist sicherlich wünschenswert,

kann jedoch schnell vernachlässigt werden, wenn das resultierende Programm für eine Anwendung

viel zu langsam läuft oder nicht allgemein genug programmiert (etwa aufgrund von Einschränkungen

durch das VP-System) werden kann. Somit ist also auch klar geworden sein, daß die aufgeführten

Vor- und Nachteile auch immer anwendungs- bzw. situationsabhängig und somit nicht unbedingt

immer allgemeingültig sind. Die Vorteile für den Anwendungsbereich der Datenanalyse werden im

folgenden Abschnitt nach einer allgemeinen Einführung in das Themengebiet veranschaulicht.

2. Visuelle Programmierung

2.3 Motivation visueller Programmierung in der Datenanalyse

viDUMP soll im Anwendungsbereich der Datenanalyse eingesetzt werden. Um dies zu motivieren,

soll an dieser Stelle eine kurze Einführung in diesen Anwendungsbereich gegeben werden.

Die Datenanalyse als eigene Disziplin ist eine Vereinigung mehrerer verschiedener Teile

wissenschaftlicher Disziplinen, wie z.B. der Statistik und insbesondere einiger Teilbereiche der

Informatik, wie die Mustererkennung, künstliche Intelligenz oder maschinelles Lernen [Han97]. Die

Statistik an sich umfaßt Verfahren zur Handhabung von Zahlendaten und dient der Auswertung und

Beschreibung von Daten, die durch Experimente oder Erhebung zu einem Thema systematisch

ermittelt wurden [Wie94]. Erst in Kombination mit anderen Disziplinen, insbesondere den

Computerwissenschaften, werden die Verfahren und Vorgehensweise der Statistik noch effizienter

nutzbar. Datenmengen, die aufgrund ihres Umfangs vorher nicht handhabbar waren, sind nun mit

Rechnerunterstützung analysierbar. Ziel der Datenanalyse ist es, beliebig große Datenmengen so zu

bearbeiten, daß aus ihnen neue Informationen gewonnen werden können [Han97] und das

Grundproblem der Handhabung der Daten zu vereinfachen. Dabei sollen Strukturen in diesen Daten

aufgedeckt werden, die aufgrund von Umfang oder Komplexität der vorliegenden Daten nicht direkt

erkennbar sind. Um solche versteckten Informationen gewinnen zu können, kann man sich an

generelle Ablaufschemata (vergleiche auch Abbildung 4.2) halten, die in [Ama97, Han97, Jam92,

LCB97] näher beschrieben werden.

Meist werden Daten, die die Grundlage für die Informationsgewinnung bilden, über Erhebungen

gewonnen, die von vornherein durch bestimmte Hypothesen beeinflußt wurden. Einen anderen Weg

geht die explorative Datenanalyse (EDA), bei der die Daten ohne vorherige Vermutungen, sondern als

Gesamtheit ohne Vorgaben betrachtet werden. Dieser Begriff wurde in den sechziger und siebziger

Jahren durch J.W. Tukey [Tuk77] geprägt, um innerhalb der Statistik bzw. der allgemeinen

Datenanalyse ein Aufgaben- und Methodenspektrum und eine Vorgehensweise zu charakterisieren.

Aufgabe der EDA ist es, alle Strukturen, Beziehungen, Abhängigkeiten, Auffälligkeiten und

Besonderheiten ausfindig zu machen, die in einem Datensatz vorhanden sind und die charakteristische

Eigenschaften der betrachteten Daten widerspiegeln [Boc92]. Dabei sollen durch effektive

Datenbetrachtungen neue Informationen entdeckt und nicht bereits vorhandene Vermutungen bestätigt

werden. Daraus ergibt sich auch der wesentliche Vorteil der EDA gegenüber der allgemeinen

Verfahren der Datenanalyse: Es können auch unerwartete Zusammenhänge und Strukturen innerhalb

des vorhandenen Datenmaterials aufgedeckt werden, da die Daten nicht von vornherein nur auf

bestimmte Hypothesen hin untersucht werden, wie es bei den herkömmlichen Verfahren der Fall ist,

wodurch möglicherweise wichtige Informationen verloren gehen können [Wie94].

Abbildung 2.4 aus [Wol92] zeigt schematisch eine generelle iterative Vorgehensweise in der EDA.

Ziel der explorativen Datenanalyse ist somit die Gewinnung neuen Wissens und nicht die Bestätigung

bereits vorhandener Vermutungen. Mit dieser Vorgehensweise lassen sich oft unerwartete

Zusammenhänge und Strukturen innerhalb der Daten finden, die bei der herkömmlichen

Vorgehensweise der Datenanalyse nicht erfaßbar sind.

2. Visuelle Programmierung

Bedenken der Ausgangslage,

Betrachtung des Anfangsproblems

Entwicklung von Fragestellungen über

Struktur und Zusammenhang der Daten

Ausbildung einer Erwartungshaltung,

wählen eines geeigneten Verfahrens

Aktivierung des

ausgewählten Verfahrens

Beobachtung der Ergebnisse

Beurteilung und Interpretation

Abbildung 2.4: Vorgehensweise in der Explorativen Datenanalyse

Die Datenanalyse an sich ist sicher kein klassisches Anwendungsgebiet der visuellen

Programmierung, dennoch kann diese hier in einigen Teilbereichen sehr hilfreich sein. Gerade wenn es

darum geht, große Datenmengen mit Hilfe mehrerer verketteter Verfahren zu bearbeiten, können

visuelle Konzepte die Arbeit des Analytikers erleichtern. Genauer betrachtet ist eine Datenanalyse

nichts anderes als eine Folge von einzelnen Analyseschritten, die sehr gut mit Hilfe einer visuellen

Programmierumgebung modelliert werden kann. Durch die Umsetzung innerhalb eines VP-Systems

wird die prozeßorientierte Sicht der Datenanalyse gefördert, indem die einzelnen Bausteine

entsprechende Analyseverfahren symbolisieren, die über Datenkanäle verbunden sind.

Mit einem VP-System, das speziell für die Datenanalyse konzipiert ist, wird dem Analytiker die evtl.

notwendige Programmierarbeit abgenommen. Eine Untersuchung bezeichnet die komplette Abfolge

aller Analyseschritte, die bis zum Erhalt der gewünschten Daten notwendig sind. Die einzelnen

Analyseschritte werden als Verfahren bezeichnet, die konkrete Algorithmen zur Bearbeitung der

Daten beinhalten. Die Modellierung von Untersuchungen erfolgt dann über das VP-System, das auf

Basis der Terminologie, den Symbolen und Konzepten der Datenanalyse optimal den Analyseprozeß

unterstützt. Dabei kann sehr gut die Gesamtstruktur einer Untersuchung visuell dargestellt werden und

so einen optimalen Überblick geben. Fehleranfälligkeit sowie Entwicklungszeit werden durch den

Einsatz eines solchen VP-Systems ebenfalls reduziert. Wie aber bereits im vorangegangenen Abschnitt

beschrieben, treten auch hier wieder die problematischen Eigenschaften auf, die es somit in dieser

Arbeit zu lösen gilt.

2. Visuelle Programmierung

2.4 Existierende visuelle Programmiersysteme in der Datenanalyse

Nachdem im vorangegangenen Abschnitt die visuelle Programmierung für die Datenanalyse motiviert

wurde, sollen im folgenden nun existierende Systeme in diesem Anwendungsbereich vorgestellt

werden. Dies geschieht insbesondere vor dem Hintergrund, sinnvolle bzw. gut verwendbare Konzepte

für viDUMP zu ermitteln. Dafür wird zunächst die Vorgehensweise erläutert, nach der die

Softwaresysteme untersucht werden sollen. Ein Analyseschema, das im folgenden Abschnitt

vorgestellt wird, beinhaltet die dafür wesentlichen Punkte. Nachdem in [Kel97] allgemeine VP-

Systeme für die verschiedensten Anwendungsbereiche vorgestellt wurden, sollen in diesem Kapitel

nur solche Systeme behandelt werden, die ihre Anwendung im Bereich der Datenanalyse finden, da

viDUMP später auch in diesem Anwendungsbereich eingesetzt werden soll. Die vier vorgestellten

Systeme wurden unter Berücksichtigung der Ziele dieser Arbeit ausgewählt und dienen mit ihrer

Realisierung verschiedener Konzepte und Ansätze als Inspiration bzw. Vorlage für die

Anforderungsdefinition in Kapitel 3 sowie den Entwurf von viDUMP in Kapitel 4.

2.4.1 Analyseschema

Um die in den folgenden Abschnitten vorgestellten Systeme einheitlich betrachten zu können, wird

hier zunächst die Vorgehensweise vorgestellt, nach der die Systeme in den folgenden Abschnitten

betrachtet werden. Dieses Schema orientiert sich im wesentlichen an den Ausführungen von [KHA97],

in denen sich ein Kriterienkatalog für visuelle Programmiersprachen auf Grundlage der verbreitetsten

Klassifikationen für VP-Systeme von Shu [Shu88], Chang [Cha87], Burnett und Baker [BB94] findet.

Weitere Aspekte zur Beurteilung und Bewertung von VP-Systemen finden sich in [Hil92] und

[WRH92], die ebenfalls in das Analyseschema einfließen. Desweiteren werden insbesondere im

Hinblick auf die Anforderungsdefinition in Kapitel 3 bereits Aspekte des Software Engineerings aus

[Ps94] mit in das Analyseschema einbezogen. Genauere Ausführungen dazu finden sich in Abschnitt

3.3. Auf dieser Grundlage beinhaltet das Schema dann sieben wesentliche Punkte, die für den weiteren

Verlauf dieser Arbeit als relevant erscheinen und im folgenden vorgestellt werden. Die Auswertung

einiger dieser Punkte werden in den vorgestellten Systemen gleich sein, doch es geht dabei nicht so

sehr darum, ob ein VP-System den einen oder anderen Punkt erfüllt, sondern insbesondere im

Hinblick auf Kapitel 4 vielmehr darum, wie es die Umsetzung realisiert hat. Eventuell vorhandene

Aspekte zur Datenvisualisierung des VP-Systems werden vernachlässigt, da dies keinen Bestandteil

dieser Arbeit darstellt.

(a) Anwendungsbereich

Jedes VP-System wird in seiner Gestaltung und Funktionalität unmittelbar durch das

Anwendungsgebiet beeinflußt, für das es konzipiert wurde. Die Funktionalität wird genauer unter den

Folgekriterien betrachtet, so daß innerhalb dieses Kriteriums festgehalten wird, ob sich das VP-System

neben dem Einsatz in seinem primären Anwendungsgebiet auch in anderen Bereichen außerhalb des

eigentlichen Anwendungsbereichs einsetzen läßt.

2. Visuelle Programmierung

(b) Paradigmen

Das Paradigma, das einem VP-System zugrunde liegt, ist äußerst wichtig für die Flexibilität und die

Einfachheit der Problembeschreibung. Deshalb wird innerhalb diesen Kriteriums nicht nur analysiert,

welches Paradigma verwendet wird, sondern ob es eventuell sogar eine Unterstützung für mehrere

Paradigmen innerhalb eines VP-Systems gibt. Fast allen in dieser Arbeit betrachteten Systemen liegt

das Datenflußparadigma zugrunde, jedoch bringt eine strenge Umsetzung einige Probleme mit sich, so

daß viele Systeme nicht nur ein Paradigma, sondern häufig auch Elemente anderer Paradigmen

integrieren. Als Bewertungs- bzw. Vergleichsmaßstab zwischen den verschiedenen Systemen gilt

folgende Hypothese [KHA97]: Je mehr verschiedene Paradigmen ein VP-System unterstützt, desto

flexibler kann es für die verschiedensten Problemlösungen genutzt werden. Dazu zerlegt man das

Problem in viele kleine Teilprobleme (ähnlich dem modularen Programmierkonzept) und sucht für

jedes Teilproblem die passende Lösung bzw. das passende Paradigma, mit dem sich das Teilproblem

am einfachsten lösen läßt.

(c) Konzepte

Viele VP-Systeme führen einige eigene Konzepte und Vorgehensweisen ein, die zur Modellierung von

Programmen mit Hilfe des Systems verwendet werden. Dieses Kriterium soll somit im Vorfeld für die

folgenden Analysepunkte die für die Anwendung wichtigsten Begriffe erläutern und kurz einen

Überblick über den generellen Aufbau des Systems geben.

(d) Visualisierung und Interaktion

Das Kriterium der Visualisierung beinhaltet Aussagen über den Gebrauch und die Handhabung

visueller Objekte im VP-System. Betrachtet wird dabei unter anderem das Verhältnis von Text zu

Grafiken in dem System. Dazu gehören auch die Aussagekraft, die Art sowie die durchgängig

einheitliche Verwendung und die Anordnung bzw. Komposition der verwendeten Symbole und

Grafiken. Besonderes Augenmerk wird dabei auf die Gestaltung der Bedienoberfläche sowie den

grafischen Editor gelegt. Dieses Kriterium ermittelt also, in welchem Maße Information innerhalb des

VP-Systems grafisch dargestellt werden kann. Fast alle VP-Systeme stellen einen oder mehrere

zweidimensionale Editoren zur Verfügung, mit deren Hilfe ein Programm gemäß der visuellen

Sprache modelliert werden kann. Über diese wird eine Interaktion mit dem VP-System ermöglicht.

(e) Kontrollstrukturen

Kontrollstrukturen und Wiederholungskonstrukte ermöglichen einen gesteuerten Programmfluß zur

Laufzeit des Programms, der explizit festgelegt wird. Dieses Kriterium ist für die imperative

Programmierung in kontrollflußorientierten VP-Systemen nicht weiter überraschend. Eine strenge

Umsetzung des Datenflußparadigmas impliziert jedoch den Verzicht auf Kontroll- und

Wiederholungskonstrukte ähnlich den IF-THEN-ELSE oder FOR-Anweisungen imperativer

Programmiersprachen. Ein Auskommen ganz ohne solche Konstrukte ist bei vielen

Berechnungsvorgängen aber nicht möglich, so daß fast alle VP-Systeme vom reinen Datenflußkonzept

abweichen und zusätzlich die Möglichkeit bieten, Kontrollstrukturen und Wiederholungen zu

definieren.

2. Visuelle Programmierung

(f) Intuitive Verständlichkeit

Ein Ziel der visuellen Programmierung ist die Vereinfachung des Programmiervorgangs bzw.

Programme verständlicher darzustellen, als es textbasierte Systeme in der Lage sind. Die

Verständlichkeit wird dabei in vier verschiedene Kategorien eingeteilt, von denen die folgenden drei

als elementar wichtig erscheinen. Neben der generellen Verständlichkeit, die Aussagen über die

Einfachheit der Handhabung zuläßt, wird zusätzlich in die Verständlichkeit für Programmierer sowie

Verständlichkeit für Spezialisten des Anwendungsgebiets ohne Programmierkenntnisse unterschieden.

Diese Unterscheidungen sind insofern sinnvoll, da die verschiedenen Kategorien von sehr

unterschiedlichen Voraussetzungen ausgehen. So kann es beispielsweise sein, daß Nicht-

Programmierer, die aber Spezialisten innerhalb des Anwendungsgebietes sind, sehr viel besser in der

Lage sind, mit Hilfe der visuellen Programmiersprache eine graphische Beschreibung des Problems zu

modellieren als eine geeignete textuelle Repräsentation zu finden. Dies läuft konform zu Kriterium (a),

denn je besser die verwendeten Grafiken und Symbole auf das Anwendungsgebiet zugeschnitten sind,

desto einfacher wird es möglich sein, ein Programm grafisch zu modellieren.

(g) Skalierbarkeit

Die Skalierbarkeit ist besonders dann wichtig, wenn große Programme in ihrer Darstellung nicht mehr

überschaubar sind. Für textbasierte Programmiersprachen sind viele Konzepte entwickelt worden, um

dem Skalierbarkeitsproblem zu begegnen. Modularisierung, Abstraktion sowie das Information-

Hiding haben sich dabei als Techniken bewährt, die allerdings nicht ohne eine entsprechende

Anpassung in den Bereich der visuellen Programmierung übernommen werden können. Die

Modularisierung kommt der funktionsorientierten Programmierung nahe (siehe Abschnitt 2.1.3), und

die Abstraktion bzw. das Information-Hiding lassen sich in einem VP-System durch Zooming oder der

Skalierbarkeit von Detailtiefen realisieren (vgl [Kel97]). Alle diese Techniken lassen sich also

einsetzen, um das Screen-Space-Problem behandeln zu können.

(h) Sonstiges

Unter diesem Punkt sollen alle Aspekte Berücksichtigung finden, die durch keine der fünf vorigen

Kriterien erfaßt werden, aber für das jeweilige System doch als wichtig erscheinen. Darunter fallen

Aussagen über das Ausführungsmodell des VP-Systems. Dies kann variieren zwischen einer

Interpretation nach der kompletten Erstellung des Flußgraphen und einer sofortigen Ausführung und

Neuberechnung nach jeder Änderung. Zusätzlich wird ein kleines grafisches Beispiel zur Illustration

der Analyse gegeben.

Ein weiterer sehr interessanter Punkt ist die Granularität der in den jeweiligen Systemen verwendeten

Bausteine bzw. Verfahren. Dabei soll darauf geachtet werden, ob und wie weit der Benutzer deren

Ablauf beeinflussen und wie detailliert er auf die einzelnen Komponenten innerhalb der einzelnen

Bausteine bzw. Verfahren Einfluß nehmen kann.

Aus den aufgeführten Kriterien zur Analyse eines VP-Systems ergibt sich eine Checkliste, die in

Abbildung 2.5 tabellarisch dargestellt ist.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 1998
ISBN (eBook): 9783832467838
ISBN (Paperback): 9783838667836
Dateigröße: 1.1 MB
Sprache: Deutsch
Institution / Hochschule: Carl von Ossietzky Universität Oldenburg – Informatik
Erscheinungsdatum: 2014 (April)
Note: 1,9
Schlagworte: programmierung datenanalys komplexe verfahren datenfluss

Autor

Carsten Keltsch (Autor:in)

Ein visuelles Programmiersystem zur Modellierung deskriptiver Untersuchungen in der Datenanalyse

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Carsten Keltsch (Autor:in)