Microsoft Visual Programming Language: End-User Perspektive · 2 ChristophHartmann wurde1987dasAlternateRealityKit(ARK)entwickelt,welcheesvisuellerlaub-te,dieGravitationvonObjektenzutesten.Dassnebendenzwei-dimensionalen

Microsoft Visual Programming Language:End-User Perspektive

Christoph Hartmann

Hasso-Plattner-Institut für Softwaresystemtechnik GmbH

Zusammenfassung. Microsoft möchte die Robotik mit seinem Robo-tics Studio massentauglich machen. Dazu reicht es nicht aus nur gu-te Programmbibliotheken bereitzustellen, sondern die Tools müssen dieEnd-User im Verstehen der komplexen Abläufe unterstützen. Damit derEnd-User nicht einmal textuell programmieren muss, bietet die MicrosoftVisuel Programming Language die Möglichkeit, alle Aufgaben visuell zuerledigen. Dieses Paper wird dabei untersuchen, wie selbsterklärend dieAnwendung der Microsoft Visuel Programming Language ist und ob sichdie Sprache auch für komplexere Projekte nutzen lässt. Im Fokus stehtdabei die End-User Perspektive anstelle der üblicherweise technischenSicht.

1 Einführung

Das Internet hat sich von einem reinen Text-Web 1963 Sketchpad1967 Grails1968 AMBIT/G1974 Pygmalion1979 ThingLab1982 Prograph1984 PICT1984 Rehearsal World1985 FORMAL1986 LabView1987 ARK1989 Agent Sheets1991 Cube1994 Forms/31996 KidSim

Tabelle 1. Entwicklungvon visuellen Program-miersprachen

zu einer multimedialen Schaltzentrale entwickelt unddennoch wird zur Entwicklung von Programmen zu-meist die textuelle Programmierung bevorzugt. Da-bei sind Ansätze für visuelle Programmiersprachenschon seit den 60er Jahren vorhanden. Die Entwick-lung der graphischen Oberfläche begann 1963 mitdem Sketchpad von Ivan Sutherland (MIT), welchermit Hilfe eines Stiftes Graphiken auf den Bildschirmmalte. 5 Jahre später entwickelte C. Christensenmit AMBIT/G die Möglichkeit, Programme als Gra-phen darzustellen. Später entdeckte David Canfliedmit Pygmalion den Bereich der Ikon-basierten Pro-grammiersprachen. 1982 erblickte die erste visuel-le Datenfluss-orientierte Sprache Prograph1 das Le-ben. Sie zeigte neue Konzepte, wie Abläufe visua-lisiert werden können. 1986 wurde LabView durchNational Instruments auf dem Markt gebracht underreichte bis heute eine große Beliebtheit im Bereichder hardwarenahen Entwicklung. Am Xerox Park1 Prograph ist heute für MacOS als Marten verfügbar. Siehehttp://www.andescotia.com/products/marten/

2 Christoph Hartmann

wurde 1987 das Alternate Reality Kit (ARK) entwickelt, welche es visuell erlaub-te, die Gravitation von Objekten zu testen. Dass neben den zwei-dimensionalenProgrammiersprachen auch drei-dimensionale Programmiersprachen als Lösungin Betracht kommen können, zeigte 1991 die Programmiersprache Cube. Sienutzte drei Dimensionen, um die sonst problematische Größe des Monitors aufzu-heben. Das von Apple 1996 entwickelte KidSim [10] erlaubte das visuelle Erstel-len von Programmen durch die Erstellung von visuellen Regeln. Einen Überblickbietet die Tabelle 1.

Heutzutage finden sich visuelle Sprachen häufig als domainspezische Ergän-zungen im Einsatz. Auch die modellgetriebene Softwareentwicklung nutzt visu-elle Repräsentationen. Hier sollen nur die Business Process Modeling Notation(BPMN)2, die ARIS Produkte von IDS Scheer3, das Eclipse Modeling Frame-work4 oder Microsoft Whitehorse5 genannt werden.1.1 Definition

Auf Grund der verschiedenen Interpretationsmöglichkeiten von visuellen Pro-grammiersprachen (VPL) 6, definiert Meyers [7] visuelle Programmierung alsein System, das Benutzern ermöglicht, ein Programm zwei oder mehrdimensio-nal zu spezifizieren. Das Ergebnis der Programmierung ist eine Software, wobeidie Granularität von Softwarebausteinen an dieser Stelle nicht festgelegt wird.Ein Baustein „Sende Dokument an Mail“ wäre ebenso möglich wie „Lese 4 Bytesaus der Datei read.txt“. Typischerweise ist eine visuelle Programmiersprache eineformale Sprache, welche visuelle Syntax zur Beschreibung der Software nutzt.

Davon muss die Programm Visualisierung abgegrenzt werden. In diesem Fallerfolgt die Programmierung im konventionellen textuellen Stil, dennoch werdenGraphiken genutzt, um Aspekte des Programms oder seiner Laufzeit darzustel-len. Denkbar wäre eine Software, welche visuell die Anzahl der Methoden undKlassen darstellt und diese graphische Darstellung direkt mit dem Quelltextverbindet.

1.2 VPL Design Goals

Nach Margaret M. Burnett [2] lassen sich vier verschiedene Designziele für eineVPL nennen:

1. Einfachheit. Dabei werden Probleme adressiert, die zum unmittelbarenVerständnis des Programms nicht notwendig sind, aber dennoch aus tech-nischen Gründen zu jedem Programm gehören. Es sind dabei insbesonderePointer, Speicherallokation, Variablendeklarationen und Gültigkeitsbereicheder Variablen zu nennen. Viele dieser Abstraktionen finden sich auch in heu-tigen Hochsprachen wie Java und C# wieder.

2 http://www.bpmn.org/3 http://www.ids-scheer.com/en/Software/ARIS_Software/3730.html4 http://www.eclipse.org/modeling/emf/5 http://msdn.microsoft.com/en-us/magazine/cc163947.aspx6 engl. Visual Programming Language

Microsoft Visual Programming Language: End-User Perspektive 3

2. Anschaulichkeit. Damit Abläufe und Änderungen für die Endbenutzerleichter zu verstehen sind, muss die VPL sie möglichst effektiv veranschauli-chen. Manche visuelle Programmiersprachen wie Forms/3 unterstützen dasSetzen von Beispielswerten, wodurch automatisch während der EntwicklungErgebnisse berechnet werden können. Je besser die visuelle Sprache den Ver-lauf veranschaulichen kann, desto einfacher versteht der Nutzer das Pro-gramm.

3. Deutlichkeit von Beziehungen. Neben der Anschaulichkeit muss die vi-suelle Programmiersprache auch die Beziehungen zwischen den graphischenElementen darstellen. Typischerweise sind besonders objektorientierte vi-suelle Sprachen mit dem Problem behaftet, durch viele Querverbindungenzwischen Objekten den Programmierer schnell zu verwirren [9]. Anderer-seits sind Datenflussdiagramme ein gutes Beispiel für die Deutlichkeit vonBeziehungen.

4. Reaktionsverhalten. Änderungen am existierenden visuellen Programmkönnen zu syntaktischen Fehlern führen. Je früher der Programmierer neueFehler der Veränderungen visualisiert bekommt, desto einfacher gestaltetsich die Fehlerbehebung.

2 Microsoft Visual Programming Language

Die Microsoft Visual Programming Language (MVPL) wird mit dem MicrosoftRobotics Studio ausgeliefert. Zur Editierung der MVPL wird dabei eine graphi-sche Entwicklungsumgebung 7 (IDE) mit ausgeliefert. Sie erlaubt die Erstellungvon Roboteranwendungen, die von simplem Textausgaben bis hin zu komplexenRoboterentwicklungen reichen. Solche Roboteranwendungen benötigen die Un-terstützung für parallele Prozesse, verteilte Anwendungen und asynchrone Sens-ordaten bzw. Motorkommandos. Microsoft entschied sich für das Konzept derDatenflussdiagramme, welches die Darstellung paralleler Prozesse ermöglicht.Dieses Konzept steht allerdings im Kontrast zu bisherigen .NET Programmier-sprachen wie C#, VisualBasic und C++, welche imperativ arbeiten. Im Gegen-satz zu den typischen .NET Sprachen findet auch die Objektorientierung keineAnwendung. Schon vorhandene .NET Bibliotheken können in visuelle Program-me bisher jedoch noch nicht eingebunden werden. Nach Morgan [6] ist die MVPLauch nicht als Universalsprache gedacht, sondern speziell auf die Umgebung derRobotik zugeschnitten. Zur Entwicklung von Programmen zieht der Nutzer Pro-grammblöcke per Drag & Drop auf die Arbeitsfläche. Im Abschnitt 2.3 werdendiese Blöcke näher erläutert. Da keine textuelle Zwischenrepräsentation für dieAusführung der MVPL benötigt wird, gehört sie zu den puren visuelle Systemen.Die neuste MVPL Version bietet zusätzlich die Möglichkeit C# Code zu gene-rieren, wodurch gleichzeitig die Einordnung in die hybriden Systeme geschehenkann. Beschreibungen zur Klassifikation befinden sich im Appendix A.

Der nächste Abschnitt gibt einen kurzen Überblick über das Robotics Studio,um die MVPL einzuordnen.7 engl. Integrated Development Environment


Abb. 1. Die IDE der Microsoft Visual Programming Language

2.1 Microsoft Robotics Studio

Das Microsoft Robotics Studio(MSRS) 8 wurde Mitte 2006 vorge-stellt und im Dezember 2006 erschi-en die Version 1.0. Mit dieser erstenVersion wurde die Microsoft Visu-al Programming Language zum er-sten Mal ausgeliefert. Bereits Mitte2007 wurde die Version 1.5 vorge-stellt, welche es erstmals ermöglich-te, Roboteranwendungen auf Windows Mobile und Windows Embedded laufenzu lassen. Im April 2008 veröffentlicht Microsoft eine neue Community Tech-nical Preview (CTP) des MSRS. Erstmals wird das Entwickeln von verteiltenApplikationen offiziell unterstützt und das Sicherheitskonzept wurde überarbei-tet. Auch die MVPL erfuhr im Laufe der Zeit Verbesserungen, wie Fehlerüber-prüfung, Unterstützung für die Entwicklung von verteilten Anwendungen sowiedie Möglichkeit C# Code aus dem Diagramm zu generieren. Für den schnellenStart mit komerziell verfügbaren Robotertoolkits wie fischertechnik, Lego, Kukaund iRobot stellt das Robotics Studio schon Services bereit. Im Folgenden wird

8 http://msdn.microsoft.com/en-us/robotics/default.aspx


die CTP April 20089 als Grundlage für Beschreibungen benutzt. Eine Beispiels-anwendung könnte wie rechts dargestellt aussehen. Dabei werden Eingabewerteüber einen virtuellen Joystick oder der Nintendo Wiimote entgegengenommen,durch die Runtime verarbeitet und anschließend zur Ansteuerung des Robotersgenutzt. Der Browser dient im Robotics Studio als Steuerungseinheit um alleeinzelnen Motoren und Sensoren überprüfen zu können.

Zur Laufzeitumgebung des MSRS wie rechtsdargestellt, zählen dabei die Common Langua-ge Runtime (CLR) 2.0, Coordination and Con-currency Runtime (CCR), Decentralized Softwa-re Services (DSS) und Runtime Services. Nebender Laufzeitumgebung wird das MSRS mit einerSimulationsumgebung und der hier vorgestelltenMVPL geliefert.

Die CCR erlaubt dem Programmierer die ein-fache Nutzung von asynchroner Kommunikation. Die als .NET Bibliothek 10

verfügbare Version kann in jedem .NET Programm verwendet werden und ab-strahiert für den Entwickler von komplexen Threading-Vorgängen. Diese Biblio-thek wird innerhalb des Robotics Studio vorrangig für die parallele Anspracheder benötigten Sensoren und Motoren benutzt.

Die DSS stellt dabei eine Service-orientierte Umgebung bereit, welche aufCCR, HTTP und dem Decentralized Software Service Protocol (DSSP)11 auf-baut. In DSS werden Daten REST-basiert 12 ausgetauscht, während die Mani-pulation von Services und der Subscription-Mechanismus mit Hilfe des SOAP-basierten Protocol DSSP ausgeführt werden.

Auf CLR, CCR und DSS aufbauend arbeiten die Runtime Services. Sie stellenServices für die Infrastruktur bereit, wie das Control Panel zum Administrierender einzelnen Services.

2.2 End User

Laut Microsoft sind die Zielgruppen Anfänger und erfahrene Entwickler. Mor-gan [6] bezweifelt dagegen, dass Personen ohne Programmierkenntnisse mit derMVPL Programme schreiben können. Nichtsdestotrotz lässt sich feststellen, dassvorrangig Universitäten das Robotics Studio nutzen. Dazu zählen unter ande-rem: Carnegie Mellon University, Georgia Tech, Hasso-Plattner-Institute, KoreaInstitute of Science and Technology, Massachusetts Institute of Technology, Prin-ceton University und die Stanford University Am Hasso-Platter-Institut wurdeein Bachelorprojekt mit Hilfe der MVPL umgesetzt und die MS Student Partners

9 http://www.microsoft.com/downloads/details.aspx?FamilyId=EB00C558-2163-45A5-BEFE-531AD48BC525

10 http://msdn2.microsoft.com/library/bb48310711 http://purl.org/msrs/dssp.pdf12 http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm


veranstalten Events mit Schülern um ihnen einen Einblick in die Programmie-rung zu geben. Da Schüler tendenziell über wenig Programmiererfahrung verfü-gen, nutzen die MS Student Partners die MVPL zum Erstellen von Programmen.Dabei implementieren die Schüler eine Robotersteuerung, die Lego-Roboter au-tonom durch ein Labyrinth fahren lässt. Nach diesen Erfahrungen haben geradePersonen mit Erfahrung aus imperativen Sprachen Probleme mit der MVPL.Schüler und Studenten aus den ersten Semestern haben dagegen meist wenigProbleme einen schnellen Einstieg zu bekommen. Dass erfahrene Programmierermehr Anfangschwierigkeiten haben, kann durch die Projektmitglieder des Ba-chelorprojektes und aus eigener Erfahrung bestätigt werden. Interessanterweisekommen Experten von National Instruments LabView [?] zu einem ähnlichemErgebnis.

2.3 Graphische Blöcke

Die graphischen Blöcke der MVPL können in Basisaktivitäten und Services un-terschieden werden. Dabei stellen Basisaktivitäten allgemeingültige Konzeptebereit, wie Variablen und für die Datenflüsse entscheidende Strukturen wie Joinund Merge. Funktionen zum Ansprechen von Sensoren oder Motoren werdenüber DSS Services eingebunden und sind nicht Teil der Basisaktivitäten. Wie dieKommunikation zwischen zwei Blöcken geschieht, ist vollständig vom Endnutzerabstrahiert. Er verbindet einfach zwei Blöcke, um eine Verbindung herzustellen.Er muss natürlich darauf achten, die richtigen Datentypen zu kombinieren. Daes sich als schwierig erweist, Datentypen an Services nur über das Eigenschafts-fenster zu erkennen, kann dies Anfangs verwirren. Allgemein können Aktivitätenund Services Eingabewerte entgegen nehmen und als Ausgabe entweder konkreteErgebnisse berechnen oder aber Notifications senden. Diese Notifications könnenfür das Event Triggern verwendet werden. Im Folgenden werden zuerst die Ba-sisaktivitäten vorgestellt, anschließend werden die Services näher betrachtet.

2.3.1 Basisaktivitäten

Name BeschreibungActivity Sie erzeugt eine neue benutzerdefinierte Aktivität, welche es Ent-

wicklern ermöglicht, eigene Blöcke zu definieren. Aktivitäten habenEingabe- und Ausgabewerte, sowie die Möglichkeit, Notifications zusenden. Aktivitäten können als Methoden gesehen werden, welchesich wiederverwenden lassen.

Variable Dieses Element speichert einen Wert, welcher dabei an anderen Stel-len wiederverwendet werden kann. Variablen stellen den Wert globalinnerhalb des Services bereit. Als Datentypen sind im Moment nurprimitive Datentypen sowie Listen möglich.


Name BeschreibungCalcualte Sie führt Berechnungen mit Hilfe der Eingabewerte und globale Va-

riablen durch. Die Berechnung beschränkt sich auf simple mathe-matische Berechnungen wie + (plus), − (minus), × (mult), ÷ (div), % (mod), && (und), || (oder), ! (not). String-Werte können mittels+ verbunden werden.

Data Das Datenfeld wird benötigt um benutzerdefinierte Werte zu setzen.Es wird meist vor Berechnungen und Variablen verwendet.

Join Diese Aktivität lässt zwei verschiedene Datenflüsse zusammenlau-fen. Die aktuellen Daten eines jeden Pfads werden gespeichert undstehen unter den definierten Namen im weiteren Datenfluss bereit.Join synchronisiert dabei die Datenflüsse und erlaubt eine weitereAusführung erst, wenn alle Eingangswerte bereitstehen.

Merge Mit Merge werden zwei Datenflüsse zusammengefasst. Dabei müs-sen nicht wie bei Join an allen Eingängen Werte anliegen.

If...Else Diese Aktivität erlaubt die Beschreibung von Bedingungen. Verglei-che sind dabei mit = (gleich), < (less) und != (ungleich) möglich.

Switch Mit Hilfe dieser Aktivität wird eine Eingangsvariable auf verschie-dene Werte überprüft.

List Erzeugt eine leere Liste mit definierten Datentyp.List Functions Die Manipulation von Listen erfolgt mit dieser Aktivität. Sie er-

möglicht: append, sort, insert item, concatenate.Comment Innerhalb eines Diagramms können Kommentare mit dieser Aktivi-

tät erzeugt werden.

2.3.2 Services Services stellen ein Erweiterungskonzept des MSRS dar undsind nicht spezifisch für die MVPL entwickelt worden. Solche Services werdendirekt mit .NET und dem Visual Studio implementiert oder aus einem erstelltenDiagramm erzeugt. Das Servicekonzept bietet eine gute Möglichkeit die Spra-che durch äußere Komponenten zu erweitern. Das Einbinden von DSS Serviceserfolgt über eine Liste direkt aus der MVPL IDE. Sie werden anschließend wieBasisaktivitäten verwendet. Die Konfiguration der Services erfolgt über ein spe-zielles Eigenschaftsfenster. Dieses erlaubt, initiale Konfigurationen zu erstellenoder sie aus einer vorhandenen Datei zu laden.


2.4 Beispiele

Hello World. Das klassische Hello World sollaufzeigen, wie ein solches ausgegeben wer-den kann. Dazu muss einfach ein Datenfeldsowie ein SimpleDialog und eine TexttoS-peechTTS Service auf die Diagrammflächegezogen werden. Wird dieses Programm aus-geführt, so erscheint der Text im AlertDia-log und wird zusätzlich über die Lautspre-cher ausgegeben.

Schleifen. Auch wenn die MVPLkeine speziellen Blöcke für Schlei-fen bereitstellt, so können die-se über die Datenflüsse dennochrealisiert werden. Rechts wirdeine For-Schleife gezeigt, wel-che von 1 bis 10 zählt und an-schließend die letzte Zahl in dasLog schreibt sowie als Text aus-gibt. Die Variablen Count undEnd werden als globale Varia-ble initialisiert, welche jeder-zeit über den Zustand des Dia-gramms abgefragt werden können. Hieraus ist vor allem sichtbar, dass Schlei-fen viel Platz auf dem Monitor verbrauchen und die automatisch gezeichne-ten Verbindungen nicht immer optimal dargestellt werden. Durch die im-mer von links nach rechts laufenden Verbindungen ist es nicht möglich eineSchleife ohne Verbindungskreuzungen im Diagramm zu erstellen.

Rekursion. Die MVPL findet für Re-kursion einen einfachen intuitivenWeg.Die Berechnung der Fibonacci-Zahlerfolgt durch die Formel f0 = 0, f1 =1, fn = fn − 1 + fn − 2(n > 1). Links wird dabei die Eingabe von Daten indie Fib-Aktivität gezeigt. Abbildung 2 stellt die Implementierung der Fib-Aktivität selbst dar. Hierbei sind die Ein- und Ausgabevariablen nicht aufAnhieb sichtbar. Diese werden nur über ein separates Fenster angezeigt. DasBeispiel zeigt, dass die Umsetzung der Rekursion wie erwartet funktioniert.

WiiMote gesteuerter Roboter. Zum Testen der Skalierbarkeit wurde die Wi-imote als Eingabegerät und ein Lego Tribot 13 miteinander verbunden. Umdem Roboter vorwärts, rückwärts sowie rechts und links steuern zu können,

13 http://mindstorms.lego.com/Overview/MTR_TriBot.aspx


Abb. 2. Implementation der Fibonacci-Funktion

werden die Informationen aus den Beschleunigungssensoren der WiiMote be-nutzt. Als Grundlage zur Ansteuerung der Wiimote wird die WiimoteLib 14

verwendet, welche einen Service für das MS Robotics Studio mitliefert. DieserService sendet eine Notification sobald neue Daten aus den Sensoren vorlie-gen. Anschließend wird Rotation und Neigung der Wiimote mit Hilfe vonroll = arctan2(ax,

√(ay2 + az2)) und pitch = arctan2(ay,

√(ax2 + az2))

berechnet15. Diese Daten liefern den Winkel um die X und Y Achse derWiimote. Diese berechneten Winkel können direkt für die Beschleunigungder Motoren verwendet werden. Um ein Lenkverhalten zu erzeugen, wird dieNeigung auf dem rechten Rad addiert und auf dem linken Rad subtrahiert.Anschließend werden die berechneten Daten an ein Lego NXT Drive Ser-vice gesendet. Während der Implementierung ist besonders aufgefallen, dasstiefe Schachtelungen von Aktivitäten zu langsamerer Ausführung führen.Weiterhin gestaltete sich das Implementieren der relativ einfach gehaltenenBerechnungen von roll und pitch als ziemlich schwierig. Nimmt diese Formelnormalerweise nur 2 Zeilen an Platz, so benötigt die Implementierung in derMVPL IDE mehr als eine Bildschirmfläche. Wird PI für die Winkelumrech-nung anstelle einer eigenen Konstante aus dem Math Service bezogen, istder Roboter nicht mehr ohne merkliche Verzögerung steuerbar. Illustratio-nen finden sich im Appendix D.

2.5 Ausführung und Debugging

Das Ausführen von Diagrammen aus der MVPL IDE ist sehr einfach möglich.Das Programm wird sofort nach einem Klick auf Ausführen ausgeführt. Möchteder Programmierer Einblick auf den Zustand einzelner Services gelangen, so muss

14 http://www.codeplex.com/WiimoteLib15 http://www.wiili.org/index.php/Motion_analysis


er über den Browser den zusätzlichen Status abfragen. Auch das Debuggingfunktioniert über dem Browser. Allerdings gestaltet sich die Bedienung als nichtsehr intuitiv, da Breakpoints nicht per unmittelbarer Auswahl der jeweiligenAktivität getätigt werden können. Insgesamt scheint die Systemsteuerung für dasRobotics Studio im Browser durch seine unübersichtlichen Verschachtelungen inder Menustruktur als wenig ausgereift.

3 Analyse

Die Microsoft Visual Programming Language wird nun anhand der VPL DesignGoals und den Skalierungsfaktoren nach [2] analysiert. Erklärungen befindensich zusätzlich im Appendix B. Die Skalierung betrachtet verschiedene Aspek-te einer VPL aus der Nutzersicht, daher wird sie zum Bewerten der End-UserPerspektive herangezogen. Es muss dabei immer betrachtet werden, dass Micro-soft die Sprache noch als Research vermarktet und es sich dabei nicht um einvollständig kommerzielles Produkt handelt. Neben vielen gelungen Dingen, wiedie Verwendung von Datenflussdiagrammen, Fehlerüberprüfung und die leichteEinbindung von externen Services werden im Folgenden vor Allem die Problemeangesprochen, welche für eine Skalierung hinderlich sein können.

Static Representation. Durch die Verwendung von Datenflussdiagrammenverwendet die MVPL im Bereich der visuellen Programmiersprachen eineanerkannte Lösung für diesen Teil.

Effective use of screen real estate. Die MVPL nutzt den Bildschirm imMo-ment nicht sehr effektiv. Zwar werden neben Zoom und Scollbalken auchAktivitäten zum Erzeugen von geschachtelten Diagrammen angeboten, den-noch ist dies nicht ausreichend, da Diagramme schnell über die Bildschirm-größe hinaus wachsen. Eigene Blöcke für Schleifen oder die Gruppierung vonBlöcken wie in LabView würden große unübersichtliche Diagramme verhin-dern. Ansetzen lässt sich auch an den Verbindungen zwischen den Blöcken.Sie verbinden Blöcke immer nur von links nach rechts und führen durchÜberkreuzungen bei komplexen Strukturen schnell zur Unübersichtlichkeit.

Documentation. Der Dokumentationsaspekt fand in der MVPL keine großeFürsorge. Sie unterstützt das elementare Hinzufügen von Kommentaren undsieht zum Sparen von Bildschirmplatz das Minimieren eines Kommentarsvor. Dennoch sind sie nicht direkt mit einzelnen Aktivitäten verknüpft undtendieren damit schnell zum veraltern. Weiterhin nutzen sie nicht annähernddie Möglichkeiten von visuellen Kommentaren aus, da keine Bilder, Skizzenoder Animationen eingebunden werden können.

Procedural Abstracktion. Weiterhin hat LabView der MVPL voraus, dassmarkierte Aktivitäten leicht in eine Überaktivität umgewandelt werden kön-nen. Das bedeutet, dass sich diese Blöcke in einem Unterdiagramm wieder-finden würden. Neben allen Nachteilen macht die Nutzung von Rekursioneinen guten Eindruck und ist intuitiv zu verwenden, wie in der FinbonacciBerechnung in Abschnitt 2.4 gezeigt wurde.


Interactive Visual Data Abstraction Zwar sind einfache Datentypen leichtin MVPL erstellbar, dennoch werden in der Praxis häufig komplexe Da-tentypen benötigt. Da diese bisher nicht unterstützt werden sind teilweisekomplexe Blockstrukturen in einem Diagramm nötigt um eine Implemen-tierung durchzuführen. Die Einführung von komplexen Datentypen würdezusätzlich dazu beitragen, Platz auf dem Monitor zu sparen.

Type Checking. An dieser Stelle wurden in der MVPL sehr viele gute Kon-zepte umgesetzt. Datentypfehler werden sofort erkannt und werden direkt ander betreffenden Stelle angezeigt. Die dabei erzeugten Fehlertexte sind meistsinnvoll und helfen oft weiter. Nichtsdestotrotz darf bemängelt werden, dasssich die Datentypen an den Schnittstellen schlecht erkennen lassen. Sie sindnur über zusätzliche Eigenschaftsfenster sichtbar. Sollte ein Review auf Ba-sis eines ausgedruckten Diagramms erfolgen, so sind Datentypen dabei nichtüberprüfbar.

Persistence. Als Persistenz sieht die Microsoft VPL nur eine SQL Daten-bank vor. Sie unterstützt die Verbindung über ADO.NET. Die Verwendungist allerdings wenig intuitiv und für Personen ohne Programmierkenntnissewahrscheinlich schwer zu meistern. Selbstverständlich könnten weitere exter-ne Services für die Persistierung erstellt werden.

Efficency. Die Effizienz der MVPL wurde nicht durch Performancemessungengetestet, dennoch neigt das Programm bei langer Benutzung dazu langsa-mer zu werden. Daneben ist auch die Laufzeit von erstellten Programmenmit diversen Problemen betroffen. Werden tiefe Schachtelungen mit Unter-aktivitäten genutzt, so steigt die Prozessorauslastung reproduzierbar rapideund macht die geschriebenen Programme unbenutzbar. Die Einbindung einesMath Services erweist sich bei Event-basierten Ereignissen als ungeeignet,da sie viel zu langsam sind. Da keine .NET Library direkt eingebunden wer-den kann, können schon einfache Zusatzfunktionen nur über REST-basierteServices aufgerufen werden. Dass simple mathematische Funktionen wie Tan-gens und Sinus nur über einen Service aufgerufen werden können, scheint we-nig effizient, entspricht aber dem verfolgten Konzept des Servicegedanken.Zusätzlich ist das Debuggen nur über ein separates Browserfenster möglichund stellt Verlaufsaktualisierungen nur flackernd dar, was den Arbeitsflussdeutlich stört. Ein ganz anderer Aspekt ist die Erstellung von Formularen.Sie sind leider nicht, wie aus dem Microsoft Visual Studio gewohnt, übereinem GUI-Editor zu erstellen, sondern nur über ein textuelles Formular-feld. Dies fällt besonders auf, da es gerade für die GUI Entwicklung schonetablierte Konzepte gibt.

Beyond Coding. Das Debuggen wird zwar elementar unterstützt, die nativeIntegration in die IDE wäre allerdings wünschenswert. Zusätzlich bietet dieMVPL nicht die aus LabView bekannten Möglichkeiten zur Anzeige von Da-tenflüssen, welche sich bei einer graphischen Programmiersprache anbietenwürden. Portierbarkeit ist durch das .NET Framework als Basis gegebenund Erweiterungen sind über externe Services immer möglich. Als wichtig-ster Punkt für große Projekte wird die Versionskontrolle und die Möglichkeit,vorhandene .NET Bibliotheken ein zu binden fehlen. Die in großen Projekten


häufig verwendeten Nightly Builds erfordern die Möglichkeit einer separatenKompilierung. Dazu unterstützt MVPL die Kompilierung als .NET Projekt.Anschließend könnte dieses Projekt zum Kompilieren verwendet werden. Diegewählte Umsetzung kann daher für Firmenanwendungen noch stark verbes-sert werden.

3.1 Fazit

Microsoft hat mit der MVPL einen guten Anfang gemacht. Die Sprache ist gutfür Anfänger ohne Programmierkenntnisse geeignet. Die vielen vorgefertigtenServices für das Microsoft Robotics Studio erleichtern den Einstieg erheblich.Werden die Projekte allerdings komplexer, werden vor allem geübte Program-mierer den Quellcode vermissen, da damit Algorithmen meist in kürzerer undeffizienterer Form implementiert werden können. Werden in zukünftigen Versio-nen die Skalierungsfaktoren beachtet, könnte die Microsoft VPL in der Zukunfteine wichtige Rolle spielen.

Literatur

1. M. Boshernitsan and M. Downes. Visual Programming Languages: A Survey.Computer, 2004.

2. Margaret M. Burnett, Marla J. Baker, Carisa Bohus, Paul Carlson, Sherry Yang,and Pieter van Zee. Scaling up visual programming languages. Computer, 28(3):45–54, 1995.

3. S. K. Chang, Margaret M. Burnett, Stefano Levialdi, Kim Marriott, Joseph J.Pfeiffer, and Steven L. Tanimoto. The future of visual languages. In VL ’99:Proceedings of the IEEE Symposium on Visual Languages, page 58, Washington,DC, USA, 1999. IEEE Computer Society.

4. Philip T. Cox, Hugh Glaser, and Stuart D. Maclean. A visual development envi-ronment for parallel applications. In VL ’98: Proceedings of the IEEE Symposiumon Visual Languages, page 144, Washington, DC, USA, 1998. IEEE ComputerSociety.

5. Philip T. Cox and Trevor J. Smedley. Visual programming for robot control.In VL ’98: Proceedings of the IEEE Symposium on Visual Languages, page 217,Washington, DC, USA, 1998. IEEE Computer Society.

6. Sara Morgan. Programming Microsoft Robotics Studio. Microsoft Press, 2008.7. BA Myers. Visual programming, programming by example, and program visuali-

zation: a taxonomy. Proceedings of the SIGCHI conference on Human factors incomputing systems, pages 59–66, 1986.

8. S. Schiffer. Visuelle Programmierung-Potential und Grenzen. Proc. der GI-96,Beherrschung von Informationssystemen, Mayr, HC (ed.), R. Oldenbourg Verlag,1996.

9. Stefan Schiffer. Visuelle Programmierung - Grundlagen und Einsatzmöglichkeiten.Addison Weslay Longmann Verlag, Bonn, 1998.

10. David Canfield Smith, Allen Cypher, and Jim Spohrer. Kidsim: programmingagents without a programming language. Commun. ACM, 37(7):54–67, 1994.

11. A. Sutcliffe and N. Mehandjiev. SPECIAL ISSUE: End-user development table ofcontents. Communications of the ACM, 47(9):31–32, 2004.


A Klassifikation

Der Umgang mit visuellen Programmiersprachen erfordert die Klassifikation inverschiedene Kategorien. Die folgenden Klassen sind Boshernitsan et al. [1] ent-nommen. Die Einordnung in die jeweilige Klasse ist nicht exklusiv und Mehrbe-legungen sind möglich.

1. Pure visuelle Systeme Diese Sprachen benutzen einen kompletten visu-ellen Entwicklungsprozess und kompiliert direkt von der graphischen Notati-on, ohne eine textuellen Zwischenrepräsentation zu benutzen. Sprachen wiePrograph und PICT sind hier als Beispiele zu nennen.

2. Hybride textuelle und visuelle Systeme Hybride Sprachen nutzen diegraphische Repräsentation aus, werden allerdings für die Ausführung in einetextuelle Form umgewandelt. Ein Beispiel ist Rehearsal World, dass nachder Fertigstellung ein Smalltalk-Programm generiert.

3. Programming-by-example Systeme Bei diesen Sprachen nutzt der Pro-grammierer Beispiele um dem Computer neues Verhalten beizubringen. Kid-Sim, Pygmalion und Rehearsal World sind Vertreter dieser Kategorie.

4. Constraint-orientierte Systeme Solche Sprachen nutzen ein Model, umdie Umgebungparameter festzulegen. Der Programmierer benutzt das Modellum einzelne Aspekte zu simulieren. So simuliert zum Beispiel das AlternateReality Kit (ARK) eine physikalische Welt. Der Benutzer kann durch einevirtuelle Hand Objekte platzieren und die Gravitation messen.

5. Formular-basierte Systeme Diese Sprachen nehmen das Konzept der Ta-bellenkalkulation auf. Variablen werden meist durch Formel verbunden. Ver-änderungen in einer Zelle werden dann „automatisch“ für die Berechnung derabhängigen Werte benutzt. Hier sticht besonders Forms/3 hervor.

B Skalierbarkeit

Als ein größeres Problem wurde die Skalierbarkeit von visuellen Sprachen durchBurnett et al.[2] und Schiffer [8] identifiziert. Skalierbarkeit versucht zu Beschrei-ben, wie sich visuelle Programmiersprache bei einfachen und komplexen Proble-men zu verhalten hat. Ist die visuelle Programmiersprache bei 50 Entwicklernan einem Projekt genauso effizient wie bei einem kleinen 3 Stunden Projekt?Burnett [2] hat verschiedene Faktoren identifiziert, welche für eine skalierbarevisuelle Programmiersprache von Nöten sind. Da diese Faktoren für die Bewer-tung der Microsoft Visual Programming Language aus Sicht des Endbenutzerseine Rolle spielen, werden die einzelnen Aspekte im Folgenden näher beschrie-ben. Die Skalierbarkeit eignet sich besonders gut für die Sicht des Endbenutzers,da sie Designziele aus Nutzersicht und nicht aus technischer Sicht verfolgen.

B.1 Representation Issues

Static representation. Die Darstellung einer Programmiersprache kann dyna-misch oder statisch sein. Beispiele solcher statischen Repräsentationen sind


textuelle und Datenfluss-basierte Sprachen sowie Zustandsübergangdiagram-me. Dagegen erschweren dynamische Sprachen der Kategorie Programming-by-Example den Programminhalt zu reviewen, analysieren und zu erklären.Ermöglicht die verwendete Sprache die Verwendung von mehrdimensionalenDatenstrukturen wie z.B. Animationen, kann eine statische Repräsentationschwer zu finden sein. Die Editierbarkeit des Programms ist dabei immer dasZiel. Ein Programm sollte mit einem normalen Monitor ohne umständlichesSkrollen erstellbar sein.

Effective use of screen real estate. Die beschränkte Fläche des Computer-bildschirms erschwert die Darstellung von großen visuellen Programmen. Dieeffektive Nutzung des vorhandenen Raums ist daher wichtig. Dazu reichenskrollbare Fenster und Ikons nicht aus, da sie das Problem nicht an der Ursa-che beheben. Größere Programme benötigen Techniken, um Programmstruk-turen zu organisieren. Dazu gehören unter andem der Zugriff auf bestimmteProgrammteile und das Suchen von einzelnen Aspekten.

Documentation. Meist lassen sich nicht alle relevanten Informationen für einenProgrammierer im Quelltext notieren. Zusätzliche Kommentare ermöglichenunter anderem das Erklären einzelner Aspekte oder aber von Konzepten. Diemeisten visuellen Programmiersprachen unterstützen dabei textuelle Doku-mentation. Kann die Dokumentation nicht ausgeblendet werden, so benötigtsie mitunter viel Platz und steht dem Bildschirmplatzverbrauch entgegen.Konzepte wie das Anzeigen von Dokumentation unter dem Mauszeiger oderdas Hineinziehen von Objekten in ein Dokumentationsfenster helfen, um die-se Probleme zu verhindern. Während die textuellen Programmiersprachen esnur ermöglichen, Kommentare mit Text zu gestalten, können visuelle Pro-grammiersprachen auch Grafiken, Filme und Zeichnungen verwenden. Ist dieDokumentation allerdings völlig unabhängig vom Quelltext, kann es passie-ren, dass diese Dokumentation sehr schnell veraltert. Alternativ sind auchandere Formen zur Verständnisförderung möglich, indem das Programm mitBeispielswerten getestet werden oder der Programmierer den Verlauf visuellanschauen kann.

B.2 Language Issues

Procedural Abstraction. In textuellen Programmiersprachen wurde schon sehrfrüh erkannt, dass die Strukturierung von Quelltexten eine wichtige Aufgabeist und das Verständnis fördern kann. Die Aufteilung in Untergraphen, Ver-wendung von Funktionen oder ganzen Bibliotheken ist schon lange in Nut-zung. Eine visuelle Programmiersprache sollte Mechanismen mitbringen, diees ermöglichen das Programm ebenso zu strukturieren.

Interactive visual data abstraction. Benutzt die visuelle Programmierspra-che Konzepte, wie Variablen kommen Datentypen bei statisch getypten Spra-chen ins Spiel. Um dem Konzept der visuellen Programmiersprache zu ent-sprechen, sollten diese auch visuell erstellbar sein. Das bedeutet, dass dergesamte Prozess zur Erstellung von neuen Datentypen bis zur Verwendung


durch die Sprache umgesetzt sein sollte. Neben den selbst erstellen Daten-typen muss das Event Handling unterstützt werden.

Type checking. Wie alle modernen Programmiersprachen können auch visuel-le Programmiersprachen verschiedene Varianten der Typüberprüfung durch-führen. Grundsätzlich lassen sich drei verschiedene Varianten der Überprü-fung unterscheiden: statische Typüberprüfung mit expliziten Datentypen,dynamische Typüberprüfung und statische Typüberprüfung mit implizitenDatentypen. Der erste Fall ermöglicht das frühe Erkennen von Fehlen schonwährend der Compile-Time, erhöht die Effizienz des Programmierens unddient dem Entwickler als Dokumentationshilfe. Dagegen vereinfacht die dy-namische Typüberprüfung die Programmierung, konzeptionelle Fehler, wiedie Zuweisung eines falschen Datentyps, sind allerdings meist erst währendder Laufzeit erkennbar. Die statische Typüberprüfung mit impliziten Da-tentypen nutzt die Eingaben des Entwicklers, um den Typ zu überprüfen.Verwendet dieser y = 5, so kann implizit darauf geschlossen werden, dass yein Integer darstellen sollen. Dieses Konzept kann die Einfachheit der Spra-che erhöhen, ermöglicht allerdings auch schnell Fehler in der Zuweisung vonVariablen zu erkennen.

Persistence. Unter bestimmten Bedingungen möchte der Programmierer Da-ten abspeichern. Verschiedene Ansätze wie direktes I/O Handling, eingebun-dene Datenbanksprache oder ein transparentes Speichern sind möglich. Aufjeden Fall wird ein Konzept benötigt, welches den VPL Designzielen nichtentgegensteht.

Efficency. Die visuelle Programmiersprache soll neben den schon genanntenFaktoren sich auch effizient verhalten. Insbesondere das Verhalten der Pro-grammierumgebung bei steigender Programmgröße ist von Interesse. Für dieSprache müssen daher Techniken entwickelt werden, welche die Program-meffizienz unabhängig von der Programmgröße beibehalten. Zusätzlich sol-len Programmveränderungen ohne störende Faktoren wie flackernde Bilder,langsamer Aufbau oder verzögerte Ausführung dargestellt werden. Der End-benutzer sollte jederzeit Feedback über Veränderungen bekommen.

B.3 Beyond Coding

Neben den reinen Programmierungsaufgaben fallen für den Entwickler Aufgabenwie das Entwerfen, Testen und Debuggen an. Dabei unterstützen viele VPLsdurch sofortigen visuellen Feedback das Testen und Debuggen. Optimalerwei-se wird das Konzept der Breakpoints gar nicht benutzt, sondern der Endbe-nutzer erhält direkt Feedback über die laufenden Daten. Beispielsweise könnenDatenflussdiagramme genutzt werden, um den aktuellen Verlauf darzustellen.Muss der Entwickler zwischen Programmieren, Testen und Debuggen nicht ex-plizit unterscheiden, kann dies zum schnelleren Verständnis beitragen. Heut-zutage werden neben der reinen Programmiersprache viele Tools zur Verbes-serung des Software-Lifecycle genutzt. Dazu gehören Versionskontrolle, separateKompilierung, Bibliothekserzeugung, Portierbarkeit, Erweiterbarkeit oder Cross-Language-Interoperability.


C Debugger

Abb. 3. Debug Ansicht der Microsoft Visual Programming Language

D Wiimote und NXT Beispiel


Abb. 4. WiiLego Hauptprogramm


Abb. 5. Aktivity: WiiAngles

Documents

Microsoft Visual Programming Language: End-User Perspektive · 2 ChristophHartmann wurde1987dasAlternateRealityKit(ARK)entwickelt,welcheesvisuellerlaub-te,dieGravitationvonObjektenzutesten.Dassnebendenzwei-dimensionalen