Masterarbeit – Philipp Hoffmann - THMAbstract This thesis describes a comprehensive concept for data processing via net-works of cooperating processes. The core of the developed

Masterarbeit

Ausdrucksmittel für datenflussorientierte Datenanalyse

zur Erlangung des akademischen Grades

Master of Science Informatik

vorgelegt demFachbereich Mathematik, Naturwissenschaften und Informatik der

Fachhochschule Gießen-Friedberg

Philipp Hoffmannim Januar 2011

Referent: Prof. Dr. Thomas LetschertKorreferent: Sebastian Süß (M. Sc.)

Zusammenfassung

Diese Arbeit beschreibt ein umfassendes Konzept zur Verarbeitung von Da-ten durch Netze kooperierender Prozesse. Kern des erarbeiteten Konzeptsist das Datenflussnetz – ein gerichteter Graph. Die Knoten des Graphenrepräsentieren Prozesse und die Kanten stehen für Verbindungen. Prozessesind voneinander unabhängig agierende Instanzen vordefinierter, parametri-sierbarer Komponenten. Ein Prozess hat einen lokalen Zustand und einenHandlungsfaden, der von seiner Komponente definiert wird.

Darüber hinaus verfügt eine Komponente über eine Reihe typisierter Kom-munikationsschnittstellen, mit deren Hilfe Prozesse mit ihrer Umwelt kom-munizieren. Unterschieden wird dabei zwischen Eingabe-Schnittstellen, überdie Daten empfangen werden können und Ausgabe-Schnittstellen, welchedas Senden von Daten ermöglichen. Die Kanten des Graphen definieren ge-richtete Verbindungen, zwischen den Ausgabe- und Eingabe-Schnittstellenvon Prozessen.

Durch die Verbindung von Prozessen über ihre Kommunikationsschnittstel-len entsteht ein Kanal. Ein Kanal überträgt die gesendeten Daten vonAusgabe- zu Eingabe-Schnittstelle und dient gleichzeitig als Datenpuffer.Die Daten „fließen“ während einer Berechnung also von Datenquelle zu Da-tensenke durch das Netz. Dabei kommunizieren die Prozesse weitestgehendasynchron.

Datenflussnetze können mit Unterstützung eines Entwicklungswerkzeugs er-stellt und von einer Ablaufplattform bereitgestellt und zur Ausführung ge-bracht werden. Im Rahmen dieser Arbeit wurde der Prototyp einer solchenAblaufplattform implementiert. Mit seiner Hilfe wurde das Konzept der da-tenflussorientierten Datenanalyse und die benötigten Ausdrucksmittel über-prüft.

Abstract

This thesis describes a comprehensive concept for data processing via net-works of cooperating processes. The core of the developed concept is a di-rected graph – called data flow network. The nodes of this graph representprocesses and its edges denote connections. Processes are independentlyoperating instances of predefined, parameterizable components. A processincorporates a local state and an algorithm, both of which are defined byits component.

Furthermore, a component also defines a series of typed communicationinterfaces, whereby processes communicate with their environment. A dis-tinction is made between input ports that can receive data and outputports that allow the sending of data. The edges of the graph define directedconnections between the output and input ports of processes.

Channels are created by linking processes via their communication ports.A channel transmits the data from output to input port and serves as adata buffer. During a calculation the data “flows” from data source to datasink through the data flow network. The processes thereby communicateasynchronously as far as possible.

Data flow networks can be created with the support of a textual or graphi-cal development tool. Subsequently, they can be deployed to and executedwithin a runtime platform. The prototype of such a runtime platform wasimplemented in the course of this work. The concept of data flow orienteddata analysis and the necessary means of expression were examined withthe aid of this prototype.

Inhaltsverzeichnis

1 Einleitung 1

2 Datenflussberechnungen 32.1 Flow-Based Programming . . . . . . . . . . . . . . . . . . . . 42.2 Kahn-Prozessnetzwerke . . . . . . . . . . . . . . . . . . . . . 5

3 Neukonzeption eines Datenflusssystems 73.1 Komponentenorientierung . . . . . . . . . . . . . . . . . . . . 73.2 Stärkere Struktur der Daten . . . . . . . . . . . . . . . . . . . 83.3 Formale Definition . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Komponenten & Prozesse 134.1 Definition von Komponenten . . . . . . . . . . . . . . . . . . 13

4.1.1 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . 144.1.2 Input- & Output-Ports . . . . . . . . . . . . . . . . . . 154.1.3 Komponentenparameter . . . . . . . . . . . . . . . . . 164.1.4 Abfragen . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.1 Instanziierung von Prozessen . . . . . . . . . . . . . . 194.2.2 Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.3 Operationen auf Ports . . . . . . . . . . . . . . . . . . 204.2.4 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Netze & Anwendungen 215.1 Definition von Netzen . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Netzparameter . . . . . . . . . . . . . . . . . . . . . . 215.1.2 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.3 Verbindungen & Kanäle . . . . . . . . . . . . . . . . . 23

5.2 Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.1 Bereitstellung von Netzen . . . . . . . . . . . . . . . . 245.2.2 Start einer Anwendung . . . . . . . . . . . . . . . . . 255.2.3 Ablaufkontrolle . . . . . . . . . . . . . . . . . . . . . . 265.2.4 Statusabfragen . . . . . . . . . . . . . . . . . . . . . . 27

6 Typen & Werte 29

vii

7 Beispiel 337.1 Berechnung der Ausfälle auf Gerätebasis . . . . . . . . . . . . 33

7.1.1 Logischer Ablauf der Berechnung . . . . . . . . . . . . 357.1.2 Tatsächlicher Ablauf der Berechnung . . . . . . . . . . 36

7.2 Verwendete Komponenten . . . . . . . . . . . . . . . . . . . . 387.2.1 PARASUITE-Lesekomponente . . . . . . . . . . . . . 387.2.2 Filterkomponente . . . . . . . . . . . . . . . . . . . . . 407.2.3 Gruppierungskomponente . . . . . . . . . . . . . . . . 427.2.4 Verbundkomponente . . . . . . . . . . . . . . . . . . . 447.2.5 Berechnung der Ausfälle . . . . . . . . . . . . . . . . . 467.2.6 CSV-Schreibkomponente . . . . . . . . . . . . . . . . . 48

8 Implementierung 518.1 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . 518.2 Struktur der Implementierung . . . . . . . . . . . . . . . . . . 528.3 Stand der Realisierung . . . . . . . . . . . . . . . . . . . . . . 53

9 Ausblick 55

10 Schluss 57

Abbildungsverzeichnis I

Quelltextverzeichnis III

Literaturverzeichnis V

viii

1 Einleitung

Im Fokus dieser Arbeit steht die Analyse von Daten durch Netze koope-rierender Prozesse. Die Motivation für die Untersuchung dieser Thema-tik entstammt einem Drittmittelprojekt mit dem Namen „PARASUITE“(von engl. „Product Analysis and Reporting Application Suite“).Am PARASUITE-Projekt beteiligt sind Mitarbeiter der Philipps-Univer-sität Marburg, der Cognidata GmbH sowie einer Forschungsgruppe derFachhochschule Gießen-Friedberg, unter Leitung von Professor Dr. Tho-mas Letschert und Sebastian Süß. Prominente Industriepartner des Projektssind der Lokomotivenhersteller Bombardier Transportation GmbH sowie dieThyssenKrupp Aufzüge GmbH.

Ziel dieses Projekts ist die Entwicklung eines Entscheidungsunterstützungs-systems zur vorausschauenden Produkt- und Anlagenwartung. Zu diesemZweck werden die benötigten Daten über Produkte und deren Lebenszy-klen in einer, an die Anwendung angegliederten, Datenbank gespeichert.Nicht nur die komfortable und flexible Anzeige dieser häufig sehr umfangrei-chen Daten, sondern vor allem die Möglichkeit, weitere Berechnungen mitden gesammelten Daten vorzunehmen und neue Erkenntnisse zu gewinnen,zeichnen PARASUITE dabei aus.

Um neuartige Berechnungen mit PARASUITE durchzuführen, erfordert dasderzeit verwendete Framework noch viele manuelle Eingriffe der Entwickler.In Zukunft soll dieser Vorgang soweit vereinfacht werden, dass nicht nur Ent-wickler, sondern auch Benutzer von PARASUITE diese Aufgabe meisternkönnen.

Henry Lieberman et al. [Lieberman et al. (2006)] sprechen in diesem Zu-sammenhang auch von EUD (von engl. „end user development“). Dabei gibtes abhängig von der Problemstellung viele verschiedene Lösungsansätze. Eintypisches Beispiel für EUD sind Tabellenkalkulationsprogramme. Sie ermög-lichen es dem Benutzer, individuelle Berechnungen auf Basis vordefinierterFormeln anzustellen, können aber in der Regel nur mit sehr begrenztenDatenmengen umgehen. Auch Skript- und domänenspezifischen Sprachen(DSL von engl. „domain specific language“) werden eingesetzt, um es Be-nutzern zu ermöglichen, Programme zu erweitern und ihren Bedürfnissenanzupassen.

1

Ziel dieser Arbeit ist die Entwicklung eines Konzepts zur Analyse von Datendurch Netze kooperierender Prozesse. Besonderes Augenmerk liegt dabei aufder intuitiven Definition von Berechnungen.

Zu diesem Zweck werden in Kapitel 2 zunächst die Grundlagen von Da-tenflussberechnungen, verwandte Konzepte und deren wichtigste Merkmaleerläutert. In Kapitel 3 wird anschließend die Neukonzeption eines Daten-flusssystems begründet und das Konzept der datenflussorientierten Daten-analyse formal definiert. Die dafür benötigten Ausdrucksmittel werden inden darauf folgenden Kapiteln 4, 5 und 6 erläutert.

Anhand eines Beispiels wird das Konzept in Kapitel 7 nochmals verdeutlicht.Im Anschluss daran wird in Kapitel 8 eine prototypische Implementierungvorgestellt.

Die Kapitel 9 und 10 sind schließlich zukünftigen Weiterentwicklungen undeinem Fazit gewidmet.

2

2 Datenflussberechnungen

Das Konzept der Datenflussberechnung ist nicht neu. Es ist eng verwandtmit dem 1969/70 von Morrison entwickelten „Flow-Based Programming“.Außerdem weist es Ähnlichkeit mit den, auf Kahn/MacQueen zurückgehen-den, Kahn-Prozessnetzwerken (KPN von engl. „Kahn Process Networks“)auf. Weitere verwandte Konzepte wie „Pipes and Filters“ und „Active Ob-ject“ erläutert [Steinseifer (2009), S. 13–14].

Kern all dieser Konzepte ist ein gerichteter Graph, auch Datenflussnetz oderschlicht Netz genannt. Die Knoten des Graphen repräsentieren Prozesse unddie Kanten stehen für (Kommunikations-)Verbindungen. Prozesse sind von-einander unabhängig agierende Instanzen vordefinierter, parametrisierbarerKomponenten. Ein Prozess hat einen lokalen Zustand und einen Handlungs-faden, der von seiner Komponente definiert wird.

Darüber hinaus verfügt eine Komponente über eine Menge von Kommuni-kationsschnittstellen, die so genannten „Ports“. Mit Hilfe dieser benanntenPorts kommunizieren Prozesse mit ihrer Umwelt. Über die Eingabe-Schnitt-stelle oder auch „Input-Port“ können Daten empfangen werden. Analogerfolgt das Senden von Daten über die Ausgabe-Schnittstelle, die im Fol-genden auch als „Output-Port“ bezeichnet wird. Die Kanten des Graphendefinieren gerichtete Verbindungen zwischen den Output- und Input-Portsvon Prozessen.

Durch die Verbindung von Ports entsteht ein (Kommunikations-)Kanal. EinKanal überträgt die gesendeten Daten von Output- zu Input-Port und dientgleichzeitig als FIFO-Puffer1. Die Daten „fließen“ also von Datenquelle zuDatensenke durch das Netz. Dabei kommunizieren die Prozesse weitestge-hend asynchron und synchronisieren sich – wenn nötig – über die Kanäle.

Dieses Konzept bildet die Grundlage auf der, damals wie heute, effizientgroße Datenmengen verarbeitet werden können.

1FIFO (von engl. „First In – First Out“) bezeichnet ein Verfahren zur Verarbeitung vonDaten ähnlich einer Warteschlange. Dabei werden diejenigen Daten, die zuerst anfallen,auch zuerst verarbeitet.

3

2.1 Flow-Based Programming

Entwickelt wurde das Programmierparadigma „Flow-Based Programming“(kurz FBP) 1969/70 von John Paul Morrison. Mit JavaFBP1 liefert Mor-rison auch eine quelloffene Implementierung von FBP auf Basis von Java[Morrison (1994)]. In PARASUITE findet derweil eine von Sven Steinseiferangepasste Version von JavaFBP Anwendung [Steinseifer (2009)].

Bei FBP handelt es sich um eine sehr umfangreiche Spezifikation. Nebender obigen allgemeinen Beschreibung sollen daher einige weitere Merkmaleerwähnt werden.

• Für die Parametrisierung von Komponenten verfügt FBP über keinseparates Konzept. Stattdessen erfolgt die Konfiguration mit Hil-fe eines (oder mehrerer) Konfigurations-Ports. Neben den „reinenNutzdaten“ fließen also auch Konfigurationsdaten durch das Netz.[Steinseifer (2009), S. 4]

• FBP erlaubt sogenannte „many-to-one“-Verbindungen, zwischen denOutput-Ports mehrerer Produzenten und dem Input-Port eines Kon-sumenten. Die Reihenfolge, in der Daten über einen solchen Port emp-fangen werden, ist also von der Ausführung mehrerer Produzentenabhängig und somit im Allgemeinen nicht vorhersehbar. In diesemFall kann sich ein Netz also nichtdeterministisch verhalten.Verboten sind allerdings „one-to-many“-Verbindungen zwischen demOutput-Port eines Produzenten und den Input-Ports mehrerer Konsu-menten. [Steinseifer (2009), S. 4, 9]

• Die Kanäle verfügen über eine endliche Kapazität. Nicht nur beimEmpfang von Daten aus einem leeren Kanal, sondern auch beimSenden in einen vollen Kanal, wird ein Prozess daher blockiert.[Steinseifer (2009), S. 6]

• Die Topologie eines Netzes ist statisch. Weder die Prozesse, noch derenVerbindungen, ändern sich zur Laufzeit. [Steinseifer (2009), S. 12]

• Mit Hilfe sogenannter Subnetze (von engl. „subnet“) ist es möglich,mehrere miteinander verbundene Komponenten zu einer neuen Kom-ponente zusammenzufassen. [Morrison (1994), S. 85]

• Typinformationen der Ports oder Daten werden nicht erfasst oder aus-gewertet. [Steinseifer (2009), S. 6]

1JavaFBP, http://www.jpaulmorrison.com/fbp/#JavaFBP

4

http://www.jpaulmorrison.com/fbp/#JavaFBP

2.2 Kahn-Prozessnetzwerke

Kahn-Prozessnetzwerke wurden von Gilles Kahn entwickelt [Kahn (1974)]und zusammen mit David B. MacQueen überarbeitet und veröffentlicht[Kahn/MacQueen (1977)]. Ein KPN ist ein verteiltes Berechnungsmodell.Es besteht ebenfalls aus einer Menge von Prozessen, die über gerichteteKanäle in Form von FIFO-Puffern miteinander verbunden sind.

Im direkten Vergleich mit FBP fallen einige Unterschiede ins Auge:

• Die Kanäle eines KPN verfügen konzeptionell über eine Kapazitätunbeschränkter Größe. Ein Prozess kann daher immer Daten senden.Nur beim Empfangen von Daten aus einem leeren Kanal wird einProzess blockiert. [Kahn/MacQueen (1977), S. 4]

• In einem KPN gibt es nur direkte Verbindungen zwischen zweiPorts. Eine Verbindung zwischen mehreren Produzenten/Konsumen-ten kann daher nur mit Hilfe zusätzlicher Ports definiert werden.[Steinseifer (2009), S. 12]

• Eine Komponente kann nicht prüfen, ob Daten an einem Port zurVerfügung stehen. Ein KPN verhält sich daher vollständig determi-nistisch, weil die Daten (mehrerer Produzenten) in keiner zeitlichenAbhängigkeit stehen. [Kahn/MacQueen (1977), S. 5]

• Die Topologie eines KPN ist dynamisch. Während der Laufzeit könnensowohl die Prozesse, als auch deren Verbindungen verändert werden.[Kahn/MacQueen (1977), S. 6]

5

3 Neukonzeption einesDatenflusssystems

Bisherige Systeme sind sehr stark durch Datenfluss als Mittel zur Paralleli-sierung geprägt. Um eine hohe Parallelisierung zu erreichen, werden daherviele Prozesse benötigt. Dabei kommen häufig Komponenten mit vergleichs-weise simplen internen Abläufen zum Einsatz. Dies führt in der Praxis un-weigerlich zu großen und damit leicht unübersichtlich werdenden Netzen.Mit Hilfe der folgenden Neukonzeption eines Datenflusssystems soll einebessere Verwendbarkeit, durch stärkere Strukturierung und Komponenten-orientierung erreicht werden.

3.1 Komponentenorientierung

Im Gegensatz zu bisherigen Konventionen, dient das Konzept des Datenflus-ses in erster Linie als intuitives Prinzip, um Berechnungsabläufe zu definie-ren. Prozesse werden deshalb primär als Berechnungskomponenten verstan-den. Sie kapseln also einen bestimmten Ablauf und nutzen eventuell internweitere Möglichkeiten zur Parallelisierung, die für den Benutzer völlig trans-parent ist.

Eine zentrale Frage bei der Betrachtung des zur Definition benötigten Auf-wands, ist das Maß der Wiederverwendbarkeit. Eine hohe Wiederverwend-barkeit von Komponenten senkt auf Dauer den Entwicklungsaufwand unddie Fehleranfälligkeit.

Um die Definition neuer Netze so weit wie möglich zu vereinfachen, wirdzwischen der Netz- und Komponentendefinition unterschieden. Diese Tren-nung der Aufgabenbereiche wird auch „2-Ebenen-Konzept“ genannt. EineNetzdefinition wird vom Benutzer mit Unterstützung eines Entwicklungs-werkzeugs textuell oder graphisch, durch Verknüpfung von Komponenten,erstellt. Dies kann ein Benutzer im Allgemeinen auch ohne Kenntnis derinternen Abläufe und Funktionsweise von Komponenten tun.

7

Die Definition eines Netzes umfasst die folgenden Bestandteile:

Prozesse sind Instanzen der verwendeten Komponenten, welche den Ablaufeiner Berechnung bestimmen.

Verbindungen zwischen den Output- und Input-Ports der verwendeten Pro-zesse regeln die Kommunikation.

Netzparameter dienen der Konfiguration eines Netzes. Beim Start einerAnwendung werden die übergebenen Argumente an die vordefiniertenParameter gebunden.

Analog sind auch bei der Definition von Komponenten nur minimale Kennt-nisse über ein umschließendes Netz sowie vor- oder nachgelagerte Komponen-ten erforderlich. Die Definition einer Komponente setzt sich aus folgendenBestandteilen zusammen:

Algorithmus (oder auch Handlungsfaden) definiert den Ablauf innerhalbeiner Komponente.

Input-Ports erlauben den Empfang von Daten.

Output-Ports ermöglichen das Senden von Daten.

Komponentenparameter dienen der Konfiguration einer Komponente.

Abfragen (auch „Queries“ genannt) können komponentenspezifische Status-informationen bereitstellen.

3.2 Stärkere Struktur der Daten

Die Definition von Komponenten wird auch durch eine stärker als üblich aus-geprägte Struktur der Daten unterstützt. Ein einfaches, aber ausreichendmächtiges Typsystem kontrolliert die Wiederverwendbarkeit von Kompo-nenten und Netzen. Die dazu benötigte Generizität lässt sich mit Hilfe einerReihe von Basisdatentypen und durch deren Komposition formulieren.

Die Angabe von Datentypen erfolgt bei der Definition von Parametern,Ports und Abfragen. Zwei Prozesse können genau dann miteinander verbun-den werden, wenn der Typ eines Output-Ports des Produzenten kompatibelmit dem Typ eines Input-Ports des Konsumenten ist. Auf diese Weise wirddie Weite/Grenze ihrer Verwendbarkeit festgelegt.

8

3.3 Formale Definition

Im Folgenden werden Datenflussnetze und ihre verschiedenen Bestandteileformal definiert.

Netze: Ein Datenflussnetz ist ein gerichteter Hypergraph G = (V, E,PNETWORK), bestehend aus einer Menge V von Prozessen und einerMenge von (Kommunikations-)Verbindungen E. Als Hypergraph wer-den Graphen bezeichnet, deren Kanten mehr als zwei Knoten mit-einander verbinden können. Solche Kanten werden auch Hyperkantengenannt.

Die Knoten oder auch Prozesse des Netzes sind Instanzen vordefinier-ter Komponenten. Die Hyperkanten des Netzes sind gerichtete Ver-bindungen zwischen den Prozessen. Mit PNETWORK verfügt ein Netzaußerdem über eine Menge von (Netz-)Parametern, welche der Konfi-guration dienen.

Anwendungen: Eine Anwendung g ∈ G repräsentiert eine laufbereite In-stanz eines Datenflussnetzes, welche mit Hilfe von (Start-)ArgumentenANETWORK parametrisiert werden kann. Während Netze in erster Li-nie interne Bestandteile des Entwicklungswerkzeugs sind, handelt essich bei den Anwendungen um interne Bestandteile der Ablaufplatt-form.

Komponenten: Eine Komponente ist ein benanntes 4-Tupel C = (A, P, Q,PCOMPONENT), bestehend aus einem Algorithmus A, einer Menge Pvon Kommunikationsschnittstellen – den sogenannten Ports, einerMenge von (Komponenten-)Parametern PCOMPONENT und einer Men-ge Q von Abfragen auch „Queries“ genannt. Instanzen dieser Kompo-nenten können als voneinander unabhängig agierende Prozesse oderThreads aufgefasst werden.1

Der Algorithmus A kennzeichnet die Komponente maßgeblich und be-stimmt ihren Handlungsfaden. Sowohl Nichtdeterminismus als auchweitere „interne“ Parallelisierung sind dabei mögliche Bestandteile desAlgorithmus. Der Algorithmus beeinflusst auch den lokalen Zustandvon Prozessen – den Instanzen einer Komponente. Falls vorhanden,liefern Abfragen weitergehende Informationen über den Status einesProzesses. Mit Hilfe von geeigneten Parametern können Prozesse kon-figuriert werden, wodurch sich die Wiederverwendbarkeit einer Kom-ponente deutlich steigern lässt.

1Instanzen dieser Komponenten müssen von der Implementierung jedoch nicht zwangs-läufig auf Threads oder Prozesse abgebildet werden.

9

Prozesse: Ein Prozess v ∈ V ist ein 2-Tupel V = (c, ACOMPONENT) undstellt eine parametrisierbare, benannte Instanz einer vordefiniertenKomponente c ∈ C dar. Von dieser Komponente c „erbt“ der Prozess vden Algorithmus, sowie die Ports, Parameter und Abfragen. Prozesseverfügen damit über einen eigenen Handlungsfaden und einen lokalenZustand. Sie sind die aktiven Elemente eines Netzes.Die Argumente eines Prozesses ACOMPONENT werden bei seiner Initia-lisierung an die Parameter gebunden.

Konzeptuell werden alle Prozesse eines Netzes so betrachtet, also obsie auf verschiedenen Maschinen ausgeführt würden. Sie können aus-schließlich, gemäß der festgelegten Verbindungen, über ihre Ports mit-einander kommunizieren.

Ports: Ein Port ist eine benannte, typisierte Schnittstelle, über die Prozessemit ihrer Umwelt kommunizieren. Jedem Prozess wird eine nicht leereMenge von Ports P , ∅ zugewiesen, wobei jeder Port p ∈ P entwederein Input-Port p ∈ PIN oder ein Output-Port p ∈ POUT ist. Die Mengealler Ports eines Prozesses ist die disjunkte Vereinigung seiner Input-und Output-Ports: P = PIN ·∪ POUT.

Während Input-Ports dem Empfang von typisierten Daten dienen, er-möglichen Output-Ports den Prozessen das Senden von Daten. DieAngabe eines Datentyps T an Input- und Output-Ports schränkt da-bei die Struktur der Daten ein und steuert so das Maß der Wiederver-wendbarkeit von Komponenten.

Ein Port ist frei, wenn er nicht Teil einer Verbindung ist PFREE B{p ∈ P | ∀e ∈ E : p < e}. Ein Netz ist gültig, wenn es keine freienPorts beinhaltet und alle Verbindungen gültig sind.

Verbindungen: Eine Verbindung e ∈ E ist eine gerichtete Hyperkante desNetzes mit e = (o, i). Sie verbindet n Output-Ports o = {o1, . . . , on} ⊆POUT mit m Input-Ports i = {i1, . . . , im} ⊆ PIN. Es gilt m, n ≥ 1.

Bei der Betrachtung einer Verbindung werden die Prozesse, derenOutput-Ports Teil der Verbindung sind, auch als Produzenten bezeich-net. Als Konsumenten werden diejenigen Prozesse bezeichnet, derenInput-Ports Teil der Verbindung sind. Ein Netz ist nichtdeterminis-tisch, wenn eine Verbindung über mehr als einen Produzenten (n > 1)verfügt.

Alle über o gesendeten Daten werden vereinigt und dann so verteilt,dass sie anschließend mit Hilfe von i empfangen werden können. EineVerbindung ist gültig, wenn der Datentyp des Output-Ports tOUT ∈ Tmit dem Datentyp des Input-Ports tIN ∈ T kompatibel ist. Dies istgenau dann der Fall, wenn tOUT spezieller oder gleich tIN ist, alsotOUT � tIN gilt.

10

Kanäle: Durch die Verbindung zweier Ports entstehen (Kommunikati-ons-)Kanäle. Diese Kanäle sind FIFO-Puffer von konzeptionell un-endlicher Größe. Tatsächlich haben die Kanäle immer eine endlicheKapazität, deren Größe jedoch nicht beschränkt ist. Die Kommunika-tion zwischen den Prozessen erfolgt daher weitestgehend asynchron.Allerdings kann ein Prozess nur dann Daten empfangen, wenn der Ka-nal nicht leer ist – anderenfalls wird er bis zum Eintreffen von Datenblockiert.

Ein Prozess kann aber auch beim Senden von Daten blockiert wer-den. Dies geschieht, wenn die Kapazität des Kanals erschöpft ist. Indiesem Fall wird der Prozess blockiert, bis wieder genügend Kapazi-tät im Kanal frei wird. Auf diese Weise synchronisiert sich ein Netz„selbstständig“ und sorgt so dafür, dass viele Prozesse gleichzeitig aktivsind.

Typen & Werte: Ein einfaches, aber ausreichend mächtiges Typsystem kon-trolliert das Maß der Wiederverwendbarkeit von Komponenten. Anden Input-Ports werden zu diesem Zweck die Datentypen spezifiziert,mit denen eine Komponente arbeiten kann. Durch die Spezifikationvon Datentypen an den Output-Ports wird festgelegt, welche Strukturdie Daten nach der Verarbeitung durch eine Komponente besitzen. MitHilfe dieser Angaben lässt sich mittels statischer Analyse feststellen,ob ein gegebenes Netz gültig ist, oder nicht.

Das Typsystem findet darüber hinaus auch bei der Typisierung von Pa-rametern und Abfragen Anwendung. Neben der Prüfung auf Kompati-bilität mittels der �-Relation ist dabei die Konvertierung von Wertenin unterschiedliche Repräsentationen die Hauptaufgabe des Typsys-tems.

11

4 Komponenten & Prozesse

Der Ablauf eines Netzes wird durch die verwendeten Prozesse und die ihnenzugeordneten Komponenten bestimmt. Komponenten definieren den Hand-lungsfaden und den lokalen Zustand von Prozessen. Sie sind in Wertpara-metern und Verbindungen parametrisierbar.

4.1 Definition von Komponenten

Eine Komponente kapselt in erster Linie einen Algorithmus. Der Algorith-mus bestimmt den Handlungsfaden, dem alle Prozesse dieses Komponenten-typs folgen. Durch die Definition von Parametern, können Komponentenkonfiguriert werden. Dies ermöglicht ein gewisses Maß an Flexibilität inner-halb von Komponenten und erhöht so deren Wiederverwendbarkeit. Dar-über hinaus definiert eine Komponente Input- und Output-Ports, über dieein Prozess mit seiner Umwelt kommunizieren kann.

Als Datenquelle können solche Komponenten betrachtet werden, die keineInput-Ports definieren. Sie lesen Daten beispielsweise aus Dateien, Daten-banken oder von Sensoren und senden die Daten dann über einen oder meh-rere Output-Ports weiter. Analog sind Komponenten ohne Output-Portsals Datensenke zu betrachten. Sie empfangen Daten über ihren Input-Port,senden diese aber nicht weiter, sondern schreiben sie beispielsweise in eineDatei oder Datenbank.

Die Daten fließen also von Datenquelle zu Datensenke durch das Netz. Aufihrem Weg treffen sie in der Regel auf eine ganze Reihe von Prozessenweiterer Komponenten. Diese intermediären Komponenten verfügen jeweilsüber mindestens einen Input- und Output-Port. Typischerweise definiert ihrAlgorithmus eine Transformation, welche zunächst auf die empfangen Datenangewendet wird. Das Ergebnis dieser Transformation wird anschließendüber einen Output-Port propagiert.

Neben dem Algorithmus können Komponenten auch Abfragen implementie-ren. Mit ihrer Hilfe können sie zusätzliche Statusinformationen für Ablauf-plattform und Benutzer zur Verfügung stellen.

13

4.1.1 Algorithmus

Der Kern einer jeden Komponente ist ihr Algorithmus. Der Algorithmus defi-niert den Handlungsfaden, den die Prozesse abarbeiten und bestimmt ihrenlokalen Zustand. Die Vielfalt der denkbaren Algorithmen ist gigantisch. ImRahmen dieser Arbeit haben sich aber bereits einige Komponenten als be-sonders nützlich erwiesen.

Lesekomponenten dienen als Datenquelle. Ihr Algorithmus bezieht die Da-ten aus (externen) Dateien, Datenbanken oder sonstigen Quellen.

Filterkomponenten können die Verarbeitung der Daten auf eine bestimmteUntermenge beschränken. Ihr Algorithmus kann beispielsweise Dupli-kate oder fehlerhafte Daten erkennen und diese verwerfen oder an einespezielle Komponente weiterleiten.

Verbundkomponenten vereinen die Daten mehrerer Quellen. Ihr Algorith-mus kombiniert und ergänzt die Daten für nachgelagerte Komponen-ten.

Gruppierungskomponenten dienen dazu die Daten zu verdichten oder ih-re Struktur zu verändern. Die Sicht der Daten aus unterschiedlichenPerspektiven vereinfacht in der Folge oft deren Verarbeitung. Ihr Al-gorithmus aggregiert die Daten, bevor er sie gemäß der Konfigurationtransformiert und weiterleitet.

Skriptkomponenten ermöglichen die Verarbeitung eines benutzerdefinier-ten Algorithmus innerhalb einer Komponente.

Schreibkomponenten fungieren als Datensenke. Ihr Algorithmus ermög-licht das Festhalten von Berechnungsergebnissen in (externen) Datei-en, Datenbanken oder anderen Datenspeichern.

In der Regel werden die Komponenten und ihre Algorithmen in Java im-plementiert. Eine Ausnahme davon bilden die Skriptkomponenten, welchedem Benutzer eine einfachere, individuelle Algorithmusdefinition ermögli-chen. Zu diesem Zweck kommt die Skriptsprache „Groovy“1 zum Einsatz.Diese hat große Ähnlichkeit mit – und die gleiche Mächtigkeit wie – Java,verfügt aber über eine ganze Reihe nützlicher Vereinfachungen.

Ein weiter Schritt in diese Richtung könnte in Zukunft die Verwendungeiner geeigneten DSL anstelle von Groovy sein. Um dem Benutzer die De-finition von Algorithmen noch weiter zu vereinfachen, sind darüber hinausauch „Formelkomponenten“ geplant. Diese sollen – ähnlich wie gängige Ta-bellenkalkulationsprogramme – nur eine begrenzte Zahl vordefinierter Be-rechnungsfunktionen und möglichst wenige Kontrollstrukturen bieten.

1Groovy, http://groovy.codehaus.org

14

http://groovy.codehaus.org

4.1.2 Input- & Output-Ports

Prozesse kommunizieren mit ihrer Umwelt mit Hilfe von Ports. Jede Kom-ponente verfügt über einen oder mehrere Ports. Jeder Port einer Kompo-nente trägt einen eindeutigen Namen sowie den designierten Typ der er-warteten/erzeugten Daten. Es werden zwei Typen von Ports unterschieden:Input-Ports dienen dem Empfang von Daten, Output-Ports dienen dem Sen-den von Daten.

Der Quelltext 4.1 zeigt eine einfache, intermediäre Komponente. Diese Kom-ponente verfügt über einen Input-Port namens „input“, an dem sie Datenvom Typ Integer erwartet. Zusätzlich besitzt sie auch einen Output-Portnamens „output“, über den sie Daten des Typs Integer sendet.

Die Ablaufplattform bindet bei der Initialisierung entsprechende Ports andie annotierten Objektvariablen, wenn ein Prozess dieser Komponente er-zeugt wird. Anschließend wird der Prozess gestartet und verfolgt dann denfolgenden Handlungsfaden:

Empfangen von Daten über den Input-Port: Liegen zu diesem Zeitpunktkeine Daten vor, dann blockiert der Prozess. Der verwendete Iteratordes Ports erkennt, ob Daten verfügbar sind und weckt den Prozessgegebenenfalls wieder auf. Der Iterator erkennt auch das Ende einerDatenübertragung und signalisiert es dem Prozess nach der Verarbei-tung des letzten Datensatzes.

Transformation: Die verwendete Groovy-Closure „each“ führt den folgen-den Abschnitt für jede Iteration aus. Der Wert jeder Iteration wird inder impliziten Variablen „it“ bereitgestellt. Die Berechnung in diesemBeispiel ist trivial – jede empfangene Zahl wird um Eins erhöht.

Senden der Ergebnisse über den Output-Port: Nach der Berechnung desErgebnisses wird dieses über den Output-Port für nachgelagerte Pro-zesse bereitgestellt. Falls der Kanal keine weiteren Daten aufnehmenkann, blockiert der Prozess bis die benötigte Kapazität wieder zurVerfügung steht.

Weitere Details zur Kommunikation der Prozesse über Ports, Verbindungenund Kanäle werden in Abschnitt 5.1.3 erläutert.

15

package de.fh_giessen.mni.doda.component.groovy

import de.fh_giessen.mni.doda.network .*

public class Example extends Component {

@In(type="Integer")public InputPort input

@Out(type="Integer")public OutputPort output

void execute () {input.each {

output.send(it + 1)}

}}

Quelltext 4.1: Definition und Verwendung von Ports

4.1.3 Komponentenparameter

Mit Hilfe von Parametern können Komponenten konfiguriert werden. Da-durch lässt sich die Wiederverwendbarkeit der Komponenten erhöhen. EineKomponente kann beliebig viele Parameter definieren. Die Definition vonKomponentenparametern umfasst dabei stets folgende Bestandteile:

Name: Ein komponentenweit eindeutiger Bezeichner identifiziert jeden Pa-rameter.

Typ: Der angegebene Typ legt den Datentyp eines Parameters fest.

Wert: Optional kann durch die Angabe eines Wertes ein Standardwert fest-gelegt werden. Der Standardwert wird verwendet, wenn die Netzdefi-nition kein anderes Argument vorgibt.

Der Quelltext 4.2 zeigt die Komponente aus dem letzten Beispiel in einererweiterten Version. Ein zusätzlicher Parameter ermöglicht die Konfigurati-on der Komponente, sodass ein beliebiger Wert auf die empfangenen Zahlenaddiert werden kann.

Zu diesem Zweck wurde die Komponente um eine weitere Objektvariable na-mens „offset“ ergänzt. Die @Paramater-Annotation markiert diese Variableals Komponentenparameter. Darüber hinaus gibt die Annotation an, dassder Parameter vom Typ Integer ist und den Standardwert „1“ hat.

16

Ist kein Datentyp angegeben, dann wird standardmäßig der Typ Stringverwendet. Optional kann mit Hilfe der Annotation auch der Name des Pa-rameters festgelegt werden – standardmäßig wird der Name der annotiertenVariable verwendet.






@Parameter(type="Integer", value="1")public def offset


output.send(it + offset)}

}}

Quelltext 4.2: Definition und Verwendung von Komponentenparametern

Bei der Initialisierung eines Prozesses dieser Komponente, wird das zum Pa-rameter zugehörige Argument an die annotierte Objektvariable gebunden.Weitere Informationen zur Verarbeitung von Parametern und Argumentenwerden in Abschnitt 5.1.1 erläutert. Kapitel 6 ist der Verarbeitung von Ty-pen und Werten sowie den Details des Typsystems gewidmet.

4.1.4 Abfragen

Um zusätzliche Statusinformationen bereitzustellen, können Komponentenoptionale Abfragen definieren. Eine Abfrage auch „Query“ genannt, wird inForm einer annotierten, parameterlosen Methode implementiert. Ihr Rück-gabetyp entspricht dem Typ String. Die Rückgabewerte abweichender Da-tentypen werden in serialisierter Form retourniert.

Quelltext 4.3 zeigt die Definition einer einfachen Abfrage auf Basis der Kom-ponente aus dem obigen Beispiel. In dieser erweiterten Version kann diedargestellte Komponente Auskunft über den Durchschnittswert der verar-beiteten Zahlen geben.

17






@Parameter(type="Integer", value="1")public def offset

private volatile double sum = 0private volatile double count = 0


sum += it++ countoutput.send(it + offset)

}}

@Query(type="Double")public String average () {

return (count > 0) ? Double.toString(sum / count) : null}

}

Quelltext 4.3: Definition von Abfragen

Durch die @Query-Annotation markiert, kann die Abfrage von der Ablauf-plattform oder dem Benutzer (vor, während und nach der Berechnung) aus-geführt werden. Standardmäßig stimmt der Name der Abfrage mit dem Na-men der annotierten Methoden überein. Falls dies nicht beabsichtigt wird,kann mit Hilfe der Annotation ein anderer Name bestimmt werden. Sie legtaußerdem den designierten Rückgabetyp fest – fehlt die Angabe, dann wirdstandardmäßig String verwendet.

Die Rückgabe der Abfrageergebnisse erfolgt stets als String. Dieser wirdanschließend mit Hilfe des designierten Rückgabetyps analysiert und in eingeeignetes Java-Objekt umgewandelt. Diese Vorgehensweise ermöglicht dieImplementierung von Komponenten auch in solchen Programmiersprachen,die nicht über die gängigen Java Datentypen verfügen.

18

Zu Beachten ist, dass die Abfragen im Kontext der Ablaufplattform – undnicht etwa im Kontext des abgefragten Prozesses – ausgeführt werden. Ausdiesem Grund sind die Objektvariablen „sum“ und „count“ auch mit demSchlüsselwort volatile gekennzeichnet. Nur so ist sichergestellt, dass Verän-derungen am Inhalt der Variablen auch über die Grenzen des ausführendenThreads sichtbar werden.

4.2 Lebenszyklus

Nach der Definition von Komponenten mit Hilfe eines Entwicklungswerk-zeugs, stehen diese zur Verwendung in zukünftigen Netzen zur Verfügung.Bei der Bereitstellung eines Netzes identifiziert und lädt die Ablaufplattformalle benötigten Komponenten. Wird eine Anwendung gestartet, dann wer-den die spezifizierten Prozesse in Form von Instanzen dieser Komponentenerzeugt und initialisiert. Anschließend wird die Anwendung der Ablaufplatt-form zur Ausführung übergeben. Um sie tatsächlich in einen laufbereitenZustand zu versetzen, werden von der Ablaufplattform Threads zur Ausfüh-rung aller Prozesse bereitgestellt.

4.2.1 Instanziierung von Prozessen

Durch den Start eines Netzes wird die Ablaufplattform dazu veranlasst, einelaufbereite Instanz des Netzes – eine Anwendung – zu erzeugen. Der Ablaufnach dem Start einer Anwendung wird in Abschnitt 5.2.2 erläutert. Unteranderem werden dabei die spezifizierten Prozesse der Anwendung erzeugtund deren Ports und Parameter initialisiert.

4.2.2 Start

Nachdem alle Prozesse einer Anwendung erzeugt und initialisiert wurden,stellt die Anwendungsplattform die zur Ausführung benötigten Threads be-reit. Anschließend werden diese Threads gestartet und beginnen mit derAuswertung der „run“-Methode, welche durch die abstrakte Basisklasse al-ler Komponenten implementiert wird. Diese Methode ist unter anderem fürdie Fehlerbehandlung verantwortlich und delegiert den Kontrollfluss alsbaldan den von der Komponente definierten Algorithmus.

19

4.2.3 Operationen auf Ports

Durch das Empfangen und Senden von Daten über Ports kann ein Prozessmit seiner Umwelt kommunizieren. Die Kommunikation erfolgt in der Regelasynchron, unter Umständen kann es aber dazu kommen, dass einer derbeteiligten Prozesse blockiert wird.

Blockieren beim Empfang: Ein Konsument wird blockiert, wenn er ver-sucht Daten über einen Input-Port zu empfangen, in dessen Kanalkeine Daten vorhanden sind. In diesem Fall wird der Konsument solange blockiert bis Daten eintreffen – also der vorgelagerte ProduzentDaten über seinen Output-Port sendet.

Blockieren beim Senden: Ein Produzent wird blockiert, wenn er versuchtDaten über einen Output-Port zu senden, dessen Kanal seine maxima-le Kapazität erreicht hat. In diesem Fall wird der Produzent blockiert,bis wieder genügend Kapazität im Kanal frei wird. Dies geschieht so-bald der nachgelagerte Konsument, über seinen Input-Port, Daten ausdem vollen Kanal empfängt. Für den Entwickler einer Komponente istdieser Vorgang transparent.

4.2.4 Queries

Allgemeine Informationen über den Zustand von Prozessen und Anwendun-gen werden von der Ablaufplattform beobachtet und auf Anfrage bereitge-stellt. Mit Hilfe von Abfragen, können Komponenten darüber hinaus indivi-duelle Informationen zur Verfügung stellen. Sofern vorhanden, können dieseAbfragen eines Prozesses sofort nach dessen Initialisierung und über das En-de einer Berechnung hinaus ausgeführt werden. Zu Beachten ist dabei, dassdie Abfragen im Kontext der Ablaufplattform – und nicht im Kontext desabgefragten Prozesses – ausgewertet werden. In Abschnitt 5.2.3 werden dieVerarbeitung von Status- und zusätzlichen Abfragen weiter beschrieben.

20

5 Netze & Anwendungen

Eine Netzdefinition wird vom Benutzer mit Unterstützung eines Entwick-lungswerkzeugs graphisch oder textuell erstellt. Zunächst einmal ist eineNetzdefinition ein rein syntaktisches Konstrukt, welches repräsentiert, wasder Benutzer geschrieben oder gezeichnet hat. Diese Form wird durch einenabstrakten Syntaxbaum repräsentiert, für den eine „Transfersyntax“ imXML-Format definiert wurde. Eine Schemadefinition legt das Speicherfor-mat des Entwicklungswerkzeugs fest und bildet die Basis, auf der graphischeoder textuelle Editoren der Entwicklungsumgebung arbeiten. Netzdefinitio-nen sind in erster Linie interne Bestandteile des Entwicklungswerkzeugs.

Ein Netz definiert den Ablauf einer Anwendung. Es umfasst Parameter, Pro-zesse und deren Verbindungen. Anwendungen sind interne Bestandteile derAblaufplattform. Eine Anwendung besteht aus einem Anwendungskontextsowie allen Prozessen und Kanälen gemäß der Netzdefinition.

5.1 Definition von Netzen

Die Definition von Netzen umfasst neben ihrem Namen einige weitere, kom-plexe Bestandteile. Die verschiedenen Elemente werden in den nun folgendenAbschnitten erläutert.

5.1.1 Netzparameter

Mit Hilfe von Netzparametern können die Komponenten eines Netzes kon-figuriert werden. Dadurch wird neben der Wiederverwendbarkeit der Kom-ponenten auch die des gesamten Netzes erhöht. Ein Netz kann, genau wieeine Komponente, beliebig viele Parameter nutzen.

21

Ihre Definition umfasst dabei wieder folgende Bestandteile:

Name: Ein innerhalb des Netzes eindeutiger Bezeichner identifiziert jedenParameter.

Typ: Der angegebene Typ legt den Datentyp eines Parameters fest.

Wert: Optional kann durch die Angabe eines Wertes ein Standardwert fest-gelegt werden. Der Standardwert wird verwendet, wenn kein passendesStartargument vorliegt.

Um eine hohe Wiederverwendbarkeit von Komponenten zu gewährleisten,ist innerhalb der Komponenten kein direkter Zugriff auf Netzparameter mög-lich. Bei der Definition der Prozesse eines Netzes (siehe Abschnitt 5.1.2)können die lokalen Komponentenparameter aber mit den globalen Netzpa-rametern verknüpft werden. Anhand dieser Definition entscheidet sich erstbei der Ausprägung konkreter Prozesse, woher ein Parameter seinen Werterhält. Daraus ergeben sich viele Möglichkeiten für die Quelle von Argumen-ten. Die gewählte Reihenfolge der folgenden Aufzählung entspricht dabei dertatsächlichen Auswertung:

Startargumente der Anwendung werden zunächst an die zugehörigen Netz-parameter gebunden. Durch die Verknüpfung von Netz- und Kom-ponentenparametern innerhalb einer Prozessdefinition erlangt gegebe-nenfalls auch ein Prozess Zugriff auf Startargumente.

Netzparameter für die ein Standardwert festgelegt wurde, können auch oh-ne die Angabe eines Startarguments verwendet werden. Auch in die-sem Fall muss dafür innerhalb der Prozessdefinition eine Verknüpfungvon Komponenten- und Netzparametern etabliert werden.

Werte können im Rahmen der Netzdefinition vordefiniert werden, um netz-oder prozessspezifische, konstante Werte für einen Parameter festzule-gen.

Standardwerte die bei der Netz- oder Komponentendefinition festgelegtwurden, sind die letztmögliche Quelle für den Wert von Parametern.Fehlen Startargument und Wert eines Parameters, für den kein Stan-dardwert festgelegt wurde, dann kommt es zu einem Fehler, weil keinWert für diesen Parameter bestimmt werden kann.

22

5.1.2 Prozesse

Netze entstehen durch die Komposition von Prozessen. Diese Prozesse sindparametrisierbare Instanzen vordefinierter Komponenten. Eine Prozessdefi-nition umfasst die folgenden Bestandteile:

Name: Innerhalb eines Netzes werden Prozesse durch einen eindeutigen Be-zeichner identifiziert.

Komponente: Ein Prozess „erbt“ Algorithmus-, Port-, Parameter- und Ab-fragedefinition der zugeordneten Komponente.

Argumente: Bei einem Argument handelt es sich entweder um einen netz-oder prozessspezifischen, konstanten Wert oder um eine Referenz aufeinen vordefinierten Netzparameter (vgl. Abschnitt 5.1.1). Sofern beider Definition der Komponente ein Standardwert für den Parametervordefiniert wurde, ist die Angabe eines Arguments optional.

Port-Datentypen: Bei Bedarf kann der designierte Typ der erwarteten/er-zeugten Daten jedes Ports konkretisiert werden. Auf Komponentene-bene ist dieser Typ oftmals generisch ausgelegt um die Wiederverwend-barkeit der Komponente zu gewährleisten.

5.1.3 Verbindungen & Kanäle

Damit Prozesse über ihre Ports kommunizieren können, bedarf es einer Ver-bindung. Eine Verbindung ist eine gerichtete Hyperkante des Datenfluss-netzes. Neben der direkten Verbindung zwischen Output- und Input-Portzweier Prozesse, sind also auch Verbindungen zwischen mehreren Output-und Input-Ports verschiedener Prozesse möglich. In jedem Fall gilt, dassjeder Konsument alle Daten sämtlicher Produzenten erhält. Dazu werdengegebenenfalls die Daten mehrerer Produzenten verschränkt und in Formvon unabhängigen Kopien an die Konsumenten verteilt. Sind mehrere Pro-duzenten Teil der Verbindung, dann kann sich ein Netz nichtdeterministischVerhalten.

Durch die Verbindung von Ports entstehen Kanäle, durch welche die Datenvom Output-Port des Produzenten zum Input-Port des Konsumenten fließen.Die Richtung der Verbindung beziehungsweise des Kanals entspricht derRichtung, in welcher die Daten fließen. Aus Sicht der beteiligten Prozesseist dies also von Output- zu Input-Port.

23

Aus Sicht eines Kanals betrachtet, ist der Output-Port des Produzenten einInput-Port und der Input-Port des Konsumenten ein Output-Port. Die Be-zeichnungen der Ports von Prozessen und Kanal lauten also entgegengesetzt.Weil dies sehr leicht zu Verwirrung führen kann, werden Verbindungen undKanäle ausnahmslos aus Sicht der beteiligten Prozesse beschrieben.

Außerdem dienen die Kanäle als FIFO-Puffer von konzeptionell unendlicherGröße. Tatsächlich haben die Kanäle immer eine endliche Kapazität, derenGröße jedoch nicht beschränkt ist. Nicht nur beim Empfangen von Datenaus einem leere Kanal, sondern auch beim Senden über einen Kanal dessenKapazität erschöpft ist, kann ein Prozess deshalb blockiert werden. Aufdiese Weise synchronisiert sich ein Netz „selbstständig“ und sorgt so füreine „faire“ Verteilung der vorhandenen Ressourcen auf die verschiedenenProzesse.

5.2 Lebenszyklus

Im Anschluss an die Definition des Netzes mit Hilfe eines Entwicklungs-werkzeugs findet zunächst eine statische Analyse (Konsistenzprüfung, Typ-berechnungen, etc.) statt. Sofern das Netz in sich konsistent ist, kann es derAblauflaufplattform übergeben werden. Die Ablaufplattform erzeugt darauf-hin eine Anwendung gemäß der Netzdefinition. Anwendungen können vomBenutzer mit Hilfe von Startargumenten parametrisiert und gestartet wer-den. Die Ablaufplattform kann dem Benutzer einfache Statusinformationenmitteilen und ermöglicht darüber hinaus auch die Ausführung komplexerAbfragen.

5.2.1 Bereitstellung von Netzen

Im Anschluss an die Netzdefinition mit Hilfe eines Entwicklungswerkzeugs,werden Netze der Ablaufplattform übergeben. Die Übergabe an die Ablauf-plattform erfolgt in Form einer XML-Datei. Anhand eines XML-Schemas,das deren Struktur festlegt, kann die Ablaufplattform das Netz auf Wohlge-formtheit und grundlegende Gültigkeit überprüfen. Anschließend erzeugt dieAblaufplattform eine interne Repräsentation des Netzes, deren Parameter,Prozesse und Verbindungen gemäß der Netzdefinition konfiguriert werden.Die Ablaufplattform verfügt darüber hinaus über einige weitere Methoden,welche die Bereitstellung von Netzen kontrollieren.

24

In Ermangelung eines Entwicklungswerkzeugs zur Netzdefinition findet der-zeit auch eine statische Analyse des Netzes innerhalb der Ablaufplattformstatt. Konfiguration und Analyse eines Netzes umfassen im Wesentlichendie folgenden Punkte:

• Prüfung der Werte von Komponentenparametern oder deren Referen-zen auf Netzparameter. Alle vordefinierten Werte und Referenzen wer-den Teil des Anwendungskontextes.

• Identifizieren und Laden aller benötigten Komponenten gemäß derProzessdefinition des Netzes. Dabei werden durch Analyse der Kompo-nenten auch die von ihnen definierten Ports, Parameter und Abfragenidentifiziert.

• Für alle Verbindungen werden die beteiligten Prozesse und deren Portsermittelt und auf Kompatibilität geprüft.

Nach bestandener Analyse steht das Netz dem Benutzer zur Ausführungzur Verfügung. Als Ergebnis erhält er eine eindeutige Kennung des soebenbereitgestellten Netzes.

5.2.2 Start einer Anwendung

Der Benutzer kann eine Liste aller Netze erfragen, die von der Ablaufplatt-form bereitgestellt werden. Entschließt sich der Benutzer eines dieser Netzezu starten, dann wird ihm dies ebenfalls durch die Ablaufplattform ermög-licht. Zum Start eines Netzes benötigt die Ablaufplattform den dazugehöri-gen Namen und gegebenenfalls die benötigten Startargumente.

Durch den Start eines Netzes wird die Ablaufplattform dazu veranlasst,eine laufbereite Instanz des Netzes – eine Anwendung – zu erzeugen. Dazugehört zunächst einmal der Anwendungskontext, welcher die Schnittstellezur Ablaufplattform darstellt. Danach werden die spezifizierten Prozesseder Anwendung erzeugt und deren Ports und Parameter initialisiert. Dabeiwerden auch die benötigten Kanäle erstellt und den Input-Ports zugewiesen.Darauf folgt die Parameterbindung, wie in Abschnitt 5.1.1 erläutert. Zuletztwerden die Output-Ports, gemäß der Netzdefinition, mit den zuvor erstelltenKanälen verbunden. Damit ist die Anwendung vollständig konfiguriert.

Die Ablaufplattform versetzt die Anwendung in einen laufbereiten Zustand,indem sie Threads zur Ausführung aller Prozesse bereitstellt. Zu beachtenist, dass die Ablaufplattform möglicherweise nicht in der Lage ist die Anwen-dung zu starten, weil beispielsweise nicht mehr genügend viele Ressourcen

25

zur Verfügung stehen. In diesem Fall wird die Ablaufplattform die Aus-führung der Anwendung verweigern oder zur späteren Bearbeitung in ei-ne Warteschlange einreihen. Schließlich erhält der Benutzer eine eindeutigeKennung der erzeugten Anwendung.

5.2.3 Ablaufkontrolle

Mit Hilfe der Ablaufplattform kann der Benutzer Informationen über denaktuellen Zustand einer Anwendung erhalten. Die Anwendung selbst be-obachtet ihre Prozesse und ermittelt ihren Status. Auf Anwendungsebenewerden derzeit die folgenden Zustände unterschieden:

Bereit signalisiert, dass eine Anwendung vollständig konfiguriert und lauf-bereit ist.

Startend / Gestartet sind Anwendungen deren Prozesse gerade gestartetwerden oder deren Prozesse laufen.

Pausierend / Pausiert werden Anwendungen um ihre Verarbeitung unddie damit verbundene Ressourcenbelastung vorübergehend zu unter-brechen. Die Ausführung von pausierten Anwendungen kann zeitnahwieder aufgenommen werden.

Stoppend / Gestoppt sind Anwendungen, die für eine längere Zeit vomBenutzer unterbrochen werden oder wurden. Im Gegensatz zu pau-sierten Anwendungen sind sie angehalten, möglichst viele der zuvorangeforderten Ressourcen wieder freizugeben.

Abbrechend / Abgebrochen sind Anwendungen die auf Wunsch des Benut-zers nicht weiter ausgeführt werden sollen. Abgebrochene Anwendun-gen können nicht fortgesetzt werden.

Scheiternd / Gescheitert sind Anwendungen, bei deren Ausführung ein un-erwarteter Fehler aufgetreten ist. Scheitert ein Prozess der Anwendung,dann werden alle weiteren Prozesse abgebrochen. Eine gescheiterte An-wendung kann nicht fortgesetzt werden.

Fertig ist eine Anwendung, wenn alle ihre Prozesse ihre Arbeit regulär be-endet haben.

Damit der Benutzer den Ablauf von Anwendungen steuern kann, stellt dieAblaufplattform eine Reihe von geeigneten Methoden zur Verfügung. Sokann der Benutzer die Verarbeitung einer Anwendung beispielsweise pausie-ren, stoppen, fortsetzen oder abbrechen.

26

5.2.4 Statusabfragen

Sofern die verwendeten Komponenten weitere Abfragen bereitstellen, kön-nen diese neben den allgemeinen Statusabfragen ausgeführt werden. Wie sol-che zusätzlichen Abfragen implementiert werden erläutert Abschnitt 4.1.4.Das dort aufgeführte Beispiel wird nun im Kontext eines fiktiven Netzesbetrachtet.

Quelltext 5.1 zeigt die Interaktion mit der Ablaufplattform – insbesonderedie Bereitstellung eines Datenflussnetzes, den Start einer Anwendung unddie Verarbeitung von Abfragen.

import de.fh_giessen.mni.doda.network .*;

ApplicationContainer container =ApplicationContainer.getInstance ();

// deploy the networkString network =

container.deploy(new File("resources/standardReport.xml"));System.out.println("Network␣" + network + "␣deployed");

// start the applicationMap <String , String > arguments = new HashMap <String , String >();arguments.put("offset", "100");

String application = container.start(network , arguments);System.out.println("Application␣" + application + "␣started");

// print application status and query results every ten secondsSet <String > queries = container.getQueries(application);while (container.isAlive(application)) {

Thread.sleep (10000);

String status = container.getStatus(application);System.out.println("Status␣" + status);

for (String query : queries) {String result = container.query(application , query);System.out.println("Query␣" + query + "␣=␣" + result));

}}

Quelltext 5.1: Verwendung von Abfragen

27

Bei der Bereitstellung eines Datenflussnetzes wird die Ablaufplattform zu-nächst alle benötigten Komponenten laden und analysieren. Während derAnalyse der Komponente „Example“ stößt die Ablaufplattform auch aufdie Definition der Abfrage „average“ und speichert eine dazugehörige Refe-renz.

Beim Start der Anwendung „application“ werden anschließend die spezifi-zierten Prozesse erzeugt. Die zuvor gespeicherte Referenz auf die obige Ab-frage wird nun konkretisiert und verweist nun auf die Methode „average“einer Instanz der Komponente „Example“.

Nach dem Start der Anwendung stellt die Ablaufplattform dem Benutzerein Liste aller Abfragen einer Anwendung zur Verfügung. Der Bezeichnereiner Abfrage wird dabei durch die Konkatenation von Prozess- und Ab-fragebezeichner gebildet und lautet beispielsweise „example.average“. MitHilfe des Bezeichners kann der Benutzer eine Abfrage anschließend von derAblaufplattform ausführen lassen.

28

6 Typen & Werte

Ein eigenständiges Typsystem erlaubt in erster Linie eine klare Schnittstellezwischen Komponenten, Netzen und der Ablaufplattform. Motiviert wurdediese Neukonzeption durch eine doppelte Aufwandsreduzierung bei der De-finition von Berechnungen. Die Deklaration von Datentypen an Input- undOutput-Ports gibt dem Entwickler einer Komponente die Möglichkeit, dieStruktur der Daten vor/nach der Transformation zu definieren. Dies wirktsich in zweifacher Hinsicht positiv aus:

Innerhalb einer Komponente kann der Entwickler davon ausgehen, dassdie von ihm festgelegten Anforderungen an die Struktur der empfan-genen Daten erfüllt werden. Damit entfällt die häufig aufwändige undredundante Prüfung dieser Datenstrukturen zur Laufzeit. Dies hat ei-nerseits zur Folge, dass die Anwendung leistungsstärker wird. Anderer-seits vereinfacht sich die Entwicklung von Komponenten, weil sich derEntwickler voll auf die Definition des Handlungsfadens konzentrierenkann.

Innerhalb eines Netzes können die deklarierten Datentypen für eine stati-sche Analyse herangezogen werden. Dadurch kann das Entwicklungs-werkzeug strukturelle Fehler innerhalb eines Netzes schon zur Entwick-lungszeit erkennen und darauf hinweisen. Außerdem kann die mögli-cherweise große Zahl vordefinierter Komponenten automatisch auf eineUntermenge kompatibler Komponenten reduziert werden. Auf dieseWeise wird also auch die Entwicklung von Netzen erheblich verein-facht.

Ziel des neukonzipierten Typsystems ist es, die Definition von Komponentenund Netzen in der beschriebenen Art und Weise zu vereinfachen. Außerdemregelt es die Weite/Grenze ihrer Wiederverwendbarkeit. Die dazu benötigteGenerizität lässt sich mit Hilfe einer Reihe von Basisdatentypen und durchderen Komposition formulieren.

29

Diese Datentypen werden, gemäß einer vordefinierten Zuordnung, auf ent-sprechende Java-Datentypen abgebildet. Tabelle 6.1 zeigt eine Übersicht derBasisdatentypen und deren Zuordnung zu Java-Datentypen.

Typ Java-DatentypBoolean java.lang.BooleanByte java.lang.ByteShort java.lang.ShortInteger java.lang.IntegerLong java.lang.LongFloat java.lang.FloatDouble java.lang.DoubleDate java.util.DateTime java.lang.Long1

DateTime java.util.DateString java.lang.String

Tabelle 6.1: Basisdatentypen

Weitere Datentypen, für die es keine vordefinierte Zuordnung gibt, könnendurch die Verwendung des Typs String auf einfache Weise in die Anwen-dung geschleust und dort beliebig verarbeitet werden. Mit Hilfe von Listenund Verbunden, den sogenannten „Records“2, können aus den Basisdaten-typen auch hierarchische Strukturen gebildet werden.

Listen vereinen beliebig viele Werte eines gemeinsamen Basisdatentyps ineiner Datenstruktur. Der Datentyp LIST wird in Java mit Hilfe derSchnittstelle java.util.List abgebildet. Diese ermöglicht unter an-derem das Hinzufügen und Entfernen von Listenelementen sowie dendirekten Zugriff über einen Index.

Beispiel für eine Liste von Zahlen:

LIST[Integer] = [1, 2, 3]

1Für den Datentyp Time wird die Klasse java.lang.Long wird verwendet, weil der Wer-tebereich der Klasse java.util.Time nur Zeitspannen bis 24 Stunden unterstützt. DieAngabe der Zeit oder Dauer erfolgt konventionsgemäß in Millisekunden.

2Die Bezeichnung „Record“ geht auf den vergleichbaren Datentyp record der Program-miersprache Pascal zurück. Auch die Programmiersprache C verfügt mit struct überein solches Konstrukt.

30

Records sind Datentypen, die sich aus benannten Komponenten verschie-dener Datentypen zusammensetzen. Weil die Datentypen RECORD undLIST selbst auch Komponenten eines Records sein können, lassen sichdamit komplexe hierarchische Strukturen beschreiben. In Java werdenRecords mit Hilfe der Schnittstelle java.util.Map abgebildet.

Beispiel für einen Record von Personen:

RECORD[name :String, [name :Doe,vorname :String, = vorname :John,geburtstag:Date ] geburtstag:1.12.1972]

In seiner Komplexität bleibt dieses Typsystem damit zwar hinter dem mäch-tigen Typsystem von Java zurück. Die erreichte Ausdruckskraft reicht in derPraxis allerdings aus, um die Schnittstelle von Komponenten hinreichend ge-nerisch zu definieren und ist zudem wesentlich benutzerfreundlicher. Stattüber komplexe Vererbungshierarchien und Schnittstellen, wie in Java, wirddie Kompatibilität von Datentypen mittels der �-Relation bestimmt.

Informal betrachtet, ist ein Datentyp t1 im Sinne der �-Relation, genaudann mit einem Datentyp t2 kompatibel, wenn t1 spezieller oder gleich t2ist. Die formale Definition der �-Relation lautet wie folgt:

Basistypen: Byte � Short � Integer � Long � Float � Double,DateTime � Date

Listen: LIST[t] � LIST[t′] ⇐⇒ t � t′

Records: RECORD[C] � RECORD[C ′] ⇐⇒ C ⊆ C ′∧∀c ∈ C∃c′ ∈ C ′ | c � c′

Überall dort, wo Werte des Basistyps Integer erwartet werden, können alsobeispielsweise auch Daten vom Typ Short verarbeitet werden. Listen sindkovariant, das heißt anstelle einer Liste mit Elementen des Typs Integerkann auch eine Liste des Typs Short verarbeitet werden. Ähnliches gilt auchfür Records. Wenn ein Record a mindestens alle Komponenten eines zweitenRecords b enthält und die Datentypen komponentenweise kompatibel sind,dann kann statt b auch a verwendet werden.

31

7 Beispiel

Die Vorgehensweise bei der Definition eines Datenflussnetzes und dessenArbeitsweise wird im Folgenden anhand eines Beispiels erläutert. Die-ses Beispiel ist angelehnt an Szenarien, wie sie auch im Rahmen desPARASUITE-Projekts auftreten.

7.1 Berechnung der Ausfälle auf Gerätebasis

Ziel der Berechnung von Ausfällen auf Gerätebasis ist es, herauszufindenzu wie vielen Fehlern es während der Nutzung eines Geräts innerhalb einesvorgegebenen Zeitraums kommt. Durch die Betrachtung mehrerer Gerätekönnen sowohl Abweichungen einzelner Geräte als auch systematische Fehlererkannt werden.

Das Ergebnis der Berechnung von Ausfällen auf Gerätebasis wird in Formzweier Tabellen festgehalten. Sie zeigen jeweils das betroffene Gerät (anhandeiner Seriennummer), die Anzahl der Ausfälle im gesamten Betrachtungszeit-raum, sowie die durchschnittliche Zahl der Ausfälle pro Monat an. Zusätzlichwerden die Ausfälle in den letzten drei Monaten vor dem Ende des Betrach-tungszeitraumes separat aufgeführt. Die beiden Tabellen unterscheiden sichnur in der betrachteten Datenmenge – während sich die erste Tabelle aufalle Fehler der ausgewählten Geräte bezieht, werden in der zweiten Tabellenur diejenigen Ausfälle betrachtet, welche bestimmten Filterkriterien (wiebeispielsweise Garantiefälle) entsprechen.

Die Tabellen 7.1 und 7.2 stellen das Ergebnis einer solchen Berechnungexemplarisch dar.

33

Seriennummer Ausfällegesamt monatlich Oktober November Dezember

4001 28 0,78 0 1 04002 13 0,36 0 0 04003 23 0,64 0 0 04004 16 0,44 0 0 14005 15 0,42 0 0 04006 8 0,22 0 0 04007 15 0,42 0 0 04008 21 0,58 0 0 24009 19 0,53 0 0 04010 20 0,56 0 0 14012 9 0,25 0 1 04013 20 0,56 0 0 14014 19 0,53 2 1 14015 8 0,22 0 0 0

Tabelle 7.1: Gesamtausfälle auf Gerätebasis

Seriennummer Ausfällegesamt monatlich Oktober November Dezember

4001 27 0,75 0 1 04002 12 0,33 0 0 04003 23 0,64 0 0 04004 16 0,44 0 0 14005 15 0,42 0 0 04006 7 0,19 0 0 04007 14 0,39 0 0 04008 19 0,53 0 0 24009 18 0,50 0 0 04010 20 0,56 0 0 14012 7 0,19 0 1 04013 17 0,47 0 0 14014 19 0,53 2 1 14015 8 0,22 0 0 0

Tabelle 7.2: Gefilterte Ausfälle auf Gerätebasis

34

7.1.1 Logischer Ablauf der Berechnung

Die Berechnung der Ausfälle auf Gerätebasis kann mit einem Datenflussnetzauf intuitive Weise definiert werden. Abbildung 7.1 zeigt die Topologie einessolchen Datenflussnetzes. Daraus gehen die verwendeten Prozesse und Kom-ponenten sowie deren Verbindungen (mit exemplarischen Daten) hervor.

Der logische Ablauf des Beispiels beginnt mit dem Prozess namens „failure“.Dieser liest gemäß seiner Konfiguration bestimmte Werte aus einer ange-schlossenen PARASUITE-Datenbank und sendet sie an seinen Nachfolger.Im konkreten Beispiel handelt es sich dabei um Ausfallmeldungen. Zu jederAusfallmeldung wird die Seriennummer des betroffenen Geräts sowie derZeitpunkt des Fehlers und diverse Fehlercodes festgehalten.

Der Prozess mit dem Namen „filter“ erfüllt gleich zwei Aufgaben. Zunächstfiltert dieser Prozess Duplikate von Ausfallmeldungen aus dem Datenstromheraus. Anschließend werden einige der Fehlercodes analysiert um festzu-stellen, um welche Art von Fehler es sich handelt. Die Ausfallmeldungenwerden um ein entsprechendes Element ergänzt und die dadurch überflüssiggewordenen Fehlercodes werden verworfen.

Der Prozess namens „group“ speichert zunächst alle eingehenden Datensät-ze in einer Liste. Sobald keine weiteren Daten mehr eintreffen, gruppiert erdie zwischengespeicherten Ausfallmeldungen anhand des betroffenen Geräts.Dadurch verändert sich die Struktur der Daten, sodass anschließend nichtmehr viele einzelne Ausfallmeldungen verschiedener Geräte, sondern eineListe von Ausfallmeldungen je Gerät verarbeitet wird.

Analog zum Prozess „failure“ liest der Prozess „device“ ebenfalls Daten auseiner angeschlossenen PARASUITE-Datenbank. Allerdings handelt es sichin diesem Fall um ergänzende Informationen über die Geräte, die nicht ausden Ausfallmeldungen hervorgehen.

Der Prozess mit dem Namen „join“ verknüpft schließlich beide eingehendenDatenströme miteinander. Dabei ergänzt er die aggregierten Ausfallmeldun-gen um die Informationen über das dazugehörige Gerät und überträgt dieDaten zum darauf folgenden Prozess.

Der Prozess namens „calc“ berechnet nun auf dieser Grundlage die Ausfälleauf Gerätebasis. Zu diesem Zweck wertet er die Daten aus und sendet jeGerät einen Datensatz mit den Ergebnissen an seinen Nachfolger.

Der letzte Prozess des Datenflussnetzes hat den Namen „result“. Er dientdazu, die eingehenden Daten in Form einer sogenannten CSV-Datei lokalzu speichern. Dabei kommt das gleiche Format wie bei PARASUITE zumEinsatz, wodurch das Ergebnis in bestehende Arbeitsabläufe integriert undanhand vorhandener Berechnungen überprüft werden kann.

35

7.1.2 Tatsächlicher Ablauf der Berechnung

Die tatsächliche Verarbeitung des Datenflussnetzes unterscheidet sich vomoben geschilderten, logischen Ablauf durch die inhärente Parallelverarbei-tung. Tatsächlich arbeiten alle Prozesse des Netzes gleichzeitig, sofern aus-reichend Ressourcen für die Berechnung zur Verfügung stehen und die Pro-zesse sich nicht blockieren. Letzteres ist vor allem dann der Fall, wenn einProzess auf eingehenden Daten wartet.

Im obigen Beispiel gilt dies für alle Prozesse bis auf „failure“ und „device“,die ungebremst mit ihrer Arbeit beginnen. Diese beiden Prozesse bauenalso eine Verbindung zu einer angeschlossenen PARASUITE-Datenbank auf,lesen gemäß ihrer Konfiguration bestimmte Werte aus und senden diesesequentiell an ihre Nachfolger.

Mit Eintreffen der Daten wird also auch die Verarbeitung durch die nach-gelagerten Prozesse „filter“ und „join“ wieder aufgenommen. Der Prozessnamens „filter“ bearbeitet jeweils einen Datensatz und sendet ihn im An-schluss daran direkt an den darauf folgenden Prozess.

Die Verarbeitung der Daten durch den Prozess mit dem Namen „group“hingegen, erfolgt derzeit nicht datenflusskonform. Um die Ausfallmeldun-gen anhand des betroffenen Geräts zu gruppieren, muss dieser Prozess zu-nächst alle eingehenden Datensätze sammeln. Sobald keine weiteren Datenmehr eintreffen, gruppiert er die zwischengespeicherten Ausfallmeldungenund sendet jede Gruppe einzeln an seinen Nachfolger.

Da nun an beiden Eingängen des Prozesses „join“ Daten anliegen, kannauch dieser seine Arbeit wieder aufnehmen. Er verknüpft die eingehendenDatenströme miteinander, indem er die aggregierten Ausfallmeldungen umdie Informationen über das dazugehörige Gerät ergänzt und überträgt dieDaten zum darauf folgenden Prozess.

Auch der Prozess mit dem Namen „calc“ nimmt seine Berechnungen mitEintreffen der Daten wieder auf. Er berechnet die Ausfälle auf Gerätebasisund sendet jeweils einen Datensatz mit den Ergebnissen an seinen Nachfol-ger. Die Ergebnisse der Berechnung fließen somit in den Prozess namens„result“, der sie nach und nach lokal, in Form einer CSV-Datei speichert.

36

failure:ParasuiteReader device:ParasuiteReader

f ilter:Filter

group:Group join:Join

result:CSVWriter

calc:DeviceBasedFailures

[device_serial: 4001, failure_serial: 3EGM003693R0001, failure_code: A11, failure_location: 13A11-A10, damage_code: C03, date_of_failure: 2005-02-21]

[device_serial: 4001, date_of_failure: 2005-02-21, filtered: false]

[device_serial: 4001, warranty_begin: 2004-09-28, warranty_end: 2006-09-28]

[device_serial: 4001, failure:[ [date_of_failure: 2005-02-21, filtered: false], ...]]

[device_serial: 4001, warranty_begin: 2004-09-28, warranty_end: 2006-09-28 failure:[ [date_of_failure: 2005-02-21, filtered: false], ...]]

[device_serial: 4001, total_failures: 28, total_failures_filtered: 27, monthly_average: 0.78, monthly_average_filtered: 0.75, actual_month: 0, actual_month_filtered: 0, last_month: 1, last_month_filtered: 1, month_before_last: 0, month_before_last_filtered: 0]

Abbildung 7.1: Datenflussnetz zur Berechnung der Ausfälle auf Gerätebasis

37

7.2 Verwendete Komponenten

Um die Untersuchung des obigen Beispiels zu vervollständigen, werden imFolgenden die verwendeten Komponenten genauer betrachtet. Mit welcherTechnologie diese Komponenten implementiert werden hängt von unter-schiedlichen Faktoren ab.

Auf der einen Seite können durch leichtgewichtige Skriptkomponenten einfa-che, individuelle Algorithmen auf Basis von Groovy definiert werden. Diesist immer dann sinnvoll, wenn eine Komponente eher selten wiederverwen-det werden kann und nicht besonders kritisch für die Geschwindigkeit derBerechnung ist. Außerdem kann die Definition von Skriptkomponenten indas Entwicklungswerkzeug integriert werden.

Auf der anderen Seite bieten vollwertige Komponenten, die direkt in Javaimplementiert und bei der Ablaufplattform hinterlegt werden, dem Entwick-ler einer Komponente größtmögliche Freiheit bei der Programmierung undeine höhere Verarbeitungsgeschwindigkeit. Weil die Entwicklung einer Kom-ponente in Java dadurch vergleichsweise aufwendig ist, lohnt sich dies vorallem für häufig benötigte oder geschwindigkeitsrelevante Komponenten.

7.2.1 PARASUITE-Lesekomponente

Die PARASUITE-Lesekomponente dient als Datenquelle, indem sie Da-ten aus einer angeschlossenen PARASUITE-Datenbank liefert. Diese Kom-ponente wurde bereits in Java implementiert und verfügt über einigePARASUITE-spezifische Konfigurationsparameter.

Parameter „locale“ legt die gewünschte Sprache fest.Standardwert: „de_DE“

Parameter „entity“ gibt die PARASUITE-Entität an, deren Daten gelesenwerden sollen. Die Entität entspricht letztlich einer Datenbanktabelle.Beispiel: „failure“ für Ausfallmeldung

Parameter „types“ enthält eine Liste aller Attribute der Entität, die gele-sen werden sollen.Beispiel: „device_serial, warranty_begin, warranty_end“

Parameter „filter“ kann optional einen Teil der Datenvorverarbeitung andas angeschlossene DBMS delegieren. Die wichtigste Aufgabe des Fil-ters ist es, die Datenmenge von vornherein auf das nötige Maß zubeschränken. Zu diesem Zweck wird der Filterausdruck in Form einer„WHERE-Klausel“ Teil der generierten Datenbankabfrage.

38

Filterausdrücke werden mit Hilfe von XML beschrieben. Ihre Strukturwird durch die Implementierung der Filterausdrücke in PARASUITEvorgegeben. Da solche Filterausdrücke schnell umfangreich werdenkönnen, wird nicht der Filter selbst als Argument genutzt. Stattdessenwird der Pfad einer XML-Datei hinterlegt, welche den Filterausdruckenthält und für die Ablaufplattform zugreifbar ist.

<?xml version="1.0" encoding="UTF -8"?><filter idGroup="false"

xmlns:xsi="http: //www.w3.org /2001/ XMLSchema -instance"xmlns:xs="http: //www.w3.org /2001/ XMLSchema"><expression >

<type locale="de_DE" entity="device">device_serial

</type><operator type="BETWEEN" /><values xsi:type="xs:int">4001</values ><values xsi:type="xs:int">4015</values >

</expression ></filter >

Quelltext 7.1: Beispiel eines Filterausdrucks

Wird ein Prozess dieser Komponente gestartet, dann baut er zunächst mitHilfe der PARASUITE-API eine Verbindung zur Datenbank auf. Anschlie-ßend wird gemäß der obigen Konfiguration eine Datenbankabfrage generiert,welche die gewünschten Daten liefert. Diese Daten werden schließlich sequen-tiell an die nachfolgenden Prozesse gesendet.

39

7.2.2 Filterkomponente

Die Filterkomponente wurde in Form einer Skriptkomponente, das heißt aufBasis von Groovy, implementiert. Quelltext 7.2 zeigt, wie sich dies im Detailgestaltet.

Ein Großteil der grundlegenden Funktionalität1 wird bereits durch dieabstrakte Basisklasse „Component“ abgedeckt. Die Individualisierung derKomponente beginnt mit der Definition ihrer Ports. Die verwendete Fil-terkomponente definiert einen Input-Port durch die Deklaration der anno-tierten Objektvariablen „input“. Analog wird im Anschluss daran auch einOutput-Port namens „output“ definiert.

Der individuelle, benutzerdefinierte Algorithmus wird innerhalb der Me-thode „execute“ implementiert. Dabei werden die Daten des Input-Portsmit Hilfe eines Iterators empfangen und sequentiell verarbeitet. Falls nötigblockiert der Prozess bis Daten eintreffen oder die Verbindung geschlossenwird – also keine weiteren Daten mehr empfangen werden können.

Zunächst filtert der Algorithmus dann Duplikate aus dem Datenstrom her-aus. Zu diesem Zweck wird anhand einiger eindeutiger Attribute ein „Fin-gerabdruck“ jedes Datensatzes erzeugt. Im Verlauf der Berechnung werdendie Fingerabdrücke von verarbeiteten Datensätzen sukzessive in einer sepa-raten Liste hinterlegt. Befindet sich der Fingerabdruck eines Datensatzesschon vor dessen Verarbeitung in dieser Liste, dann handelt es sich um einDuplikat das ignoriert werden kann.

Anschließend werden einige der Fehlercodes der Ausfallmeldungen analysiertum festzustellen, um welche Art von Fehler es sich handelt. Jeder Datensatzwird um ein entsprechendes Attribut ergänzt und die dadurch überflüssiggewordenen Fehlercodes werden verworfen. Schließlich wird der modifizierteDatensatz über den Output-Port an den nächsten Prozess gesendet.

1Dazu gehört beispielsweise die Methode namens „checkpoint“, welche den Status ei-nes Prozesses mit seiner Anwendung abgleicht und diesen falls nötig pausiert, stoppt,fortsetzt oder abbricht.

40



public class Filter extends Component {

@In(type = "RECORD[device_serial:Integer ,␣failure_serial:String ,␣failure_code:String ,␣failure_location:String ,␣damage_code:String ,␣date_of_failure:Date]")

public InputPort input

@Out(type = "RECORD[device_serial:Integer ,␣date_of_failure:Date ,␣filtered:Boolean]")

public OutputPort output

void execute () {def fingerprints = []input.each {

def fingerprint = [it.date_of_failure , it.failure_serial ,it.failure_location]

if (! fingerprints.contains(fingerprint)) {fingerprints.add(fingerprint)

def filtered = trueswitch (it?. failure_code) {

case "A00":case "A05":case "A06":case "A07":case "A16":case "A17": filtered = false

}filtered |= it?. damage_code == "C31"it.filtered = filtered

it.remove("failure_serial")it.remove("failure_code")it.remove("failure_location")it.remove("damage_code")output.send(it)

}checkpoint ()

}}

}

Quelltext 7.2: Beispiel einer Filterkomponente

41

7.2.3 Gruppierungskomponente

Auch die Gruppierungskomponente wurde auf Basis einer Skriptkomponen-te realisiert. Ihre Implementierung wird im Quelltext 7.3 dargestellt. DieAufgabe dieser Komponente ist es, Ausfallmeldungen anhand des betroffe-nen Geräts zu gruppieren. Dadurch verändert sich die Struktur der Daten,sodass nicht mehr viele einzelne Ausfallmeldungen verschiedener Geräte, son-dern eine Liste von Ausfallmeldungen je Gerät verarbeitet wird.

Um eine vollständige Gruppierung zu gewährleisten, speichert diese Kom-ponete zunächst alle eingehenden Datensätze in einer temporären Liste.1Sobald keine weiteren Daten mehr eintreffen, werden die zwischengespei-cherten Ausfallmeldungen gruppiert. Die dadurch entstehenden Gruppenwerden anschließend einzeln über den Output-Port an den nächsten Prozessgesendet. Nach der Gruppierung sind die Daten wie folgt strukturiert:

RECORD [device_serial:Integer ,failure:LIST[

RECORD[date_of_failure:Date ,filtered:Boolean

]]

]

Datenstruktur des Output-Ports

[device_serial :4001 ,failure :[

[date_of_failure :2005 -02 -21 ,filtered:false

], ...]

]

Beispiel eines Records nach der Gruppierung

1Diese Vorgehensweise wird selbstverständlich bei großen Datenmengen problematischund steht auch der Parallelverarbeitung imWege – sie stellt aber die einfachste Strategiedar und ist für dieses Beispiel ausreichend.

42



public class Group extends Component {

@In(type = "RECORD[device_serial:Integer ,␣date_of_failure:Date ,␣filtered:Boolean]")


@Out(type = "RECORD[device_serial:Integer ,␣failure:LIST[RECORD[date_of_failure:Date ,␣filtered:Boolean ]]]")


private volatile List list = []private volatile Map groups = [:]


list.add(it)checkpoint ()

}

groups = list.groupBy { it.device_serial }groups.each { key , value ->

value*. remove("device_serial")output.send([ device_serial:key , fam:value])

}}

@Query(type = "RECORD[received:Integer ,␣groups:Integer]")public String queryStatus () {

return ["received": list.size(), "groups": groups.size()]}

}

Quelltext 7.3: Beispiel einer Gruppierungskomponente

43

7.2.4 Verbundkomponente

Die Aufgabe einer Verbundkomponente ist es, mehrere Datenströme zu verei-nen. Für die Berechnung der Ausfälle auf Gerätebasis wurde die Vereinigungebenfalls in Form einer Skriptkomponente – die im Quelltext 7.4 dargestelltwird – implementiert.

Bei den zu verbindenden Daten handelt es sich zum einen um die nach Ge-räten gruppierten Ausfallmeldungen und zum anderen um zusätzliche Infor-mationen über die betroffenen Geräte1. Um beide Datenströme zu vereinenwird jeweils nach zueinander passenden Datensätzen gesucht. Zu diesemZweck empfängt die Komponente zunächst die gruppierten Ausfallmeldun-gen eines Geräts. Anschließend wird überprüft, ob die zusätzlichen Informa-tionen über dieses Gerät bereits bekannt sind.

Ist dies nicht der Fall, dann empfängt die Verbundkomponente anschließendDaten über ihren zweiten Input-Port. Dies tut sie solange bis ein passenderDatensatz eintrifft oder die Verbindung geschlossen wird – also keine wei-teren Daten mehr über diesen Input-Port empfangen werden können. Da-bei werden die zusätzlichen Informationen aller Geräte zwischengespeichert,um später bei der Verarbeitung entsprechender Ausfallmeldungen daraufzurückgreifen zu können.

Wenn die zusätzlichen Informationen des betroffenen Geräts bereits vorhan-den sind oder inzwischen empfangen wurden, dann werden die Ausfallmel-dungen um die zusätzlichen Informationen ergänzt. Schließlich werden dieergänzten Ausfallmeldungen an den nächsten Prozess weitergeleitet.

Sollten über ein Gerät keine zusätzlichen Informationen empfangen werden,dann ist eine Verarbeitung der dazugehörigen Ausfallmeldungen nicht mög-lich. In diesem Fall wird eine entsprechende Warnung ausgegeben.

1Die zusätzlichen Informationen über die betroffenen Geräte sind im weiteren Verlaufdes Beispiels, nicht aber im zugrundeliegenden Szenario, entbehrlich.

44



public class Join extends Component {

@In(type = "RECORD[device_serial:Integer ,␣warranty_begin:Date,␣warranty_begin:Date]")

public InputPort devicePort

@In(type = "RECORD[device_serial:Integer ,␣failure:LIST[RECORD[date_of_failure:Date ,␣filtered:Boolean ]]]")

public InputPort failurePort

@Out(type = "RECORD[device_serial:Integer ,␣warranty_begin:Date ,␣warranty_begin:Date ,␣failure:LIST[RECORD[date_of_failure:Date ,␣filtered:Boolean ]]]")


void execute () {def devices = [:]failurePort.each {

def failure = itif (! devices[failure.device_serial ]) {

devicePort.each {def device = itdevices[device.bn_serfzg] = device

if (failure.device_serial == device.device_serial) {return

}checkpoint ()

}}def device = devices[failure.device_serial]if (device) {

failure.putAll(device)output.send(failure)

} else {System.err.println "process␣$name␣could␣not␣join␣token␣

$failure"}checkpoint ()

}}

}

Quelltext 7.4: Beispiel einer Verbundkomponente

45

7.2.5 Skriptkomponente zur Berechnung der Ausfälle

Auch für die Berechnung der Ausfälle kommt eine Skriptkomponente zumEinsatz. Als erste Skriptkomponente verfügt sie über spezielle Parameter,welche den Start- beziehungsweise Endpunkt des betrachteten Zeitraumsfestlegen. Quelltext 7.5 zeigt die verwendete Implementierung.

Zu Beginn der Berechnung werden die beiden angesprochenen Parametervom Datentyp DateTime zu einem Calendar-Objekt umgewandelt. Dies istnötig, um von den vereinfachten Sprachmitteln für Datumsarithmetik inGroovy zu profitieren.1 Anschließend werden die Stichtage der letzten dreiMonate vor Berichtsende sowie die Anzahl der Monate im betrachteten Zeit-raum ermittelt.

Die darauf folgende Berechnung liefert die Daten für die beiden Tabellen 7.1und 7.2. Jede Spalte dieser Tabellen wird innerhalb der Skriptkomponentedurch eine entsprechende Variable repräsentiert, derenWert in Abhängigkeitvon den Daten modifiziert wird. Aufgrund der im Vorfeld vorgenommenenGruppierung, erfolgt die Verarbeitung der Ausfallmeldungen an dieser Stellebereits gebündelt nach Geräten.

Die Anzahl der Ausfallmeldungen eines Geräts wird innerhalb des betrachte-ten Zeitraums sowie gesondert für die letzten drei Monate ermittelt. Dabeiwird auch berücksichtigt, ob eine Ausfallmeldung den festgelegten Filterkri-terien entsprochen hat. Im Anschluss an die Analyse aller Ausfallmeldun-gen eines Geräts wird das Ergebnis der Berechnung für dieses Gerät an dennächsten Prozess gesendet.



public class DeviceBasedFailures extends Component {

@In(type = "RECORD[device_serial:Integer ,␣warranty_begin:Date,␣warranty_begin:Date ,␣failure:LIST[RECORD[date_of_failure:Date ,␣filtered:Boolean ]]]")


@Out /* type definition omitted */public OutputPort output

1Wie deutlich zu sehen ist gestaltet sich der Umgang mit Datumswerten vergleichsweiseschwierig. Obwohl durch den Einsatz von Groovy gegenüber Java schon eine leichteVereinfachung erreicht wurde, ist hier noch viel Spielraum für Verbesserungen.

46

@Parameter(type="DateTime")public def begin

@Parameter(type="DateTime")public def end

void execute () {

GregorianCalendar calendar = new GregorianCalendar ()calendar.setTime(begin)begin = calendar

calendar = new GregorianCalendar ()calendar.setTime(end)end = calendar

def aux1 , aux2 , aux3 , totalMonths = 0use(org.codehaus.groovy.runtime.TimeCategory) {

aux1 = end.time - 1. monthaux2 = end.time - 2. monthsaux3 = end.time - 3. months

for(def i = begin.time; i < end.time; i += 1.month) {++ totalMonths

}}

input.each {def totalFailures = 0, totalFailuresFiltered = 0,

actualMonth = 0, actualMonthFiltered = 0,lastMonth = 0, lastMonthFiltered = 0,

monthBeforeLast = 0, monthBeforeLastFiltered = 0

it.failure.each {if (begin.time <= it.date_of_failure

&& it.date_of_failure <= end.time) {++ totalFailuresif (it.filtered) ++ totalFailuresFiltered

if (aux1 <= it.date_of_failure) {++ actualMonthif (it.filtered) ++ actualMonthFiltered

} else if (aux2 <= it.date_of_failure) {++ lastMonthif (it.filtered) ++ lastMonthFiltered

} else if (aux3 <= it.date_of_failure) {++ monthBeforeLastif (it.filtered) ++ monthBeforeLastFiltered

}}

}

47

output.send(["device_serial": it.device_serial ,"total_failures": totalFailures ,"total_failures_filtered": totalFailuresFiltered ,"monthly_average": totalFailures / totalMonths ,"monthly_average_filtered":

totalFailuresFiltered / totalMonths ,"actual_month": actualMonth ,"actual_month_filtered": actualMonthFiltered ,"last_month": lastMonth ,"last_month_filtered": lastMonthFiltered ,"month_before_last": monthBeforeLast ,"month_before_last_filtered": monthBeforeLastFiltered])

checkpoint ()}

}}

Quelltext 7.5: Skriptkomponente zur Berechnung der Ausfälle

7.2.6 CSV-Schreibkomponente

Auch die letzte verbleibende Komponente des betrachteten Datenflussnetzesist eine Skriptkomponente. Sie dient dazu die Ergebnisse von Berechnun-gen in Form einer CSV-Datei festzuhalten. Der Pfad dieser Datei ist übereinen Parameter der Komponente konfigurierbar. Zur Verarbeitung des CSV-Formats wird eine auch von PARASUITE genutzte Bibliothek verwendet.

Die Implementierung der Komponente ist im Quelltext 7.6 dargestellt. Dader Input-Port keinen konkreten Datentyp vorgibt, wird automatisch der ge-nerische Standardtyp RECORD verwendet. Um die Wiederverwendbarkeit derKomponente weiter zu erhöhen, wird die Kopfzeile auf Basis der Schlüsselempfangener Records gebildet. Bei der Verarbeitung des allerersten Daten-satzes wird vor dem eigentlichen Inhalt zunächst die Kopfzeile ausgegeben.Anschließend werden die Werte der empfangenen Records in die CSV-Dateigeschrieben.

48



public class CSVWriter extends Component {

@Inpublic InputPort input

@Parameterpublic def filename

void execute () {def file = new FileWriter("./ $filename")def writer = new de.parasuite.csv.CSVWriter(file)def headline = trueinput.each {

def values = []if (headline) {

def keys = []it.each { key , value -> keys.add(key.toString ()) }writer.writeNext(keys.toArray(new String [0]))headline = false

}it.each { values.add(it.value.toString ()) }writer.writeNext(values.toArray(new String [0]))checkpoint ()

}writer.close()

}

}

Quelltext 7.6: Beispiel einer Schreibkomponente

49

8 Implementierung

Um das Konzept der datenflussorientierten Datenanalyse näher zu untersu-chen, wurde im Rahmen dieser Arbeit der Prototyp einer Ablaufplattformimplementiert. Im Fokus der Untersuchungen standen neben der Erprobungdes Gesamtkonzepts insbesondere die beiden Gesichtspunkte: Machbarkeitund Benutzerfreundlichkeit. Da im Rahmen des PARASUITE-Projekts be-reits gute Erfahrungen mit dem Konzept des Datenflusses gemacht wurden,spielte die Leistungsstärke der prototypischen Implementierung zunächst ei-ne untergeordnete Rolle.

8.1 Entwicklungsumgebung

Genau wie PARASUITE wurde auch die Ablaufplattform in Java, mit Hilfeder Entwicklungsumgebung Eclipse for RCP and RAP Developers1, imple-mentiert. Zum Einsatz kam dabei die Version Helios und die folgenden dreiZusatzmodule.

Groovy-Eclipse liefert die Implementierung der Skriptsprache Groovy (inVersion 1.7.3) und bindet diese in die Eclipse Entwicklungsumgebungein. Eingesetzt wurde Groovy-Eclipse2 in der Version 2.0.

Subclipse ermöglicht den nahtlosen Zugriff auf Apache Subversion3 ausder Eclipse Entwicklungsumgebung. Bei Subversion handelt es sichum ein quelloffenes Versionsverwaltungssystem, dass im Rahmen desPARASUITE-Projekts verwendet wird. Eingesetzt wurde Subclipse4

in der Version 1.6.

Eclipse Checkstyle unterstützt Entwickler bei der Einhaltung bewährterProgrammierstandards. Zu diesem Zweck analysiert Eclipse Checksty-le den Quelltext und markiert Stellen, die gegen solche Standards ver-stoßen. Die verwendete Konfiguration basiert auf den „Sun Code Con-ventions“5. Eingesetzt wurde Eclipse Checkstyle6 in der Version 5.1.

1Eclipse, http://eclipse.org2Groovy-Eclipse, http://groovy.codehaus.org/Eclipse+Plugin3Apache Subversion, http://subversion.apache.org4Subclipse, http://subclipse.tigris.org5Sun Code Conventions, http://java.sun.com/docs/codeconv6Eclipse Checkstyle, http://eclipse-cs.sf.net

51

http://eclipse.org

http://groovy.codehaus.org/Eclipse+Plugin

http://subversion.apache.org

http://subclipse.tigris.org

http://java.sun.com/docs/codeconv

http://eclipse-cs.sf.net

8.2 Struktur der Implementierung

Zur Erprobung des Konzepts der datenflussorientierten Datenanalyse wurdeder Prototyp einer Ablaufplattform implementiert. Die Vielzahl der dazubenötigten Klassen wurde gemäß ihrer Funktionalität in einigen wenigenPaketen gruppiert. Die Paketstruktur des Prototyps wird in Abbildung 8.1dargestellt.

de.fh_giessen.mni.doda

main

type

java groovy

component

impl

network

«access»

«access»

«access»

Abbildung 8.1: Paketstruktur des Prototyps

Die folgende Übersicht gibt Auskunft darüber, welche Funktionalität diePakete umfassen.

Paket „main“ beinhaltet eine Klasse mit deren Hilfe die Ablaufplattformgestartet und eine Anwendung ausgeführt werden kann.

Paket „network“ enthält die öffentliche Schnittstelle (API von engl. „appli-cation programming interface“) der Ablaufplattform. Diese API dienteinerseits zur Steuerung der Ablaufplattform und wird andererseitsauch bei der Implementierung von Komponenten verwendet. Soweitmöglich und sinnvoll, wurde die API von ihrer Implementierung ge-trennt.

Paket „impl“ welches dem Paket „network“ untergeordnet ist, um-fasst die zur API dazugehörige Implementierung.

52

Paket „component“ ist das Paket in dem die Ablaufplattform nach denKomponenten eines Datenflussnetzes sucht. Übersichtlichkeitshalberwurden diese Komponenten ferner anhand der verwendeten Technolo-gie unterteilt.

Paket „java“ fasst alle Komponenten zusammen, die direkt in Javaimplementiert wurden.

Paket „groovy“ ist der Ort, an dem Groovy-Skriptkomponenten re-sidieren.

Paket „type“ kapselt alle dem Typsystem zugehörigen Klassen.

8.3 Stand der Realisierung

Die prototypische Implementierung der Ablaufplattform bildet die Grundla-ge, auf deren Basis ein Gesamtkonzept für die Verarbeitung von Daten durchNetze kooperierender Prozesse – von ihrer Definition mit Hilfe parametri-sierbarer Komponenten, über die Komposition zu Datenflussnetzen, bis hinzu deren Bereitstellung und Ausführung – erarbeitet werden konnte. Trotz-dem stellt der Prototyp primär den Ausgangspunkt für weitere Arbeiten indiesem Umfeld dar.

Insbesondere Aufgrund des Fehlens eines geeigneten Entwicklungswerkzeugszur Unterstützung der Netzdefinition, mussten bei der Implementierung desPrototyps einige Kompromisse eingegangen werden. Dies betrifft vor allemden Informationsaustausch zwischen dem Entwicklungswerkzeug und derAblaufplattform. So werden im Entwicklungswerkzeug zur Definition einesDatenflussnetzes beispielsweise Informationen über die vorhandenen Kom-ponenten benötigt. Wenngleich diese Informationen innerhalb der Ablauf-plattform zur Verfügung stehen, gibt es noch keine geeignete Schnittstelleum sie nach Außen bereitzustellen.

Noch unzureichend festgelegt ist auch das Format, in welchem die Netz-definition vom Entwicklungswerkzeug an die Ablaufplattform übertragenwird. Das erarbeitete XML-Schema beschreibt im Wesentlichen die Topolo-gie des Datenflussnetzes. Sobald mit Hilfe des Entwicklungswerkzeugs auch(Skript-)Komponenten definiert werden können, wird zum Austausch derNetzdefinition ein „Deploymentartefakt“ benötigt. Dieses Deploymentarte-fakt sollte beispielsweise auch externe Bibliotheken beinhalten können, diebei der Definition von Komponenten genutzt werden.

53

Derzeit werden Komponenten ausnahmslos mit Hilfe der Eclipse Entwick-lungsumgebung implementiert und direkt bei der Ablaufplattform hinter-legt. Die Eclipse Entwicklungsumgebung bietet dank des ZusatzmodulsGroovy-Eclipse auch für die Entwicklung von Skriptkomponenten eine her-vorragende Unterstützung. Darüber hinaus erlaubt dieses Vorgehen eineAnalyse der implementierten Komponenten mit Hilfe des Debuggers.

Die Unterstützung durch das Entwicklungswerkzeug fehlt auch bei der Kon-kretisierung der generischen Port-Datentypen von Komponenten bei der De-finition von Prozessen. Aus diesem Grund wurde schließlich auf die Angabeund Verifikation konkretisierter Typinformationen bei der Prozessdefinitionverzichtet. Stattdessen werden vorläufig nur die Typdefinitionen der Kompo-nenten beachtet. Folglich bietet auch die Implementierung des Typsystemsnoch Spielraum für Verbesserungen.

Schließlich können auch Steuerung und Kontrolle laufender Anwendungennoch verbessert werden. Zwar stellt die abstrakte Basisklasse aller Kompo-nenten eine Methode namens „checkpoint“ bereit, welche den Status einesProzesses mit seiner Anwendung abgleicht und diesen falls nötig pausiert,stoppt, fortsetzt oder abbricht – eleganter wäre es aber, diese nicht in dieHände eines Komponentenentwicklers zu legen, sondern sie automatisch bei-spielsweise beim Senden oder Empfangen von Daten aufzurufen.

54

9 Ausblick

Für die Zukunft der datenflussorientierten Datenanalyse sind einige Weiter-entwicklungen angedacht. Diese betreffen vordergründig die prototypischeImplementierung der Ablaufplattform. Zunächst ist die Implementierungweiterer grundlegender Komponenten geplant, welche die Definition von Be-rechnungen nochmals vereinfachen. Zur Verwaltung der wachsenden Zahlvon Komponenten und Bibliotheken in verschiedenen Versionen könnte fer-ner das Komponentenmodell OSGi1 in die Ablaufplattform integriert wer-den.

Des Weiteren soll untersucht werden, inwieweit verschiedene Technologi-en zur „internen“ Parallelisierung von Komponenten beitragen können.Vielversprechend erscheint hierfür das MapReduce2-Konzept, die Unterstüt-zung durch ein DBMS sowie die Nutzung von Grafikprozessoren durchNvidia CUDA3.

Die vielleicht wichtigste Aufgabe ist aber die Implementierung eines graphi-schen Entwicklungswerkzeugs, welches den Benutzer bei der Definition vonDatenflussnetzen und Skriptkomponenten unterstützt.

1OSGi, http://www.osgi.org/About/HomePage2Google MapReduce, http://labs.google.com/papers/mapreduce.html3Nvidia CUDA, http://www.nvidia.com/object/cuda_home.html

55

http://www.osgi.org/About/HomePage

http://labs.google.com/papers/mapreduce.html

http://www.nvidia.com/object/cuda_home.html

10 Schluss

Im Rahmen dieser Arbeit wurde ein umfassendes Konzept zur datenflussori-entierten Datenanalyse erarbeitet. Dieses Konzept beschreibt die Verarbei-tung von Daten durch Netze kooperierender Prozesse und deckt dabei – vonder Definition parametrisierbarer Komponenten, über die Verknüpfung vonProzessen zu Datenflussnetzen mit Hilfe typisierter Kommunikationsschnitt-stellen, bis hin zur Bereitstellung und Ausführung dieser Netze – sämtlicheArbeitsschritte ab.

Die dazu benötigten Ausdrucksmittel wurden mit dieser Arbeit dokumen-tiert und anhand einer prototypischen Implementierung überprüft. Dabeihat die Implementierung nicht nur die Tragfähigkeit des erarbeiteten Kon-zepts bestätigt. Durch stärkere Strukturierung und Komponentenorientie-rung der Neukonzeption, wurden darüber hinaus auch die Erwartungen hin-sichtlich der Intuitivität erfüllt.

In Zukunft kann die prototypische Implementierung in PARASUITE alsGrundlage für datenflussorientierte Datenanalyse dienen. Sie liefert außer-dem eine Basis für weitere Forschungen in diesem Umfeld.

57

Abbildungsverzeichnis

7.1 Datenflussnetz zur Berechnung der Ausfälle auf Gerätebasis . 37

8.1 Paketstruktur des Prototyps . . . . . . . . . . . . . . . . . . . 52

I

Quelltextverzeichnis

4.1 Definition und Verwendung von Ports . . . . . . . . . . . . . 164.2 Definition und Verwendung von Komponentenparametern . . 174.3 Definition von Abfragen . . . . . . . . . . . . . . . . . . . . . 18

5.1 Verwendung von Abfragen . . . . . . . . . . . . . . . . . . . . 27

7.1 Beispiel eines Filterausdrucks . . . . . . . . . . . . . . . . . . 397.2 Beispiel einer Filterkomponente . . . . . . . . . . . . . . . . . 417.3 Beispiel einer Gruppierungskomponente . . . . . . . . . . . . 437.4 Beispiel einer Verbundkomponente . . . . . . . . . . . . . . . 457.5 Skriptkomponente zur Berechnung der Ausfälle . . . . . . . . 467.6 Beispiel einer Schreibkomponente . . . . . . . . . . . . . . . . 49

III

Literaturverzeichnis

Kahn, Gilles: The Semantics of Simple Language for Parallel Program-ming. In IFIP Congress. 1974, S. 471–475.

Kahn, Gilles/MacQueen, David B.: Coroutines and Networks of Par-allel Processes. In IFIP Congress. 1977, S. 993–998.

Lieberman, Henry et al.: End-User Development: An Emerging Para-digm. In End User Development. Band 9, Springer Netherlands, 2006,ISBN 978–1–4020–5386–3, S. 1–8.

Morrison, J. Paul: Flow-Based Programming: A New Approach to Ap-plication Development. Van Nostrand Reinhold, 1994, ISBN 0–442–01771–5.

Steinseifer, Sven: Evaluation and Extension of an Implementationof Flow-Based Programming. Masterarbeit Fachhochschule Gießen-Friedberg, 2009.

V

Eidesstattliche Erklärung

Hiermit versichere ich, die vorliegende Arbeit selbstständig und unter aus-schließlicher Verwendung der angegebenen Literatur und Hilfsmittel erstelltzu haben. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keineranderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.

Mücke, Philipp Hoffmann

Documents

Masterarbeit – Philipp Hoffmann - THMAbstract This thesis describes a comprehensive concept for data processing via net-works of cooperating processes. The core of the developed