Projekteminar Visuelle Programmierung Vortrag: Konzepte Visueller Programmierungssysteme 20.11.2002 Sebastian Huß
Gliederung Begriffsklärungen Abgrenzung Konzepte....Steuerflußorientierter VP-Systeme..Funktionsorientierter VP-Systeme..Objektorientierter VP-Systeme..Constraintorientierter VP-Systeme..Regelorientierter VP-Systeme..Beispielorientierter VP-Systeme..Formularorientierter VP-Systeme..Multiparadigmenorientierter VP-Systeme
Gliederung II Konzepte Datenflußorientierter VP-Systeme Darstellung Ausführung Implizite Ausführungsreihenfolge und Parallelität Nebeneffektfreiheit Variablenfreiheit Behandlung strukturierter Daten Ablaufstrukturen
Begriffsklärungen Visuell: (Objekteigenschaft) mindestens eine Information des Objektes ist nur durch den visuellen Wahrnehmungsapparat des Menschen zu gewinnen visuelle Programmiersprache: formale Sprache mit visueller Syntax oder Semantik, die vollständig die Eigenschaften von Software beschreibt Universal- oder Spezialprogrammiersprache visuelle Programmierungssysteme (VP-Systeme): Menge integrierter Werkzeuge zur Erstelung von Software mittels visueller Programmiersprachen (und visueller Softwarebeschreibungssprachen)
Abgrenzung Verbale Programmiersprachen: Lineare Anordnung der Elemente ist ausreichend, visuelle Elemente sind Syntaktisch und Semantisch bedeutungslos VP-Systeme sind nicht: Programmierumgebungen mit grafischer Benutzungsoberfläche fuer verbale Programmiersprachen Anwendung grafischer Entwurfsmethoden ohne maschinelle Generierung von Software(-teilen) Entwicklung von Software für grafische Datenverarbeitung Grafisches Editieren der Dokumentation...
Konzepte Steuerflußorientierter VP-Systeme Generell: Anwendung des imperativen Programmierparadigmas -Anweisungssequenzen: lineare Operationsfolge mit Ablaufstrukturen, teilweise mit Konstrukten für Parallelität meist Ablaufpläne/Blockdiagramme Bsp:Flußdiagramme (FPL,Pict), Nassi-Shneiderman-Diagramme geringe Bedeutung, da keine neuen Konzepte zu verbalen Prog.Sp. -Komponentennetze: Objekte sind mittels Kanäle lose verkoppelt, Tokens auf den Kanälen aktivieren die Objekte Hohes Abstraktionsniveau, sehr flexibel Bsp: Vista
Konzepte Steuerflußorientierter VP-Systeme II -Transitionsnetze: Automaten und Petrinetze -> reaktive Systeme exakte Spezifikation von Systemeigenschaften beweisbare Aussagen über das Systemverhalten besonders geeignet für die Definition das Ablaufs/Zusammenwirkens von Prozessen
Konzepte Funktionsorientierter VP-Systeme Gleicher theoretischer Unterbau wie Datenflußorientierte VP- Systeme, um klassische funktionale Konzepte erweitert -Funktionen als Argumente -Polymorphe Funktionen -Implizite Typsysteme Aber: wenig verbreitet, da die Funktionale Programmierung als mathematische Formulierung entstand und somit textuelle Notation vorteilhafter ist Visuelle Darstellung: Funktionsdiagramm Bsp: VisaVis
Konzepte Objektorientierter VP-Systeme Aufteilung der Software-Erstellung auf zwei Ebenen: - Erstellung von Programmbausteinen mittels verbaler Programmiersprachen und Klassenbibliotheken - Erstellung von Applikationen durch visuelle Verbindung von Bausteinen zu komplexen Einheiten Kommunikation der Bausteine mittels Attribute, Ereignisse, Nachrichten enge Verbindung von Problem und Lösung legt eine visuelle Repräsentation mit den Möglichkeiten direkter Manipulation nahe Nachteile: -Tendenz zur Unübersichtlichkeit - keine Methoden der Vererbung - Probleme mit Objekterzeugung und Polymorphismus Bsp: PARTS, VisualAge
Konzepte Constraintorientierter VP-Systeme -Keine Algorithmischen Programmkonstrukte (wie Zuweisungen, Prozeduren) -Angabe zu geltender Beziehungen (Constraints) zwischen Objekten -> Constraint-Satisfier sorgt für ihre Beibehaltung -Constraints sind ungerichtet -Denkmodelle der logischen bzw. Deklarativen Programmierung Probleme: -Über-/Unterspezifikation (zuviele/zuwenige Constraints) führt zu keinen/zuvielen Lösungen -Wechselwirkungen zwischen Constraints -Laufzeit -starke Begrenzung der möglichen Anwendung
Konzepte Regelorientierter VP-Systeme Programme als Folge von Bildtransformationen: -Menge von Transformationsregeln -Versuch, ein Muster (linke Seite einer Transformationsregel) in einer Eingabegrafik zu finden (um es dann zu transformieren) -ständige Wiederholung dieses Vorgangs (es läuft sozusagen ein Film ab) bis keine transformierbaren Muster mehr gefunden werden Probleme: -Konfliktbehandlung (Lösungsansatz: Regelwahrscheinlichkeiten) -kombinatorische Explosion der Regelanzahl bei komplexeren Aufgabenstellungen Verwendung: -Simulationen in Biologie, Chemie und Elektronik, LEGOsheets Bsp: PROGRES
Konzepte Beispielorientierter VP-Systeme Idee: Benutzer führt vor, System beobachtet, zieht Schlussfolgerungen, generiert Programm zur wiederholten Ausführung Programmieren mit Beispielen: -direkte Übersetzung ohne Absichtserkenntnis -z.b. Makrorekorder Programmierung durch Beispiele: -Demonstration typischer Szenarien -> das generierte Programm soll aus gegebenen Daten das gewünschte Resultat erzielen, auch für ähnliche Situationen -Problem: Beschränkung der Interaktion des Benutzers auf die visuelle Ebene erschwert den Vorgang, Diskrepanz zsichen Nutzeraktion und Systemcode
Konzepte Formularorientierter VP-Systeme -aus Konzepten der Tabellenkalkulation entstanden -> es fehlen sequentielle Abläufe, Datenabstraktion, algorithmische Konstrukte -deklarative Programmierung -für DB-Systeme bewährt Bsp: QBE (query by example)
Konzepte Multiparadigmenorientierter VP-Systeme -Zusammenfassung mehrerer Programmierparadigmen -nahtlose Integration dieser Konzepte Bsp: -Prograph (OOP+DFD) -Visual ToolSet (Steuerfluß, DF, Bsp.,Form.) -Vista (Steuerfluss, DF, OOP) Nachteile: -Tendenz zu konzeptioneller Überladung -Komplexität -Problem: Stärke der einzelnen Paradigmen vs. Gesamtqualität
Konzepte Datenflußorientierter VP-Systeme Datenflußmodell: -Verfügbarkeit von daten bestimmt die Ausführungsreihenfolge von Operationen (kein Befehlszähler wie bei Steuerflußorientierung) -gleicher theoretischer Unterbau wie funktionsorientierte VP-Systeme -spezielle Beschreibung und Ausführungsmechanismen für funktionale Programme - in der visuellen Programmierung weit verbeitet, auch kommerziell erfolgreich -Verzicht auf schwierige Konzepte wie Variablen/dynamische Datenstrukturen -keine Querbeziehungen -> leichtes Top-Down-Modellieren -Parallelität Visualisierung der Programmausführung
Darstellung Als gerichteter Graph mit Datenquellen, Datensenken, Operationen, durch Kanäle verbunden Regeln: -ein Kanal pro Eingang, pro Ausgang auch mehrere -eine Qperation hat min. 1 Eingang -Operationen ohne Ausgang haben Nebenffekte oder sind wirkungslos
Ausführung Wird durch den Fluß der Daten durch das System bestimmt Daten sind aktive Elemente, bestimmen welche Operationen wann ausgeführt werden Eine Operation wird aktiviert, sobald alle Eingänge belegt sind, sie schaltet, und lifert genau einen Datenwert pro Ausgang (-> alle Daten werden verarbeitet, auch ohne Synchronisation)
Implizite Ausführungsreihenfolge Sequenz der Operationsausführung nur implizit durch den Datenfluss gegeben Problem: bestimmte Reihenfolge kann unabdingbar sein Lösung: künstliche Datenkanäle oder extra Sequenz-Anweisungen
Nebeneffektfreiheit Bewirkt starke Einschräkung der Möglichkeiten: keine Zustandvariablen etc. -> teilweise Aufgabe dieses Prinzips mit Einschleppung entsprechender Nachteile
Variablenfreiheit Variablen sind konzeptionell unnötig: Daten sind auf den Kanälen gespeichert Vorteile durch Wegfall von Fehlermöglichkeiten -wird trotzdem in VP-Systemen ermöglicht
Strukturierte Daten -werden in der regel kopiert vor Veränderungen wegen Nebeneffektfreiheit Problem: Laufzeit, Speicher, Systemressourcen
Ablaufstrukturen Verzweigungen, Fallunterscheidungen, Schleifen -schwer zu realisieren aber notwendig -> führen zu schwer verständlichen Diagrammen ->besondere Strukturierungsmechanismen in den einzelnen VP- Systemen, besonders gut in LabVIEW