• Keine Ergebnisse gefunden

für visuelle Programmierung

N/A
N/A
Protected

Academic year: 2022

Aktie "für visuelle Programmierung"

Copied!
39
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Grundprojekt

Lukas Lühr

Konzeption eines Smart Object Development Frameworks

für visuelle Programmierung

(2)

Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einleitung 1

2 Smart Objects 2

2.1 CSTI - Creative Space for Technical Innovations . . . 2

2.2 Zielsetzung . . . 3

3 Beispielszenario - Ein akustischer Ball 5 3.1 Technische Beschreibung . . . 5

3.2 Alternative Szenarien . . . 7

4 Visuelle Programmierung 8 4.1 Programmablaufplan . . . 8

4.2 Nassi-Schneiderman-Diagramme . . . 8

4.3 Event-driven Programming . . . 9

4.4 Datenstromorientierte Programmierung . . . 9

5 Entwurf eines Frameworks 11 5.1 Entwurf des Beispielszenarios . . . 11

5.2 Datenstruktur . . . 12

5.2.1 Notation . . . 12

5.2.2 Namensräume . . . 13

5.2.3 Interfaces . . . 15

5.2.4 Komponenten . . . 16

5.2.5 Komponenten-Netze . . . 16

5.2.6 Komponenten-Nodes . . . 19

5.2.7 Netze . . . 20

5.3 Lebenszyklus eines Netzes . . . 22

5.3.1 Build . . . 22

5.3.2 Deployment und Startup . . . 24

5.3.3 Steuerung zu Laufzeit . . . 24

5.4 Textuelle Repräsentation . . . 25

6 Ausblick/ Zusammenfassung 32

Literatur 33

(3)

Inhaltsverzeichnis

Selbstständigkeitserklärung 36

(4)

1 Einleitung

1 Einleitung

Gegenstand dieses Grundprojektes ist die Konzipierung eines Frameworks, welches ei- ne Realisierung von Smart Objects bzw. Systemen aus mehreren Smart Objects, durch Konzepte der grafische Programmierung, ermöglichen soll.

Ziel ist es hierbei, sowohl erfahrenen Entwicklern als auch fachfremden Personen ein Werkzeug für ein produktives Arbeiten bereitzustellen. Um dies zu erreichen, wird neben einem visuellen auch ein klassisch textueller Ansatz der Repräsentation verfolgt. Der visuelle Ansatz soll ein exploratives Arbeiten und Lernen ermöglichen, und somit einen Einstieg erleichtern, aber auch als grafisches Artefakt das Vermitteln des Verhaltens eines Systems ermöglichen. Durch die textuelle Sicht sollen Vorteile der Eingabe durch eine Tastatur genutzt, und die Akzeptanz des Frameworks unter Entwicklern erhöht werden.

Die Arbeit ist wie folgt strukturiert: Einleitend wird zunächst das Themengebiet um Smart Objekts beleuchtet, gefolgt von einer Abgrenzung der Zielgruppen. Hiernach wird ein Beispielszenario um einen mit Sensorik angereicherten Ball vorgestellt. Dieses wird zur Veranschaulichung der Funktionsweise des Frameworks herangezogen. Anschließend werden Ansätze der grafischen Programmierung vorgestellt, um hierauf aufbauend ein Konzept für das zu entwickelnde Framework zu erarbeiten. Aufbauend auf dem Konzept wird eine textuelle Repräsentation vorgestellt und Teile einer grafischen Repräsentati- on umrissen. Abschließend werden die Ergebnisse zusammenfassend dargelegt, und ein Ausblick, in welchem offene Punkte sowie ein mögliches weiteres Vorgehen beschrieben werden, gegeben.

(5)

2 Smart Objects

2 Smart Objects

Der Begriff Smart Object beschreibt um mit Informations- und Kommunikationstechno- logien angereicherte physikalische Objekte. Smart Objects lassen sich je nach konkreter Ausprägung in den Kategorien Internet of Things (IoT) und Industry 4.0 einordnen, wel- che gemeinsam das Forschungsfeld der Cyber-physical Systems (CPS) bilden. Ein CPS ist dabei ein System, welches sowohl aus mechanischen, elektronischen und informations- technischen Komponenten besteht und durch deren Zusammenspiel ausgemacht wird.

[23]

Forschung im Bereich von CPS wird beispielsweise im Rahmen der deutschen Hightech- Strategie 2014 insbesondere im Kontext industrieller Produktionsanlagen und Vernetzung als Industrie 4.0 gefördert. [11]

Ein Smart Object als CPS, oder als Bestandteil in einem größeren System, ist in der La- ge mittels Sensorik seine Umgebung zu erfassen, durch Kommunikationstechnologien mit anderen Smart Objects bzw. Servicen verbunden zu werden, und Veränderungen in seiner Umwelt zu bewirken. Ziel ist es hierbei, physikalische Objekte mit dynamischen Eigen- schaften digitaler Objekte auszustatten, die über den ursprünglichen Verwendungszweck hinaus gehen, um somit einen Mehrwert zu generieren. [23]

Als Kernkompetenzen von Smart Objects können die fünf allgemeinen Fähigkeiten zur Datenerfassung, Datenverarbeitung, Datenhaltung, Interaktion mit der Umgebung und Kommunikation betrachtet werden. [21]

2.1 CSTI - Creative Space for Technical Innovations

Diese Arbeit wird im Kontext des Labors /*Creative Space for Technical Innovations*/

(//CSTI) der HAW Hamburg durchgeführt. Das //CSTI ist eine Plattform, welche durch Technologien und Methoden aus der Informatik, Mechatronik, Design- und Kunst, sowie den Sozial- und Kulturwissenschaften (inter-)disziplinäre Projekte, Kooperationsformate, Studien, Abschlussarbeiten und Workshops ermöglicht. [2]

Hierbei werden unter anderem auch Smart Objects behandelt. So wurde etwa für das In- novationsforums eCulture das Projekt Shelldon, ein Schwarm kommunizierender Schild- kröten, entwickelt. Diese tauschen Informationen über ihre Position in der Welt aus, und

(6)

2 Smart Objects

agieren gegebenenfalls gemeinsam. Zum Einsatz kamen hierbei 3D-Druck, Beleuchtung, Sensorik und Netzwerk Komponenten. [24]

Ein anderes Beispiel ist die Entwicklung eines interaktiven und proaktiven Smart Ob- jects in Form einer Pflanze, welche mittels Feuchtigkeits-Sensor Wasserbedarf ermittelt und bei Bedarf nahestehende Personen mittels Microsoft Kinekt lokalisiert und durch Gesichtserkennung identifiziert. Dies ermöglicht es, potentielle Gießer zu ermitteln und via Sprachsynthese zu kontaktieren. Zusätzlich erfolgt eine Anbindung an einen Online Kalender von potentiellen Gießern. [32]

Smart Objects kommen auch im Kontext von künstlerischen Installationen und Ästhe- tik vor, wie beispielsweise bei dem Projekt IVORY [10], welches ein Tangable Interfaces realisiert, um nicht direkt wahrnehmbare Informationen, in diesem Falle Luftqualität, unmittelbar optisch und akustisch erfahrbar zu machen. Hierbei wird auch auf Sonnifica- tion, also die Nutzung von nicht sprachlichem Audio zur Vermittlung von Informationen zurückgriffen [20].

2.2 Zielsetzung

Um das Entwickeln von Smart Objects zu beschleunigen und die Wiederverwendbarkeit von Objekten oder Teilkomponenten zu erleichtern, soll eine Sammlung von Werkzeugen beziehungsweise ein Framework geschaffen werden, welches eine einheitliche Struktur bietet und repetitive Arbeitsschritte weitgehend vermeidet.

Das zu entwickelnde Framework soll zweierlei Zielgruppen bedienen, einerseits sollen Informatiker und professionelle Anwender andererseits aber auch Einsteiger, etwa Teil- nehmer eines Workshops wie smileIT [7] angesprochen werden.

Im Kontext von Schulungen oder Workshops soll Nicht-Informatikern die Nutzung des Frameworks ermöglichen, auf explorative Weise Smart Objects und verteilte Systeme zu entwickeln. Hierzu soll die Logik von Smart Objects in einer visuellen Programmierspra- che repräsentiert werden, welche unterstützt durch eine zugehöriger IDE ein exploratives Arbeiten ermöglicht.

Ergänzend hierzu soll auch ein rein textueller Einsatz, etwa für die Vorbereitung von Schulungen und Workshops, der Entwicklung von wiederverwendbaren Teilkomponenten oder von Anwendungen aus Teilkomponenten, möglich sein.

(7)

2 Smart Objects

Der Fokus liegt in dieser Arbeit auf der Struktur des Frameworks und der textuellen Repräsentation.

(8)

3 Beispielszenario - Ein akustischer Ball

3 Beispielszenario - Ein akustischer Ball

Um den Umgang mit dem Framework zu veranschaulichen, wird ein Beispielszenario ver- wendet. Konkret werden die Bewegungen eines Balles mittels Modell basierter Sonifikati- on [20] hörbar gemacht. Hierzu wurde ein Ball mit Sensorhardware ausgestattet, welcher mittels WLAN, Informationen über seine Bewegungen an ein Audio-Synthesemodell sen- det, das wiederum durch eine Netzwerkverbindung eine Wiedergabeeinheit mit einem Audiostrom versorgt.

Eine mögliche grobe Aufteilung des Szenarios sind die Komponenten Sensorik, Synthe- se und Wiedergabe. Die Abbilung 1 zeigt eine mögliche Sicht auf das Gesamtsystem:

Die Sensorik liefert hierbei Sensorwerte für die Audiosynthese, welche wiederum einen Audiostrom für die Wiedergabe-Komponente generiert.

Abbildung 1: Mögliche Sicht des Systems, Bestandteile als Datenquellen

3.1 Technische Beschreibung

Um ein möglichst breites Technologiespektrum abzudecken, werden für die Realisierung des Szenarios drei unterschiedliche Plattformen verwendet, welche über eine Netzwerk- schicht miteinander kommunizieren.

Für die Erfassung von Sensorwerten und die Weiterleitung dieser mittels WLAN wird ein ESP-8266 [15] Micro Controller verwendet. Als Sensor ist ein MPU6050 (Six-Axis MEMS MotionTracker) mittelsI2Can diesen angebunden. Der Sensor verbindet ein drei Achsen Gyroskop, ein drei Achsen Akzelerometer sowie einen Temperatursensor in einer Einheit. Das Gyroskop ermöglicht Messungen mit einer Genauigkeit von +-250 grad/sec bis zu +-2000 grad/sec und das Akzelerometer kann mit einer Genauigkeit von +-2g bis zu +-16g betrieben werden. [19] Die nötige Logik wird plattformbedingt in C++

realisiert.

Für die Audiosynthese wird ebenfalls C++, jedoch auf einer x64 Linux Maschine, verwen- det. Das Produkt der Audiosynthese wird abschließend als Audiostrom an die Wiedergabe-

(9)

3 Beispielszenario - Ein akustischer Ball

(a) Offenes Gehäuse (b) Hardware Cylinder (c) Ball mit Ladekabel Abbildung 2: Der mit Sensorik angereicherte Ball, in Einzelteilen und montiert

Komponente geleitet. Die Wiedergabe-Komponente läuft in Python auf einem Raspberry Pi.

Unabhängig von der Software soll die Hardware des Balles für spätere Arbeiten als Platt- form weiter verwendet werden können.

Als Gehäuse dient eine mittel FDM in PLA gedruckte Kugel mit einem Durchmesser von 70mm und einer Wandstärke von 4mm. Das obere Drittel der Kugel ist mit dem unteren Teil der Hülle verschraubt. Abbildung 2 zeigt den Ball.

Die Elektronik ist in Form eines Zylinders (siehe Abbildung 2b) um einem mittigen Akku angeordnet, um den Schwerpunkt des Balles möglichst zentral und den Durchmesser klein zu halten. Um den Akku zu laden, steht ein drei poliger Anschluss im Deckel des Balles zu Verfügung.

Für die Stromversorgung werden ein 300mAh 7.2V LiPo Akku und ein MP1584 basierter Abwärtswandler verwendet, um 5V zu erhalten.

Um eine unbeabsichtigte Entladung des Akkus zu vermeiden, kann die Stromversorgung vor dem MP1584 mittels eines Schalters unterbrochen werden. Dieser Schalter kann be- tätigt werden, wenn der Ball geschlossen ist.

Die 5V werden genutzt, um zwei RGB-LEDs (WS2812B) und ein ESP8266 Development Board mit Strom zu versorgt.

Auf dem verwendeten ESP8266 Board ist ein weiterer Spannungswandler verbaut, um 3.3V Betriebsspannung zu erhalten, welche von dem verbauten Sensor(MPU6050) und dem Micro Controller benötigt werden.

Zusätzlich sind noch drei Montagepunkte für Taster im Deckel des Gehäuses, und ein Piezoschallwandler vorhanden, welche jedoch noch nicht verwendet werden.

(10)

3 Beispielszenario - Ein akustischer Ball

Innerhalb des Gehäuses werden die einzelnen Komponenten mittels Punkt zu Punkt Wickelverbindung verdrahtet. Diese können angefertigt werden, während die Hardware am Gehäuse montiert ist. Dadurch entfällt ebenfalls die Verwendung eines Lötkolbens bei der Endmontage, zusätzlich können Verbindungen nahezu beliebig oft wieder entfernt und neu angelegt werden, was insbesondere für den Einsatz bei Schulungen oder Workshops interessant sein könnte.

3.2 Alternative Szenarien

Das Beispielobjekt verfügt über Hardware, welche im Beispielszenario nicht verwendet wird. Konkret sind die drei Taster, die LEDs sowie der Piezosummer für eine spätere Verwendung in anderen Szenarien vorgesehen.

So könnte der Summer etwa verwendet werden, um auf einen externen Lautsprecher zu verzichten, und das Objekt selber als Schallquelle zu verwenden. Etwa zur Signalisierung eines niedrigen Akku-Ladezustandes oder dem Wiedergeben von Audiosignalen.

Auch könnte die Hardware verwendet werden, um Spiele wie etwa Hot Potatoe [6] oder auch User Interface Elemente über die Sensorik, den Summer und die LEDs zu realisie- ren.

(11)

4 Visuelle Programmierung

4 Visuelle Programmierung

Visuelle Programmiersprachen ermöglichen die Erstellung von Programmen durch ein grafisches und nicht ausschließlich textbasiertes Medium. Dabei werden unterschiedliche Ansätze, die Programmlogik zu repräsentieren, verfolgt. An dieser Stelle werden verschie- dene Ansätze der visuellen Programmierung beschrieben, und teilweise auf ihre praktische Anwendung eingegangen.

4.1 Programmablaufplan

Programmablaufpläne sind ein relativ altes Mittel zur Planung bzw. Dokumentation von Programmabläufen. Die ursprünglichen Symbole und deren Bedeutung sind in der 1983 erschienenen DIN 66001 [12] definiert.

Programmablaufpläne bilden imperative Programmierung ab, wodurch sie einem Nutzer wenig Limitierungen auferlegen, und analog zu klassischer imperativer Programmierung, ein Sprunganweisung bereitstellen. Hierdurch wird nicht strukturierte Programmierung, bzw. Spaghetti Code, ermöglicht. [31] Strukturen der strukturierten Programmierung werden nicht direkt abgebildet, können aber wie in flowgorithm nachgebildet werden.

Programmablaufpläne können beispielsweise in der Lernumgebung Kara verwendet wer- den, um das Verhalten eines virtuellen Marienkäfers zu steuern. [34]

Eine weitere Implementation von grafischer Programmierung mittels Ablaufplan, wenn auch nicht strikt im Sinne von DIN 66001, ist Flowgorithm, diese ermöglicht das Erstel- len von Programm Ablaufplänen und übersetzen dieser in 26 verschiedene Programmier- sprachen, darunter auch C++, Java, Python und Ruby. Da jedoch nicht alle Zielsprachen imperative Programmierung mit Sprüngen unterstützen, werden die Ablaufpläne auf Ele- mente der strukturierten Programmierung limitiert. [3]

4.2 Nassi-Schneiderman-Diagramme

Einige grafische Programmiersprachen setzen auf Konzepten von Nassi-Shneiderman- Diagrammen (NSD), und somit auf strukturierter Programmierung, auf. Die in DIN 66261 beschriebene Repräsentation bildet konzeptionell strukturierter Programmierung ab, und stellt hierfür die Kontrollstrukturen in Form von Bausteinen, welche verbunden

(12)

4 Visuelle Programmierung

werden, da [13]. Dieser Ansatz verhindert, je nach verwendetem Editor, Syntaxfehler und ermöglicht ein exploratives Kennenlernen der Repräsentation.

Wie auch Programmablaufpläne unterstützt Kara ebenfalls das Arbeiten mit Nassi- Shneiderman-Diagrammen. [34]

Im Bereich von Hardwareentwicklung gibt es unter anderem Vertreter wie Ardublock [1]

oder Grasp.IO [4], welche das Programmieren von Arduino bzw. Raspbery Pi mittels NSD ähnlichen Ansätzen ermöglichen, und teilweise Hardware Module integrieren.

4.3 Event-driven Programming

Ein weiterer Ansatz, welcher ebenfalls durch grafische Sprachen aufgegriffen wird, ist Event-driven Programming. Hierbei wird der Programmfluss durch interne oder exter- ne Events gesteuert, auf welche entsprechend reagiert wird. Event-driven Programming wird beispielsweise im Kontext von Benutzerinterphasen eingesetzt, ein Mausklick oder Tastendruck des Nutzers wird hierbei als Event, welches durch entsprechende Handler bearbeitet wird, verstanden.

Auch im Bereich der Spieleentwicklung kann ein Event basierter Ansatz für die Ab- bildung der Anwendungslogik verwendet werden. Beispiele hierfür sind etwa die Spiele Engine Construct3 [8] oder die von Micrsoft entwickelte Lernumgebung Kodu [25], welche Kindern einen spielerischen Einstieg in die Entwicklung von Programmen bieten soll.

Ein weiteres Beispiel aus der Aufgabenautomatisierung ist IFTTT (If This Then That), ein Webservice, welcher eine breite Landschaft aus Produkten von über 600 Marken integriert, welche in wenn-dann-Regeln verschaltet werden können. [5]

Ein Kritikpunkt, welcher oftmals an dem Event orientierten Ansatz angebracht wird ist, dass Programme zu einer flachen Struktur und hoher Komplexität neigen, und dadurch fehleranfällig sind. [33]

4.4 Datenstromorientierte Programmierung

Programme werden in Datenstromorienterter Programmierung (eng.: Dataflow program- ming) als ein gerichteter Graph von Operationen, in welchem Daten über die Kanten fließen, abgebildet.

(13)

4 Visuelle Programmierung

Durch die direkte Abbildung von Datenflüssen eignet sich dieser Ansatz gut für Daten- verarbeitungsaufgaben. Ein Vertreter ist beispielsweise LabVIEW (Laboratory Virtual InstrumentationEngineering Workbench) des US Hard- und Softwareproduzenten Na- tional Instruments, welcher es ermöglicht in einer visuellen Programmiersprache virtuelle Instrumente etwa für Bereiche der Regelungs- und Automatisierungs- sowie Messtechnik zu erstellen. [29]

Ein weiteres etabliertes Beispiel für Datenflussorienterte Programmierung ist Simulink, eine grafische Entwicklungsumgebung, welche auf Matlab aufsetzt. Simulik wird für Si- mulation und Model-Based Design beworben, und ermöglicht teilweise das Generieren von C und VHDL Code aus entwickelten Lösungen etwa für einen direkten Einsatz auf FPGAs. [22]

Auch im Bereich von eher klassischer Anwendungsentwicklung finden sich Vertreter dieses Ansatzes. So etwa Node-RED, eine auf node.js aufsetzende Umgebung, welche für den Einsatz im Bereich des Internet of Things konzipiert wurde, und das Verbinden von Hardware Bausteinen untereinander und mit Web-APIs ermöglicht. [30]

Ähnliche Ansätze finden sich als Flow Based Programming (FBP), welches in den 1970er Jahren von J. Paul Morrison popularisiert wurde [28]. Daten Fließen hier über Queues begrenzter Größe zwischen Daten verarbeitenden Operationen, ein duplizieren von Da- tenpaketen ist nicht direkt vorgesehen. Da die Queues endlich sind, baut sich backpressure auf, so dass endlose Datenmengen verarbeitet werden können. [27]

Inspiriert von FBP entstanden Flowhub, NoFlow, Microflow, imgFlow sowie MsgFlow, welche gemeinsam ein Ökosystem zur Erstellung von Fullstackanwendungen vom Micro- controller bis zur Cloud bilden. Die Queues sind teilweise jedoch nur über den Haupt- speicher limitiert und Datenpakete können direkt dupliziert werden, wodurch sie keinem eindeutigem Besitzer zugeordnet werden können. In diesen wesentlichen Aspekten un- terscheiden sich die Konzepte von Flowhub und Flow Based Programming somit. [17]

[26]

(14)

5 Entwurf eines Frameworks

5 Entwurf eines Frameworks

Wie in Kapitel 4 beschrieben, gibt es bereits ein breites Spektrum an visuellen Program- miersprachen und Werkzeugen, welche sich in verschiedenen Domänen unterschiedlich Beliebtheit erfreuen und verschieden stark vertreten sind.

Daher wird für das Framework ein Ansatz gewählt, welcher nicht alternativ zu genannten Ansätzen, sondern ergänzend eingesetzt werden kann.

Angelehnt an Datenfluss orientierter Programmierung werden Programme bzw. Systeme hierzu als gerichtete Multigraphen (im Folgenden Netze) dargestellt. Jedoch symbolisiert eine Kante keinen Datenfluss, sondern das Verbinden zweier kompatibler Schnittstellen.

Die Knoten sind Komponenten, welche eine gewisse Funktion erfüllen, und Schnittstellen zu ihrer Umgebung bereitstellen. Aus dieser Verschaltung von Komponenten zu einem Netz ergibt sich das Verhalten des Gesamtsystems. Die konkrete Implementation einer Komponente ist dabei nicht relevant, solange entsprechende Schnittstellen eingehalten werden. Für die Beschreibung von einzelnen Komponenten stehen also weiterhin klassi- sche Programmiersprachen oder auch grafische Ansätze bereit.

Um dies darzustellen wird eine domänenspezifische Sprache (DSL) für die Beschreibung von Komponenten und Verschaltung dieser zu Netzen benötigt. Da die Implementation von Komponenten in einer Trägersprache (im folgenden Runtime) erfolgt, muss die DSL diese Domain nicht abdecken. Neben einem Konzept der Sprache wird auch eine textu- elle Repräsentation sowie, zumindest für einen wesentlichen Teil der Funktionalität, eine äquivalente Grafische Repräsentation benötigt.

Im Weiteren wird zunächst eine mögliche Realisierung des Beispielszenarios und eine Datenstruktur vorgestellt, welche der DSL des Frameworks zugrunde liegt. Anschließend wird eine textuell Repräsentation dieser und des Prozesses der Ausführung eines Netzes vorgestellt. Abschließend folgt ein kurzer Umriss der Grafischen Repräsentation.

5.1 Entwurf des Beispielszenarios

Das Beispielszenario setzt sich aus den drei semantischen Einheiten Sensorik, Synthese und Wiedergabe zusammen, welche über definierte Schnittstellen miteinander kommuni- zieren.

(15)

5 Entwurf eines Frameworks

Die Sensor-Komponente wird in C++ unter Verwendung des offiziellen SDK [14] imple- mentiert. Sie bietet eine Netzwerkschnittstelle, über welche sie Sensordaten anbietet.

Die Synthese-Komponente bietet ihrerseits Schnittstellen für die Übermittlung von Audio- und den Konsum von Sensor-Daten. Intern werden die Sensordaten in einem Datenfluss orientiertem Ansatz zu Audiosignalen überführt. Hierzu werden in einer entsprechenden Laufzeitumgebung einzelne Funktionsbausteine zu Laufzeit verbunden. Die Bausteine werden jeweils als compilierte Einheiten aus entsprechend strukturierten Shared Object Dateien geladen, um die Bausteine zu implementieren wird C++ verwendet.

Die Wiedergabe ist als Python Programm realisiert, und kann über eine Schnittstelle einen Audiostrom konsumieren.

Das Gesamtsystem ergibt sich aus der Verschaltung der Einzelkomponenten, wie in Ab- bildung 3 dargestellt.

Abbildung 3: Voneinander unabhängige Komponenten, welche über eine Vermittlung ver- bunden werden.

5.2 Datenstruktur

Um ein System wie das Beispielobjekt abzubilden, wird eine geeignete Datenstruktur benötigt. Diese bildet somit auch den Rahmen der textuellen und grafischen Repräsenta- tion. Da die textuelle und grafische Repräsentation für die Entwicklung verwendet werden sollen, muss die Datensturkur auch fehlerhafte oder unvollständige Strukturen abbilden können. Eine solche Struktur wird im Folgenden beschrieben.

5.2.1 Notation

• A “ist vom Typen” B wird alsA:B geschrieben.

• Listen werden als[a, ..., n]geschrieben

• Für eine ListeL, die nur Objekte eines Typen T enthält L: [T]

(16)

5 Entwurf eines Frameworks

• Tupel werden als(a, ..., n) geschrieben.

• Für eine TupelT, das an Positionen gewisse Typen fordertL: (T1, ..., Tn)

• Tupel können als Parameter verwendet werden: wennT = (x, .., z), dannF(T) = F(x, .., z)

• Mengen werden als{a, ..., n}geschrieben.

• Abbildunge/Maps als Mengen von Paaren werden als {(a → a), ...,(n → n)}

geschrieben.

• Schlüssel in Map vorhanden :n∈A= (n→x)∈A

• Für eine Abbildung Adie von Type T1 auf Type T2 abbildet A:{T1→T2}

• Multimengen werden als{|2a,1b, ..., xn|} geschrieben.

5.2.2 Namensräume

Um Objekte wie Netze oder Netzbausteine referenzieren zu können, werden diese in einer hierarchischen Struktur von Namensräumen (Namespaces) abgelegt. Ein Namespace ist eine Zuordnung von Namen zu Objekten und kann auch weitere Namespaces enthalten.

N amespace:{name:String→object} (1)

Dabei gelten einige Einschränkungen. Jeder Namespace hat eine Selbstreferenz:

ns:N amespace⇒(0.0 →ns)∈ns (2)

Wenn ein Namespace einen ‘..’ Eintrag hat, so ist dies ein Namespace:

(ns:N amespace∧(0..0 →x)∈ns)⇒x:N amespace (3)

Da für die Dastellung von Pfaden sowohl0/0 als auch 0\0 häufig verwendet werden, darf kein verwendeter Name diese enthalten:

(ns:N amespace∧(s→x)∈ns)⇒(0/0 ∈/s∧0\0 ∈/ s) (4)

Die Namespacestruktur ist recht uneingeschränkt und muss keinen Baum bilden, kann jedoch wie einer genutzt werden. Zusätzlich ist auch ein Verlinken, also dass über einen

(17)

5 Entwurf eines Frameworks

anderen Pfad Verfügbar machen von Namespaces, ohne die Umgebung des verlinkten Namespace zu verändern, möglich.

Ein Namenkann innerhalb eines Namensraumes ns|(n→o)∈nsgenutzt werden, um auf ein Objekt zuzugreifen, geschieben alsns[n] =o.

(ns:N amespace∧(n→o)∈ns)⇒(ns[n] =o) (5)

Eine Liste von Namen bildet einen Pfad (Path) innerhalb einer Struktur von Namens- räumen, welcher Objekte referenzieren kann.

P ath: [String] (6)

Die Auflösung eines Pfades p, ausgehend von einem Namespace ns, erfolgt sukzessive, wobei ein beliebig langer Suffix des Pfades ignoriert werden kann, um etwa auf den Namensraum eines referenzierten Objektes zuzugreifen.

Definiert als resolve(ns:N amespace, path:P ath, ignore:Integer)→Any, der letzte Parameterignore gibt die Anzahl der zu ignorierenden Elemente an, wird dieser wegge- lassen, so wird ignore= 0 angenommen.

resolve(ns,[f |rest], ignore= 0) =

ns[f], if len(rest)<=ignore resolve(ns[f], rest, ignore) otherwise

(7) Verkürzt geschrieben als:

resolve(ns, path, ignore) =ns[path, ignore] (8)

Oder auf Mengen:

ns[pathes:{P ath}, ignore] ={ns[p, ignore]| ∀p∈pathes} (9)

(18)

5 Entwurf eines Frameworks

Falls für eine Menge von Pfaden sowohl das referenzierte Objekt als auch der es enthal- tende Namespace benötigt werden:

resolves+ns(ns, pahtes:{P ath}) ={(ns[p,1], ns[p])| ∀p∈pathes} (10)

5.2.3 Interfaces

Die Kommunikation innerhalb von Netzen findet zwischen Interfaces statt. Ein Inter- face stellt dabei Implementationen seiner Funktionalität und eine Liste von Pfaden zu Interfaces, welche es konsumieren kann, bereit.

Eine Implementation eines Interfaces bietet jeweils spezifisch für eine Runtime eine API welche die Funktionalität des Interfaces kapselt. Da Implementationen in verschiedenen Sprachen bzw. für verschiedene Runtimes vorliegen können, werden sie in einer Map (Interf aceimplementations) abgebildet, die einer Runtime ein Artefakt zuordnet.

Interf ace: (implementations:{Runtime→Artef akt}

, Consumes:{P ath}) (11)

Ein Interface i ist in einem Namensraum ns gültig, wenn alle Pfade aus iConsumes

auf in ihren Namensräumen valide Interfaces verweisen, geschrieben als valideif(ns : N amespace, i:Interf ace).

valideif(ns, i, explored={}) = (nso, io)∈resolves+ns(ns, iConsumes)

⇒((nso, io)∈explored

∨valideif(nso, io, explored∪ {(nso, io)}))

(12)

Dieexplored Menge wird verwendet, um mit Schleifen in der Namensraumstruktur um- gehen zu können. Sie enthält bekannt valide Interfaces bzw. solche, deren Validität für eine weitere Prüfung angenommen wird, um eine wiederholte Prüfung zu verhindern.

(19)

5 Entwurf eines Frameworks

5.2.4 Komponenten

Eine Komponente (Component) ist eine Einheit, die Funktionalität kapselt und nach außen Schnittstellen zu dieser bietet. Hierfür werden Schnittstellen, in Form von be- nannten Interfaces, in einer Map Componentinterf aces abgelegt. Das Verhalten einer Komponente wird in Form von seinen Implementationen in verschiedenen Runtimes in Componentimplementations hinterlegt.

Component: (interf aces:{String→P ath}

, implementations:{Runtime→Artef akt})

(13)

Eine Komponentecist in einem Namespacensvalide, wenn alle incInterf acesenthaltenen Pfade in ns zu validen Interfaces auflösen.

validecomp(ns, c) = (nso, io)∈resolves+ns(ns, cinterf aces)

⇒valideif(nso, io)

(14)

Eine Komponentecimplementiert in einemnseine Runtimer, wenn ein entsprechendes Artefakt incimplementationsund für die verwendeten Interfaces hinterlegt ist:

implementscomp(ns, c, r) = (r ∈cimplementations∧((_name, path)∈cinterf aces

⇒r ∈ns[path]implementations)) (15)

Komponenten sind eine Art von Netzbausteinen und bilden die Grundlage von Komponenten- Netzen.

5.2.5 Komponenten-Netze

Ein Komponenten-Netz (ComponentNet) ist eine Verschaltung von kompatiblen Netz- bausteinen.

(20)

5 Entwurf eines Frameworks

Die Logik eines Komponenten-Netzes kann über Schnittstellen (ComponentN etinterf aces), analog zu denen von Komponenten, nach außen zugänglich gemacht werden. Dabei sind Komponenten-Netze Runtime spezifisch, daher können als Netzbausteine (nodes) nur Komponenten, die diese implementieren, und Komponenten-Netze (SubCN ets) der sel- ben Runtime, verwendet werden. Ein Komponenten-Netz kann eigenständig ausgeführt werden. Innerhalb eines Komponenten-Netzes gibt es zwei Arten von Verbindungen, ei- nerseits Verbindungen (Connections) zwischen Interfaces vonnodesund andereseits Zu- ordnungen (Links) von Netzschnittstellen zu Schnittstellen von Netzbausteinen.

ComponentN et= (interf aces:{String→P ath}

, components:{String→P ath}

, subCN ets:{String→P ath}

, connections:{|((nodef rom:String, Interf acef rom:String), (nodeto:String, Interf aceto:String))|}

, links:{|(netInt:String,(node:String, Interf ace:String))|}

, runtime:Runtime)

(16)

Ein Komponenten-Netz cn ist im Kontext eines Namespaces ns gültig, wenn alle refe- renzierten Komponenten in ihrem Namespaces gültig sind und eine Implementation für die Runtime cnruntime bereitstellen, außerdem müssen alle SubNetze ebenfalls die Run- timecnruntime verwenden und valide sein. Hinzu kommt, dass die Verbindungen in Form von cnconnections und cnlinks zwischen kompatiblen Interfaces sein müssen. Zusätzlich gilt, dass jedes Netzinterface mit einem Komponenten-Interface gelinkt sein muss. Auch dürfen keine Namen in sowohl cncomponents als auch cnsubCN ets gleichzeitig verwendet werden. Dieexplored Menge wird hier verwendet, um zyklische Abhängigkeiten in vali- den Netzen zu verhindern. Dies schließt nicht aus, das in einem späteren Template-system Netztemplates rekursiv verwendet werden können.

(21)

5 Entwurf eines Frameworks

validecnet(ns, cn, explored={}) = ((n, i)∈resolve+ns(ns, cninterf aces)

⇒valideif(n, i)∧cnruntime ∈iimplementations)

∧((n, c)∈resolves+ns(ns, cncomponents)

⇒validecomp(n, c)∧implementscomp(ns, c, cnruntime))

∧validecnetCons(ns, cn)

∧validecnetLinks(ns, cn)

∧(sub∈ns[cnsubCN ets]⇒(sub /∈explored

∧validecnet(n, sub, explored∪ {cn})

∧subruntime =cnruntime))

∧((n→x)∈cninterf aces→(n, y)∈cnlinks)

∧((n→x)∈cncomponents →(n→y)∈/cnsubCN ets)

∧((n→x)∈cnsubCN ets →(n→y)∈/cncomponents)

(17)

Die Komponenten und Subnetze bilden zusammen die Nodes, welche durch die Connec- tions und Links verbunden werden:

nodescnet(ns, cn) ={name→resolve+ns(ns, path)| ∀name, path∈ cncomponents∪cnsubCN ets}

(18)

Die Connections sind valide, wenn die Quellinterface unter den konsumierten Interfaces des Zielinterfaces ist.

validecnetCons(ns, cn) = ((f romnode, f romint),(tonode, toint))∈cnconnections

⇒((x, f romobj) =nodescnet(ns, cn)[f romnode]

∧(tons, toobj) =nodescnet(ns, cn)[tonode]

∧f romobj∈tons[toobjconsumes])

(19)

Die Links eines Netzes sind valide, wenn das Netzinterface und das Nodeinterface denselbe Typ aufweisen.

(22)

5 Entwurf eines Frameworks

validecnetLinks(ns, cn) = ((netInt,(node, nodeInt))∈cnlinks

⇒((nsnode, nodeobj) =nodescnet(ns, cn)[node]

∧nodeif =nsnode[nodeobjinterf aces[nodeInt]]

∧netif =ns[cninterf aces[netInt]]

∧nodeif =netif))

(20)

Ein Komponenten-Netz cnimplementiert die RuntimecnRuntime :

implementscnet(ns, cn, r) = (cnruntime =r) (21)

5.2.6 Komponenten-Nodes

Wie Komponenten sind Komponenten-Nodes Netzbausteine, welche über benannte Inter- faces Funktionalität kapseln. Sie sind weitestgehend identisch zu Komponenten, weisen jedoch nur eine Implementation auf und werden nicht in Komponenten-Netzen, sondern auf derselben strukturellen Ebene wie diese in Netzen verwendet.

ComponentN ode: (interf aces:{String →P ath}

, runtime:Runtime , implementation:Artef act)

(22)

Ein Komponenten-Node c ist in einem Namespace ns gültig, wenn die Interfaces, die verwendet werden, valide sind:

validecnode(ns, c) = (name, path)∈cInterf aces⇒valideif(ns, path) (23)

Ein Komponenten-Node c implementiert seine Runtime r, wenn für alle Interfaces eine Implementation für diese Runtime vorliegt, oder die Interfaces von der Komponente implementiert werden. Dies wird durch die spezielle Runtime none gekennzeichnet.

(23)

5 Entwurf eines Frameworks

implementscnode(ns, c, r) = (c=cruntime=none)∨(r =cruntime

∧((y →p)∈cinterf aces ⇒r ∈ns[p]implementations))

(24)

Die Runtime kann auch weggelassen werden:

implementscnode(ns, c) =implementscnode(ns, c, cruntime) (25)

5.2.7 Netze

Ein Netz ist die allgemeinste Einheit, in welcher Komponenten-Netze und Komponenten- Nodes miteinander verbunden werden. Dabei verfügt ein Netz analog zu Komponenten- Netzen über Interfaces und kann daher in einem Netz als Subnetz verwendet werden.

In Netzen können Systeme wie etwa das Beispielobjekt, welches in zwei Komponenten- Nodes (Sensorik und Wiedergabe) und einem Komponenten-Netz (Synthese) realisiert ist, abgebildet werden.

N etwork: (Interf aces:{String→P ath}

, ComponentN ets:{String→P ath}

, ComponentN odes:{String→P ath}

, SubN ets:{String→P ath}

, connections:{|((nodef rom:String, Interf acef rom:String), (nodeto:String, Interf aceto:String))|}

, links:{(netInt:String,(node:String, Interf ace:String))|}

(26)

InN etworkcomponentN ets werden benannte Instanzen von Komponenten-Netzen abgebil- det, die mit den Instanzen der Komponenten-Nodes aus N etworkcomponentN odes sowie denen der SubNetzen aus N etworksubN ets die Nodes des Netzes bilden:

nodesnet(ns, N) ={name:resolve+ns(ns, path)| ∀name, path∈ NcomponentN ets∪NcomponentN odes∪NsubN ets}

(27)

(24)

5 Entwurf eines Frameworks

Ein NetzNist im Kontext eines Namespacesnsvalide, wenn alle referenzierten Komponenten- Netze, -Nodes, Interfaces, als auch SubNetze in ihren Namespaces valide sind und alle Links und Connections entsprechenden Regeln folgen.

validenet(ns, N, explored={}) = (name∈NcomponentN ets

⇒validecnet(nodesnet(ns, N)[name]))

∧(name∈NcomponentN odes⇒validecnode(nodesnet(ns, N)[name])

∧(implementscnode(nodesnet(ns, N)[name]))

∧(name∈NsubN ets⇒nodesnet(ns, N)[name]∈/ explored

∧validenet(nodesnet(ns, N)[name]), explored∪ {(ns, N)})

∧validenetCons(ns, N)

∧validenetLinks(ns, N)

(28)

Die Connections sind, wie auch bei einem Komponenten-Netz, valide, wenn die jeweilige Quelle unter den konsumierten Interfaces der Senke ist:

validenetCons(ns, N) = ((f romname, f romint),(toname, toint))∈Nconnections

⇒(f romns, f romobj) =nodesnet(ns, N)[f romname]

∧(tons, toobj) =nodesnet(ns, N)[toname]

∧f romobj ∈tons[toobjconsumes]

(29)

Die Links eines Netzes sind valide, wenn das Netz Interface und das Node Interfaces auf dasselbe Interface verweisen.

validenetLinks(ns, N) = (netIf,(node, nodeIf))∈Nlinks

⇒((nodens, nodeobj) =nodesnet(ns, N)[node]

∧nodeif =nsnode[nodeobjinterf aces[nodeIf]]

∧netif =ns[Ninterf aces[netIf]]

∧nodeif =netif)

(30)

(25)

5 Entwurf eines Frameworks

5.3 Lebenszyklus eines Netzes

Zur Beschreibung des Systems um den Ball wird ein Netz verwendet. Die Schritte, die notwendig sind, um dieses ausführbar zu machen, auszuführen und zu Laufzeit zu steuern, werden hier beschrieben.

Ein Netz ist die allgemeinste funktionsbeschreibende Einheit des Frameworks. Sie beste- hen aus Komponenten-Netzen, Komponenten-Nodes und Subnetzen. Die Subnetze kön- nen durch die in ihnen enthaltenden Komponenten-Netzen und Nodes ersetzt werden.

Das Verhalten des Netzes ergibt sich aus der verteilten Ausführung und Kommunikation von Komponenten-Nodes und -Netzen, daher müssen entsprechende lauffähige Artefakte generiert und auf das Zielsystem überspielt werden.

5.3.1 Build

Ein Netz wird auf unterschiedlichen Ebenen durch einen Build Prozess in, falls erforder- lich, mehrere ausführbare Artefakte übersetzt. Die wesentlichen Schritte auf den unter- schiedlichen Ebenen werden hier am Beispielszenario beschrieben.

Netz: Das Beispielszenario als Ganzes wird als Netz abgebildet, der Build Prozess eines Netzes, an dessen Ende ein Archiv von ausführbaren Artefakten steht, unterteilt sich in folgende Teilschritte: Zunächst werden alle Subnetze aufgelöst, um ein Netz ohne Subnetze zu erhalten. Anschließend werden Artefakte für die verbleibenden Instanzen von Komponenten-Netze und Komponenten-Nodes gebaut. Die resultierenden ausführbaren Artefakte enthalten Informationen über ihre Rolle im Netz und verbinden sich, wenn ausgeführt, zu diesem. Um die einem Netz zugehörigen Artefakte zentral zu sammeln und ihre Validität gewährleisten zu können, werden die Artefakte mit Signaturen versehen und in einem Archiv gepackt.

Wie der konkrete Schritt des Aufbaues der Netzverschaltung abläuft, ist abhängig von den verwendeten Runtimes. Im Beispielszenario wird ein Komponenten Node der Runtime

‘esp8266’, einer der Runtime ‘python’ und ein Komponenten-Netz der runtime ‘nodecpp’, in welchem C++ Komponenten für die Audiosynthese verschaltet werden, verwendet.

(26)

5 Entwurf eines Frameworks

Komponenten Nodes: Aktuell werde drei Runtimes für Komponenten-Nodes unter- stützt.

Komponenten-Nodes können in Python implementiert werden, Interface-definitionen wer- den als Python Pakete bereitgestellt. Zusätzlich wird ein Paket generiert, welches die konkreten Interfaces des Nodes und Funktionalität zum interfacen mit dem Netz be- reitstellt. Auch C++ kann auf zwei Architekturen (einerseits x86/x86-64 und esp8266) verwendet werden, um Komponenten-Nodes zu erstellen. Interfaceimplementationen sind hierbei C++ Header und Sourcefiles. Für konkrete Interfaces und weitere Netz Funktio- nalität wird entsprechender Quellcode generiert. Im Beispiel Objekt sind die Sensorik und die Wiedergabe als Komponenten-Nodes realisiert, welche in C++, beziehungsweise Python, realisiert sind.

Der Build Prozess eines Komponenten-Node ist abhängig von der verwendeten Run- time und ist nur möglich wenn der Komponenten-Node valide ist. Für einen gültigen Komponenten-Node wird ein Build Ordner erstellt, in welchemcImplementation sowie alle Artefakte der Interfaces, die er verwendet kopiert werden. Abschließend wird ein Runti- me spezifischer Build Prozess angestoßen, welcher die Definition des Nodes und optional seine Verschaltung in einem Netz berücksichtigt, hierbei wird typischerweise Code oder Konfiguration generiert.

Komponenten-Netze: Für Komponenten-Netze steht die ‘nodecpp’ Runtime zur Ver- fügung, welche für die Audiosynthese verwendet wird. Es werden kompilierte Codeteile zu Laufzeit verschaltet, um das gewünscht Verhalten zu erhalten. Die Komponenten wer- den hierzu kompiliert in einer entsprechend strukturierten Shared-Object Datei abgelegt.

Benötigte Komponenten werden beim Starten der Ausführung von der Runtime geladen, und entsprechend einer Initialverschaltung verbunden.

Komponenten: Der Build Prozess einer Komponente hängt stark von der zu verwen- denden Runtime ab, zurzeit wird lediglich eine unterstützt.

Komponenten der Runtime nodecpp werden in C++ code beschrieben, und werden zu einer Shared Object Datei compiliertm welche einen Index der Komponenten und einer Beschreibung dieser enthält.

(27)

5 Entwurf eines Frameworks

5.3.2 Deployment und Startup

Das Deployment und anschließend der Startschritt eines Netzes sind abhängig von ver- wendeter Hardware und Verschaltung der Komponenten-Netze/-Nodes. Für die Realisie- rung des Beispielobjektes müssen Artefakte auf einem Microcontroller, einem Raspber- ryPy und einem x64 Linux Rechner ausgeführt werden.

Die Geräte werden manuell mit der Software bespielt. Der Start des Sensor Knotens erfolgt mit Einschalten der Stromversorgung. Mit dem Startup meldet sich der Sensor Knoten in einem WLAN-Netz an und mit seinem Netz und Bezeichner in diesem bei einem Namensserver, daraufhin wartet er auf Anfragen für Sensor Daten.

Ein zentraler Namensserver ist an dieser Stelle optional und kann durch andere Mecha- nismen ersetzt werde. Er wird verwendet, um ein einfaches Finden von Kommunikati- onspartnern zu ermöglichen.

Das zu verwendende WLAN-Netz ist über ein Web Interfaces konfigurierbar, welches über einen Hardware Jumper aktiviert werden kann.

Das Komponenten-Netz der Synthese benötigt eine Runtime für die Ausführung. Zu- nächst werden die Shared-Objects unter entsprechenden Bezeichnern in der Runtime hinterlegt. Anschließend wird die Runtime gestartet, und über eine Netzwerkschnittstel- le eine Instanz des Komponenten-Netzes mittels der binären Beschreibung erstellt. Dieser Prozess wird zurzeit manuell durchgeführt.

Nach Start verbindet sich der Prozess zum Namensserver und wartet auf die Verfügbar- keit des Sensors und der Wiedergabe. Dieses Verhalten ergibt sich aus den Interfaceim- plementationen. Nach dieser Verbindungsphase geht die Komponente in einen regulären Betrieb über, welcher ggf. durch einen Steuerbefehl oder etwa einen Netzwerk-Fehler unterbrochen werden kann.

5.3.3 Steuerung zu Laufzeit

Für die Steuerung von Komponenten-Nodes oder Komponenten-Netzen zur Laufzeit gibt es keine expliziten Mechanismen. Grundsätzlich müssen Komponenten also keine Inter- faces für eine Steuerung bereitstellen.

(28)

5 Entwurf eines Frameworks

Zusätzlich bietet die Synthese die Möglichkeit, das Komponenten-Netz zu Laufzeit zu modifizieren und intern anfallende Daten über ein seperates Interface nach Außen be- reitzustellen. Hierdurch ist es möglich, während der Entwicklung interne Signale zu ana- lysieren und das Synthesemodell anzupassen. Auch das Nachladen von Komponenten zur Verwendung im Komponenten-Netz ist möglich.

5.4 Textuelle Repräsentation

Hier wird die textuelle Repräsentation anhand des Beispielszenarios beschrieben. Die tex- tuelle Repräsentation setzt auf Markdown auf, welches für die Dokumentation verwendet werden kann, und ist auf mehrere Dateien aufgeteilt. Aus Platzgründen wird hier nur ein Einblick gegeben. Dafür wird wieder das Beispielszenario herangezogen, und angepasste Ausschnitte der Definition erläutert. In Listing 1 wird zunächst das Gesamtsystem als Netz in einem Namespace definiert.

0

1 # System B e s c h r e i b u n g

2

3 D i e s i s t d i e B e s c h r e i b u n g d e s Gesamtsystems , w e l c h e d a s Zusammenspiel d e r

4 d r e i Komponenten S e n s o r i k , S y n t h e s e und Wiedergabe d e f i n i e r t .

5

6 Die D a t e i i s t h i e r a c h i s c h w i e e i n Markdown Dokument o r g a n i s i e r t ,

7 und e n t h ä l t s o w o h l Dokumentation a l s auch I m p l e m e n t a t i o n .

8

9 I n n e r h a l b e i n e r D a t e i dü r f e n Namespaces d e f i n i e r t werden .

10 E i n e N a m e s p a c e d e f i n i t i o n s i e h t d a b e i w i e f o l g t a u s :

11 ~~~

12 : namespace name JSONData ! {

13 body

14 } !

15 ~~~

16 Im Body k ö nnen Komponenten , Komponenten−Netze , Komponenten−Nodes ,

17 N e t z e und Namespaces d e f i n i e r t werden .

18

19 JSONData w i r d h i e r durch den P l a t z h a l t e r { . . . } d a r g e s t e l l t ,

20 und i s t e i n JSON Objekt , w e l c h e s z u s ä t z l i c h e I n f o r m a t i o n e n ,

21 w i e b e i s p i e l s w e i s e f ü r e i n e g r a f i s c h e n D a r s t e l l u n g , e n t h a l t e n kann .

22

23 Das JSON Objekt i s t o p t i o n a l , kann a l s o w e g g e l a s s e n werden .

(29)

5 Entwurf eines Frameworks

24 I n d i e s e m B e i s p i e l wurde e s an a l l e n e r l a u b t e n S t e l l e n d a r g e s t e l l t .

25

26 : namespace S o u n d B a l l { . . . } ! {

27 Fü r j e d e d e r Komponenten w i r d e i n s e p e r a t e r Namespace v e r w e n d e t .

28 D i e s e Namespaces werden a u s D a t e i e n g e l a d e n .

29 Die Syntax i s t d a b e i w i e f o l g t :

30 ~~~

31 : namespace NS_path FS_path : NS_name JSONData !

32 ~~~

33

34 Der Namespace mit dem Namen NS_name w i r d a u s d e r D a t e i ,

35 a u f w e l c h e durch FS_path v e r w i e s e n wird ,

36 im a k t u e l l e n Namespace ns u n t e r dem Namespacepfad NS_path e i n g e b u n d e n .

37

38 Dabei muss ns [ NS_path , 1 ] a u f e i n e n v a l i d e n namespace ,

39 ns [ NS_path ] j e d o c h a u f k e i n Objekt v e r w e i s e n .

40

41 Wenn ’ : Namespace ’ s t a t t ’ : namespace ’ g e s c h r i e b e n wird ,

42 w i r d d e r Namespace , i n w e l c h e n e i n g e b u n d e n wird , a l s ’ . . ’ E i n t a g

43 i n dem e i n g e b u n d e n e n Namespace h i n t e r l e g t .

44 Ein Namespace d a r f hö c h s t e n s an e i n e r S t e l l e

45 i n e i n e r Namespace S t r u k t u r m i t t e l s ’ : Namespace ’ e i n g e b u n d e n werden .

46

47 Wenn d e r e i n z u b i n d e n d e Namespace i n d e r s e l b e n D a t e i d e f i n i e r t i s t ,

48 kann f ü r "FS_path : NS_name" "@: NS_name" g e s c h r i e b e n werden .

49

50 Ein Pfad i n n e r h a l b d e r N a m e s p a c e h i e r a r c h i e ( NS_path ) b e g i n n t

51 mit einem #und v e r w e n d e t \ a l s T r e n n z e i c h e n .

52 Ein Pfad im D a t e i s y s t e m ( FS_path ) b e g i n n t mit einem @

53 und v e r w e n d e t / a l s T r e n n z e i c h e n .

54

55 NS_name i s t e i n NS_Path , j e d o c h w i r d d i e f ü h r e n d e # w e g g e l a s s e n .

56 Dadurch kann auch e i n Subnamespace e i n e s Namespaces e i n g e b u n d e n werden .

57

58 : Namespace #.\ s e n s o r @. / s e n s o r . emd : s e n s o r { . . . } !

59 : Namespace #.\ s y n t h e s i s @. / s y n t h e s i s . emd : s y n t h e s i s { . . . } !

60 : Namespace #.\ p l a y b a c k @. / p l a y b a c k . emd : p l a y b a c k { . . . } !

61 62

63 E i n e N e t z w e r k d e f i n i t i o n s i e h t w i e f o l g t a u s :

64

65 : network main { . . . } ! {

66

67 : node s e n s o r #.\ s e n s o r \ main { . . . } !

(30)

5 Entwurf eines Frameworks

68 : node s y n t h e s i s #.\ s y n t h e s i s \ main { . . . } !

69 : node p l a y b a c k #.\ p l a y b a c k \ main { . . . } !

70

71 I n n e r h a l b e i n e s N e t z w e r k e s werden Knoten m i t t e l s

72 " : node name NS_path JSONData ! "

73 d e f i n i e r t , und u n t e r e i n a n d e r m i t t e l s

74 " : c o n n e c t node_src . i n t e r f a c e _ s r c node_dst . i n t e r f a c e _ d s t ! "

75 verbunden .

76

77 : c o n n e c t s y n t h e s i s . s e n s o r t o s e n s o r . c o n t r o l l { . . . } !

78 : c o n n e c t s y n t h e s i s . a u d i o t o p l a y b a c k . p l a y { . . . } !

79 } !

80 } !

Listing 1: Gesamtsystem als Netz, bestehend aus Komponenten-Nodes und Komponenten-Netzen

Neben Netzen und Namespaces sind auch Komponenten-Nodes und Interfaces Bestand- teile der textuellen Repräsentation. Der Code in Listing 2 zeigt einen Ausschnitt der Definition der Sensorik, welche als Komponenten-Node realisiert ist, und zwei Interfaces bereitstellt. Der Code befindet sich relativ zur Definition des Gesamtsystems in der Datei

‘./sensor.emd’.

0

1 : namespace s e n s o r { . . . } ! {

2 3

4 : i n t e r f a c e SensorData_out { . . . } ! {

5 D i e s i s t d i e D e f i n i t i o n e i n e s I n t e r f a c e s ,

6 f ü r w e l c h e s e i n e I m p l e m e n t a t i o n v o r l i e g t .

7 Es b i e t e t e i n e S c h n i t t s t e l l e ,

8 ü b e r w e l c h e S e n s o r d a t e n b e r e i t g e s t e l l t werden kö nnen .

9

10 : i m p l e m e n t a t i o n e s p 8 2 6 6 @. / i m p l / SensorDataOut / e s p 8 2 6 6 !

11

12 Dabei g i b t " : i m p l e m e n t a t i o n r u n t i m e FS_path ! " an ,

13 wo im D a t e i s y s t e m d i e D e f i n i t i o n d e s I n t e r f a c e s

14 f ü r e i n e Runtime zu f i n d e n i s t .

15 } !

16

17 : i n t e r f a c e SensorData_in { . . . } ! {

(31)

5 Entwurf eines Frameworks

18 D i e s e s I n t e r f a c e b i e t e t e i n e Mö g l i c h k e i t , S e n s o r d a t e n ,

19 w e l c h e ü b e r d a s e n t s p r e c h e n d e I n t e r f a c e a n g e b o t e n werden ,

20 zu k o n s u m i e r e n . Was durch " : consumes #NS_path ! " a n g e g e b e n w i r d .

21

22 D i e s e s I n t e r f a c e w i r d von d e r S y n t h e s e verwendet , um

23 mit d e r S e n s o r i k zu i n t e r a g i e r e n .

24

25 : i m p l e m e n t a t i o n nodecpp @. / i m p l / S e n s o r D a t a I n / nodecpp !

26

27 : consumes #.\ SensorData_out !

28 } !

29 30

31 : componentNode main { . . . } ! {

32 D i e s e r Komponenten−Node s t e l l t d i e e i g e n t l i c h e S e n s o r l o g i k b e r e i t .

33 Die I n t e r f a c e s e i n e s Komponenten−Nodes werden ,

34 a n a l o g zu denen von Komponeten−Netzen und Netzen ,

35 m i t t e l s " : i n t e r f a c e name NS_path JSONData ! " s p e z i f i z i e r t .

36

37 : i n t e r f a c e c o n t r o l l #.\ SensorData_out { . . . } !

38 : i m p l e m e n t a t i o n e s p 8 2 6 6 @. / i m p l / s e n s o r / e s p 8 2 6 6 { . . . } !

39 } !

40 } !

Listing 2: Sensorik als Komponenten-Node mit Interfaces

Da die Wiedergabe ebenfalls als Komponenten-Node realisiert ist, wird an dieser Stelle nicht genauer auf diese eingegangen.

Die Synthese ist als Komponenten-Netz realisiert, in welchem Audio Syntheseschritte in Form von Komponenten zu einem Synthesemodell verschaltet werden. In Listing 5.4 werden exemplarisch einige Komponenten definiert und zu einem Komponeten-Netz ver- schaltet. Relativ zur Definition des Gesamtsystems befindet sich der Code in der Datei

‘./synthesis.emd’.

0 : namespace s y n t h e s i s { . . . } ! {

1

2 Da d i e Audio S y n t h e s e a l s Komponenten−Netz r e a l i s i e r t i s t ,

3 mü s s e n d i e v e r w e n d e t e n Komponenten zun ä c h s t d e f i n i e r t werden ,

4 d i e s g e s c h i e h t h i e r i n dem Subnamespace ’ o p e r a t i o n s ’ , w e l c h e r auch

5 i n l i n e d e f i n i e r t werden kann .

6 H i e r b e i g i l t w i e d e r d a s d e r ’ . . ’ E i n t r a g nur g e s e t z t wird ,

(32)

5 Entwurf eines Frameworks

7 wenn : Namespace s t a t t : namespace g e s c h r i e b e n w i r d .

8 9

10 : Namespace o p e r a t i o n s { . . . } ! {

11

12 Zunä c h s t werden z w e i I n t e r f a c e s f ü r d i e Üb e r t r a g u n g von Audio ,

13 i n n e r h a l b d e s Komponenten−N e t z e s d e f i n i e r t :

14

15 : i n t e r f a c e Audio_out { . . . } ! {

16 : i m p l e m e n t a t i o n nodecpp @. / i m p l / a u d i o S y n t h / Audio / o u t / nodecpp !

17 } !

18 : i n t e r f a c e Audio_in { . . . } ! {

19 : i m p l e m e n t a t i o n nodecpp @. / i m p l / a u d i o S y n t h / Audio / i n / nodecpp !

20 : consumes #./ Audio_out !

21 } !

22

23 : component s y n t h e s i s { . . . } ! {

24 D i e s e Komponente s t e h t e x e m p l a r i s c h f ü r e i n e S y n t h e s e

25 o p e r a t i o n . S i e k o n s u m i e r t und p r o d u z i e r t e i n e n Audiostrom .

26 S y n t h e s e O p e r a t i o n e n werden e b e n f a l l s ü b e r I n t e r f a c e s mit

27 Parametern v e r s o r g t . D i e s e werden i n d i e s e m B e i s p i e l j e d o c h

28 w i e d e r a u s P l a t z g r ünden v e r n a c h l ä s s i g t .

29

30 : i n t e r f a c e i n #.\ Audio_in !

31 : i n t e r f a c e o u t #.\ Audio_out !

32

33 : i m p l e m e n t a t i o n nodecpp @. / i m p l / a u d i o S y n t h / s y n t h e s i s / nodecpp !

34 } !

35 } !

36

37 : component S e n s o r A d a p t e r { . . . } ! {

38 I n d i e s e m B e i s p i e l b i l d e t d i e s e Komponente d a s B i n d e g l i e d ,

39 w e l c h e s S e n s o r d a t e n i n e i n e n Audiostrom ü b e r f ü h r t .

40 I n d e r r e a l e n I m p l e m e n t a t i o n werden S e n s o r d a t e n n i c h t d i r e k t

41 i n e i n e n Audiostrom , s o n d e r n i n Parameter f ü r d i e

42 S y n t h e s e o p e r a t i o n e n ü b e r f ü h r t .

43

44 : i n t e r f a c e s e n s o r # . . \ S e n s o r \ SensorData_in !

45 : i n t e r f a c e a u d i o #.\ a u d i o S y n t h \ Audio_out !

46

47 : i m p l e m e n t a t i o n nodecpp @. / i m p l / a u d i o S y n t h / S e n s o r A d a p t e r !

48 } !

49

50 : component P l a y b a c k A d a p t e r { . . . } ! {

(33)

5 Entwurf eines Frameworks

51 : i n t e r f a c e a u d i o #.\ a u d i o S y n t h \ Audio_in !

52 : i n t e r f a c e audioOut # . . \ p l a y b a c k \ AudioOut !

53

54 : i m p l e m e n t a t i o n nodecpp @. / i m p l / a u d i o S y n t h / P l a y b a c k A d a p t e r !

55 } !

56

57 : compoentenNet nodecpp main { . . . } ! {

58 D i e s i s t d i e D e f i n i t i o n e i n e s Komponenten−N e t z e s , w e l c h e s den

59 Namen main h a t und d i e Runtime nodecpp v e r w e n d e t .

60

61 : i n t e r f a c e s e n s o r # . . \ S e n s o r \ SensorData_out { . . . } !

62 : i n t e r f a c e a u d i o # . . \ p l a y b a c k \ AudioOut { . . . } !

63

64 Ein Komponenten−Netz w i r d w e i t e s t g e h e n d a n a l o g zu einem

65 Netz d e f i n i e r t . A l s Nodes k ö nnen j e d o c h nur Komponenten ,

66 w e l c h e d i e Komponenten−Netz Runtime i m p l e m e n t i e r e n ,

67 v e r w e n d e t werden .

68

69 : node s i #.\ S e n s o r A d a p t e r { . . . } !

70 : node s y n t h #.\ a u d i o S y n t h \ s y n t h e s i s { . . . } !

71 : node n e t I n t #.\ P l a y b a c k A d a p t e r { . . . } !

72

73 L i n k e n d e r Netz−I n t e r f a c e s :

74

75 : l i n k s e n s o r t o s i . s e n s o r { . . . } !

76 : l i n k a u d i o t o n e t I n t . audioOut { . . . } !

77

78 V e r b i n d e n d e r Nodes :

79

80 : c o n n e c t s i . a u d i o t o s y n t h . i n { . . . } !

81 : c o n n e c t s y n t h . o u t t o n e t I n t . a u d i o { . . . } !

82 } !

83 } !

Die wesentlichen Aspekte der textuellen Repräsentation wurden hier am Beispiel vorge- stellt.

Für eine grafische Repräsentation müssen die textuellen Strukturen der DSL auf grafische Strukturen abgebildet werden. Hierfür bietet sich zunächst an, Netze als herachische Verschaltungen von Einheiten, welche über Interfaces verfügen, darzustellen.

(34)

5 Entwurf eines Frameworks

Inwieweit Namespaces oder Definitionen von Komponenten, Kompontentn-Nodes und Interfaces außerhalb von Netzen grafisch darzustellen sind, muss bei der Konzipierung einer Entwicklungsumgebung geklärt werden. Die konkrete Ausprägung der grafischen Repräsentation hängt stark mit der Entwicklungsumgebung zusammen, in welche sie in- tegriert werden soll. Eine solche Entwicklungsumgebung wird in einer späteren Arbeit samt der grafischen Repräsentation und formalen Definition der textuellen Repräsenta- tion vorgestellt.

(35)

6 Ausblick/ Zusammenfassung

6 Ausblick/ Zusammenfassung

In dieser Arbeit wurde ein Framework vorgestellt, welches es ermöglicht, Programme bzw. Systeme, die in unterschiedlichen Sprachen implementiert wurden oder verschiedene Laufzeitumgebungen verwenden, gesammelt in einem kohärenten Artefakt zu beschrei- ben.

Dabei wurde insbesondere auf die logische Struktur der verwendeten DSL und ihre tex- tuelle Repräsentation eingegangen. Die grafische Repräsentation wurde lediglich kurz vorgestellt, jedoch nicht vollständig ausgearbeitet, da die Nützlichkeit dieser ohne eine entsprechende Entwicklungsumgebung nur bedingt gegeben ist. In einem auf dieser Ar- beit aufbauenden Projekt soll eine solche Umgebung und die grafische Repräsentation entwickelt werden.

Einige Fragen bleiben noch unbeantwortet, beispielsweise inwieweit der Ansatz geeignet, ist um nicht konstruierte Probleme zu bewältigen, und die Interessen der geteilten Ziel- gruppe zu bedienen. Um dies zu beantworten, müssen die grafische Repräsentation und eine zugehörige IDE ausgearbeitet werden, um den Gegenstand der Frage zu schaffen. Zur verifizierung der Akzeptanz des vorgestellten Ansatzes müssen anschließend Studien mit Personen der Zielgruppen durchgeführt werden, oder ggf. auch Analysen nach Ansätzen wie etwa Kognitive Dimensions of Notation [18] durchgeführt werden.

Auch stellt sich die Frage, inwieweit ein Debugging oder Tracing der Einzelkomponenten oder ihrer Verschaltung in einem Netz möglich ist. An dieser Stelle könnte etwa versucht werden, Vektor Uhren in die Interfaces zu integrieren, oder zu prüfen wie weit Ansätze aus ErlViz [9] übernommen werden können. Auch eine interaktive Visualisierung der Kommunikation im System in der IDE wäre eine Möglichkeit das interne Verhalten eines Netzes zu vermitteln.

Des Weiteren muss geprüft werden, welche Runtimes in das Framework integriert wer- den sollen. Dies umfasst sowohl klassische Programmiersprachen als auch grafische Spra- chen. So währe auch die Integration eines Schaltungs-Simulators/Editors ähnlich dem Interkativen Java Applet [16] denkbar, um auch die Hardware des Objektes abbilden zu können.

(36)

Literatur

Literatur

[1] Ardublock. http://blog.ardublock.com/. – Accessed: 2019-08-11

[2] CSTI Webpage. https://csti.haw-hamburg.de/. – Accessed: 2019-09-21 [3] Flogorithm - Flowchart Programming Language. http://flowgorithm.org/. –

Accessed: 2019-08-20

[4] grasp.IO. https://www.grasp.io/. – Accessed: 2019-08-11

[5] ITTT: Everything works better together.https://ifttt.com/. – Accessed: 2019- 09-12

[6] Learn How to Play the Hot Potato Game and All its Variation. https://

partyjoys.com/how-to-play-hot-potato-game. – Accessed: 2019-10-10

[7] Smile - Smarte Umgebungen zum Anfassen, Mitmachen und (Er-) Forschen.

https://www.smile-smart-it.de/. – Accessed: 2019-08-11

[8] Construct 3 manual. https://www.construct.net/en/make-games/

manuals/construct-3. 2017. – Accessed: 2019-12-19

[9] Allers, Sven: Entwicklung und Realisierung eines Systems zum Tracingaktorba- sierter Software. 2019

[10] Broscheit, Jessica ; Draheim, Susanne ; Luck, Kai von: IVO- RY: ATangibleInterfaceto PerceiveHuman-Environment Interrelationships.

https://users.informatik.haw-hamburg.de/~ubicomp/arbeiten/

papers/tei2019.pdf. 2019

[11] Bundesministerium für Bildung und Forschung: Die neue Hightech- Strategie Innovationen für Deutschland. https://www.bmbf.de/upload_

filestore/pub_hts/HTS_Broschure_Web.pdf

[12] Deutsches Institut für Normung: DIN 60001- Information processing; gra- phical symbols and their application. 1983

[13] Deutsches Institut für Normung: DIN 66261 - Informationsverarbeitung;

Sinnbilder für Struktogramme nach Nassi-Shneiderman. 1985

[14] Espressif Systems: ESP8266 SDK. https://github.com/espressif/

ESP8266_RTOS_SDK

Referenzen

ÄHNLICHE DOKUMENTE

als die gerade Richtung der Tangente PQ (durch den Berührungs- punkt X) feststellen, bestimmen wir sie in einer statischen Instanz dieser geometrischen Struktur;

Aufgabe 4-4 Einfache Anweisungen in Java Hausaufgabe Ein Pizza-Service berechnet den Preis einer Pizza nach folgendem Schema: Der Grundpreis einer Pizza ist 5.50 Euro und jeder

Schreiben Sie in einer Klasse Investitionsrechner ein Java-Programm, welches pro Jahr aus- gibt, das wievielte Jahr gerade berechnet wird, wieviele Autos in diesem Jahr

a) Geben Sie an, welche dieser Ausdr¨ ucke syntaktisch nicht korrekt und welche Ausdr¨ ucke syntaktisch korrekt, aber nicht typkorrekt sind (jeweils mit Begr¨ undung).. Aufgabe

a) Definieren Sie in einer Klasse InvestitionsrechnerA zun¨ achst die Herstellungskosten von 22500 Euro f¨ ur ein Auto, den Verkaufspreis von 25000 Euro sowie die zu erwartende

b) Deklarieren Sie in Ihrer Klasse FigurFrame ein Attribut aktuelleFigur mit Klassentyp Figur. Erweitern Sie Ihre Klasse FigurFrame um eine Ereignisbehandlung f¨ ur den Button

d) Zur L¨ osung der Aufgabe sollen nun die generischen Klassen LinkedList&lt;E&gt; und Iterator&lt;E&gt; der Java-Bibliothek verwendet werden. Nehmen Sie die Benutzeroberfl¨ ache

 Bachelor Statistik Wahlpflichtlehrveranstaltung (falls Informatik nicht als Nebenfach gewählt ist).  Bachelor Chemie und