2 Visuelle Programmierung
2.2 Mächtigkeit visueller Programmierung
2.2.2 Vor- und Nachteile visueller Programmierung
3.2 Kontroll- und Datenfluß
3.2.2 Datenflußdiagramme
3.2.3 Zustandsübergangsdiagramme
3.2.4 Allgemeine Anforderungen an Flußdiagramme
3.3.2 Programmierung durch Beispiele
3.3.3 Zeitleiste
4.1.2 VIPR
4.1.3 VisPro REXX
4.2.2 Macromind Director
4.4 Überblick
5.2 Die EPI-Workbench
5.3 Übertragung der Konzepte visueller Programmierung
5.3.2 Erweiterungen des Kontrollflusses
5.3.3 Kontext und Kommentare
Literaturverzeichnis
Index
Abbildung 2.1: Entstehung einiger wichtiger Programmiersprachen
Abbildung 2.3: Typen visueller Programmiersprachen
Abbildung 2.4: Beispiel visueller Programmierung
Abbildung 3.1: Grundsymbole von Nassi-Shneiderman Diagrammen
Abbildung 3.2: Fakultätsberechnung in NS-Notation
Abbildung 3.3: Allgemeine Symbole in Datenflußdiagrammen
Abbildung 3.4: Elementares Datenflußdiagramm für das n-Damen-Problem
Abbildung 3.5: Zustandsübergangsdiagramm
Abbildung 4.1: Einige wichtige Grundsymbole von Prograph
Abbildung 4.2: Attribut lesen / Attribut schreiben in Prograph
Abbildung 4.3: Beispielmethode Push in Prograph
Abbildung 4.4: Kontrollfluß in Prograph anhand der Methode Quicksort
Abbildung 4.5: Beispiel eines VIPR Programms
Abbildung 4.6: Bedingte und unbedingte Ausführung in VIPR
Abbildung 4.7: Iteration in VIPR
Abbildung 4.8: Grafische Oberfläche einer ToDo Liste in VisPro REXX
Abbildung 4.9: Aktionseditor Aufnehmen und die fertige ToDo Liste
Abbildung 4.10: Informationsobjekt in FMAD
Abbildung 4.11: Benutzerschnittstelle von FMAD
Abbildung 4.12: Macromind Director
Abbildung 4.13: Elemente einer EPK
Abbildung 4.14: Aufbau einer Workflow-Definition
Abbildung 5.1: Vorgehensweise in der EDA
Abbildung 5.2: Graphischer Editor der EPI-Workbench
Abbildung 5.3: Ein durch Verschmelzung erzeugtes Netzwerk
Abbildung 5.4: Probleme der Verschmelzung
Abbildung 5.5: Aggregation und De-Aggregation
Abbildung 5.6: Bedingte Ausführung in der EPI-Workbench
Abbildung 5.7: Kommentare in der EPI-Workbench
Programmiersprachen stellen eine Schnittstelle zwischen Computer und Mensch dar, deren Erlernen meist nur durch einen aufwendigen Prozeß machbar ist. Die klassische Programmierung baut auf einer guten Kenntnis des Programmierers über die jeweilige Programmiersprache oder die Maschinensprache des jeweiligen Computers. Diese sind i.a. linear aufgebaut, man gibt der Maschine Schritt für Schritt in einer imperativen Vorgehensweise an, was sie zu tun hat. Mit der Einführung von Hochsprachen wurde von der Maschinensprache des jeweiligen Computersystems abstrahiert, die Programme waren in textueller Form nun leichter nachvollziehbar, der Quellcode wurde verständlicher. Diese Form der Programmiersprachen hat sich bis heute gehalten, da man durch ihre lineare textuelle Repräsentation eine effiziente Abbildung auf die lineare computerinterne Struktur ermöglichen kann. Die Entwicklung neuer Konzepte, wie z.B. die Modularisierung oder die objektorientierten Ansätze erhöhten zwar den Abstraktionsgrad, dennoch blieb die Repräsentation bzw. Visualisierung der Programme an sich immer eine eindimensionale Liste von Befehlen und Wörtern in der Syntax der Programmiersprache, die durch wachsende Komplexität und Funktionalität wieder viel an Übersichtlichkeit verlor. Der sich daraus ergebende große Nachteil liegt in der erschwerten Auffindung von Fehlern, die u.a. eine gute Kenntnis der Programmiersprachensyntax voraussetzt.
Die visuelle Programmierung erlaubt dem Benutzer ein Programm in einer zwei- oder mehrdimensionalen Art und Weise zu spezifizieren. Klassische textuelle Sprachen gehören zu den eindimensionalen Sprachen, da die Compiler bzw. Interpreter die mit ihr erstellten Programme als lange, eindimensionale Zeichenfolgen behandeln. Zweidimensional meint die Erstellung eines Programms durch das verbinden von grafischen Symbolen. Das Programmiersystem interpretiert dann die zweidimensionale Struktur dieser so erstellten Abbildung und generiert daraus ein lauffähiges Programm. Die Erweiterung auf mehrere Dimensionen sind bisher nur in einigen wenigen Konzepten verwirklicht, sie wird zur Zeit vorrangig nur dazu genutzt, um das Screen Space Problem zu lösen, das in Abschnitt 2.2.2 näher erläutert wird. Programme werden dabei in ihrem Datenfluß z.B. dreidimensional auf den Bildschirm gebracht, der Benutzer kann dann alle Programmteile durch Rotation sichtbar machen. An eine solche Darstellung angelehnt ist somit auch die mehrdimensionale Programmerstellung zu definieren. Einzelne Programmkonstrukte bestehen dann nicht mehr aus zweidimensionalen Kacheln, sondern etwa aus dreidimensionalen Würfeln, die sich dann analog zu den Kacheln kombinieren lassen. Der weitere Verlauf dieser Arbeit stützt sich auf die herkömmliche zweidimensionale Darstellung, da zwar schon einige Ansätze der mehrdimensionalen Darstellung realisiert wurden [Gli87, Naj94], diese aber für das eigentliche Thema dieser Arbeit nicht weiter relevant sind.
Mit Hilfe der grafischen (visuellen) Programmierung soll das Verfahren der Programmentwicklung soweit vereinfacht werden, daß auch Nichtprogrammierer in der Lage sind, ohne die Kenntnis der zugrundeliegenden Programmiersprache und der zugehörigen Programmierkonzepte, ihre Ideen zu verwirklichen. Programmierer sollen durch einen einfacheren und fehlerfreien Programmaufbau in der Programmentwicklung unterstützt werden. Eine genauere Abhandlung über visuelle Programmierung erfolgt in Abschnitt 2.2. Durch die Nutzung der angedeuteten Aspekte in den nicht klassischen Bereichen, wie z.B. Multimedia, können nun auch Designer und Graphiker, die nicht über die Fähigkeit der Programmierung von Software in einer bestimmten Programmiersprache verfügen, schnell Programme erstellen, die nicht mehr die speziellen Kenntnisse der Programmierung erfordern. Die Entwicklungszeit einer solchen Anwendung ist im Vergleich zur herkömmlichen Programmierung sehr viel kürzer und mit einer niedrigeren Fehlerrate behaftet. Dennoch bringt die visuelle Programmierung auch einige nicht zu unterschätzende Nachteile mitsich, die zusammen mit den Vorteilen ausführlich im Abschnitt 2.2.2 vorgestellt werden.
Der Einsatz der visuellen Programmierung ist u.a. für den Bereich der Datenanalyse sehr interessant. Die Datenanalyse hantiert mit sehr großen Datenmengen und versucht aus diesen neue Informationen über bestimmte Sachverhalte zu gewinnen. Dazu bedient sie sich teilweise sehr komplexer Verfahren, die entsprechend modelliert oder auch programmiert werden müssen. Je nach Verfahren kann das mitunter ein äußerst aufwendiger Prozeß werden, so daß tiefgreifende Spezialkenntnisse nötig werden. Hier können Konzepte visueller Programmierung zumindest eine Arbeitserleichterung schaffen. Sie helfen dem Anwender, auf eine intuitive Art und Weise die entsprechenden Verfahren visuell zu modellieren. Es ist dabei für den Anwender sehr viel einfacher mit visuellen Objekten zu modellieren, die die einzelnen Bausteine eines Verfahrens bezeichnen, als per Hand geeignete Methoden zu implementieren. Mittels dieser Art der Programmierung eines Datenflusses auf visueller Basis wird der Datenbearbeitungsprozeß stark vereinfacht. So können z.B. Analysemethoden durch einzelne grafische Objekte repräsentiert werden, die dann visuell beliebig oder aber nach bestimmten Kriterien kombinierbar sind. Wie eine solche Unterstützung aussehen kann, soll in Abschnitt 5.2 anhand der EPI-Workbench [Wie94] gezeigt werden. Ein ausführlicherer Einblick in das Umfeld der Datenanalyse erfolgt in Abschnitt 5.1.
In dieser Arbeit erfolgt zunächst in Kapitel 5 eine Einführung über Programmiersprachen und insbesondere der visuellen Programmierung mit ihren Vor- und Nachteilen. Danach werden in Kapitel 2 im ersten Schwerpunkt dieser Arbeit einige wichtige Konzepte visueller Programmierung erarbeitet, die anhand von Anwendungsbeispielen in Kapitel 3 vorgestellt werden. Der zweite Themenschwerpunkt liegt auf der Untersuchung, inwieweit die Konzepte visueller Programmierung auf den Bereich der Datenanalyse anwendbar sind. Dazu wird in Kapitel 5 die EPI-Workbench [Wie94] betrachtet, die bereits einige Konzepte visueller Programmierung in diesem Bereich realisiert hat. Dabei werden die in den vorangegangenen Kapitel erarbeiteten Aspekte zur Erweiterung des Systems herangezogen. Abschließend erfolgt eine kurze Zusammenfassung der gesamten Arbeit in Kapitel 5.
"Mir sind Sprachen lieber, die von Anfang an Gewähr bieten, daß Programme als geistiges Eigentum geschützt werden, weil sie nur der Autor versteht!" C. Isab, Software Archäologe [Böh95]
Eine kurze Abhandlung über die generelle Klassifikation von Programmiersprachen soll helfen, visuelle Programmiersprachen und damit auch die visuelle Programmierung zuordnen zu können. Visuelle Programmiersprachen bilden dabei im Bereich der Systemprogrammierung keine eigene Klasse von Sprachen, da sie keine neuen Sprachen im eigentlichen Sinne sind, sondern lediglich ein "Aufsatz" auf schon vorhandene Sprachen. Das Dilemma der Definition von visuellen Programmiersprachen und visueller Programmierung wird dabei zunächst nicht einbezogen, aber in Abschnitt 2.2.1 näher betrachtet.
Im allgemeinen werden Programmiersprachen in ein 5-stufiges Klassenmodell unterteilt [Böh95]:
Maschinensprachen sind die speziellsten aller Programmiersprachen. Eine Folge von Zahlencodes, bestehend aus 0 und 1, bilden Ihre Befehle. Der große Vorteil von Maschinensprachen liegt im sehr effizienten Laufzeitverhalten. Eine Fehlerfindung und ggf. Korrektur ist durch die unübersichtliche Darstellung allerdings nur äußerst mühsam durchführbar und die Zahlencodes sind darüber hinaus immer abhängig vom jeweiligen Prozessortypen, so daß eine Portierung des Programms auf andere Prozessoren meist sehr aufwendig ist. Somit ist eine Abstraktion vom Prozessor hier also nicht gegeben. Wegen dieser Nachteile kommt die Programmierung in Maschinensprache heute nur noch in den Bereichen vor, wo eine effiziente und schnelle Implementierung notwendig ist. Dabei ermöglichen es einige Programmiersysteme höherer Programmiersprachen, Maschinenbefehle direkt in den Quellcode zu integrieren.
Assembler erhöhen den Abstraktionsgrad, bleiben aber trotzdem im allgemeinen an einen bestimmten Prozessortyp gebunden. Anstelle von Zahlencodes wird in Assemblersprachen mit Hilfe von symbolischen Bezeichnern codiert. Eine Anweisung wird dabei in genau einen Maschinenbefehl umgesetzt. Assembler ermöglichen eine sehr effiziente Implementierung, bieten aber trotz der symbolischen Bezeichner schlechte Wartungsmöglichkeiten, da durch die Fülle von Befehlen, wie bei den Maschinensprachen, die Übersichtlichkeit nur in sehr geringe Maße gewährleistet ist.
Durch die Sprachen der 3. Klasse erhöhte sich der Abstraktionsgrad soweit, daß die Programmierung weitgehend maschinenunabhängig wurde. Wesentliche Vorteile der Sprachen dieser Klasse sind die direkte Unterstützung der Notation von Algorithmen, die Einführung von Konzepten der Modularisierung sowie strenge Typenverwaltung und Zeigerstrukturen. Wie auch für die 1. und 2. Klasse gilt hier, daß die Programmerstellung anwendungsneutral erfolgt, d.h. man wird nicht durch die Programmiersprache auf einen Anwendungsbereich beschränkt, sondern es können Programme für beliebige Bereiche erstellt werden.
Die 4. Klasse der Programmiersprachen bildet keine eigene Evolutionsstufe der Programmiersprachen, sondern vereinen alle Paradigmen der 3. Klasse, um sie anwendungsbezogen zu erweitern. Solche Erweiterungen sind meist relativ komplexe, anwendungsbezogene Operationen. Häufige Anwendung finden die Sprachen dieser Klasse z.B. bei der Programmierung von Datenbankzugriffsprogrammen durch SQL basierte Programmiersprachen.
Die Sprachen der 5. Klasse streben der Beschreibung von Sachverhalten und Problemen entgegen, nicht so sehr deren Programmierung. Kennzeichnend für diese Sprachen ist, daß sie, basierend auf der Beschreibung eines Problems, entsprechend dem jeweiligen Sprachkonzept, den Problemlösungsweg selbst wählen. Solche Sprachsysteme kommen vor allem im Bereich der künstlichen Intelligenz (KI) zum Einsatz. Bekanntester Vertreter ist PROLOG, das basierend auf einer Menge von Fakten und Regeln versucht, eine Anfrage zu verifizieren oder zu widerlegen.
Abbildung 2.1 zeigt einen ungefähre Abhängigkeit in Aufbau und Entstehung einiger wichtiger Programmiersprachen nach [Böh95, Wat89]. Durch die gestrichelten Linien wird versucht, eine Einteilung in die verschiedenen Klassen vorzunehmen. Die 4. Klasse wurde dabei vernachlässigt, weil sie eben keine eigentliche Evolutionsstufe bilden.
Im allgemeinen endet hier die Einteilung der Programmiersprachen in das Klassenmodell. Dennoch ist in den letzten 10 Jahren eine Programmiertechnik hervorgebracht worden, die zwar keine eigene Programmiersprache erfordert, dennoch aber eine neue Klasse von Sprachen schuf, die visuellen Programmiersprachen. Somit soll an dieser Stelle das herkömmliche Modell um eine Klasse erweitert werden, so daß dieser Entwicklung Rechnung getragen wird.
6. Klasse: Visuelle Programmiersprachen
Die Sprachen der 6. Klasse bilden ähnlich wie die Sprachen der 4. Klasse keine eigentliche Evolutionsstufe von Programmiersprachen. Vielmehr kommt hier eine Programmiertechnik zum tragen, die generell auf alle Klassen anwendbar ist, sich aber nur für die höheren Programmiersprachen (3. bis 5. Klasse) durchgesetzt hat. Visuelle Programmiersprachen existieren meist nur als "Aufsatz" zu bereits etablierten Sprachen. Mit ihnen werden die jeweiligen Programmierkonstrukte oder auch Gruppen von Konstrukten visuell dargestellt und durch Relationen zueinander in Verbindung gebracht. Aber auch die Erstellung von grafischen Benutzeroberflächen wird häufig zur visuellen Programmierung gezählt, so daß eine differenzierte Definition notwendig ist, die in Abschnitt 2.2.1 erfolgen soll.
Das vorgestellte Klassenmodell ist nicht als strenge zeitliche Entwicklung zu betrachten, sondern die aufgeführten Klassen können durchaus parallel, oder auch beinhaltend sein, obwohl ein gewisser zeitlicher Ablauf nicht ganz abwegig ist. Die Klasse der Maschinensprachen ist sicherlich als erstes entstanden, ihr folgten die Klassen der Assembler und höheren Programmiersprachen. Eine Hierarchie soll hier lediglich in der Abstraktion der Programmiersprachen in den einzelnen Klassen gesehen werden. Die 1. und 2. Klasse mit der geringsten bzw. gar keiner Abstraktion vom Prozessor bilden dabei die Basiseinheiten, die 6. Klasse, mit der bisher höchsten Abstraktion, die oberste Hierarchiestufe. In ihr erfolgt nicht nur eine Abstraktion vom Prozessor, sondern zusätzlich auch von der zugrundeliegenden Programmiersprache.
Abbildung 2.2 zeigt eine Anordnung der Programmiersprachen in Bezug auf den Abstraktionsgrad vom Prozessor. Die Sprachen der 5. Klasse (VHHL) haben den höchsten Abstraktionsgrad, die Sprachen der 1. und 2. Klasse den niedrigsten. Eine Art Oberklasse in Bezug auf die Abstraktion zum Prozessor und zusätzlich zur Abstraktion in Bezug auf die Programmiersprache bilden die visuellen Programmiersprachen. Der schattierte Pfeil nach unten drückt den von oben nach unten abnehmenden Abstraktionsgrad aus. Die Klassen der höheren Sprachen und die der anwendungsbezogenen Sprachen haben etwa den gleichen Abstraktionsgrad, die anwendungsbezogenen Sprachen bilden ja lediglich eine Spezialisierung der höheren Sprachen in Bezug auf den Anwendungsbereich der Sprache.
Zusätzlich zu der Einteilung in die beschriebenen Klassen, werden auch verschiedene Programmierstile unterschieden [Böh95,Wat89]:
Die ersten beiden Klassen der Programmiersprachen gehören nach dieser Klassifikation zur imperativen Programmierung, obwohl neuere Varianten von Assemblern auch in Teilen die prozedurale Programmierung unterstützen. Generell alle Programmierstile finden sich bei den Programmiersprachen der 3. und 4. Klasse, den höheren und anwendungsbezogenen Programmiersprachen. Beispiele sind LISP für funktionale Programmierung, FORTRAN in allen seinen Variationen für imperative Programmierung und die prozedurale Programmierung läßt sich unter anderem mit MODULA oder PASCAL realisieren. Die 5. Klasse hat ihren bekanntesten Vertreter für die logische Programmierung in der Sprache PROLOG [Wat89]. Trotz dieser Unterscheidung der Programmierstile, gibt es fast keine Programmiersprache, die nur ein einziges Programmierparadigma unterstützt. Meist sind z.B. objektorientierte Sprachen (z.B. C++) in der Lage auch imperative und prozedurale Programmierung zu verarbeiten.
Offensichtliche Unzulänglichkeiten der klassischen Programmiersprachen erstrecken sich über die Programmerstellung bis hin zur Darstellung des Quellcodes eines Programmes. Das Verstehen und Nachvollziehen blieb denjenigen vorbehalten, die über eine gute Kenntnis von Programmiersprachen verfügten. Durch die ständig fallenden Hardwarepreise und stetig steigende Prozessorleistungen ist es jedoch nicht mehr unbedingt erforderlich, die Programmierung von den technischen Möglichkeiten einer Rechnerplattform abhängig zu machen. Man geht nun dazu über, auch Nichtprogrammierern Programmiertechniken zur Verfügung zu stellen. Dies geschieht über die visuelle Programmierung, in der von den Programmiersprachen so weit abstrahiert wird, daß nur noch einzelne grafische Objekte kombiniert werden müssen, um ein lauffähiges Programm zu erzeugen. Das entspricht allerdings dem Idealfall, der sich meist gerade in der Systemprogrammierung nicht immer realisieren läßt, da sich viele Programmierstile häufig gar nicht so weit abstrahieren lassen, als Beispiel sei die Rekursion genannt. Aber in anderen Anwendungsgebieten ist dieser Idealfall durchaus auch der Regelfall. Beispielsweise im Bereich Multimedia werden in solchen Systemen lediglich grafische Objekte mit einer Relation, meist einer Zeitschiene, verknüpft und die Programmerstellung läuft dann automatisch. Dies eignet sich dann insbesondere zum Erstellen von multimedialen Präsentationen. Ein Umgang mit einem solchen System fällt dem Menschen leichter als die Programmierung mit symbolischen Bezeichnern, der "harten" Kodierung von Programmtexten, weil die menschliche Wahrnehmung und dabei insbesondere die Informationsaufnahme durch folgende Prämissen beeinflußt wird [Shu87]:
Ein bereits angesprochenes Manko der visuellen Programmierung ist die in der Literatur durchaus unterschiedliche Definition des Begriffs. Häufigstes Problem ist die meist vermischte Verwendung der Begriffe Programmvisualisierung und Visuelle Programmierung [Cha87, Die94, Mye89, Naj94]. Die visuelle Programmierung meint ein System, das einem Benutzer die Programmentwicklung mit zwei- oder mehrdimensionalen Mitteln (gegenüber der konventionellen Programmierung) erlaubt. Die Programmvisualisierung bezeichnet dagegen den Einsatz grafischer Hilfsmittel zur Visualisierung des Programmcodes, wobei der Programmcode selbst weiterhin nur eindimensional ist. Beispiel hierfür ist etwa ein Klassenbrowser, der Abhängigkeiten wie z.B. Vererbungen in einer grafischen Repräsentation aufbereitet, den Programmcode visualisiert, aber dem Programmierer keine Hilfsmittel zur Programmerstellung (außer der grafischen Aufbereitung) selbst bietet. Visuelle Programmierung beschreibt also den direkten Programmentwurf, während die Programmvisualisierung meist in integrierten Entwicklungsumgebungen zum Einsatz kommt.
Ein ähnliches Problem der Definition entfaltet sich im Begriff visuelle Programmiersprache. Zum einen werden als visuelle Sprachen solche Sprachen bezeichnet, die visuelle Informationen verarbeiten, zum anderen wird der Begriff auch für Sprachen verwendet, die eine visuelle Programmentwicklung mit Hilfe grafischer Objekte ermöglichen. Aufgrund dieser Mehrdeutigkeit hat Chang [Cha87] versucht, eine Typisierung visueller Programmiersprachen vorzunehmen, wie sie in Abbildung 2.3 verdeutlicht ist.
|
|
|
|
|
|
|
|
|
|
|
|
Wie in der obigen Abbildung ersichtlich, wird in 4 Kategorien unterschieden. In die Klasse der visuelle Information verarbeitende Sprachen gehören danach alle textuellen Programmiersprachen, mit denen visuelle Objekte, wie z.B. Bilder verarbeitet werden können. Beispielsweise gehören in diese Klasse Sprachen, die die Bildverarbeitung unterstützen. Die betroffenen Objekte sind dabei visuell, die Programmierkonstrukte textuell. Ikonisch visuelle Information verarbeitende Sprachen ermöglichen es, mit visuellen Programmierkonstrukten, visuelle Objekte zu verarbeiten, wie es z.B. Graphikeditoren ermöglichen. Textuelle Programmiersprachen, in denen abstrakte Daten textuell repräsentiert und bearbeitet werden, heißen eine visuelle Interaktion unterstützende Sprachen. Dies sind textuelle Sprachen, die abstrakte Daten visuell repräsentieren und bearbeiten können. Zu diesen Sprachen gehören z.B. die Sprachen LOGO und HI-VISUAL. Aber auch solche Sprachen, mit denen man Nassi-Shneiderman Diagramme modellieren kann, gehören dazu. Solche NS-Diagramme repräsentieren die Konzepte der Sequenz, Iteration und Selektion [Cha87, NS72]. Die Programmstatements werden aber immer noch in der konventionellen Programmiersprache verfaßt. Somit ist die NS-Diagramm Applikation eine visuelle Interaktion unterstützende Sprache [Cha87]. Nach Chang sind dann visuelle Programmiersprachen alle die Sprachen, in denen Programmierkonstrukte visuell repräsentiert werden und mit denen abstrakte logische Objekte verarbeitet werden können, die ebenfalls visualisiert dargestellt werden [Die94].
Im folgenden soll es nur noch um visuelle Programmiersprachen gehen, jedoch wird schnell klar werden, daß man sich auf eine solch enge Definition oft nicht alleine stützen kann., da diese Sprachen meist nur als Mischformen existieren. In Kapitel 2 werden mehrere Konzepte vorgestellt, die der visuellen Programmierung zugrunde liegen können und durchaus stark voneinander abweichen. Die visuellen Programmiersprachen können aber noch in weitere 2 Gruppen unterteilt werden. Die Sprachen der ersten Gruppe, hier als programmierorientierte visuelle Programmiersprachen bezeichnet, zeichnen sich dadurch aus, daß der Benutzer dieser Sprachen die grundsätzlichen Prinzipien und Konstrukte der zugrundeliegenden Programmiersprache verstanden haben muß, um lauffähige Programme zu erstellen. Solche Systeme bieten oft lediglich nur die Visualisierung von textuellen Programmkonstrukten und bieten dazu Alternativen an. Sprachen, die sich in diese Gruppe einordnen lassen, finden sich meist im Bereich der Systemprogrammierung. Die zweite Gruppe, anwendungsorientierte visuelle Programmiersprachen, findet sich im Gegensatz zu ersten Gruppe auch in anderen Anwendungsbereichen oft vertreten. Die Sprachen dieser Gruppe zeichnen sich durch einen sehr viel höheren Abstraktionsgrad aus, die Programmerstellung beschränkt sich dann im Idealfall, wie bereits beschrieben, auf die Kombination grafischer Objekte. Im Verlauf dieser Arbeit wird jedoch deutlich werden, daß eine solch genaue Unterscheidung oft nicht exakt zu treffen ist.
Abbildung 2.4 zeigt ein Beispiel der Programmentwicklungsumgebung
Prograph [BP94, Car94]. Dargestellt ist die Realisierung eines Sortieralgorithmus,
der auf einem bereits definierten Modul Quicksort basiert. Die Bedeutung
der verschiedenen Symbole bestimmt die jeweilige Funktion. Zunächst
werden alle benötigten Werte ermittelt, bei Bedarf mit Quicksort sortiert
und wieder ausgegeben. Die unterschiedliche Funktion der gleich bezeichneten
Objekte wird durch verschiedene Symbolik verdeutlicht. Eine ausführlichere
Behandlung des visuellen Programmiersystems Prograph erfolgt in Abschnitt
4.1.
Das recht einfache Beispiel soll verdeutlichen, wie eine solche grafische Programmierung aussehen kann. In einer höheren Ebene könnte man dann z.B. dieses Programmbeispiel in einen Programmablauf integrieren. Weitere Beispiele werden innerhalb dieser Arbeit in Kapitel 3 behandelt.
Die Unterscheidung von visuellen Systemen in die oben definierten Kategorien fällt meist nicht eindeutig aus, i. d. R. haben Mischformen einen großen Verbreitungsgrad. Eine solche Mischform ist z.B. ein System, das es einem mittels einer visuellen Umgebung ermöglicht, den groben Programmaufbau zu gestalten. Dies mag aus der Kombination vorgegebener Module bestehen, die dann aber im Detail doch noch per Hand auszuprogrammieren sind. Ein solches System zu realisieren ist dementsprechend einfacher, als eine echte visuelle Programmiersprache umzusetzen. Warum aber macht man es sich dann nicht einfach und erstellt anwendungsorientierten visuellen Programmiersysteme für alle nur denkbaren Anwendungsgebiete? Die Beantwortung dieser Frage ist so einfach nicht zu geben, eine Abwägung des Für und Wider zur Erörterung findet sich im folgenden Abschnitt.
Der Idealfall der visuellen Programmierung ist, wie vorher schon weitläufig beschrieben, daß nur noch grafische Objekte, mit denen gewisse Methoden assoziiert werden, mittels Relationen kombiniert werden. Auf Knopfdruck kann dann das eigenständig lauffähige Programm generiert werden. Dabei stellt sich dann natürlich die Frage, warum man nicht nur noch visuell Programmiert, und sich die mühevolle Eingabe von Quellcode spart, was ohnehin sehr viel fehleranfälliger ist. Natürlich hat die visuelle Programmierung neben ihren offensichtlichen Vorteilen auch Nachteile, die die scheinbare Einfachheit der Programmerstellung relativiert.
Vorteile visueller Programmierung
Die Vorteile der visuellen Programmierung wurden in den vorigen Kapiteln bereits stellenweise beschrieben, werden hier aber der Übersichtlichkeit halber noch einmal zusammengefaßt:
Betrachtet man die aufgeführten Vorteile, so wird schnell klar, warum die visuelle Programmierung ständig an Beliebtheit gewinnt. Für immer mehr Programmiersprachen und Anwendungsbereiche werden visuelle Varianten entwickelt, die sich meist mehr oder weniger an den Konzepten der visuellen Programmierung orientieren. So gehören viele der Programmiersprachen, die im Titel das Wort visuell tragen, gar nicht zu den echten visuellen Programmiersprachen (siehe Abschnitt 1.2.1), sondern bieten ein Gemisch aus visueller Programmierung und Programmvisualisierung. Aber auch solche Entwicklungspakete erhöhen natürlich den Programmierkomfort für den Benutzer.
Nachteile visueller Programmierung
Neben den sehr überzeugenden Vorteilen, existieren aber noch Probleme, die die visuelle Programmierung einschränken und sie doch teilweise stark vom bereits beschriebenen Idealfall abweichen lassen.
Nach der Betrachtung der Vor- und Nachteile stellt sich zwangsläufig die Frage nach der Mächtigkeit visueller Programmiersprachen. Sicherlich scheint es klar geworden zu sein, daß die Programmierung eines Betriebssystemkerns mittels visueller Programmierung wohl nicht ratsam ist, kommt es doch gerade dort auf ein sehr effizientes Laufzeitverhalten an. Desweiteren sollte man sich auch vor der Nutzung fragen, wie detailliert man die Funktionalität der Programmiersprache nutzen will oder muß, und wie weit dies durch die visuelle Umgebung realisiert werden kann. In anderen Anwendungsgebieten, wie z.B. Multimedia, wo solche strengen Anforderungen nicht unbedingt verlangt sind, sieht das wieder ganz anders aus. Hier ist die visuelle Programmierung durch Autorensysteme geradezu prädestiniert für diesen Bereich.
Man muß also abwägen, für welchen Bereich man Programme erstellen will und welche Anforderungen an diese Programme gestellt werden. Es ist für einige Anwendungen eben unabdinglich, doch per Hand geschrieben zu werden, um beispielsweise eine hardwarenahe Implementierung zu realisieren, die dann sicherlich sehr viel schneller ist. Desweiteren hängt es natürlich auch von den Kenntnissen des jeweiligen Programmierers ab, inwieweit die Programmierumgebung ihn noch unterstützen kann oder muß.
Nachdem im vorigen Kapitel die visuelle Programmierung mit ihren Vor- und Nachteilen ausgiebig behandelt wurde, sollen in diesem Kapitel nun die Konzepte und Paradigmen vermittelt werden, die der visuellen Programmierung zugrunde liegen. Dazu gehört zunächst die Erörterung in Abschnitt 3.1, welche Anforderungen man an die dort verwendeten grafischen Objekte stellen muß bzw. sollte, damit diese für den Benutzer handhabbar sind. Anschließend wird in Abschnitt 3.2 auf Flußdiagramme näher eingegangen, auf deren verschiedene Formen fast jedes visuelle Programmiersystem basiert oder zumindest teilweise von diesen abgeleitet ist. Da aber für den Bereich der visuellen Programmierung nicht nur ein explizites Konzept existiert, sondern mehrere verschiedene Ansätze entwickelt wurden, die mitunter auch in einem System zusammen integriert sein können, widmet sich Abschnitt 3.3 alternativen Konzepten für die visuelle Programmierung.
Wenn im folgenden von visueller Sprache oder visueller Programmierungebung die Rede ist, dann soll darunter folgendes verstanden werden:
Eine visuelle Programmierumgebung ist ein Tool, mit dem Benutzer visuelle Sätze erstellen können. Ein visueller Satz repräsentiert graphisch einen Teil des Programms, das mit dem visuellen Programmiersystem erstellt werden kann. Wie ein solcher visueller Satz aufgebaut ist, hängt immer von der zugrunde liegenden Programmiersprache und vom Anwendungsbereich ab. Allgemein besteht ein visueller Satz aus Symbolen (visuelle Objekte, siehe Abschnitt 3.1), die die vom System zu bearbeitenden Objekte repräsentieren. Den zweiten wichtigen Bestandteil eines visuellen Satzes bilden die Operatoren, die einzelne Symbole in Beziehung setzen. Diese Operatoren, auch Prozeßsymbole genannt, kennzeichnen Operationen und Kommunikationen zwischen den Symbolen und sind meistens von ihrem Kontext, d.h. den zu verbindenden Symbolen abhängig, die vorgeben, welche Operatoren wie auf sie anwendbar sind. Eine visuelle Programmiersprache ist dann eine Kombination visueller Sätze [Cha96].
Zentraler Bestandteil der visuellen Programmierung ist der Umgang mit visuellen, grafischen Objekten. Dies resultiert hauptsächlich aus dem in Abschnitt 2.2.2 bereits beschriebenen Vorteilen von Bildern gegenüber Texten. Um aber mit solchen grafischen Objekten, im folgenden Symbole genannt, umgehen zu können, bedarf es bei ihrem Entwurf einer entsprechenden Planung bzw. der Beachtung einiger Richtlinien. [IJK90] unterscheidet hierzu in semantische, pragmatische und syntaktische Vorgaben, die die Basis für eine visuelle Kommunikation bilden:
Der Anwender der visuellen Programmierumgebung sollte nicht nur das Symbol leicht verstehen, sondern auch leicht behalten und sich wieder daran erinnern können. Man erinnert sich an bedeutungsvolle Information sehr viel besser, als an bedeutungslose [And88]. Dementsprechend wichtig ist es auch, daß die einzelnen Symbole in keiner Inkonsistenz zu anderen Symbolen oder Symbolkategorien des Programmiersystems stehen. Dies beinhaltet natürlich, daß Symbole nur das aussagen, was beabsichtigt ist und nicht irgendwelche ungewollten Zweideutigkeiten oder Informationen ohne Bezug enthalten.
Alle Beziehungen eines Symbols zu anderen Symbolen des Programmiersystems müssen verständlich sein. Die wichtigsten Symbole sollten gegenüber den anderen hervorgehoben sein, so daß sie sofort erkennbar sind und mögliche Kombinationen der Symbole sollten nur analog zum Programmfluß machbar sein, um die Übersicht zu gewährleisten und Irritationen des Benutzers zu vermeiden.
Die meisten visuellen Programmiersysteme basieren auf sogenannten Flußdiagrammen, auch Flußgraphen genannt. Solche Diagramme geben einen grafischen Überblick über den Daten- und/oder den Kontrollfluß des betreffenden Programms. Deshalb spricht man oft auch von Kontrollfluß- bzw. Datenflußdiagrammen [PS94, Naj94]. Die wohl bekanntesten Vertreter von Kontrollflußdiagrammen sind wohl Nassi-Shneiderman Diagramme, die bereits in den frühen 70er Jahren entwickelt wurden [NS72]. Ihre alleinige Anwendung ist in den letzten Jahren, nicht zuletzt durch das aufkommen objektorientierter Strukturierungsansätze aus der Mode gekommen. Vielmehr tauchen sie verstärkt in angepaßter Form, häufig vermischt mit Komponenten anderer Flußdiagramme auf. Ebenfalls sehr gebräuchlich sind Datenflußdiagramme, die ebenfalls mit wenigen Symbolen auskommen. Beide Ansätze werden im folgenden kurz erläutert, da sie eine Visualisierung von Programmcodes ermöglichen und teilweise in angepaßter Form in visuellen Programmiersystemen Einsatz finden. Eine Spezialform von Flußdiagrammen bilden die Zustandsübergangsdiagramme, die in Abschnitt 3.2.3 kurz erläutert werden. In Abschnitt 3.2.4 werden dann einige allgemeine Anforderungen an Flußdiagramme formuliert. Vorweg sei darauf hingewiesen, daß es kaum möglich ist, visuelle Programmiersysteme mit nur einem der folgenden Paradigmen zu realisieren. Deshalb sollen die Abschnitte 3.2 und 3.3 als theoretische Grundlage für Kapitel 3 verstanden werden, so daß die dort behandelten Anwendungsbeispiele systematischer analysiert werden können.
Nassi-Shneiderman Diagramme [NS72] lassen sich ohne großen Lernaufwand dazu nutzen, um Programme mit grafischen Hilfsmitteln zu entwerfen oder aber schon vorhandenen Programmcode strukturiert darzustellen. Durch die Beschränkung auf 4 Symbole (siehe Abbildung 3.1) bleiben sie in ihrer Struktur stets übersichtlich, sie sind intuitiv ihrer Bedeutung zuordnenbar. Alle Symbole lassen sich untereinander beliebig kombinieren, so daß Programmabläufe vollständig dargestellt werden können. Das Prozeßsymbol ist das elementarste aller vier Symbole, es repräsentiert Zuweisungen, Ein-/Ausgabeanweisungen, sowie alle sonstigen elementaren Anweisungen wie Sprünge, Prozedur und Funktionsaufrufe. Durch das Iterationssymbol können Schleifen wie DO, FOR, WHILE oder REPEAT in die Darstellung eingebracht werden.
Als Anweisungen im Rumpf dieses Symbols lassen sich wieder
alle anderen Symbole kombiniert einfügen. Der Anweisungsblock repräsentiert
einen Zusammenschluß von elementaren Anweisungen. Dieser wird z.B.
für das Entscheidungssymbol benötigt, wenn zwischen dem THEN-ELSE
Konstrukt mehrere Anweisungen zusammenhängend ausgeführt werden
sollen. Ist die Bedingung im Entscheidungssymbol wahr, so werden die Anweisungen
im THEN-Zweig ausgeführt, sonst die im ELSE-Zweig. Mit diesen vier
Grundsymbolen ist es möglich, sogar komplexere Programme strukturiert
darzustellen. Jedoch wird schnell klar, je komplexer ein darzustellendes
Programm ist, desto platzintensiver wird diese Notation.
In Abbildung 3.2 ist ein einfaches Programm zur Berechnung der Fakultät einer Eingabezahl in Nassi-Shneiderman Notation dargestellt. Die Verwendung von Nassi-Shneiderman Notationen ist ein Weg, um unübersichtlichen linearen textuellen Programmcode strukturiert darzustellen. Dieser Weg ist jedoch sehr einfach und stößt in der Darstellung bei größeren und komplexeren Programmen schnell an seine Grenzen, beispielsweise ist die Methodik der Sprünge in einem Programm mit dieser Notation schlecht darstellbar. So ist dann auch ein reines visuelles Programmiersystem auf Grundlage dieser Notation kaum denkbar, dafür sind die Symbole nicht differenziert genug, so daß die manuelle Programmierarbeit in jedem Fall bleibt. In vielen visuellen Programmiersystemen sind immer wieder abgewandelte Elemente dieser Notation anzutreffen. Will man dennoch größere Projekte mit dieser Art der Darstellung realisieren, kann man vom Detailgrad der Anweisungsblöcke abstrahieren. Hier lassen sich dann beispielsweise symbolische Bezeichner verwenden, die an anderer Stelle durch detaillierte Beschreibungen genauer definiert werden. Dies entspricht einer Modularisierung ähnlich der prozeduralen oder auch funktionalen Programmierung (siehe Abschnitt 2.1).
Während Nassi-Shneiderman Diagramme mehr auf die strukturierte Darstellung des eigentlichen Programmcodes abzielen und dabei einen Kontrollfluß modellieren, kann man mit Datenflußdiagrammen den Datenfluß eines Programms darstellen bzw. erstellen. Dabei ist es dann erstmal nicht so wichtig, wie die einzelnen Komponenten (Prozesse) realisiert werden, sondern der Datenfluß innerhalb des Programms tritt in den Vordergrund [PS94]. Sie finden in vielen visuellen Programmiersystem ihren Einsatz, wobei ihre Erscheinungsformen dabei durchaus stark variieren können.
Ähnlich zu den NS-Diagrammen sind Datenflußdiagramme aus Grundsymbolen aufgebaut, die in Abbildung 3.3 aufgeführt sind und auf den Ausführungen von [PS94, SS95] basieren:
Um das Zusammenspiel dieser 4 Primitiven von Datenflußdiagrammen zu verstehen, sei auf ein einfaches Beispiel zum bekannten n-Damen-Problem in Abbildung 3.4 verwiesen. Bei der Analyse bzw. Erstellung von komplexen Programmen reichen elementare Flußdiagramme nicht aus. Für solche Fälle gibt es die sog. mehrstufigen Flußdiagramme, die eine Darstellung komplexer Probleme durch funktionale Zerlegung ermöglichen. Dabei wird das Gesamtsystem über Prozesse hierarchisch in Datenflußdiagramme unterschiedlichen Abstraktionsgrades zerlegt. Von Stufe zu Stufe nimmt der Detailgrad der in den Diagrammen enthaltenen Informationen zu. Zu weiteren Vertiefungen zum Thema Flußdiagramme sei auf [PS94] hingewiesen.
Eine weitere Methode zur Beschreibung bzw. Erstellung von Programmen ist die Verwendung von Zustandsübergangsdiagrammen [PS94], die ihren Ursprung in der Automatentheorie haben [CO92] und strenggenommen nicht den Flußdiagrammen zuzuordnen sind. Hier werden keine Daten- oder Kontrollflüsse modelliert, sondern Zustandsübergänge eines Automaten. Es handelt sich dabei also um die Darstellung von Ereignissen bzw. Ereignismodellen. Im Gegensatz zu den vorherigen Diagrammen charakterisieren sie den zeitlichen Ablauf eines Systems. Zustände werden hierbei als Rechtecke dargestellt und ähnlich zu den Datenflußdiagrammen mit Pfeilen verbunden, die die Zustandsübergänge kennzeichnen. Zur Verdeutlichung dient Abbildung 3.5.
Die Beschriftung der Pfeile ist für jeden Übergang in zwei Teile untergliedert. Über dem Strich steht die Bedingung, unter der dieser Zustandsübergang erfolgt. Unter dem Strich stehen dementsprechend die zur Bedingung gehörigen Aktionen. Das durch diese Art von Diagrammen dargestellte System reagiert meist auf Ereignisse (extern oder intern), durch die ein Zustandswechsel des Systems hervorgerufen wird. Ausschlaggebend ist hier nicht nur die Eingangsinformation allein, wie z.B. bei Datenfluß- oder auch Kontrollflußdiagrammen, sondern auch der jeweilige aktuelle Zustand des Systems. Der häufigste Einsatzbereich liegt in der Modellierung von Systemzuständen von Anwendungssoftware.
Aber wie auch bei den Flußdiagrammen, ergeben sich bei Zustandsübergangsdiagrammen ähnliche Probleme mit Darstellung und Handhabung bei komplexeren Programmen. Obwohl man eine sehr deutliche Unterscheidung zwischen den einzelnen Flußdiagrammarten treffen kann, so zeigt es sich oft als vorteilhafter, Mischformen zu benutzen, die die jeweiligen Vorteile der Diagramme zu einer neuen Darstellung vereinen, je nach Problemart und Komplexität. So wäre z.B. ein Diagramm denkbar, daß die Datenflüsse per normalen Datenflußdiagrammen darstellt. Die dabei einbezogenen Prozesse ließen sich dann detaillierter z.B. mit Nassi-Shneiderman Diagrammen wiedergeben. Solche Diagramme treten selten nur in den oben beschriebenen Formen auf, sondern oft kommen abgewandelte oder zusätzliche Symbole hinzu, die die Mächtigkeit der jeweiligen Diagramme erhöhen sollen.
So unterschiedlich Flußdiagramme auch sein mögen, alle haben im Grunde einen analogen Aufbau, so daß man einige einfache Anforderungen an solche Diagramme stellen kann [PS94], die die Handhabung erleichtern.
Zusätzlich zu diesen Anforderungen kommen meist noch andere, wie z.B. Numerierung von Prozessen oder ähnliches. Für eine genauere Auflistung sei auf [PS94, SS95] verwiesen, sie werden hier nicht weiter betrachtet, da sie nicht in unmittelbarem Bezug zum Thema der visuellen Programmierung stehen.
Wie bereits mehrfach angedeutet, existieren kaum visuelle Programmiersysteme, die sich nur einem Konzept verschrieben haben. Vielmehr haben sich diverse Mischformen und Abkömmlinge von den Flußdiagrammen entwickelt, die hier im folgenden nur kurz umrissen werden sollen, da in Kapitel 3 weitere Beispiele dafür behandelt werden.
Einige visuelle Programmiersysteme benutzen ein Programmierverfahren, das zunächst die Erstellung einer grafischen Benutzeroberfläche [DGHL91] vorsieht und dann die einzelnen grafischen Elemente, wie z.B. Buttons, Listen oder Textfelder mit einer Funktion belegt. Benutzerschnittstellen werden durch ihre visuelle Darstellung und ihre Reaktion auf Nachrichten (Interaktionen) charakterisiert [Göt93]. Deshalb bezeichnet man die Elemente, über die ein Benutzer mit dem System kommunizieren kann auch als Interaktionsobjekte. Zur näheren Definition besitzt jedes Element ein Kontextmenü, aus dem Aktionen ausgewählt werden können, die nur auf dem entsprechenden Element ausführbar sind. Durch eine gemeinsame Kommunikationsschnittstelle können diese Aktionen in die Funktionen der einzelnen anderen Elemente übernommen werden. Die einfachste solcher Schnittstellen ist die Zwischenablage, die unter nahezu jedem Betriebssystem nutzbar ist. Diese Art der visuellen Programmierung ist aus dem Bereich der Erstellung von grafischen Benutzeroberflächen abgeleitet und um Konzepte der visuellen Programmierung erweitert worden. Ein ausführliches Beispiel hierfür wird in Abschnitt 4.1 behandelt.
Einen ganz anderen Weg geht die Methode der Programmierung durch Beispiele (Programming - By - Example, PBE). Dieses Prinzip ist nicht exklusiv für die Nutzung in visuellen Programmiersystemen vorgesehen, sondern kann durchaus auch in allen anderen Programmiersystemen genutzt werden. Da aber die meisten PBE-Systeme Konzepte der visuellen Programmierung benutzen [Die94, KE89], wird diese Methode kurz vorgestellt. Charakteristisch für solche Systeme ist, daß der Programmentwickler dem System einen Satz von Beispieldaten vorgibt. Aus diesen Beispieldaten generiert das PBE-System auf eine durch den Entwickler vorgegebene Art und Weise mit Hilfe eines Inferenz-Mechanismusses automatisch das fertige Programm. Solche Daten sind Sätze von Ein-/Ausgabedaten, deren Struktur das Programm ermittelt und dann in späteren Programmabläufen auf gleichgeartete Daten anwendet [Die94, KE89].
Ein auf Flußgraphen basierendes Prinzip ist die sog. Zeitleiste, deren häufigster Einsatz im Anwendungsbereich Multimedia vorkommt. Auf ihr plazierte Objekte laufen zunächst einmal nur streng chronologisch ab, die Ablauffolge ist somit fest vorgegeben. Im Bereich Multimedia eignet sich dies besonders zur Erstellung von Animationen, in denen Bilder in einer fest vorgegebenen Reihenfolge hintereinander ablaufen und somit eine Bewegungsillusion erzeugen. Aber auch im Bereich der Systemprogrammierung eignet sich dieses Verfahren, um immer wiederkehrende hintereinander ablaufende Programmschritte zu realisieren. Diese können dann in einzelne Sequenzen zusammengefaßt werden, die parallel zueinander ablaufen. Dieses Prinzip jedoch allein, ist nicht sehr geeignet, um aufwendigere Programme zu erstellen. Man hat keine Möglichkeit, den Ablauf zu variieren so daß z.B. Sprünge nicht realisiert werden können. Deshalb haben die meisten Systeme, die eine Zeitleiste als grundlegendes Programmierkonzept nutzen, Erweiterungen vorgesehen, die es ermöglichen, einen zusätzlichen Kontrollfluß zu implementieren. Dies erfolgt häufig über Skripte, die man zusätzlich zu jedem Objekt definieren und mit denen man die chronologische Abfolge manipulieren kann. Ein Beispiel dazu findet sich in Abschnitt 4.2.2.
Nachdem in Kapitel 1 die theoretischen Grundlagen der visuellen Programmierung näher erläutert wurden, soll in diesem Abschnitt mehr der Praxisbezug in den Vordergrund rücken. Exemplarisch wird anhand der drei Anwendungsbereiche Systemprogrammierung, Multimedia und Workflow der Einsatz visueller Programmierung demonstriert. Für den Bereich der Systemprogrammierung werden in Abschnitt 4.1 drei verschiedene visuelle Programmiersysteme, Prograph, VIPR und VisPro REXX in den Abschnitten 4.1.1, 4.1.2 und 4.1.3 vorgestellt. Diese Systeme nutzen unterschiedliche Ansätze, um die in Kapitel 1 erläuterten Konzepte zu realisieren, die visuellen Sätzen der einzelnen Systeme sind damit auch unterschiedlich verwirklicht worden. Genauer wird darauf bei den Einzelbeschreibungen der jeweiligen Systeme eingegangen.
Im Anwendungsbereich Multimedia liegt der Schwerpunkt auf der Erstellung von multimedialen Präsentationen und Anwendungen (siehe Abschnitt 4.2). Allgemein bestehen hier die Objekte aus Medientypen wie z.B. Audios oder Videos, die mit Operatoren verknüpft werden, die meist zeitliche Beziehungen definieren. Aber auch andere Abhängigkeiten, wie z.B. auslösende interaktive Ereignisse können so gesteuert werden. Die beiden Beispiele in diesem Anwendungsbereich, der Macromind Director und das Autorensystem FMAD, werden aber zeigen, daß die grafische Realisierung der visuellen Sätze durchaus stark voneinander abweichen kann, obwohl die gleiche Grundlage genutzt wird. Näheres dazu findet sich in den Abschnitten 4.2.1 und 4.2.2.
Der Anwendungsbereich Workflow macht sich ebenfalls Konzepte visueller Programmierung nutzbar. Im Beispiel des SAP R/3-Systems werden Workflows als sogenannte ereignisgesteuerte Prozeßketten, mit einem grafischen Editor modelliert und dienen dann der Ablaufsteuerung von Geschäftsprozessen in einem rechnergestützten Firmennetz. Dieses System wird mit seinen Grundlagen kurz in Abschnitt 4.3 vorgestellt. Als Abschluß dieses Kapitels erfolgt in Abschnitt 4.4 ein kurzer tabellarischer Überblick über die wichtigsten Merkmale der einzelnen in diesem Kapitel vorgestellten visuellen Programmiersysteme.
Bei dem Anwendungsbereich der Systemprogrammierung handelt es sich um den Bereich der allgemeinen Programmierung. In diesem Anwendungsbereich können z.B. Programmierumgebungen für andere Anwendungsbereiche erstellt werden. Für den Bereich der Systemprogrammierung werden 3 verschiedene Systeme vorgestellt, die sich alle mehr oder weniger die vorgestellten Paradigmen nutzbar machen. Dabei unterscheiden sich die drei Systeme stark in ihrer Abstraktion und im Grad der visualisierten Programmerstellung. Dieser bezieht sich darauf, wieviel manuelle Programmierung zusätzlich investiert werden muß, um mit dem jeweiligen Programmiersystem ein fertiges Programm erstellen zu können. Prograph [BP94, Car94] ist ein Programmiersystem, daß sich an den in dieser Arbeit beschriebenen Idealfall visueller Programmierung anlehnt (siehe Abschnitt 2.2). Es nutz vollständig die Eingabe über grafische Symbole, Objekte werden mit Linien verbunden. Manuell textuelle Programmierung ist überflüssig. Einen anderen Weg schlägt das Programmiersystem VIPR [CDZ94, CZ97a, CZ97b] ein, das grafisch definierbare Kontrollsemantik, dargestellt durch Kreise und Pfeile, mit manuell erstelltem Programmcode, angelehnt an eine Skriptsprache in einem System vereint. Zur kompletten Programmerstellung ist also noch manuell Programmcode zu implementieren. Einen ganz anderen Ansatz verfolgt das System VisproREXX, das aus dem Bereich der Erstellung von Benutzeroberflächen kommt und diesen um visuelle Programmierkonzepte insofern erweitert, daß einfache Programme ebenfalls ohne manuelle Programmierung, aber auf Grundlage einer graphischen Benutzerschnittstelle erstellt werden können.
Das visuelle Programmiersystem Prograph [BP94, Car94] läuft auf einem Macintosh, System 7 oder höher. Es arbeitet auf Grundlage von Datenflußdiagrammen und basiert auf objektorientierter Programmierung. Dadurch können Programme so weit gekapselt werden, das einzelne kleine Methoden ein Objekt definieren. Auf die Attribute (Daten) dieser Objekte kann dann auch nur mit Methoden der jeweiligen Objekte zugegriffen werden. Innerhalb der Datenflüsse ist die Ausführung von Methoden und Anweisungen abhängig von der Verfügbarkeit der Daten, die sie als Eingangsdaten erhalten. Sind alle Eingangsdaten vorhanden, ist die Operation bereit zur Ausführung. Die Reihenfolge der ausgeführten Operationen ist dann zufällig. Jede Operationen ist durch ein Symbol dargestellt, das wiederum Ein- und Ausgänge hat. Die Symbole werden mit Linien verbunden, die den Datenfluß zwischen den Objekten bzw. Methoden repräsentieren. Diese Verbindungen gehen über die vorgegebenen Ein-/Ausgabe Schnittstellen, an den Symbolen durch kleine Kreise gekennzeichnet. Prograph kommt bei der gesamten Programmerstellung ohne textuellen Programmcode aus. Zur Implementierung eines Programms ist ein gewisser Grundschatz an Programmsymbolen zu erlernen, die aber sehr viel weniger und sehr viel allgemeiner sind, als bei herkömmlichen Programmiersprachen. Einige Grundsymbole sind exemplarisch in Abbildung 4.1 aufgeführt, zur Vertiefung der Grundlagen sei aber auf [BP94, Car94] verwiesen. Die wichtigsten Symbole sind der Ein-/Ausgabebalken und Attribut lesen/schreiben (siehe Abbildung 4.2). Mit den Ein-/Ausgabebalken werden die Ein-/Ausgabeschnittstellen der jeweiligen Methoden spezifiziert. Das Symbol des Rechtecks mit der nach innen zeigenden Spitze steht für die Operation Attribut lesen bzw. ermitteln, die für jede Methode in Prograph automatisch generiert wird. Das Gegenstück dazu findet sich in der Operation Attribut schreiben, das ebenfalls automatisch generiert wird. Die folgenden beiden Symbole werden für die Konstantendefinition und einem Vergleich benötigt, der am Ende erläutert wird.
Konstante bzw. Vergleichswert sind in Abbildung 4.1 durch
null exemplarisch angegeben. Durch diese beiden Symbole können
z.B. Schleifen und bedingte Sprünge realisiert werden. Das letzte
Symbol bezeichnet einen Ausdruck bzw. einen Methodenaufruf und wird durch
ein Rechteck visualisiert. Generell gilt, daß die Kreise auf dem
Symbol die Eingabeparameter symbolisieren, Kreise unter dem Symbol dementsprechend
die Ausgabewerte. In Abbildung 4.3 ist die Implementierung einer Methode
Push eines Stacks angegeben, an dem die Funktionsweise von Prograph
verdeutlicht werden kann.
Die Methode bekommt zwei Eingangswerte, Element und Liste. Aus der Liste werden die Attribute value list und size extrahiert. Mit der Methode attach-l wird das neue Element an die extrahierte Liste angefügt. Durch die Anwendung der Attribut schreiben Operation auf value list wird die neue Liste übernommen.. Ähnlich wird auf der rechten Seite die Länge (size) des Stacks um 1 erhöht und wieder mit der Attribut schreiben Operation übernommen. Beide neuen Werte zusammen ergeben dann den neuen Stack. Der bereits erwähnte Vergleich und damit die Realisierung von Kontrollstrukturen in Prograph ist etwas komplizierter. Soll in Prograph ein Vergleich realisiert werden, müssen pro Methode 2 Fälle implementiert werden. In Abbildung 4.4 ist ein Kontrollfluß in Prograph verdeutlicht. Die beiden Fälle einer Methode werden dabei numeriert, es wird immer mit dem linken Fall begonnen. Zentrales Element ist hier das Vergleichssymbol, das mit einem "X" gekennzeichnet ist. Es testet den Eingangsparameter list auf die leere Liste. Ist der Vergleich wahr, so wird die Liste auch gleich ausgegeben. Schlägt der Vergleich fehl, so wird mit dem zweiten Fall ("Quicksort 2") fortgefahren. Auf die konkrete Beschreibung des zweiten Falls soll hier verzichtet werden.
Resümee
Prograph nutzt das Konzept der Datenflußdiagramme, um Programme zu erstellen und verknüpft diese mit Konzepten der objektorientierten Programmierung. Zur Programmerstellung sind keine textuellen Komponenten erforderlich, durch die Kombination der Objekte auf grafischer Basis lassen sich vollständige Programme erstellen. Prograph hat, wie die meisten visuellen Programmiersysteme, Defizite in der Darstellung, sobald man größere Programme realisieren will. Dabei kommt dem System aber die Möglichkeit der Kapselung zugute, die die Definition einzelner Unterprogramme ermöglicht. Die Darstellung ist durch die Beschränkung auf einige wenige, dafür aber in ihrer Funktionalität eindeutige Symbole übersichtlich. Die mit dem System Prograph erstellten Flußdiagramme sind somit leicht verständlich, die Namensgebung der Symbole ermittelt sich hier aus deren Funktion bzw. aus dem Objekt, auf den die betreffende Funktion angewendet wird. Leider ist in dem System die Möglichkeit für Kommentare oder Kontextbeschreibungen nicht vorgesehen.
VIPR [Visual Imperative PRogramming language][CDZ94, CZ97a, CZ97b] ist ein visuelles Programmiersystem, daß sich an der imperativ-prozeduralen Programmierung orientiert. Es kombiniert grafische Kontrollsemantik mit textuellen Ausdrücken und basiert dabei auf Tcl [Ous94]. Tcl ist eine interpretierte Skriptsprache, die so konstruiert wurde, daß man sie leicht in Programmiertools, wie Editoren, Debugger etc. integrieren kann. Das Programmiersystem VIPR läuft auf einem Power Macintosh ab System 7 oder höher. Es ist ein Beispiel für die visuelle Programmierung basierend auf einer grafischen Repräsentation von Kontrollflüssen. Der Abstraktionsgrad ist in diesem System nicht sehr hoch, Kontrollstrukturen werden zwar visuell über grafische Elemente definiert, aber einzelne Statements und Anweisungen sind noch per Hand zu editieren.
In VIPR werden einzelne Anweisungen durch Ringe dargestellt, einander enthaltene Ringe repräsentieren einen sequentiellen Programmablauf, wobei die Abarbeitungsfolge vom äußeren Ring bis hin zum innersten Ring erfolgt. Mehrere auf der gleichen Ebene liegende Ringe werden ohne spezielle Reihenfolge ausgeführt. Um dennoch den Ausführungsablauf kontrollieren zu können, enthält jeder Ring zwei wichtige Elemente, Wächter und Aktionen. An der linken oberen Seite der Ringe sind die Wächter zu finden, die eine Ausführungsbedingung für den jeweiligen Ring darstellen. Auf der rechten oberen Seite befinden sich als Ergänzung dazu die Aktion, die ausgeführt wird, wenn die Ausführungsbedingung verifiziert wurde. Sprünge werden in VIPR durch Substitutionspfeile symbolisiert, die von einem Kreis ausgehen und auf einen anderen verweisen. Der äußerste Ring dient in der vorliegenden Version von VIPR dazu, den Beginn des Programms, die Hauptprozedur, zu spezifizieren. Dieser Ring ist immer durch ein halbes Rechteck am oberen Rand gekennzeichnet.
Abbildung 4.5 zeigt ein kleines, mit VIPR erstelltes Beispielprogramm. In diesem Beispiel ist eine sequentielle Programmfolge realisiert, die eine Variable x mit dem Wert 1 initialisiert und nachfolgend zweimal inkrementiert. Die Abarbeitungsfolge erfolgt vom äußeren Ring bis hin zum innersten Ring, danach terminiert die Ausführung. Jeder Ring enthält nur ein Element, nämlich eine Aktion. Das Beispiel kommt ganz ohne Wächter aus.
VIPR unterstützt drei Grundelemente von Kontrollstrukturen, sequentielle Ausführung, bedingte Ausführung und Iteration. Die sequentielle Ausführung ist bereits durch Abbildung 4.5 verdeutlicht worden, viel interessanter jedoch sind die Möglichkeiten der bedingten Ausführung und der Iteration. Die bedingte Ausführung wird im Gegensatz zur sequentiellen Ausführung durch Ringe in der gleichen Ebene repräsentiert. Abbildung 4.6 links zeigt eine solche bedingte Ausführung. Der Wächter prüft, ob der Ausdruck gleich 1 ist. Ist der Ausdruck verifiziert dann wird in der zugehörigen Aktion die Variable y auf 2 gesetzt, ist der Ausdruck ungleich 1, wird y auf 3 gesetzt. Diese Darstellung kommt einem CASE Konstrukt einer imperativen Programmiersprache gleich. Die Ringe werden in keiner speziellen Reihenfolge auf ihre Ausführbarkeit hin untersucht, so daß durch die Wächter sichergestellt werden muß, daß immer nur die gewünschten Prozeduren bzw. Anweisungen bearbeitet werden. Abbildung 4.6 rechts zeigt eine Kombination aus bedingter und unbedingter Ausführung in VIPR. Zunächst werden die beiden linken Ringe auf ihre Ausführbarkeit geprüft, der rechte Ring wird erst bearbeitet, wenn es ihm durch den Kontrollfluß gestattet wird. Wird die Aktion einer der beiden linken Ringe ausgeführt, so ist sequentiell folgend der innere Ring als nächstes zu bearbeiten. Dieser ist aber über einen Substitutionspfeil mit einem anderen Ring verbunden, d.h. dieser wird dann abgearbeitet. Somit ist sichergestellt, daß der substituierte Ring nur dann ausgeführt wird, wenn es erfordert wird. Im Beispiel wird der rechte Ring also immer ausgeführt.
VIPR unterstützt ebenfalls die Möglichkeit der Implementierung von Iterationen (Schleifen). Dafür wird wieder der Substitutionspfeil verwendet, der einfach einen Rücksprung auf einen äußeren Ring ermöglicht, so daß eine Schleife realisiert wird. Der Wächter am folgenden inneren Ring prüft die Abbruchbedingung und stellt somit eine genau definierte Anzahl von Iterationen bzw. Schleifendurchläufe sicher. In Abbildung 4.7 ist eine einfache WHILE-Schleife realisiert. Die Variable x wird solange dekrementiert, bis sie 0 ist. Danach wird der untere Ring ausgeführt, das Programm terminiert. Weiterführend lassen sich mit VIPR auch Prozeduren mit Parameterübergaben realisieren, die zugehörigen Ringe liegen dann außerhalb des äußeren Kreises und sind von jedem Punkt innerhalb des Programms aufrufbar. Dazu erscheinen am äußersten Ring der aufgerufenen Prozedur kleine Ringe, die die Parameter visualisieren. Die gleiche Anzahl von Ringen existiert dazu an dem aufrufenden Ring [CZ97a, CZ97b].
Resümee
VIPR orientiert sich an Kontrollflußgraphen, die komplett visuell modelliert werden können. Die Bedingungen und Aktionen sind jedoch noch textuell in der Skriptsprache Tcl zu spezifizieren. Die Kommunikation von Prozeduren läuft programmintern über Variablen. Dadurch, daß VIPR-Programme in der vorliegenden Version sehr platzintensiv sind, kommt schnell eine unübersichtliche Darstellung zustande. Die kann zwar teilweise durch eine effiziente Zoomfunktion des graphischen Editors von VIPR verbessert werden, jedoch ist auch diese bei komplexeren Programmen sehr schnell überfordert. Der Platzbedarf ist also offensichtlich höher, als bei herkömmlichen imperativen Programmen, die beispielsweise in Tcl programmiert sind. Die intuitive Nachvollziehbarkeit von Programmen, die mit VIPR erstellt wurden, ist nicht sehr gut. Es wird für fast alle Arten von Operationen das gleiche Symbol genutzt, die vielen Ringe machen die Darstellung sehr unübersichtlich. Auch in diesem System gibt es keine Möglichkeit Kommentare oder Kontextdiagramme in das Programm zu integrieren.
Die Programmierumgebung Visual Pro REXX stammt ursprünglich aus dem Bereich der Programmierung von Benutzeroberflächen und wurde um ein visuelles Programmierkonzept erweitert. Dieses System läuft in der vorgestellten Version 2.11-Gold Edition unter dem Betriebssystem OS/2 Warp Connect. Grundlage dieses Programmiersystems ist die Programmiersprache REXX, die ein eingebettetes Bestandteil des OS/2 Betriebsystems ist. Der Abstraktionsgrad von VisPro REXX ist nicht so hoch, wie in den vorigen Kapiteln als Idealfall beschrieben wurde, doch lassen sich an diesem System sehr gut die Ideen der visuellen Programmierung verdeutlichen. Das Programm folgt dem alternativen Konzept zur visuellen Programmerstellung, der erweiterten Programmierung von Benutzeroberflächen (siehe Abschnitt 3.3). In diesem System gibt es verschiedene grafische Interaktionsobjekte, wie z.B. Buttons, Listen und Scrollbars, die in einem grafischen Editor frei positioniert werden können.
Zu jedem Objekt gibt es eine Menge von Eigenschaften und Funktionen, die es jeweils annehmen bzw. ausführen kann. Über diese können die einzelnen Objekte der graphischen Benutzerschnittstelle miteinander interagieren. Einfache Programme können durch visuelle Interaktionen mit dem Programmiersystem implementiert werden. Dazu plaziert der Benutzer aus einem Pool von Interaktionsobjekten die benötigten innerhalb eines graphischen Editors. Dies entspricht zunächst nur der graphischen Gestaltung der Benutzerschnittstelle und unterliegt zu diesem Zeitpunkt noch keinerlei Programmierkriterien, lediglich auf ein optisch ansprechendes Layout ist zu achten. Der eigentliche Programmfluß wird dann im zweiten Schritt über die Kontextmenüs der Interaktionsobjekte realisiert. Dazu existieren wie bereits erwähnt zu jedem Objekt eine spezifische Menge an Funktionen, die zu anderen Objekten in Beziehung gebracht werden können. Diese werden über eine Auswahlliste per Mausclick in das entsprechende textuelle Konstrukt der Programmiersprache REXX übersetzt und in die Zwischenablage kopiert. Sämtliche Aktionen, die für ein Objekt realisiert werden sollen, müssen über einen Texteditor definiert werden. Dazu braucht man aber dann nur noch die Inhalte der Zwischenablage hineinkopieren. Weiterführende und detailliertere Konstrukte müssen allerdings manuell ausprogrammiert werden.
Um dies zu verdeutlichen soll ein kleines Beispielprogramm in Form einer einfachen ToDo-Liste implementiert werden, die Einträge in ein Liste aufnehmen und wieder entfernen kann.
Das Fenster in Abbildung 4.8 enthält alle erforderlichen Elemente, die sich nach ihrer Positionierung noch weiter formatieren lassen, so sind z.B. Erscheinungsform, Größe, Vorgabeinhalt usw. einstellbar. Beispielsweise lassen sich Vorgabetext, maximale Eingabelänge, Eigenschaften bei der Eingabe oder auch die Ausrichtung einstellen. Die grafische Oberfläche des Testprogramms ist damit fertig, es fehlt noch die Funktionalität der Elemente, die das eigentliche Programm erst ausmachen. Zunächst soll daher ein Button mit der Funktion Aufnehmen ausgestattet werden. Wird der Button betätigt, soll der Eintrag aus dem Eingabefeld in die Liste eingetragen werden. Dazu öffnet man zunächst das Kontextmenü des Eingabefeldes und wählt die Operation Wert lesen aus, die auf dem Eingabefeld ausgeführt werden soll. Die ausgewählte Aktion wird in die Zwischenablage geschrieben, von der aus sie überallhin integriert werden kann.
Nun geht man in das Kontextmenü vom Aufnehmen Button uns selektiert die Option When Clicked. Es öffnet sich ein Editor, in dem man per Hand Programmcode eingeben kann, wenn man möchte. Dies ist für uns allerdings nicht erforderlich, da der für diesen Button benötigte erste Teil des Programmtextes bereits in der Zwischenablage steht. Diesen fügt man einfach ein und hat so bereits den ersten Teil der Funktion implementiert, der Wert des Eingabefeldes ist jetzt bekannt. Um die Funktion zu vollenden geht man jetzt analog zu vorigem Vorgehen in das Kontextmenü der Liste und wählt die Elementfunktion Add item. Sie ermöglicht es uns, der Liste ein Element hinzuzufügen.
Jetzt geht man wieder in das noch geöffnete Editorfenster
vom Button und fügt ebenfalls den Inhalt der Zwischenablage ein. Die
Datenübergabe zwischen den Elementfunktionen sämtlicher Objekte
des Programmiersystems ist durchgängig einheitlich über die gleiche
Variable gesteuert, so daß immer eine Schnittstelle zwischen den
aufeinanderfolgenden Aktionen existiert. Abbildung 4.9 zeigt die Einträge,
die aus obiger Vorgehensweise entstanden sind. Analog dazu geht man jetzt
vor, um den Button Entfernen mit einer Funktion zu belegen. Die
Implementierung des Buttons Aufnehmen zeigt Abbildung 4.9. Anzumerken
ist hier noch, daß die Funktionen innerhalb des Programmiersystems
für alle Interaktionsobjekte gleich sind. Lediglich eine 4-stellige
Nummer zeigt der Funktion an, um welches Objekt es sich handelt. Bei der
Plazierung eines Objekts innerhalb der grafischen Oberfläche werden
diese automatisch zugewiesen.
Auf weitergehende Konstrukte, wie z.B. der Überprüfung, ob überhaupt ein Eintrag ausgewählt ist (index=0), wurde verzichtet. Diese sind aber, wie alle anderen Elemente bequem über ein Menü auswählbar und in das Programm integrierbar. Dies betrifft hier aber nur den Rumpf des jeweiligen Konstrukts, wie z.B. von Schleifen oder Vergleichen. Die Ausprogrammierung hat dann herkömmlich per Hand zu erfolgen. Das Eingabefeld und die Liste müssen nicht näher spezifiziert werden, alle Funktionen werden über die Buttons gesteuert. Das Programm läßt sich nun innerhalb des Programmiersystems in einem Testlauf begutachten, ein Debugger hilft ggf. bei der Fehlersuche. Sind alle Fehler beseitigt, kann das eigenständig ausführbare Programm generiert werden. Die ToDo Liste ist somit fertiggestellt (siehe Abbildung 4.9 rechts), ohne daß eine Zeile Programmcode per Hand eingegeben werden mußte.
Resümee
Diese Art der visuellen Programmierung benutzt die Kontexte der Interaktionsobjekte, um die einzelnen grafischen Elemente mit Aktionen zu belegen. Alle Aktionen, die auf einem Element ausführbar sind, werden durch ein Kontextmenü verfügbar gemacht. Die Datenübergabe im gesamten Programmiersystem ist einheitlich gestaltet, so können auch komplexere Programme ohne Kenntnis der Programmiersprache implementiert werden. Weiterführende und tiefergehende Manipulationen machen jedoch eine manuelle Programmierung erforderlich. VisproREXX verzichtet ganz auf die Verwendung von Flußdiagrammen, legt den Schwerpunkt auf die Erstellung von Benutzeroberflächen mit zusätzlicher Funktionalisierung der einzelnen Interaktionsobjekte, die visuelle Programmierkonzepte nutzt. Die Nachvollziehbarkeit der mit diesem System erstellten Programme ist sehr schlecht, da der Programmfluß nicht visuell sichtbar ist. Lediglich die Benutzerschnittstelle ist sichtbar, Programmkonstrukte werden in den Kontexten der Interaktionsobjekte versteckt, wie welche Objekte miteinander kommunizieren ist nicht sofort ersichtlich.
Die herkömmlichen Anwendungsbereiche visueller Programmierung finden sich ohne Zweifel im Bereich der Systemprogrammierung, aber auch in nicht klassischen Anwendungsbereichen, wie z.B. im Bereich Multimedia lassen sich Konzepte der visuellen Programmierung nutzen. Die Erstellung von multimedialen Präsentationen ist ein Bereich der Multimedia und dient der rechnergestützten Präsentation eines Produkts oder einer Firma [Die97]. Multimedia-Systeme integrieren heterogene Medien, wie z.B. Text, Videos und Audios in einen Gesamtkontext. Einen weiteren Bereich umfassen die interaktiven multimedialen Anwendungen, wie z.B. Lernprogramme. Um solche Präsentationen und Anwendungen zu erstellen, die letztendlich nichts anderes sind als normale Computerprogramme, die verschiedene Medientypen integrieren und kombinieren, benutzt man sogenannte Autorensysteme. Versucht man sich an der Notation zu orientieren, die in den vorigen Abschnitten verwendet wurde, so kann man auch hier wieder von Symbolen mit Operationen als Beziehungen sprechen. Medientypen wie z.B. Audios und Videos oder aber Szenen und Bilder werden durch Symbole dargestellt, die wiederum zu anderen Symbolen in Beziehung stehen können. Dies kann in zeitlicher oder aber auch in nicht-zeitlicher Abhängigkeit erfolgen, was eine Aktionssteuerung bedeutet, die man z.B. durch einen Klick auf einen Button auslöst. Autorensysteme sind graphisch-interaktive Entwicklungswerkzeuge für interaktive multimediale Anwendungen [Die95] und können als Softwareentwicklungsumgebungen angesehen werden, deren spezielles Ziel die Erstellung multimedialer Anwendungen ist. Dies muß nicht zwangsläufig mit Hilfe visueller Programmierkonzepte geschehen, eine Realisierung solcher Autorensysteme kann auch grundsätzlich anderen Konzepten folgen. Im folgenden werden zwei Beispiele vorgestellt, die unterschiedliche Ansätze der Visualisierung verfolgen. FMAD ist ein Autorensystem zur Erstellung interaktiver multimedialer Anwendungen und erlaubt es, direkt mittels Flußgraphen Anwendungen zu modellieren. Der Macromind Director unterstützt ebenfalls die Erstellung von multimedialen Präsentationen und Anwendungen, orientiert sich aber bei der Modellierung dieser an einem abgewandelten Flußgraphenprinzip, einer Zeitleiste (siehe Abschnitt 3.3). Die Abstraktion bei beiden Systemen ist so hoch, daß komplette Präsentationen und Anwendungen ohne manuelle Codierungen erstellt werden können. Hier, wie auch bei den bereits vorgestellten Systemen im Anwendungsbereich der Systemprogrammierung gilt, daß man eine Verfeinerung durch manuelle Codierung treffen kann, aber nicht muß.
Das Autorensystem FMAD [Die94, Die95, Die97] (XFantasy-based
Multimedia Application Developer) dient zur Erstellung
interaktiver multimedialer Anwendungen, die als Netzwerk modelliert werden.
Zwischen Informationsbjekten (siehe Abbildung 4.10), die die einzelnen
Medientypen repräsentieren, können beliebige Beziehungen definiert
werden. Durch diese Beziehungen werden der Kontrollfluß, die optische
Gestaltung und die Interaktionsmöglichkeiten des Benutzers definiert.
Ein visueller Satz besteht in diesem System also aus Medientypen
(Objekten), die mit Beziehungen (Operatoren) verknüpft werden. Die
Implementierung von FMAD erfolgte auf der Grundlage des IMRA (Inter-
Media- Relationships via Attributes) Modells. In diesem
Modell bestehen alle multimedialen Anwendungen aus einer Menge von Informationsobjekten
und Beziehungen zwischen diesen [Die94, Die95]. Zur Visualisierung dieses
Modells werden sogenannte MR (Media-Relationship-Diagramme)
Diagramme genutzt. Die Informationsobjekte werden in solchen Diagrammen
als Rechtecke dargestellt, die jeweils in textueller Form den zugeordneten
Typ und einen eindeutigen Objektnamen enthalten. Beziehungen zwischen den
einzelnen Informationsobjekten werden durch Pfeile dargestellt, solche
Beziehungspfeile sind immer gerichtet und verbinden die Objekte
über Ports, die den Informationsobjekten zugeordnet sind. Diese
Ports sind durch kleine Rechtecke an den Informationsobjekten symbolisiert.
Dabei wird zwischen drei Arten von Ports unterschieden: Start-, Ende- und
Attribut-Ports. Pfeile hinführend zu Start- bzw. Ende-Ports, definieren
zeitliche Auswirkungen, z.B. Start oder Abbruch eines Objekts, beispielsweise
eines Videos. Pfeile, die von Start- bzw. Ende-Ports wegführen, kennzeichnen
dazu im Gegensatz zeitliche Auslöser (wiederum Start oder Ende eines
Objekts). Attribut-Ports werden zur Definition von nicht-zeitlichen Auslösungen
bzw. Auswirkungen verwendet, also sämtlichen Beziehungen, die nicht
über die Start-/Ende-Ports definiert werden können. So lassen
sich sämtliche Beziehungen zwischen Objekten und der Zugriff auf deren
Attribute definieren. Nicht-zeitliche Auslösungen können z.B.
durch Interaktionsobjekte initiiert werden, die in keinem zeitlichen Kontext
innerhalb des Programms stehen. Typisches Beispiel hierfür wäre
ein Button, der eine Aktion o.ä. auslöst. Dabei wird diese Auslösung
wieder über die schon beschriebenen Start-/Ende-Ports realisiert.
Abbildung 4.11 zeigt die Benutzerschnittstelle von FMAD auf der einige
Informationsobjekte mit Beziehungspfeilen verknüpft sind (mitte).
Links oben sind alle für die Anwendung verfügbaren Medienobjekte
aufgeführt, die bei Bedarf im Eingabe-Editor plaziert werden können.
Im Fenster links-unten läßt sich die Komplette Anwendung abspielen,
bzw. als Vorschau begutachten.
Resümee
FMAD nutzt grafische Flußdiagramme zur Visualisierung des Programmflusses bei der Erstellung von interaktiven multimedialen Anwendungen. Sämtliche Informationsobjekte können über ihre Ports mit anderen Informationsobjekten in Beziehung gesetzt werden. Hierüber lassen sich die optische Gestaltung der Anwendung und die Eingriffsmöglichkeiten der Benutzer aber auch der Kontrollfluß innerhalb der Anwendung definieren. Komplette Anwendungen können realisiert werden, ohne manuellen Programmcode eingeben zu müssen, jedoch können detaillierte Konstrukte über die Attributbelegungen manuell definiert werden, womit sich dann auch Kontrollstrukturen realisieren lassen. Die Darstellung verschiedener Medientypen werden auch durch verschiedene Symbole repräsentiert, so daß hier sofort ersichtlich ist, um welchen Typen es sich handelt, oder welches Interaktionsobjekt zu einem Medientypen in Beziehung steht.
Das Autorensystem Macromind Director [Mac92] läuft
in der vorliegenden Version 3.1.1D auf einem Power Macintosh ab System
7 oder höher. Mit Hilfe dieses Werkzeuges lassen sich komplette multimediale
Präsentationen nahezu beliebiger Form erstellen. Dabei richtet sich
das Programm in seiner Handhabung nach einem Prinzip, das aus der Theaterwelt
entliehen wurde. Durch eine Regie werden Akteure auf einer Bühne gelenkt.
Dies intuitiv leicht verständliche Prinzip ermöglicht es, ohne
Vorkenntnisse schnell auch komplexere Präsentationen zu erstellen,
die auch um interaktive Elemente wie z.B. Eingabefelder und Buttons erweitert
werden können. Abbildung 4.12 zeigt ein Beispiel einer Entwicklungsumgebung
des Macromind Director. Sie besteht aus 4 Komponenten, Szene, Regie,
Besetzung und Steuerpult. Am unteren Rand in Abbildung 4.12
befindet sich die Besetzung in der alle Elemente aufgelistet sind, die
in der Präsentation vorkommen. In Abbildung 4.12 ist unter anderem
der Schriftzug "Test" als ein solcher Akteur erkennbar. Solche Elemente
werden als Akteure bezeichnet. Von hier aus können sie per
Maus in eine beliebige Szene gezogen werden. Ändert man das Aussehen
der Akteure in der Besetzung, so ändern sich automatisch auch ihre
Vorkommen in den einzelnen Szenen. Eine Szene besteht aus einem Bild, in
das auch Sequenzen wie Videos oder Audios integriert werden können.
In Abbildung 4.12 ist eine Szene eine Zelle in der erkennbaren Matrix.
Der komplette Ablauf und die Kombination aller Elemente wird über
die Regie gesteuert. Eine Präsentation ist in aufeinanderfolgende
Szenen untergliedert, die in Abbildung 4.12 als Matrix zu erkennen
sind. Die Zeilen dieser Matrix markieren die zeitliche Abfolge der einzelnen
Szenen, alle Szenen der gleichen Spalte werden parallel ausgeführt.
Eine solche Szene kann per Maus ausgewählt werden und erscheint dann
in voller Größe im Hintergrund. In der vorliegenden Version
können bis zu 24 Objekte gleichzeitig, d.h. parallel bewegt bzw. animiert
werden. Dazu liegt jede Szene in einer Spur (Zeile der Matrix), von der
es dementsprechend 24 Stück gibt. In der Abbildung (Regie unten) sind
die Spuren 1 bis 3 erkennbar, wobei Spur 3 nicht belegt ist..
Die Spuren 1 und 2 enthalten jeweils 20 Szenen, die in diesem Fall einfache Bilder sind. Jetzt kann die ausgewählte Szene mit Akteuren aus der Besetzung ausgestattet werden. Dies geschieht nach dem Muster eines graphischen Editors, alle Akteure sind frei positionierbar, so daß man z.B. bei aufeinanderfolgenden Szenen eine Illusion von Bewegung erzeugen kann. Darüber hinaus ist für eine detailliertere Programmierung die Möglichkeit der Definition von Skripten für jede Szene gegeben, die es erlauben ein z.B. differenziertes Verhalten von Interaktionsobjekten mittels einer einfachen Skriptsprache zu steuern. Zusätzlich zu den 24 Objektspuren existieren noch 4 weitere, die für die Einbindung von Klangeffekten, Spezialeffekten, Farbdefinitionen und Zeitzuweisungen pro Szene genutzt werden können. Diese befinden sich über den Spuren innerhalb der Regie angeordnet. Die gesamte Präsentation läßt sich abschließend über das Steuerpult abspielen.
Resümee
Der Macromind Director bedient sich bei der Erstellung von Präsentationen einer abgewandelten Form von Flußgraphen, einer Zeitleiste. Elemente werden in einer Szene plaziert, die wiederum in Spuren angeordnet werden. Diese Spuren repräsentieren den Fluß in der Präsentation, der durch die Zeit gesteuert werden kann. Legt man dies zugrunde, so läßt sich eine solche Art der Programmierung wohl in den Bereich der Kontrollflußdiagramme einordnen. Durch die Skripte lassen sich zusätzlich noch Sprünge in die Präsentationen einbauen, ein weiterer wesentlicher Punkt des Kontrollflusses. Die Nutzung der Konzepte visueller Programmierung beschränkt sich in diesem System auf eine zeitliche Anordnung von Szenen. Diese Anordnung, wie auch die Definition der Szenen selbst, ist über einen graphischen Editor modellierbar. Der Ablauffluß ist, sobald Sprünge über Skripte eingebracht werden, nicht mehr sofort erkennbar, da sich die Darstellung auf die chronologische Abfolge der einzelnen Szenen beschränkt und Skripte in dieser Darstellung nicht angezeigt werden, sondern nur im Kontext der Szenen untergebracht werden.
Der Bereich Workflow umfaßt die Vorgangsverarbeitung eines Unternehmens. Solche Vorgänge bestehen aus Geschäftsprozessen, die in einer fest definierten Reihenfolge bearbeitet werden. Visuelle Programmierkonzepte lassen sich hier insofern nutzen, daß man Geschäftsprozesse mit Hilfe grafischer Elemente modellieren kann. Den so grafisch erstellten Ablauf kann man später ablaufen lassen, er steuert dann den Workflow für den modellierten Bereich des Unternehmens. Um dies verdeutlichen zu können, wird das SAP R/3 Business Workflow System [Bah95, Föc95] kurz vorgestellt, daß eben diese Funktionalität innerhalb einer Organisation, die mit SAP R/3 arbeitet, zur Verfügung stellt.
In Bereich Workflow wird in drei Hauptbereiche unterschieden, Organisationsmodell, Prozeßmodell und Objektmodell, auf deren Erklärung hier nur kurz eingegangen wird, da nur die visuell unterstützte Modellierung mit anschließender Ausführung im Mittelpunkt stehen soll. Weiterführende Literatur zu diesem Thema findet sich in [SAP94, Öst95]. Das hier vorgestellte System SAP R/3 mit seiner integrierten Komponente Business Workflow [SAP94] setzt auf diesen drei Modellen auf und ermöglicht es mit Hilfe eines graphischen Editors, Geschäftsprozesse zu modellieren. Im Organisationsmodell werden dazu alle Elemente in Organisationseinheiten zusammengefaßt, die an einem Geschäftsprozeß beteiligt sind, wie z.B. Stellen oder Planstellen. Diesen Organisationseinheiten sind Aufgaben zugeordnet, die für die Modellierung von Geschäftsprozessen wichtig sind. Innerhalb des Prozeßmodells werden Kontroll- und Datenfluß definiert, indem einzelne Aufgaben zu Geschäftsprozessen verknüpft werden. Sie sind eine Folge von Transaktionen zwischen betrieblichen Objekten und ihre Arbeitsschritte beziehen sich dabei nicht direkt auf ein Anwendungsprogramm, sondern auf eine Aufgabe einer Organisationseinheit aus dem Organisationsmodell. Die eigentliche Implementierung der Arbeitsschritte eines Geschäftsprozesses erfolgt dann innerhalb des Objektmodells, in dem Objektdefinitionen die für die Vorgangssteuerung relevanten Informationen (Attribute) enthalten. Eine Objektdefinition enthält die dafür benötigten Methoden und Ereignisse [Föc95]. Neben allen sonstigen Aspekten, die unter SAP R/3 und der Business Workflow Komponente definiert und modelliert werden müssen, kann über einen Workflow-Editor die eigentliche Workflow-Definition erfolgen.
Eine Workflow-Definition ist die Implementierung eines
Geschäftsprozesses [SAP94, Föc95]. Der Workflow-Editor ist ein
grafisches Modellierungswerkzeug, mit dem der Prozeßverlauf auf Basis
ereignisgesteuerter Prozeßketten (EPK) dargestellt wird [Föc95].
Abbildung 4.13 zeigt einige Elemente einer solchen EPK. Die Modellierung
mit Hilfe des Editors zeichnet sich dadurch aus, daß ein grafisches
Symbol für jede Art von Funktion/Ereignis (siehe Abbildung 4.13) verwendet
wird.
Jeder Funktion in einer Workflow-Definition hat
immer mindestens ein Ereignis zu folgen, die die Beendigung der
vorausgegangenen Funktion in Abhängigkeit von den möglichen Ergebnissen
dieses Schrittes beschreibt [94, Föc95]. Die Anordnung von Schritten
erfolgt immer blockorientiert. Innerhalb eines Blockes ist eine in sich
konsistente Abfolge von Funktionen und Ereignissen zusammengefaßt.
Ein Block besitzt genau einen Ein- und einen Ausgang. Weitere wichtige
Symbole sind die Verknüpfungsoperatoren, die die logischen Verbindungen
zwischen Ereignissen und Funktionen beschreiben. In Abbildung 4.13 sind
die Operatoren für Exklusiv-Oder, Und und Oder
zu sehen. Das Kontrollflußsymbol wird durch einen gestrichelten Pfeil
symbolisiert und beschreibt die zeitlich logischen Abhängigkeiten
von Ereignissen und Funktionen. Der Informations- und Materialfluß
beschreibt, auf welche Art und Weise von einer Funktion auf Daten zugegriffen
wird. Dabei wird in lesen, ändern und schreiben differenziert.
Die Einheiten-Zuordnung beschreibt lediglich, welche Einheit (meist Mitarbeiter des Unternehmens) die jeweilige Funktion bearbeitet. In Abbildung 4.14 [SAP94] ist der modulare Aufbau einer Workflow-Definition schematisch angedeutet. Diese Abbildung enthält zusätzlich die Markierung einiger Kontrollstrukturen, wie CASE, IF und eine Schleife. Das Beispiel besteht aus einer Kombination von Funktionen und Ereignissen, teilweise verbunden mit Verknüpfungsoperatoren. Erkennbar sind drei parallel laufende Prozesse, die am Ende wieder zusammengeführt sind. Zu jeder Funktion sind zusätzlich noch organisatorische Einheiten zugeordnet, die diese Funktion realisieren. Diese Zuordnungen fehlen in der Abbildung, sie werden durch Ellipsen dargestellt und über das Einheit-Zuordnungs-Symbol miteinander verbunden.
Resümee
Das SAP R/3 Business Workflow nutzt einen graphischen Editor, um Geschäftsprozesse mit Hilfe von einfachen Symbolen in Form von Flußgraphen zu modellieren. Das System kommt vollständig ohne manuelle Programmtexte aus, da sich das gesamte System auf einem sehr hohen Abstraktionsgrad bewegt. Sämtliche Definitionen werden über visuelle Symbole modelliert. Unterstützt werden dabei die Methoden des Daten- und des Kontrollflusses, um Geschäftsprozesse als ereignisgesteuerte Prozeßketten zu definieren. Datenflüsse bestehen innerhalb der Prozeßketten in Form von Informations- und Materialflüssen.
Nachdem in den vorigen Abschnitten sechs Beispiele für visuelle Programmiersysteme in unterschiedlichen Anwendungsbereichen behandelt wurden, die sich alle mehr oder weniger an visuellen Programmierkonzepte orientieren, sollen hier kurz in tabellarischer Form die wichtigsten Merkmale der verschiedenen Systeme aufgeführt werden.
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
Die wesentlichen Elemente visueller Programmierung ist die Basierung sämtlicher vorgestellter Systeme auf den Datenfluß und Kontrollfluß Konzepten. Lediglich im Bereich Multimedia kommt die alternative Form des Zeitflusses zum tragen, der eine strenge chronologische Abfolge einzelner Programmschritte gewährleistet. Abstraktion meint, daß der Anwender keine oder nur wenig Kenntnisse von der zugrunde liegenden Programmiersprache des Systems haben muß. Die Abstraktion steht in der obigen Tabelle für jeweils zwei komplementäre Werte pro System. Eine hohe Abstraktion beinhaltet, daß die Notwendigkeit der Einbringung von manuell erstelltem Programmcode sehr gering ist. Dementsprechend ist die Notwendigkeit bei Systemen mit einer geringen Abstraktion sehr hoch, meist sogar unbedingt erforderlich. Die Bezüge zur Anwendungs- bzw. Programmierorientierung leiten sich aus der zugehörigen Definiton in Abschnitt 2.2.1 ab.
In den vorangegangenen Kapiteln 1 und 1 ist ausführlich auf die visuelle Programmierung und die zugehörigen Konzepte eingegangen worden. In Kapitel 1 wurde veranschaulicht, wie sich verschiedene visuelle Programmiersysteme in unterschiedlichen Anwendungsbereichen Konzepte visueller Programmierung nutzbar machen. In dem nun folgenden Kapitel soll untersucht werden, inwiefern die in dieser Arbeit erarbeiteten Konzepte visueller Programmierung auf den Anwendungsbereich der Datenanalyse übertragbar sind. 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. In einem der Datenanalyse entstammenden Anwendungsbereich, die deskriptive Epidemiologie, ist bereits im Rahmen des Projekts CARLOS (Cancer Registry Lower-Saxony) [AFH+96] die EPI-Workbench [Wie94] entstanden. Dieses System erlaubt es, mit Hilfe eines graphischen Editors Verfahren zu modellieren, die dann auch ausgeführt werden können. Um dieses System innerhalb seines Anwendungsbereichs verstehen zu können, erfolgt zunächst in Abschnitt 5.1 eine Einführung in die Datenanalyse. Dabei wird auf die explorative Datenanalyse und einen ihrer Anwendungsbereiche, die deskriptive Epidemiologie eingegangen. In Abschnitt 5.2 erfolgt dann die Vorstellung der EPI-Workbench, wobei dort das System soweit unter die Lupe genommen wird, daß alle in ihr enthaltenen visuellen Programmierkonzepte verdeutlicht werden. In Abschnitt 5.3 werden alle bisher in dieser Arbeit gesammelten Erkenntnisse für eine Erweiterung des Systems genutzt. Insbesondere kommen dort auch die Punkte zum Tragen, die bei der Evaluation der verschiedenen visuellen Programmiersysteme in Kapitel 1 innerhalb der Resümees bemängelt wurden. Abschnitt 5.4 bietet dann zum Abschluß dieses Kapitels einen Ausblick, in welche Richtung sich die EPI-Workbench entwickeln kann.
Nach der zuletzt stark gestiegenen Leistungsfähigkeit von Computersystemen sind diese aus dem Bereich der Datenerfassung nicht mehr zu entbehren. Riesige Datenmengen können in Datenbanken erfaßt werden und auf diese kann man dann in angemessener Zeit zugreifen [Liu96]. Der Anwendungsbereich Statistik muß naturgemäß mit großen Datenmengen umgehen können, sodaß sich der Einsatz von Computern in diesem Bereich geradezu anbietet. Die Statistik an sich umfaßt lediglich Verfahren zur Handhabung von Zahlendaten und dient der Auswertung und Beschreibung [Har95] von Daten, die durch Experimente oder Erhebungen zu einem Thema systematisch ermittelt wurden [Wie94]. So lassen sich Daten auf konkrete Fragestellungen hin untersuchen und beschreiben. Der Kern liegt dabei in der Aufbereitung vorhandenen Datenmaterials sowie deren Analyse und Beurteilung, um daraufhin Schlüsse ziehen und Entscheidungen treffen zu können. Diese so aber ohne jeglichen Kontext gespeicherten Daten können sehr viel mehr Informationen enthalten, als nur ihre eigentlichen Werte. Diese Informationen zu ermitteln, ist die Aufgabe eines Spezialgebietes, das sich u.a. aus der Statistik entwickelt hat, die Datenanalyse. Sie bedient sich sowohl der Verfahren aus der Statistik als auch aus anderen Anwendungsgebieten, wie z.B. der Informatik. Die Datenanalyse bezeichnet dabei den Prozeß, während die Statistik die dazu benötigten Werkzeuge bietet. Eine exakte Abgrenzung zwischen diesen beiden Gebieten ist kaum zu treffen, oft werden beide Begriffe, Statistik und Datenanalyse, sogar synonym verwendet. 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 Datenmengen aufgedeckt werden, die aufgrund von Umfang oder Komplexität der vorliegenden Daten nicht direkt erkennbar sind. Um diese versteckten Informationen gewinnen zu können, kann man sich an ein generelles Ablaufschema der Datenanalyse in Anlehnung an [Jam92] halten. Es setzt sich aus folgenden Teilschritten zusammen:
Explorative Datenanalyse
Der Begriff explorative Datenanalyse (EDA) wurde in den sechziger Jahren von J.W. Tukey geprägt, um innerhalb der Statistik ein Aufgaben- und Methodenspektrum und eine Vorgehensweise zu charakterisieren [Boc92]. Aufgabe der EDA ist es, alle Strukturen, Beziehungen, Abhängigkeiten, Auffälligkeiten und Besonderheiten herauszufinden, die in einem Datensatz vorhanden sind und die charakteristische Eigenschaften der betrachteten Datenmenge widerspiegeln [Boc92, Liu96]. Ziel der explorativen Datenanalyse ist es, durch effektive Datenbetrachtung Neues zu entdecken und nicht bereits vorhandene Vermutungen zu bestätigen. Ein wesentlicher Vorteil der EDA gegenüber den Verfahren der Datenanalyse ist die Möglichkeit, unerwartete Zusammenhänge und Strukturen innerhalb des vorhandenen Datenmaterials zu entdecken. Dies resultiert aus der Tatsache, daß die Daten nicht von vornherein nur auf bestimmte Hypothesen hin untersucht werden, wie es bei den herkömmlichen Verfahren der Fall ist. Dadurch können möglicherweise wichtige Informationen verloren gehen [Wie94].
In [Wol92] findet sich ein Zyklus über die konzeptionelle Vorgehensweise in der EDA (siehe Abbildung 5.1). Einen Einstiegspunkt in den Zyklus bietet die Analyse der Ausgangslage und Anfangsprobleme, denn daraus lassen sich Fragestellungen über die Strukturen und Zusammenhänge der betreffenden Daten ableiten. Sind diese formuliert, entwickelt man eine darauf abgestimmte Erwartungshaltung und wählt ein geeignetes Verfahren der EDA, das im Anschluß aktiviert wird. Hier läßt sich allerdings kein klarer Trennstrich, ziehen, denn eine Erwartungshaltung bildet sich meist schon sehr viel früher, beispielsweise ist die Entwicklung einer Fragestellung wohl kaum ohne eine gewisse Erwartungshaltung möglich. Während und nach der Beobachtung der resultierenden Werte erfolgt eine Beurteilung und Interpretation der Ergebnisse. An diesem Punkt wird dann entschieden, ob die Resultate ausreichend sind oder sich evtl. neue Ideen bezüglich des Datenmaterials entwickelt haben. Zentraler Punkt der explorativen Datenanalyse ist die sich daran anschließende Wiederholung des Zyklusses, da die Besonderheiten oder Eigenschaften des zugrunde liegenden Datenmaterials erst nach der Betrachtung der Daten erkannt werden und nicht vorher durch die Annahme einer Hypothese bestimmt werden.
Deskriptive Epidemiologie
Die deskriptive Epidemiologie ist ein typischer Anwendungsbereich für die explorative Datenanalyse [Wie94]. Die Epidemiologie an sich ist die Wissenschaft von der Entstehung und Verbreitung übertragbarer Krankheiten aber auch nichtinfektiöser zeittypischer Massenerkrankungen und Zivilisationsschäden. Dies betrifft beispielsweise Herzinfarkte, Diabetes oder Krebs [Mey87]. Sie entwickelt und definiert Verfahren, um Fragestellungen der Medizin und gesundheitliche Sachverhalte beschreiben zu können [Wie94]. Eine zeitgemäßere Umschreibung bezieht auch das Zusammenwirken von unterschiedlichen Disziplinen ein. Danach ist die Epidemiologie der Bereich, der die Fragen der Medizin und der Gesundheitswissenschaften mittels Methoden aus Statistik und anderen Disziplinen bearbeitet [HBL93]. Die deskriptive Epidemiologie beschreibt dann den Zustand und die Entwicklung von Krankheiten in Bezug auf die Verteilung und Häufigkeit. Aber auch Eigenschaften und Ausmaß der Krankheiten insbesondere in Zusammenhang mit Einflußfaktoren werden beschrieben. Dazu bedient sie sich einer Vielzahl von Größen und Verfahren, die hier nicht weiter erläutert werden. Bei den innerhalb der Epidemiologie gewonnenen Datensätzen ist es oft sehr viel angebrachter, das Datenmaterial nach Auffälligkeiten und Zusammenhängen zu untersuchen, als dieses mit einer vorher zugrunde gelegten Hypothese zu verifizieren. Diese Vorgehensweise bietet sich hier an, weil man über erhobene Daten, die Krankheiten in verschiedenster Form beschreiben, Zusammenhänge herausfinden möchte. Die Zusammenhänge werden nicht vorher über eine Hypothese formuliert, sondern erst durch die Betrachtung der Daten ermittelt.
Das System EPI-Workbench [Wie94] entstand im Rahmen des Projektes CARLOS und ermöglicht die visuelle Modellierung (Programmierung) und Durchführung deskriptiver epidemiologischer Untersuchungen. Es läuft unter dem UNIX-Betriebssystem SunOS 4.1.3 und verwendet einige Konzepte visueller Programmierung, die im folgenden genauer beschrieben werden. Allgemein handelt es sich bei der EPI-Workbench um einen graphischen Editor, mit dem ein epidemiologisches Verfahren durch ein Netz von Symbolen und Verbindungen modelliert werden kann, den visuellen Sätzen dieses Systems. Jeder Knoten repräsentiert die Anwendung einer Methode einer speziellen Verfahrensklasse auf ein oder mehrere Datensätze. Dabei basiert das System auf dem Datenflußkonzept, Ansätze von Kontrollfluß sind aber auch vorhanden und werden später erläutert.
Generell gilt für alle Symbole bzw. Knoten, daß Dateneingänge durch die kleinen Quadrate auf der linken Seite eines jeden Objekts dargestellt werden, Datenausgänge durch Quadrate auf der rechten Seite. Alle Knoten können untereinander verbunden werden. Die Verbindungen zwischen den Knoten repräsentieren den Datenfluß von den Ausgängen einer Methode zu den Eingängen einer anderen. Dabei können durchaus mehrere Datenquellen auf verschiedene Eingänge des Symbols zeigen, die dann auch über verschiedene Ausgänge weitergeleitet werden können (siehe Abbildung 5.2 links). Dies bewirkt eine Parallelität innerhalb des Datenflusses, indem Paare von Ein- und Ausgängen verschiedene Datenströme mit dem gleichen Verfahren bearbeiten. Ausgangspunkt von allen mit der EPI-Workbench modellierten Netzen ist eine oder mehrere Datenquellen, die auf die oben beschriebene Vorgehensweise mit den anderen zur Verfügung stehenden Symbolen über Verbindungslinien miteinander verknüpft werden können. Abbildung 5.2 zeigt den graphischen Editor, in dem exemplarisch ein Beispielverfahren modelliert wurde. Es wird verwendet, um aus Mortalitätsdaten eine Tabelle mit Fallzahl, Bevölkerung, roher Rate und zwei alters- und geschlechtsstandardisierten Raten in den fünf Spalten und den betrachteten Landkreisen in den Zeilen zu erzeugen. Der linke Teil des Netzes selektiert die interessierenden Altersgruppen, Geschlecht und Zeitintervall, während der rechte Teil die verschiedenen Maßzahlen berechnet [Wie94].
.
Bisher stehen fünf Klassen von Methoden zur Verfügung, visualisiert durch verschiedene Symbole, mit denen man epidemiologische Untersuchungen modellieren kann. Die Erweiterbarkeit des Systems ermöglicht aber eine Ergänzung dieser Methoden um weitere Verfahren oder insgesamt die Erweiterung des gesamten Systems um weitere Verfahrensklassen. Eine Datenquelle bezeichnet beispielsweise eine Datenbank, aus der das zu bearbeitende Datenmaterial bezogen wird. Mit Hilfe des Datenmanagements können Datensätze durch bestimmte Verfahren eingeschränkt und aggregiert werden. Eine Standardisierung ermöglicht den Vergleich von Datensätzen, die beispielsweise nach der Altersstruktur einer Studienpopulation vorgenommen werden könnte. Sie repräsentiert eine Klasse von Analyseverfahren in der Epidemiologie - prinzipiell nichts anderes als Maßzahlenberechnungen. Schließlich folgt die Visualisierung eines oder mehrere bearbeiteten Datensätze.
Jeder Knoten repräsentiert eine Menge von Verfahren, die über ein Kontextmenü des jeweiligen Knotens näher definiert werden können. Dort können sie ausgewählt und näher über evtl. vorhandene Parameter spezifiziert werden. Der Name der ausgewählten Methode erscheint dann unterhalb des Symbols. Die dort resultierten Daten können wiederum über Datenmanagement-Knoten weiter verarbeitet werden oder über Standardisierungen zur Ausgabe (Visualisierung) geführt werden.
Neben dem Datenfluß ist ebenfalls eine Kontrollfluß-Modellierung innerhalb der Erstellung eines Verfahrens möglich. Die EPI-Workbench besitzt zwei verschiedene Modi, es wird unterschieden zwischen Modellierung und Propagierung. Im Modellierungs-Modus kann das Netz innerhalb des graphischen Editors modelliert werden, ohne daß Kontrollen vom System vorgenommen werden. Der Propagierungs-Modus (siehe auch Abschnitt 5.3.2) gewährleistet dann die Berechnung der Daten. Dies geschieht zum einen, sobald ein neuer Knoten zum Netzwerk hinzugefügt wurde, zum anderen, wenn die Modi gewechselt oder aber Parameter der einzelnen Methoden geändert werden. Dafür werden dann für alle Verfahren Anwendbarkeitstests durchgeführt, die die Anwendbarkeit der Methode im Kontext prüft. Dabei werden eingehende Kanten farbig markiert, sobald sie keine Daten propagieren oder dies nur schlecht tun, da die Methode auf die eingehenden Daten nicht oder nur eingeschränkt anwendbar ist. Dieser Propagierungs-Modus dient zur Berechnung der Daten, von den Datenquellen bis hin zur Visualisierung. Durch diese Art der Unterstützung soll der Benutzer eine Hilfe erhalten, ob die Verfahren, die er gerade eingefügt hat, sinnvoll sind oder besser andere zu verwenden sind. Dabei ist jedem Verfahren ein oder mehrere Anwendbarkeitstests zugeordnet, die für den Benutzer weder sichtbar noch editierbar sind.
Man kann sich diese Eigenschaft allerdings auch anders nutzbar machen. So sind z.B. auch direkte Verzweigungen realisierbar, die im Anwendungsbereich der Systemprogrammierung als IF-THEN-ELSE Konstrukte bezeichnet werden. Dies kann man realisieren, indem man z.B. einen Datenausgang mit zwei oder mehr verschiedenen Eingängen mehrerer Knoten verbindet. Dabei muß dann gewährleistet sein, daß nur die Datenausgänge der verschiedenen Knoten die geforderten Daten propagieren, von denen es auch gemäß dem Programmablauf erwartet wird. Das ganze ist aber nur ein Nebeneffekt des Propagierungs-Modus der EPI-Workbench.
Die Erweiterung der EPI-Workbench läuft bisher vollständig ohne Verwendung von visuellen Programmierkonzepten, die z.Zt. vorhandenen Knoten und damit auch die zugrunde liegenden Methoden sind nur durch eine C++ Anbindung erweiterbar. Dabei folgt das System generell dem Prinzip der objektorientierten Programmierung. Die als Symbole innerhalb des Netzes visualisierten Knoten repräsentieren die Klassen, wobei die Verfahren innerhalb dieses Knotens die Instanzen der jeweiligen Klassen sind.
Resümee
Die EPI-Workbench beschränkt sich in der Benutzung visueller Programmierkonzepte auf die Nutzung von Datenflußgraphen. Dies geschieht jedoch in einer so hohen Abstraktion, daß keine weiteren manuellen Programmtexte oder Methodendefinitionen vorgenommen werden müssen. Allerdings gilt das nur, soweit man die vordefinierten Methoden des Systems nutzt. Bei eventuellen Erweiterungen, für die das System durchaus vorbereitet ist, werden vertiefte Kenntnisse über die Programmiersprache C++ notwendig. Dabei kommt dem Benutzer aber der modulare Aufbau des Systems entgegen, sodaß einzelne Bausteine leicht hinzugefügt oder redefiniert werden können. Ansatzweise ist auch die Möglichkeit des Kontrollflusses integriert. Große Probleme gibt es mit diesem System, wie auch in allen bisher vorgestellten Systemen, sobald aufwendigere Netze modelliert werden sollen. Die Übersichtlichkeit nimmt stark ab, eine Möglichkeit innerhalb des Systems zu zoomen oder weiter zu abstrahieren fehlt ebenfalls. Desweiteren fehlt die Möglichkeit, wie auch in allen anderen vorgestellten Systemen, Kontexte und/oder Kommentare in diesen Netzen unterzubringen.
Die vorgestellt EPI-Workbench ist ein System, das innerhalb der Datenanalyse im Bereich der deskriptiven Epidemiologie Konzepte visueller Programmierung nutzt, um Untersuchungen in diesem Bereich zu vereinfachen. Zentrales Element ist dabei der graphische Editor. Die bereits in der EPI-Workbench realisierten Konzepte visueller Programmierung sowie einige Eigenheiten, die im vorigen Abschnitt bereits beschrieben wurden, sollen hier noch einmal stichpunktartig aufgeführt werden, bevor dann im folgenden über eine Erweiterung nachgedacht wird.
Unter dem Begriff Abstraktion sollen hier einige Erweiterungen erarbeitet werden, die das in dieser Arbeit bereits behandelte Screen Space Problem (siehe Abschnitt 2.2.2) und die damit verbundenen Defizite verbessern können. Zur Lösung diese Problems sollen die Konzepte der Verschmelzung und des Zoomens erarbeitet werden. Wie ebenfalls in [Wie94] angemerkt, ist die EPI-Workbench bei der Modellierung von Studien typischer Größe besagter Problematik unterlegen. Es ist zwar möglich, die jeweils betreffenden Symbole/Methoden per scrolling in den Fokus zu holen, somit ist aber die Verschaffung eines Gesamtüberblicks um so schwerer, je mehr Symbole im Netzwerk verwendet werden. Eine Verkleinerung der Symbole und/oder die Anpassung von Bildschirmauflösungen sind dabei zwar sehr einfache, keinesfalls aber zufriedenstellende Lösungsansätze. Einen weiteren Ansatz bietet die ebenfalls in dieser Arbeit kurz beschriebene Einbeziehung mehrerer (meist 3) Dimensionen (siehe Kapitel 1) zur Modellierung von Verfahren, jedoch ist damit auch hier keineswegs gewährleistet, daß größere Netzwerke übersichtlicher werden.
Verschmelzung von Teilnetzen
Sehr viel interessanter wäre allerdings die Möglichkeit, ganze Teile des Netzwerks zu verschmelzen. Dabei ist dann ein so entstandener neuer Knoten nichts anderes, als eine Zusammenfassung verschiedener Methoden. Dies macht evtl. eine Überarbeitung und Erweiterung der im graphischen Editor verfügbaren Symbole notwendig. Somit muß dann auch die Benutzerschnittstelle des graphischen Editor selbst erweitert werden. Zusätzlich soll mit der Verschmelzung die Technik des zoomens kombiniert werden, die durch Vergrößerung bzw. Verkleinerung die Abstraktionsebene der Detailtiefe variiert.
Um die Funktion des Verschmelzens in den bereits bestehenden Editor zu integrieren, verfährt man mit der Modellierung des Teil des Netzwerkes, das zusammengefaßt werden soll, wie bisher. Dabei ist lediglich darauf zu achten, daß eine Zusammenfassung eines in sich konsistenten Netzwerkteils erfolgt. Dazu ist ggf. die bereits bestehende Anwendbarkeitsanalyse so zu modifizieren, daß sich auch Teile eines modellierten Verfahrens verifizieren oder falsifizieren lassen und nicht nur das Gesamtsystem. Um nun Knoten zusammenfassen zu können, ist z.B. ein variables Viereck denkbar, daß sich mit der Maus frei positionieren und in der Größe ändern läßt. Mit diesem Viereck werden dann die betreffenden Symbole umgeben, die zusammenzufassen sind. Die angepaßte Benutzerschnittstelle muß dann dafür eine Funktion zur Verfügung stellen, die die umgebenen Knoten verschmilzt und einen neuen Knoten erstellt. Die Funktion der Verschmelzung muß natürlich auch in der umgekehrten Richtung ausführbar sein, aus einem Knoten muß das darin enthaltene Netzwerk extrahierbar sein. Ein so entstandener neuer Knoten hat dann die gleiche Anzahl eingehender und ausgehender Kanten, wie das verschmolzene Teilnetzwerk. Die Durchführung wird aber zeigen, daß die strickte Beibehaltung der Kantenanzahlen auf Probleme stoßen wird, die u.a. durch Aggregationen gelöst werden können.
Zu beachten ist dabei, daß es sich nicht um einen normalen Knoten handelt und somit auch ein eigener Anwendbarkeitstest erforderlich ist. Dieser läßt sich am einfachsten realisieren, indem man die einzelnen Anwendbarkeitstests der verschmolzenen Knoten nacheinander anwendet. Jeder Knoten innerhalb der Verschmelzung hat aber seine eigenen, mitunter nur für ihn gültige Anwendbarkeitstests. Hier ist also eine Gewichtung zu finden, die alle Tests des verschmolzenen Teilnetzwerks zueinander in Beziehung setzen. Eventuell mag es sogar reichen, lediglich die Knoten des Teilnetzes zu testen, die unmittelbar mit den Eingängen des verschmolzenen Knotens verbunden sind. Propagieren diese keine Daten, so können zwar die folgenden Knoten generell anwendbar sein, dennoch werden auch sie keine Daten propagieren, so daß man sich die Tests der folgenden Knoten sparen kann. Eine andere Lösung wäre die Neudefinition eines Anwendbarkeitstests für einen Verschmelzungs-Knoten. Dieser Ansatz wird näher in Abschnitt 5.3.2 behandelt.
Je mehr solcher Verschmelzungen man aber nun in ein Netzwerk einbringt, desto schwerer ist das gesamte Verfahren noch nachzuvollziehen, die Funktion einzelner Knoten ist dann nicht mehr unbedingt ersichtlich. Dazu sollte es dann auch möglich sein, den Inhalt (Netzwerk) eines Knotens visualisieren zu können. Dies kann in unterschiedlicher Form erfolgen. Die wohl einfachste und übersichtlichste Möglichkeit ist, das im Knoten enthaltene Teilnetzwerk in einem eigenen Fenster anzuzeigen. Als Erweiterung dazu sollte man Überlegungen einbeziehen, ob und wie das Teilnetzwerk in diesem Fenster modifiziert werden kann, oder ob erst eine Entschmelzung stattfinden muß. Abbildung 5.3 zeigt beispielhaft, wie eine solch beschriebene Verschmelzung aussehen könnte. In dem Netzwerk aus Abbildung 5.2 wurden sämtliche Knoten in der Mitte zusammengefaßt. Der neu entstandene Knoten bekommt ein eigenes, neu entworfenes Symbol. Dies soll die Verschmelzung von mehreren Einheiten zu einer Einheit symbolisieren. Das neue Symbol hat anstatt eines quadratischen Ausgangs einen dreieckigen. Dies soll symbolisieren, daß hier mehr als nur ein Datensatz den Knoten verlassen. Im vorliegenden Beispiel sind es fünf Datensätze, da das verschmolzene Teilnetzwerk eben insgesamt fünf Ausgänge hat. Hier weicht der neue Knoten also von der bisherigen Nutzung innerhalb der EPI-Workbench ab. Er kann also zusätzlich auch aggregierte Datensätze als Ausgang haben. Dafür ist evtl. die Datenstruktur des Systems anzupassen, damit die bereits vorhandenen Knoten auch mit dieser neuen Eigenschaft des generierten Knotens umgehen können. Dies hier als sehr einfach dargestellte Prinzip der Verschmelzung trifft aber auf einige Probleme bei der Realisierung. Will man beispielsweise ein Teilnetz verschmelzen, wie es in Abbildung 5.4 zu sehen ist, stellt sich zwangsläufig die Frage nach den Ein- und Ausgängen des verschmolzenen Knotens. Gemäß der bisherigen Verfahrensweise in der EPI-Workbench müßte er einen Eingang und ebenfalls einen Ausgang haben. Wie kann man dann aber z.B. die verschiedenen Eingangsdaten innerhalb des verschmolzenen Knotens unterscheiden? Wie erkennen die Knoten 1 und 2 der Verschmelzung ihre Eingangsdaten? Die Daten liegen schließlich alle am gleichen Eingang an. Würde man zur Lösung mehrere verschiedene Eingänge am verschmolzenen Knoten verwenden, widerspricht das der bisherigen Definition der Parallelität der Ein- und Ausgänge an Knoten, man würde ein überaus wichtiges Konzept der EPI-Workbench für Verschmelzungen nicht zur Verfügung stellen können. Die gleiche Frage stellt sich analog für die Ausgänge der Verschmelzung, die Ausgangsdaten der Knoten 1 und 2 werden alle über einen Ausgang propagiert und eine Differenzierung ist danach schlecht möglich. Hier ist also ein Weg zu finden, der einen Verschmelzungsknoten so in die EPI-Workbench integriert, daß er in sich seiner Handhabung den bereits bestehenden Konzepten anpaßt.
Aggregation und De-Aggregation von Datenströmen
Weiterführend läßt sich das gesamte System um die Möglichkeit der Aggregation bzw. De-Aggregation erweitern. Dazu werden zwei neue Knoten eingeführt, die in Abbildung 5.5 zu sehen sind. Der obere Knoten aggregiert verschiedene Datenströme (in der Abbildung sind es 4 Datenströme) zu einem, der untere Knoten hebt diese Aggregation wieder auf. Beide Symbole heben sich also gegenseitig auf. Im ersten Schritt kann man dazu eine einfache Aggregation realisieren, die alle eingehenden Daten nach einer fest vorgegebenen Art und Weise zu einem ausgehenden Datenstrom kombiniert. In diesem Falls könnte ein einziger Eingang/Ausgang für den De-Aggregationsknoten/Aggregationsknoten ausreichen. Im zweiten Schritt ließe sich dies so erweitern, daß der Anwender z.B. über ein Kontextmenü zu diesen neuen Knoten vorgeben kann, nach welchem Schema die Aggregation bzw. De-Aggregation vorgenommen werden soll. Hier sind dann allerdings mehrere Eingänge bzw. Ausgänge notwendig.
Zoom von Detailtiefen
Eine weitere Verbesserung könnte neben der oben beschriebene Verschmelzung von Teilnetzwerken mit Hilfe einer Zoom-Funktion in die EPI-Workbench integriert werden. Dabei lassen sich generell zwei verschiedene Ansätze verfolgen, die aber durchaus auch kombinierbar sind. Der erste Ansatz verfolgt lediglich die Vergrößerung bzw. Verkleinerung der visuellen Symbole und deren Verbindungen innerhalb des graphischen Editors. So lassen sich bei entsprechender Verkleinerung sehr viel mehr Komponenten eines Verfahrens auf einmal im Fokus darstellen. Jedoch muß man dabei beachten, daß die unterschiedlichen Symbole immer schlechter zu unterscheiden sind, je kleiner sie dargestellt werden. Eine exzessive Ausuferung dieser Funktion wäre also mehr hinderlich als hilfreich und ist somit nur als Ergänzung anderer Konzepte zu verstehen und nicht als Alternative.
Ein wohl sinnvollerer Ansatz bietet sich in der Möglichkeit, die Detailtiefen der Darstellung zu vergrößern bzw. zu verkleinern. Das bezieht sich hier nicht auf die visuelle Darstellung, sodaß Grafiken einfach nur in vergrößert oder verkleinert werden, sondern auf die Abstraktionsebenen des Systems [GQ94]. So wäre es z.B. denkbar auf der höchsten Abstraktionsebene mit der niedrigsten Detailtiefe eine Darstellung wie bereits in Abbildung 5.2 gezeigt mit der Erweiterung der Verschmelzung zu ermöglichen. Um die Detailtiefe eines Knotens zu erhöhen, Zoomt man in den Knoten hinein. Dann wird in einer übersichtlichen Darstellung der Inhalt des Knotens wieder in einer abstrakten Darstellung, z.B. über Symbole, angezeigt. Bei einem Verschmelzungs-Knoten wird dann z.B. das von ihm enthaltene Teilnetzwerk angezeigt. Die nächste verfügbare Detailtiefe könnte dann eine grafische Repräsentation eines einzelnen Knoteninhalts sein. Hier wird das Verfahren visualisiert, welches innerhalb des Knotens abläuft. Das ganze ließe sich soweit fortführen, so daß man über beispielsweise 2-3 Abstraktionsebenen schließlich auf einer höchsten Ebene des Detailgrades ankommt, auf der dann nur noch C++ Code editiert und angezeigt wird.
So einfach, wie es hier beschrieben wird, ist diese Möglichkeit der Visualisierung von verschiedenen Detailtiefen sicherlich nicht realisierbar. Für eine Darstellung eines Verfahrens in einem Knoten ist eine eigene visuelle Programmierumgebung zu realisieren, denn der Inhalt soll sinnvollerweise nicht nur angezeigt, sondern natürlich auch änderbar sein. Hier könnte man durchaus einen verbindenden Schritt machen und dazu die EPI-Workbench mit einer Programmierumgebung aus der Systemprogrammierung so erweitern, daß eben die Verfahren innerhalb der Knoten auf einfache Art und Weise modelliert werden können. Anbieten würde sich dazu ein System nach Art von Prograph (siehe Abschnitt 4.1.1). Es erlaubt eine komplett visuelle Programmierung ohne Einschränkungen und ohne manuelle Programmierschritte.
Die EPI-Workbench unterstützt bisher einen Kontrollfluß in Form von Anwendbarkeitstests. Wird ein neues Symbol zum Netzwerk hinzugefügt, prüft ein Anwendbarkeitstest, ob die hinzugefügte Methode überhaupt an der betreffenden Stelle anwendbar ist oder wie gut sie die Daten propagiert. Ist sie nicht anwendbar oder propagiert sie die Daten nur schlecht, wird die entsprechende Verbindungslinie zwischen den Knoten, rot eingefärbt. Alle weiteren an dieser Verbindung hängenden Knoten bekommen somit auch keine Daten. Diesen Effekt kann man sich nutzbar machen, um unter Berücksichtigung einiger Bedingungen z.B. zwei sich gegenseitig ausschließende Methoden zu einem IF-THEN-ELSE Konstrukt zu verbinden. Beide Methoden bekommen die gleichen Daten an ihre Dateneingänge und propagieren ihre Ausgangsdaten zum gleichen Eingang einer Folgemethode. Es muß dabei aber unbedingt sichergestellt sein, daß immer nur eine der beiden Methoden Daten propagiert. Ansonsten könnte die Folgemethode Probleme mit ihren Eingangswerten bekommt, falls sie beispielsweise nur einen Datensatz erwartet. Ein weiteres Problem besteht dadurch, daß diese bedingten Ausführungen in einem größeren Netzwerk kaum auffindbar sind, da sie sich optisch nicht von einem normalen Datenfluß unterscheiden.
Bedingte Ausführung
Im folgenden soll eine Möglichkeit entwickelt werden, wie zum einen eine bedingte Ausführung von Methoden optisch prägnanter realisiert werden kann. Zum anderen soll dies zugleich zuverlässiger geschehen, als es bisher möglich ist, denn es kann in der bisherigen Implementierung immer noch vorkommen, daß beide Methoden gleichzeitig anwendbar sind und somit auch beide ihre bearbeiteten Daten propagieren. Dabei soll aber auf die Einführung neuer Symbole verzichtet werden, um die bisherige Einheitlichkeit der Darstellung nicht zu ändern. Lediglich bei den Verbindungen zwischen den Symbolen, die bisher nur aus einfachen Linien bestehen, wird eine neue Art eingeführt. Sie besteht aus einer ausgefüllten Raute und findet ihre Verwendung zwischen zwei Symbolen, oberhalb oder unterhalb. Abbildung 5.6 zeigt eine bedingte Ausführung, wie sie nach der Erweiterung des Systems aussehen könnte. Zwei so miteinander verbundene Methoden schließen sich dann gegenseitig aus. Das Kriterium liegt dabei in der Ausführbarkeit bzw. Anwendbarkeit der Methoden, d.h. erst wird versucht die erste Methode anzuwenden. Schlägt dies wegen der Nicht-Anwendbarkeit der Methode auf die eingehenden Daten fehl, so wird die nachfolgende Methode ausgeführt, die über eine Raute mit der Methode verbunden ist. Dieses Konzept beschränkt sich allerdings nur auf die Ausführbarkeit bzw. Nicht-Ausführbarkeit. Die Anwendbarkeitstests sind aber weitaus differenzierter, sie unterscheiden sogar zwischen schlechter und guter Ausführbarkeit der betreffenden Methode. Hier ist also eine Gewichtung der zur Methode gehörigen Tests vorzunehmen, um eine bedingte Ausführung realisieren zu können. Es muß entschieden werden können, wann eine Methode ausgeführt wird und wann nicht, falls die Anwendbarkeitstests kein eindeutiges Ergebnis zur Anwendbarkeit/Nicht-Anwendbarkeit liefern, sondern nur aussagen, ob eine Methode gut oder Schlecht anwendbar ist. Bei der Modellierung der bedingten Ausführung ist es nicht mehr wie vorher erforderlich, daß man per visueller Modellierung jeder Methode einen Eingangsdatenstrom zuweist. Methoden die sich so miteinander Verbunden gegenseitig ausschließen, also eine bedingte Ausführung implementieren, bekommen den gleichen Eingabedatenstrom, deshalb reicht es dann auch aus, wenn die erste Methode eine Verbindung zu einer vorhergehenden Methode hat. Anders verhält sich dies allerdings mit den ausgehenden Daten der bedingten Methoden. Hier kann jede Methode verschiedene Ausgangswerte abhängig von den Eingabedaten haben, so daß auch von jeder Methode eine Verbindungslinie zur nachfolgenden Methode bestehen muß. In einer zweiten Erweiterung mag man evtl. auch dies soweit verfeinern, daß auch dafür nur noch eine ausgehende Verbindung notwendig ist. Lediglich die bedingten Methoden würden noch untereinander über die Rauten verbunden. Jedoch ist es durch die Trennung z.B. möglich, auch verschieden Knoten von den einzelnen bedingten Methoden aus zu erreichen.
Die so eingebrachten Erweiterungen zur Realisierung eines Kontrollflusses innerhalb der EPI-Workbench realisieren mehr, als das Anfangs geforderte THEN-ELSE Konstrukt. Verbindet man mehr als zwei Knoten miteinander, so ist sogar eine CASE-Konstrukt möglich. Zu beachten bleibt lediglich noch die Ausführungshierarchie, zuerst wird auch die erste Methode auf Anwendbarkeit getestet und ggf. ausgeführt. Erst wenn diese nicht anwendbar ist, wird die nächste Methode getestet usw. Für diese Erweiterung ist der Anwendbarkeitstest, der schon in der EPI-Workbench geringfügig so zu modifizieren, daß er selbständig erkennen kann, ob es sich um bedingte Methoden handelt und diese entsprechend behandelt.
Das oben beschriebene Konzept erweitert die EPI-Workbench um eine direkte Möglichkeit eine bedingte Ausführung von Methoden in die Modellierung einzubinden. Der Vorteil gegenüber der vorher schon bestandenen indirekten Möglichkeit besteht darin, daß nun sichergestellt wird, daß immer nur eine Methode Ausgangsdaten propagiert. Die Folgemethode bekommt also nicht mehr zu viele Eingangsdaten. Weiter bestehen bleibt allerdings das Problem, daß sichergestellt sein muß, ob sich die einzelnen Methoden auch wirklich gegenseitig ausschließen. Wird nämlich das erste Verfahren aufgrund seiner Anwendbarkeit ausgeführt, werden die weiteren in der Kette hängenden Verfahren nicht mehr getestet und damit mit Sicherheit auch nicht ausgeführt. Dies ist aber ein generelles Problem des Konstrukts und ist vergleichbar zur Systemprogrammierung auch dort vorhanden.
Zuordnung von Anwendbarkeitstests
Eine weitere Möglichkeit, die Modellierung von Kontrollflüssen innerhalb der EPI-Workbench zu erweitern, liegt im bereits beschriebenen Anwendbarkeitstest selbst. Bisher ist in jedem Knoten eine Klasse von Verfahren verfügbar, aus der dann ein konkretes Verfahren ausgewählt und über Parameter spezifiziert werden kann. Jedes konkrete Verfahren hat dabei auch seinen eigenen Anwendbarkeitstest, der für den Benutzer unsichtbar und auch nicht beeinflußbar ist. Die hier vorgeschlagene Erweiterung soll nun über die grafische Benutzerschnittstelle eine Auswahl von Symbolen bieten, die einzelne Anwendbarkeitstests repräsentieren. Diese werden dann vor die einzelnen Eingänge der jeweiligen Knoten gesetzt. Somit ist dann nicht nur individuell für jeden Knoten, sondern sogar für jeden einzelnen Datenstrom definierbar, welcher Anwendbarkeitstest jeweils genutzt werden soll und was getestet werden soll. Für jeden Eingang eines Knotens wäre so also ein oder mehrere eigene Tests (oder auch keiner) definierbar, der allgemeine Test für das Verfahren innerhalb des Knotens entfällt damit. Jedoch ist einer solchen Erweiterung schnell Grenzen gesetzt, zu viele verschiedene Anwendungstests geben dem Anwender zwar die Möglichkeit, Verfahren frei und ohne Einschränkungen zu modellieren, dennoch würde dies erheblich zur Unübersichtlichkeit beitragen, da zu viele unterschiedliche Symbole die Darstellung überladen würden. Deshalb erscheint es wohl sinnvoller, die Definition eines Anwendbarkeitstest über ein einziges Symbol zu realisieren. Wird dieses Symbol vor einen Eingang eines Knotens plaziert, so entfällt der knoteninterne Test. Das neue Symbol wird dann, analog zu den Verfahren in den Knoten, über ein Kontextmenü näher spezifiziert. Läßt man das Test-Symbol vor einem Eingang weg, wird wie bisher der zum Verfahren gehörige vordefinierte Test angewendet. Die in der EPI-Workbench bisher realisierten Anwendbarkeitstests sind auf verschiedenen Ebenen definiert, die zusammen über eine Gewichtung entscheiden, ob ein Verfahren bzw. die Methode anwendbar ist oder nicht. Dies sollte ebenfalls in die Erweiterungen mit einbezogen werden. Eine ganz abstrakte Erweiterung wäre das Konzept des Zoomens (siehe Abschnitt 5.3.1) für das neue Test-Symbol. Die EPI-Workbench und die in diesem Abschnitt vorgestellten Erweiterungen sind also offensichtlich noch längst nicht ausgereizt, immer andere Kombinationen ergeben neue Möglichkeiten.
In diesem Abschnitt soll ergänzend zu den vorigen Erweiterungen darüber nachgedacht werden, ob es sinnvoll ist in visuelle Programmiersysteme die Möglichkeit von Kommentaren oder Kontexten einzuarbeiten. Darauf aufbauend wird ein Lösungsansatz beschrieben, wie ein solches Konzept innerhalb visueller Programmiersysteme realisiert werden könnte und wie dies anhand der EPI-Workbench aussehen könnte. Alle bisher in dieser Arbeit vorgestellten visuellen Programmiersysteme ließen eine Unterstützung von Kommentaren oder das editieren von Kontexten missen. Kommentare und Kontexte sollen in ihrer Begrifflichkeit im folgenden synonym verwendet werden, in einer weiterführenden Betrachtung mag es evtl. sinnvoll sein, dies zu differenzieren, was aber nicht Gegenstand dieses Abschnitts sein soll.
Kommentare sind ein aussagekräftiges Hilfsmittel, um gerade größere Projekte besser nachvollziehbar zu machen. Im Anwendungsbereich der Systemprogrammierung z.B. ist es unabdingbar, daß manuell erstellter Programmcode mit Kommentaren erläutert wird. Ohne diese ist er zu einem späteren Zeitpunkt oder für Dritte kaum verständlich und sehr schwer nachzuvollziehen. Bisher wurden Kommentare nur in textueller Form innerhalb des Programmcodes eingefügt. Dies bietet sich für textorientierte Programmiersysteme an, doch auch mit visuellen Programmiersystemen lassen sich komplexe Programme erstellen. Je größer das Programm wird, desto schwerer wird es verständlich. Dies gilt insbesondere für Programme, die mit eben solchen visuellen Programmiersystemen erstellt wurden, da solche Programme mehr Platz benötigen, als ihre textuell programmierten Entsprechungen.
Wie es Kapitel 1 bereits vermuten ließ, ist es in keinem visuellen Programmiersystem möglich, Kommentare anzubringen. Deshalb soll an dieser Stelle ein Ansatz für ein solches Konzept erarbeitet werden, das beispielhaft anhand der EPI-Workbench verdeutlicht wird. Jedoch wird es auch allgemeinen Ansprüchen genügen, so daß sich dieses Konzept prinzipiell in alle visuellen Programmiersysteme integrieren läßt. Insbesondere ist dabei auf folgende Punkte zu achten:
Angestrebt werden sollte für visuelle Programmiersysteme auch eine Art visueller Kommentare, die jedoch schwer zu verwirklichen sind. Ihre Realisierung ginge sicherlich über die Verwendung von grafischen Symbolen, die auf zweierlei Art und Weise in das System eingebracht werden können. Zum einen können Symbole anstelle von Texten zur graphischen Erläuterung eingesetzt werden (siehe Abschnitt 2.2), zum anderen können Symbole als Platzhalter für Texte fungieren, die man beispielsweise anklicken muß, um den Text darzustellen. Doch beide Vorgehensweisen scheitern meist am gleichen Problem. Die im System zur Programmierung benutzten Symbole sollten sich durch ihre Optik selbst erklären (siehe Abschnitt 3.1). Desweiteren würden zusätzliche Symbole innerhalb des Editors die Darstellung unnötig überladen, zu leicht könnten sie mit Programmiersymbolen verwechselt werden. Aus diesen Gründen ist also die Einbindung von Kommentaren über Symbole wohl kaum eine geeignete Lösung für das Problem.
Eine weitere Möglichkeit bietet sich, indem man innerhalb des grafischen Editors einige kurze Textphrasen einbettet, die spezielle Teile des Netzes umschreiben. Dies hat den Vorteil, daß sich so eingebrachte Kommentare eindeutig vom eigentlichen Programm abheben. Probleme treten hier jedoch auf, wenn der beschreibende Text sehr lang wird und damit wieder das oben bereits aufgeführte Problem der Übersichtlichkeit implizieren kann. Desweiteren birgt diese Art von Kommentaren kein visuelles Konzept an sich, was in dieser Arbeit jedoch im Vordergrund steht.
Um beiden Ansätzen gerecht zu werden, soll ein Mittelweg gewählt werden, der sowohl visuelle als auch textuelle Konzepte miteinander kombiniert. Dazu wird der graphische Editor der EPI-Workbench so erweitert, daß er es dem Benutzer ermöglicht, mehrere Knoten einzurahmen. Dies geschieht ähnlich der Umrandung, die in Abschnitt 5.3.1 beschrieben wurde. Eine solche Umrandung sollte sich dann frei definieren lassen, sodaß nicht nur geometrische Figuren erstellbar sind, sondern dieser Rahmen jede beliebige zweidimensionale Form annehmen kann. Zusätzlich wird der Hintergrund des Rahmens farbig vom Hintergrund des graphischen Editors abgesetzt. Dabei muß jedoch gewährleistet werden, daß alle umrahmten Symbole und die zugehörigen Verbindungen klar erkennbar bleiben. Desweiteren kann dann ein so entstandener Rahmen mit einem Text versehen werden, der den umrahmten Teil des Netzes zusätzlich erläutert. Abbildung 5.7 zeigt, wie das beschriebene Konzept in der EPI-Workbench aussehen könnte. Hier wurden zwei Blöcke innerhalb des Netzes mit Hilfe der neuen Möglichkeit der Markierung durch Kommentare gebildet. Der größere Block erhielt durch einen zusätzlichen Text innerhalb des Rahmens eine ergänzende Erklärung. Diese Verbindung zwischen visueller Markierung und textueller Beschreibung von Segmenten des im graphischen Editor dargestellten Netzes scheint eine geeignete Möglichkeit zu sein, Teile des Programmflusses zu erläutern bzw. hervorzuheben ohne das eigentliche visuelle Programm störend zu beeinflussen. Probleme kann es jedoch bei größeren Netzen geben, in denen sich solche Blöcke überschneiden oder sogar beinhalten. In diesem Fall können sich die Kommentare gegenseitig soweit beeinträchtigen, daß sie nicht mehr verständlich sind oder eine eindeutige Zuordnung zu Teilen des Netzes nicht mehr offensichtlich ist.
Dieser Abschnitt soll nun ergänzend zu den vorangegangenen Überlegungen dieses Kapitels kurz einen Ausblick auf eine weitere Möglichkeit für die Erweiterung der EPI-Workbench geben. Dabei soll ein Konzept betrachtet werden, das zwar an sich nicht typisch für visuelle Programmiersysteme ist, aber dennoch oft mit der visuellen Programmierung in Verbindung gebracht wird. Die Einbindung von Skripten soll die Erweiterbarkeit des Systems verbessern. Diese Überlegung wird hier im Ausblick behandelt und nicht im vorigen Abschnitt, da sie wie bereits erwähnt, keine typische visuelle Programmiertechnik ist, dennoch aber auch in visuellen Programmiersystemen zu finden ist.
Bisher ist es unbedingt erforderlich, für eine Erweiterung der EPI-Workbench um weitere Methoden und Verfahren über gute Kenntnisse in C++ zu verfügen. Dies ist sicherlich für viele Anwender des Systems, die nicht unbedingt über Programmierkenntnisse verfügen ein großes Hindernis, das System eigenständig zu erweitern. Der dieser Arbeit logisch folgende Ansatz müßte nun lauten, daß man ein visuelles Programmiersystem, das eine Erstellung von C++ Programmen erlaubt und fertigen Code generiert, in das System für die Erweiterung integriert. Dies hat dann jedoch nicht mehr viel mit dem Spezialgebiet der deskriptiven Epidemiologie zu tun, der Anwender des Systems wird wahrscheinlich auch damit überfordert sein. Eine gute Möglichkeit bietet sich hier in der Verwendung von Skripten, die genaugenommen eigentlich ein Rückschritt von der visuellen zur manuell-/textuellen Programmierung bedeuten. Dennoch kann man ihnen einen gewissen Vorteil in einigen Bereichen nicht absprechen. Innerhalb der EPI-Workbench sind durchaus unterschiedliche Ansätze denkbar, Skripte einzubinden. So könnten sich z.B. über eine programmeigene Skriptsprache komplette Netze beschreiben lassen, die durch einen Interpreter o.ä. in ein visuelles Netz umgewandelt werden. Die umgekehrte Richtung wäre dann auch denkbar. Man erstellt auf visueller Basis ein Netzwerk mit der EPI-Workbench und wandelt dies dann in ein textuelles Skript um. Dies kann dann manuell erweitert oder geändert werden. So könnte sich der Anwender sein bevorzugtes Verfahren zur Erstellung aussuchen oder aber auch beide kombinieren.
Eine solche Skriptsprache ließe sich aber nicht nur zur Beschreibung von Netzen verwenden, sondern auch für die Erweiterung der EPI-Workbench kann sie eingesetzt werden. Dabei ist aber zu beachten, daß sich eine Skriptsprache zur Beschreibung eines Netzes von einer Skriptsprache zur Definition eines Verfahrens grundlegend unterscheiden kann, aber nicht muß. Am besten wäre hier natürlich ein Mittelweg, also eine Sprache, mit der beide Aspekte abgedeckt werden können. Hier stößt man allerdings auf ein bereits bestehendes Problem. Je allgemeiner eine solche Sprache ist, desto komplexer wird auch ihre Struktur sein. Ein Anwender muß sich also wieder in mehr oder weniger komplizierte Konstrukte einarbeiten, die programmeigene Programmiersprache erlernen. Dies ist sicherlich einfach für jemanden, der sich im Bereich der Programmierung ein wenig auskennt. Versucht dies allerdings jemand, der sich mit diesen Themen nie beschäftigt hat, stößt das ganze Konzept an seine Grenzen.
Jetzt kann man natürlich darüber nachdenken, ob dann eine Erweiterung des Systems um eine komplexe Skriptsprache überhaupt sinnvoll ist, bietet das System doch eine komplette Erweiterungsbasis auf C++-Ebene. Für einen Anwender ist jedoch eine anwendungsbezogene Skriptsprache wahrscheinlich sehr viel einfacher erlernbar, als C++. Allerdings ist das auch von der Komplexität der Sprache abhängig, die somit ein gewisses Maß nicht überschreiten darf, um mehr als nur eine Alternative zu einer Programmiersprache zu sein.
Die herkömmliche Programmierung, mit der man i.a. die manuell textuelle Programmcode-Erstellung verbindet, war bisher nur den Kennern der Materie zugänglich. Je mehr verschiedene Anwendungsbereiche und Einsatzgebiete aber für Computer erschlossen wurden, desto mehr Entwickler drängen auch aus anderen Anwendungsgebieten in den Bereich der Programmierung. Wollen diese ihre Ideen verwirklichen, sind sie gezwungen entweder mit Programmierern zusammenzuarbeiten oder die Programmierung selbst zu erlernen. Beides behindert die Kreativität und Entwicklung einer Idee. Die visuelle Programmierung versucht nun, solchen Anwendern, aber auch spezialisierten Programmierern, Werkzeuge an die Hand zu geben, um ihre Ideen schnell und möglichst ohne Einschränkungen verwirklichen zu können. Dabei kommen visuelle Programmierumgebungen zum Einsatz, in denen man visuelle Objekte mit einigen Beziehungen kombiniert, um ein eigenständig lauffähiges Programm zu erhalten. Das System abstrahiert vom Prozessor und von der zugrunde liegenden Programmiersprache auf einem so hohem Niveau, daß über Details der Programmierung nicht mehr nachgedacht werden muß. Es hilft dem Anwender soweit, daß kaum noch Fehler gemacht werden. Der Entwickler des Programms braucht sich somit nicht mehr um die eigentliche Programmierung kümmern, sondern kann seine Idee und das Design in den Vordergrund stellen, den Rest übernimmt die visuelle Programmierumgebung.
Visuelle Programmiersprachen bilden keine eigene Evolutionsstufe der Programmiersprachen, da sie meist nur Aufsätze oder Weiterentwicklungen von bereits bestehenden Sprachen sind, bilden aber dennoch eine eigene Klasse. Die Vorteile einer solchen Umgebung liegen in der kurzen Entwicklungszeit für Programme, die darüber hinaus auch meist weitaus fehlerfreier als bei der herkömmlichen Programmierung sind. Bei großen Programmen bekommt man allerdings ein Platzproblem in der Darstellung und die mit einer visuellen Programmierumgebung erstellten Programme sind meistens sehr viel langsamer, als ihre manuell programmierten Entsprechungen.
Eine Programmierung über visuelle Objekte bietet sich deshalb an, da der Mensch den Informationsgehalt von Bildern besser aufnehmen kann, als die entsprechenden Informationen in textueller Form, da die menschliche Wahrnehmung darauf optimiert ist. Die beiden prägnantesten Konzepte visueller Programmierung basieren auf dem Kontroll- bzw. Datenfluß. Diese können sehr gut über visuelle Objekte und Verbindungen dargestellt und modelliert werden. Wann welches Konzept am besten zum Einsatz kommen kann, hängt meist vom Anwendungsbereich ab, in der die Programmierumgebung genutzt werden soll. Nicht so gängige Konzepte sind aber durchaus auch gebräuchlich, wie z.B. die erweiterte Programmierung von Benutzeroberflächen, PBE-Systeme oder Zeitleisten. Dabei gibt es in jedem der drei aufgeführten Anwendungsbereiche sehr unterschiedliche Ansätze, wie visuelle Programmiersysteme realisiert werden können.
Ein nicht klassischer Anwendungsbereich der visuellen Programmierung ist die Datenanalyse. Die Bearbeitung von großen Datenmengen über manuell erstellte Verfahren ist ein sehr komplizierter und auch zeitaufwendiger Prozeß, der durch Konzepte visueller Programmierung stark vereinfacht werden kann. Für einen speziellen Teilbereich der Datenanalyse, die deskriptive Epidemiologie, existiert bereits u.a. ein visuelles Programmiersystem, die EPI-Workbench. In ihr sind über einen graphischen Editor komplette epidemiologische Untersuchungen modellierbar, die auf Grundlage eines Datenflußdiagramms erstellt werden. Defizite finden sich allerdings in der Modellierung von Kontrollflüssen, sowie wie bei den meisten visuellen Programmumgebungen, in der Darstellung und der Kommentierung von komplexeren Untersuchungen. Speziell zu diesen Problemen wurde die Integration folgender neuer Konzepte in die EPI-Workbench auf theoretischer Basis abgehandelt:
Die angesprochenen Probleme lassen sich durch die in dieser Arbeit entwickelten Erweiterungen der EPI-Workbench zwar nicht vollständig beheben, aber die Handhabung kann wesentlich verbessert werden. Ein darüber hinausgehender, nicht unbedingt der visuellen Programmierung zugehöriger Ansatz, die Integration von Skripten, hat gezeigt, daß das System noch lange nicht ausgereizt ist. Geht man einen Schritt weiter und versucht die in dieser Arbeit ausgeführten neuen Konzepte in die EPI-Workbench zu integrieren, werden sicherlich noch weitere Probleme auftreten, die bisher noch nicht berücksichtigt oder erkannt wurden. Jedoch werden sich in einer solchen Phase durchaus auch neue Ideen entwickeln, die die einzelnen Konzepte verbessern oder evtl. sogar überflüssig machen können. Man muß dabei aber beachten, daß man das System bei der Implementierung der neuen Funktionen nicht überlädt, so daß es einen Negativ-Effekt gibt und die EPI-Workbench wegen zu vieler unübersichtlicher Funktionen nicht mehr handhabbar ist. Dabei gilt es einen guten Kompromiß zu finden.
| [AFH+96]
|
H.-J. Appelrath, J. Friebe, H: Hinrichs, V. Kamp, J. Rettig, W. Thoben und F. Wietek. CARLOS Tätigkeitsbericht für den Zeitraum 1.1. - 31.12.1996. Technischer Bericht, OFFIS, Oldenburg, 1996. |
| [And88]
|
J.R. Anderson. Kognitive Psychologie. Spektrum der Wissenschaft, Heidelberg, 1988. |
| [Böh95]
|
|
| [BB94]
|
M. Burnett und M. Baker. A classification system for visual programming languages. Technischer Bericht, Department of Computer Science, Oregon State University, 1994. Ftp://ftp.cs.orst.edu/pub/burnett/vplclassification. tr.ps. |
| [Boc92]
|
H. Bock. Grundlegende Methoden der exploratorischen Datenanalyse. Methoden und Werkzeuge für die exploratorische Datenanalyse in den Biowissenschaften, Fischer Verlag, 1992. |
| [BP94]
|
M. Baker und J. Power. Visual Programming Languages. Technischer Bericht, Department of Computer Science, Washington, 1994. Http://www.cs.washington.edu/homes/ jpower/vpl |
| [Car94]
|
J. Carriere. Prograph. Technischer Bericht, University of Waterloo, 1994. Http://www.cgl.uwaterloo.ca/~j2carrie/prograph-talk/prograph.html |
| [Cha87]
|
S. Chang. Visual languages: A tutorial and survey. IEEE Software, Seiten 29-39, 1987. |
| [Cha96]
|
S. Chang. Elements of a visual language. Technischer Bericht, Universität Pittsburgh, Knowledge Systems Institute, 1996 |
| [CDZ94]
|
Citrin, M. Doherty und B. Zorn. The design of a completely visual object oriented programming language. Technischer Bericht, Department of Computer Science, University of Colorado, 1994. Ftp://ftp.cs.colorado. edu/pub/techreports/ citrin/voop-vipr.ps.z. |
| [CO92]
|
Prof. Dr. V. Claus und Prof. Dr. E.-R. Olderog. Grundbegriffe der Theoretischen Informatik. Vorlesungsskript, Fachbereich Informatik, Universität Oldenburg, 1992. |
| [CS96]
|
P. Cox und T. Smedly. A visual language for the design of structured graphical objects. Technischer Bericht, Technical University of Nova Scotia, 1996. Ftp://ftp.dad.cs.tuns.ca/smedley/papers/VL96sub.ps.z. |
| [CZ97a]
|
W. Citrin und B. Zorn. VIPR Environment User’s Manual. Department of Computer Science, University of Colorado, 1997. Http://soglio.colorado. edu/web/vipr.html |
| [CZ97b]
|
W. Citrin und B. Zorn. VIPR/Tcl Language Reference Manual. Department of Computer Science, University of Colorado, 1997. Http://.soglio.colorado. edu/web/vipr.html |
| [DGHL91]
|
D. Duce, M. Gomes, F: Hopgood und J. Lee. User Interface Management Design. Springer Verlag, Berlin, 1991. |
| [Die94]
|
D. Boles. Integration von Interaktionen in das Autorensystem FMAD. Diplomarbeit, Fachbereich Informatik, Abteilung Informationssysteme, Universität Oldenburg, 1994. |
| [Die95]
|
D. Boles. FMAD - Ein objektorientiertes Autorensystem für interaktive multimediale Anwendungen. Technischer Bericht, Fachbereich Informatik, Abteilung Informationssysteme, Universität Oldenburg, 1995. |
| [Die97]
|
D. Boles. Multimedia-Systeme. Vorlesungsskript, Fachbereich Informatik, Abteilung Informationssysteme, Universität Oldenburg, 1997. |
| [Föc95]
|
E. Föcker. SAP Business Workflow. Projektarbeit Workflowmanagement, Lehrstuhl für Wirtschaftsinformatik, Uni-Münster. Http://www-wi.uni-muenster.de/is/ workflow/PS9697/referat.htm. |
| [Gli87] | E. P. Glinert. Out of Flatland:
Towards 3-D Visual Programming. IEEE Proceedings 2nd Fall
Joint Computer Conference, Seiten 292-299, IEEE Computer Society Press.
|
| [Göt93]
|
R. Götze. Dialogmodellierung für multimediale Benutzerschnittstellen. Dissertation, Fachbereich Informatik, Universität Oldenburg, 1993. |
| [GQ94]
|
M. Gorlick und A. Quilici. Visual Programming-in-the-Large versus Visual Programming-in-the-small. 10th annual IEEE onference on VL, Seiten 137 - 144, 1994. |
| [GS92] |
|
| [Han97]
|
D. Hand. Intelligent Data Analysis: Issues and Opportunities, Advances in Intelligent Data Analysis. Springer Verlag, Seiten 1-14, Berlin Heidelberg, 1997. |
| [Har95]
|
J. Hartung. Statistik. Lehr- und Handbuch der angewandten Statistik. 10. Auflage, Oldenbourg Verlag, München, 1995. |
| [HBL93]
|
W. Hellmeier, H. Brand und U. Laaser. Epidemiologische Methoden der Gesundheitswissenschaften. Aus: K. Hurrelmann und U. Laaser, Gesundheitswissenschaften: Handbuch für Lehre, Forschung und Praxis. Beltz Verlag, Weinheim, Basel, 1993. |
| [IJK90] | T. Ichikawa, E. Jungert und R.R.
Korfhage. Visual languages and applications. Plenum Press, 1990.
|
| [Jam92] | M. Jambu. Explorative Datenanalyse.
Gustav Fischer Verlag, 1992.
|
| [KE89]
|
A. Kilgour & R. Earnshaw. Graphics Tools for Software Engineers. Cambridge University Press, 1989. |
| [Liu96]
|
X. Liu. Intelligent data analysis: issues and challenges. The Knowledge Engineering Review, Seiten 365-371, 1996. Http://www.dcs.bbk.ac. uk/ida97.html. |
| [Mac92]
|
MacroMind Director Handbuch, Mcromedia Inc., San Francisco, 1992. |
| [Mey87]
|
Meyers enzyklopädisches Lexikon, Band 8, Bibliographisches Institut Mannheim, Lexikonverlag, 1987. |
| [Mye89]
|
B. Myers. Visual programming and program visualisation. In Kilgour und Earnshaw, Graphics Tools for Software Engineers, British Computer Society Workshop Series, 1989. |
| [Naj94] | M.-A. Najork. Programming in
three dimensions, Doktorarbeit, Technische Hochschule Darmstadt, 1994.
Http://www.research.digital.com/src/personal/ Marc_Najork/thesis/index.html.
|
| [NS72] | I. Nassi und B. Shneidermann.
Flowchart Techniques for Structured Programming, 1972.
|
| [Öst95]
|
H. Österle. Business Engineering, Prozeß- und Systemenwicklung. Springer Verlag, Berlin, 1995. |
| [Ous94]
|
J. Ousterhout. Tcl an the Tk Toolkit. Addison-Wesley Professional Computing Series, 1994 |
| [PS94]
|
B. Pagel und H. Six. Software Engineering, Band 1: Die Phasen der Softwareentwicklung. Addison Wesley, 1994 |
| [Rek95] | J. Rekers. Visual languages,
visual programming & program visualization. Technischer Bericht,
Universität Leiden, 1995. Http://www.wi.leidenuniv.nl/ cs/seis/vislang/
vlcourse.html.
|
| [SAP94]
|
Funktionen im Detail - SAP Business Workflow, SAP AG Walldorf, 1994. Http://www.sap.com/bfw/media. |
| [Shu86]
|
N.C. Shu. Visual Programming Languages - A Perspective and a Dimensional Analysis. IBM Academic Information Systems, Seiten 11-34, Los Angeles Scientific Center, 1986. |
| [SS95]
|
M. Sonnenschein und J. Sauer. Software-Engineering. Vorlesungsskript, FB Informatik, Uni-Oldenburg, 1995. |
| [Tuk77]
|
J. Tukey. Exploratory Data Analysis. Addison Wesley, Reading, 1977 |
| [Wat89]
|
D. Watson. High level languages and their compilers. Addison Wesley, 1996. |
| [Wie94] | F. Wietek. Eine wissensbasierte
generische Statistikkomponente für die deskriptive Epidemiologie.
Diplomarbeit, Fachbereich Informatik, Universität Oldenburg, Abteilung.
Informationssysteme, 1994.
|
| [Wol92]
|
H. Wolf. Zehn Punkte zur Standortbestimmung von EDA - Einige Bemerkungen über die Verbindlichkeit von exploratorischen Datenanalysen. Methoden und Werkzeuge für die exploratorische Datenanalyse in den Biowissenschaften, Fischer Verlag, 1992. |