Lehrstuhl für Informatik 7Rechnernetze und Kommunikationssysteme
Mirko Hansen
Regelbasierte syntaktische Veränderung vonausführbaren UML2-Aktivitätsdiagrammen aufSensorknoten am Beispiel von SunSPOTs
Studienarbeit im Fach Informatik
28. Oktober 2010
Please cite as:Mirko Hansen, “Regelbasierte syntaktische Veränderung von ausführbaren UML2-Aktivitätsdiagrammen auf Sensorknotenam Beispiel von SunSPOTs,” Studienarbeit, University of Erlangen, Dept. of Computer Science, October 2010.
Friedrich-Alexander-Universität Erlangen-NürnbergDepartment Informatik
Rechnernetze und Kommunikationssysteme
Martensstr. 3 · 91058 Erlangen · Germany
www7.informatik.uni-erlangen.de
Regelbasierte syntaktische Veränderung vonausführbaren UML2-Aktivitätsdiagrammen
auf Sensorknoten am Beispiel von SunSPOTs
Studienarbeit im Fach Informatik
vorgelegt von
Mirko Hansen
geb. am 3. Februar 1983in Köln
angefertigt am
Lehrstuhl für Informatik 7Rechnernetze und Kommunikationssysteme
Department InformatikFriedrich-Alexander-Universität Erlangen-Nürnberg
Betreuer: Gerhard Fuchs
Betreuender Hochschullehrer: Prof. Dr.-Ing. Reinhard German
Beginn der Arbeit: 1. Februar 2010
Abgabe der Arbeit: 28. Oktober 2010
Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser
als Teil einer Prüfungsleistung angenommen wurde.
Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als
solche gekennzeichnet.
Declaration
I declare that the work is entirely my own and was produced with no assistance
from third parties.
I certify that the work has not been submitted in the same or any similar form for
assessment to any other examining body and all references, direct and indirect, are
indicated as such and have been cited accordingly.
(Mirko Hansen)
Erlangen, 28. Oktober 2010
Abstract
Programming of sensor nodes is a recent research topic on which the chair is
specialized with the ACOOWEE project. They develop a framework that allows
controlling Sun SPOTs (sensor nodes developed by Sun Microsystems) with UML2
activity diagrams. Previously those diagrams had to be created with the UML2 tool
Papyrus, then converted by XML transformation (XSLT) into an own RDF based
format of the framework and at last imported and executed. With that solution
there was no possibility at any time to modify the diagram at runtime within the
framework.
This thesis introduces exactly this possibility. UML2 activity diagrams can be modified
with a ruleset, developed for this purpose. Though the modifications are limited
to syntactical modifications. Due to the functionality of the ruleset it is possible to
describe complex selection and replacement scenarios.
By the use of generalization you are able to create universal UML2 activity diagrams
that can get specialized by each sensor node itself. Furthermore you are able to
readept diagrams to recent changes to environmental properties and correct minor
mistakes without having to modify and convert the whole diagram again. With a
simple programming interface, the developer can use the new feature everywhere
within the framework in an easy and uncomplicated way.
iii
Kurzfassung
Programmierung von Sensorknoten ist ein aktuelles Forschungsthema, mit dem
sich, im Zuge des ACOOWEE-Projekts, auch der Lehrstuhl beschäftigt. Dort wird ein
Framework entwickelt, welches die Steuerung von Sun SPOTs (Sensorknoten der
Firma Sun Microsystems) per UML2-Aktivitätsdiagrammen erlaubt. Bisher wurden
diese Diagramme mit Hilfe des UML2-Tools Papyrus entworfen, anschließend durch
XML-Transformation (XSLT) in ein RDF-basiertes, eigenes Format des Frameworks
konvertiert und schließlich eingelesen und ausgeführt. Bei diesem Ablauf bestand zu
keiner Zeit die Möglichkeit Änderungen an einem Diagramm zur Laufzeit innerhalb
des Frameworks durchzuführen.
Mit dieser Arbeit wurde eben diese Möglichkeit geschaffen. UML2-Aktivitätsdiagram-
me lassen sich, mit einer eigens zu diesem Zweck entwickelten Regelsprache, verän-
dern. Diese Veränderungen sind jedoch auf syntaktische Änderungen beschränkt.
Durch die Funktionsvielfalt der Regelsprache ist es allerdings möglich sogar sehr
komplexe Auswahl- und Ersetzungsszenarien zu behandeln.
Durch Generalisierung lassen sich universelle UML2-Aktivitätsdiagramme erstellen,
welche von jedem Sensorknoten spezialisiert werden können. Außerdem können
Veränderungen an der Umgebung angepasst, sowie kleinere Fehler korrigiert werden,
ohne dabei das komplette Diagramm verändern und neu konvertieren zu müssen.
Durch eine einfache Schnittstelle steht dem Programmierer die Neuerung an jeder
Stelle des Frameworks, ohne größeren Programmieraufwand, zur Verfügung.
iv
Inhaltsverzeichnis
Abstract iii
Kurzfassung iv
1 Einleitung 1
2 Ziel 3
2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Regelbasiert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Syntaktische Veränderung . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Arbeiten auf dem Gebiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Ausgangssituation 9
3.1 Sun SPOTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 UML2 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 Extensible Stylesheet Language Transformation (Extensible
Stylesheet Language Translations (XSLTs)) . . . . . . . . . . . . 13
3.2.3 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Umsetzung 17
4.1 Veränderung/Optimierung durch Extensible Markup Language (XML)-
Konverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Regelbasierte Veränderungen im Framework . . . . . . . . . . . . . . . 19
4.2.1 Besucher-Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Regelsprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
v
Inhaltsverzeichnis vi
4.2.2.1 Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2.2 Modifikation . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.3 Regelparser/-grammatik . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.4 Regelbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.5 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.6 Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Veränderung/Optimierung durch Besucher . . . . . . . . . . . . . . . . 40
5 Beispiele & Anwendungen 41
5.1 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Zusammenfassung 49
Abbildungsverzeichnis 52
Tabellenverzeichnis 53
Literaturverzeichnis 54
Kapitel 1
Einleitung
Programmierung von Sensorknoten ist ein weitläufiges und aktuelles Thema in
der Forschung. Das ACOOWEE-Projekt [1] untersucht die Möglichkeit, UML2-
Aktivitätsdiagramme (UADs) auf Sensorknoten, speziell Sun SPOTs, ausführen
zu lassen. Zu diesem Zweck wurde ein Framework geschaffen, welches diese Funk-
tionalität bietet. Dabei wird ein UML2-Aktivitätsdiagramm (UAD) mit Hilfe eines
Modellierungstools entworfen, im XML Metadata Interchange (XMI)-Format ab-
gespeichert, durch Transformationsregeln in ein anderes XML-basiertes Format
gebracht und kann anschließend verwendet und interpretiert werden.
Das entwickelte Framework ist durchaus auch für größere Mengen an Sensorkno-
ten verwendbar, jedoch eröffnet sich mit zunehmender Menge an Sensorknoten in
einem, womöglich heterogenen, Sensornetz ein Problem: Es befindet sich beispiels-
weise ein kleiner Fehler in dem UAD. Um diesen beheben zu können, muss das UAD
im Modellierungstool verändert werden, anschließend erneut transformiert und an
alle Sensorknoten verteilt werden. Wenn nun noch verschiedene Varianten dieses
UADs verteilt wurden, wird diese Arbeit schnell sehr mühselig und zeitraubend.
Ein Weg, den Aufwand für dieses Problem zu minimieren, wird mit dieser Arbeit
geschaffen: Es sollen gezielt UADs zur Laufzeit verändert werden können, wobei die
Veränderungen durch Regeln ausgedrückt werden.
Da es sich bei Sensorknoten um Geräte mit stark begrenzten Systemressourcen
handelt, darf in diesem Zuge auch der Speicherverbrauch, sofern möglich, optimiert
werden.
Die Arbeit ist wie folgt aufgebaut: In Kapitel 2 wird das Ziel der Arbeit genauer
beleuchtet. Kapitel 3 beschäftigt sich mit dem Framework und der Umgebung vorher,
1
1 Einleitung 2
Kapitel 4 mit dem Entwurf, der Umsetzung und Implementierung der Erweiterung.
Wie die Neuerung zu verwenden ist beschreibt Kapitel 5. Abschließend liefert Ka-
pitel 6 eine Zusammenfassung dieser Arbeit, sowie einen Ausblick auf mögliche
weitere Entwicklungen.
Kapitel 2
Ziel
Das Ziel meiner Arbeit ist es, das bestehende Framework so zu erweitern, dass sich
UADs zur Laufzeit anhand von Regeln syntaktisch verändern lassen.
2.1 Definition
Essenziell ist natürlich die Frage, was genau unter „Regelbasierte syntaktische Ver-
änderung von ausführbaren UML2-Aktivitätsdiagrammen auf Sensorknoten am
Beispiel von SunSPOTs“ zu verstehen ist, sowie unter den einzelnen Bestandteilen
des Themas.
Ein ausführbares UML2-Aktivitätsdiagramm ist eine Erweiterung des von der
OMG [2] spezifizierten UML2-Aktivitätsdiagramms, welches den Ablauf eines Ver-
haltens festlegt. Dies ist durch die grafische Darstellung von Aktionen, welche durch
Kontroll- und Datenflüsse verkettet sind, möglich. Unterstützt werden dabei auch
Entscheidungen und Parallelität. Aufgrund der grafischen Repräsentation und der
nicht notwendigen Kenntnis einer traditionellen Programmiersprache, ist das Be-
schreiben eines Verhaltens einfacher erlernbar.
In einer anderen Arbeit [3] wird beschrieben, wie UML2-Aktivitätsdiagramme aus-
geführt werden können. Von der OMG wurde eine entsprechende Spezifikation [4]
entwickelt. Ein solcher Interpreter, zur Ausführung von UADs, wurde im Zuge der
Entwicklung des Frameworks von Damm [5] implementiert, und stellt die Basis
eben dieses dar.
Ein Sensorknoten [6] ist ein kleines Gerät, welches lediglich zum Messen von Daten
3
2.1 Definition 4
(z.B. Temperatur mit Hilfe eines Temperatursensors), Aufbereiten/Verarbeiten von
diesen (z.B. Durchschnittstemperatur über 10 Sekunden berechnen), und Kommuni-
kation untereinander, vorgesehen ist. Dieses minimalistische Prinzip erlaubt es, mit
wenig Energieverbrauch und geringen Kosten ganze Netze, sogenannte Sensornetze,
aufzubauen. Diese Sensorknoten können mit Hilfe von traditionellen Programmier-
sprachen (wie im Beispiel der Sun SPOTs: Java) programmiert werden. Es können
daher richtige Anwendungen, welche auf die Funktionalität und Systemresourcen
der Geräte zugeschnitten sind, entwickelt werden.
Am Lehrstuhl werden Sun SPOTs eingesetzt, welche in Abschnitt 3.1 noch beschrie-
ben werden. Daher setzt sich diese Arbeit ausschließlich mit der Anwendung auf
diesen Sensorknoten auseinander.
2.1.1 Regelbasiert
Das Ziel dieser Arbeit ist es, UADs gezielt zu verändern. Dies kann auf statischem
Weg erfolgen, also die möglichen Änderungen werden fest in den Programmcode
des Frameworks übernommen und compiliert. Damit entfällt jedoch die Möglichkeit,
Veränderungen zur Laufzeit anpassen zu können, oder sie ist durch die Unflexibilität
des Codes sehr eingeschränkt.
Die bessere Wahl sind dynamische Änderungen, die zur Laufzeit ausgewertet werden
können. Diese Lösung hätte eine hohe Flexibilität, da sie nahezu unabhängig vom
Programmcode des Frameworks ist, und es bietet sich eine große Bandbreite an
verschiedenen Möglichkeiten von Veränderungen.
Das Stichwort regelbasiert spezifiziert hier genauer, wie diese dynamischen Verände-
rungen ausgedrückt und definiert werden sollen. Diese sollen mit Hilfe von Regeln,
die im weitesten Sinne nichts Anderes sind, als logische mathematische Folgerungen
in der Form WENN ... DANN ..., festgelegt werden. Jede Regel besteht aus einer
Prämisse, also einer Bedingung, und einer Konklusion, einem Folgeschluss. Mit Hilfe
dieser Regeln kann zur Laufzeit genau festgelegt werden was verändert wird, und
wie es verändert wird.
2.1.2 Syntaktische Veränderung
Unter der Syntax versteht man die Korrektheit eines Programms (oder hier: UAD)
in Bezug auf die Grammatik, ohne dabei die Bedeutung, also die Semantik, zu be-
2.1 Definition 5
trachten. Ein Programm ist dann syntaktisch korrekt, wenn es vom Parser akzeptiert
wird. [7]
Im Falle dieser Arbeit ist diese Abgrenzung jedoch nicht so einfach zu treffen.
Zu beachten ist, dass im gesamten Verarbeitungsprozess eines UADs mehrere Ab-
straktionsschichten, wie in Tabelle 2.1 zu sehen, durchlaufen werden. Die Verar-
beitung beginnt mit einer einfachen Textdatei, welche durch verschiedene Schritte
innerhalb des Frameworks zu einer internen, objektorientierten Repräsentation
eines UADs (entspricht der Schicht 3 in Tabelle 2.1) für den Interpreter im Speicher
ausgewertet wird.
Das Ziel dieser Arbeit ist es, syntaktische Änderungen gezielt durchzuführen. Es
soll dabei die Semantik, also die Bedeutung, wie zum Beispiel in Schicht 4 die
Funktionsweise des beschriebenen Verhaltens des UADs, erhalten bleiben. Dabei
wird ausschließlich in Schicht 3 gearbeitet. Der Graph an sich bleibt mit allen seinen
Knoten und Kanten erhalten wie er ist. Lediglich Eigenschaften dieser Elemente
werden verändert.
Wichtig ist, dass durch die Veränderungen der Syntax in tieferen Schichten, Verän-
derungen der Semantik in höheren Schichten herbeigeführt werden können. Die
Einschränkung auf syntaktische Veränderungen ist also das primäre Ziel, ein Neben-
effekt, also die Veränderung der Semantik in höheren Abstraktionsebenen, ist also
nicht auszuschließen und teilweise sogar erwünscht. So lassen sich beispielsweise
über die Veränderung von Eigenschaften der ausgehenden Kanten eines Entschei-
dungsknoten auf Schicht 3 andere Entscheidungen, und somit andere Abläufe
erzeugen.
2.2 Arbeiten auf dem Gebiet
Obwohl es sich bei dem Themengebiet Unified Modeling Language (UML) um
ein Thema der intensiven Forschung und Weiterentwicklung handelt, wurde zum
Zeitpunkt der Erstellung dieser Arbeit keine weitere Arbeit oder Veröffentlichung ge-
funden, die sich mit dem Thema der Veränderung von UML2-Aktivitätsdiagrammen
beschäftigt. Eine Spezialisierung auf die Verwendung in Sensorknoten wurde bei
der Recherche generell vermieden, da diese Problemstellung doch sehr speziell, und
ein Sucherfolg um einiges unwahrscheinlicher wäre. Selbst eine Generalisierung
des Problems zur Suche bis hin zur regelbasierten Veränderung von (gerichteten)
2.2 Arbeiten auf dem Gebiet 6
Tabelle 2.1: Abstraktionsschichten eines UADs
Schicht Elemente Beschreibung
4 UML2-Aktivitätsdiagramm
Aktionen, Kontroll-& Objektflüsse
Beschreibung eines Verhaltens.
3 GerichteterGraph
Knoten & Kanten Der gerichtete Graph beschreibt,zusammen mit den Eigenschaf-ten der Knoten und Kanten,ein UML2-Aktivitätsdiagramm. Einsyntaktisch veränderter gerichteterGraph beschreibt weiterhin ein gül-tiges UML2-Aktivitätsdiagramm.Auf dieser Schicht arbeitet das Fra-mework.
2 XML-Baum Knoten & Attribute Der XML-Baum wird nach demParsen in eine höhere Abstrakti-onsschicht konvertiert, welche dieinterne Klassenstruktur repräsen-tiert. Ein syntaktisch veränderterXML-Baum beschreibt weiterhineinen gültigen gerichteten Gra-phen.
1 Textdatei Bytes Die Textdatei wird von einem XML-Parser zerteilt und in Baumformbeschrieben. Eine syntaktisch ver-änderte Textdatei ist weiterhin ei-ne valide XML-Datei.
2.2 Arbeiten auf dem Gebiet 7
Graphen blieb erfolglos. Zur Suche herangezogen wurden wissenschaftliche Such-
maschinen wie Google Scholar1 und CiteULike2. Gesucht wurde sowohl auf Deutsch
als auch auf Englisch.
2.3 Ansatz
Zunächst stellen sich mit dem Thema und mit Blick auf das bestehende Framework
einige Fragen, insbesondere „Was soll verändert werden?“, „Wie soll etwas verändert
werden?“ und „Wie soll dies ausgedrückt werden?“. Die Frage, wann genau eine
Veränderung stattfinden soll, wird vorerst zurückgestellt, da diese zum jetzigen
Zeitpunkt nicht relevant ist. Zu Testzwecken wird die Veränderung vorerst nur
einmalig am Anfang, wenn ein UAD eingelesen und im Speicher abgelegt wird,
durchgeführt, kann und soll dann aber im Zuge der späteren Entwicklung auch an
anderen Orten des Frameworks platziert und ausgelöst werden.
Nun aber zu den wichtigen Fragen:
„Was soll verändert werden?“ Nach der Definition von Abschnitt 2.1.2 soll der
Graph auf Abstraktionsschicht 3, also alle Knoten und Kanten in ihren Verknüpfung-
en, unverändert bleiben. Es dürfen lediglich die Attribute und Eigenschaften der
einzelnen Elemente verändert werden. Als Beispiele hierfür zu nennen sind die
Bedingungen von Kanten an Entscheidungsknoten, ein Name einer aufzurufenden
Aktivität oder die Zuweisung einer Adresse eines anderen Sun SPOTs zur entfernten
Ausführung einer Aktivität.
„Wie soll etwas verändert werden?“ Bei der Art der Veränderung gilt, genau
wie bei der vorherigen Frage, dass der Graph selber in seiner Form nicht verändert
werden darf. Es werden zwei mögliche Veränderungsarten festgelegt: komplettes
und partielles Ersetzen von Eigenschaften. Beispiele hierfür wären das Ersetzen von
verwendeten Variablen, sowie das Festlegen von kompletten Eigenschaften.
„Wie soll dies ausgedrückt werden?“ Um eine solche Veränderung ausdrücken
zu können, muss eine eigene Sprache eingeführt werden, mit welcher genau spe-
zifiziert werden kann, was verändert werden soll und wie. Diese Sprache sollte in
1http://scholar.google.de/2http://www.citeulike.org/
2.3 Ansatz 8
soweit flexibel sein, dass man mit den vorhandenen Mitteln jede mögliche Verände-
rung, welche auf die beiden oberen Fragen zutrifft, ausdrücken und durchführen
kann. Außerdem ist eine (einfache) Erweiterungsmöglichkeit wünschenswert, falls
in einer Weiterentwicklung eine größere Funktionalität gewünscht wird.
Kapitel 3
Ausgangssituation
Als Basis für diese Studienarbeit dient das Framework, welches im Zuge des
ACOOWEE-Projekts aus diversen Diplom- und Studienarbeiten, sowie eigenen Ent-
wicklungen des Lehrstuhls entstand. Dieses ist primär für die am Lehrstuhl verwen-
deten Sun SPOT Sensorknoten entwickelt worden. In diesem Abschnitt werden die
Sensorknoten und das Framework genauer in Augenschein genommen.
3.1 Sun SPOTs
Als Hardwarebasis werden sogenannte Sun SPOTs eingesetzt. Dabei handelt es sich
um Sensorknoten der Firma Sun Microsystems1, die von Haus aus diverse Sensoren
und Aktoren anbieten und sich auch mit kleinen, am Lehrstuhl entwickelten Robo-
tern verbinden lassen. Im Folgenden die wichtigsten technischen Merkmale [8] der
Sun SPOTs.
3.1.1 Hardware
Prozessor:
• 180 MHz 32 bit ARM920T Prozessor
• 512 KB RAM
• 4 MB Flash-Speicher
• 2.4 GHz IEEE 802.15.4 Funkkommunikation mit integrierter Antenne
• AT91 Zeitgeber
1http://www.sun.com
9
3.1 Sun SPOTs 10
Abbildung 3.1: Sun SPOTs neben einer AA-Batterie
• USB Schnittstelle
Sensoren/Aktoren:
• 2G/6G Drei-Achsen-Beschleunigungssensor
• Temperatursensor
• Lichtsensor
• 8 dreifarbige LEDs
• 6 analoge Eingänge
• 2 Tastschalter
• 5 Mehrzweck-I/O-Pins und 4 Hochstrom-Ausgangs-Pins
Batterie:
• 3.7V Lithium-Ionen-Akku mit 750 mAh
• 30 uA im Tiefschlaf-Modus
• Automatische Energieverwaltung durch die Software
3.1 Sun SPOTs 11
3.1.2 Software
Auf den Sun SPOTs läuft eine spezielle Version der Java Micro Edition (Java ME)
mit dem Namen Squawk [9]. Diese Java VM unterstützt die beiden Standards CLDC
1.1 und MIDP 1.0.
3.2 Framework
Das im Zuge des ACOOWEE-Projekts entwickelte Framework bietet die Möglichkeit
die Funktionen eines Sensorknotens (Sensoren, Aktoren, Funkkommunikation) mit
Hilfe von UADs zu nutzen. Dabei wird mit eben diesen ein „Programm“ in Form
einer UML-Aktivität beschrieben. Entworfen werden können solche Aktivitäten mit
dem UML-Modellierungstool Papyrus [10]. Theoretisch sollte das auch mit anderen
Tools möglich sein, es wurde jedoch bisher nur mit Papyrus (erfolgreich) getestet.
Die von Papyrus gespeicherten XMI-Dateien müssen in eine für das Framework
brauchbare Form konvertiert werden. Anschließend kann der Interpreter des Frame-
works diese vom Parser einlesen, in abstrakter Form im Speicher ablegen, und auf
Befehl ausführen lassen. Die wichtigsten Punkte dieses Vorgehens für diese Arbeit
werden im Folgenden etwas detaillierter beschrieben.
3.2.1 UML2 Aktivitätsdiagramme
Das Framework wird mit Hilfe von UML2 Aktivitätsdiagrammen gesteuert. Dies
bietet sich an, da ein UAD einen Arbeitsfluss beschreibt und somit eine interaktive
Steuerung ermöglicht. Es werden dabei Aktivitäten, Kontrollflüsse und Objektflüsse
als grundlegende Elemente verwendet, um einen Arbeitsfluss festzulegen. Es besteht
zusätzlich die Möglichkeit Entscheidungen sowie Parallelität zu modellieren, was
somit die Beschreibung nahezu jedes Szenarios auf einfache Weise erlaubt.
Da die Elemente eines UADs für diese Arbeit essenziell sind, werden diese nochmal
kurz erläutert. Eine detailliertere Übersicht und Beschreibung findet man in der
dazugehörigen Spezifikation der OMG [2] oder weiterer Literatur [11] zum Thema
UML2.
Die Grundelemente eines UADs sind in Abbildung 3.2 dargestellt:
Startknoten Beginn des Ablaufs in einer Aktivität.
Endknoten Ende einer Aktivität für alle Kontrollflüsse.
3.2 Framework 12
Startknoten
Endknoten Ablaufende
Aktion
Abbildung 3.2: Die Grundelemente eines UML2-Aktivitätsdiagramms.
[Bedingung1]
[Bedingung2]
Entscheidung Zusammenführung
Abbildung 3.3: Entscheidungen in einem UAD.
Ablaufende Ende eines einzelnen Kontrollflusses.
Aktion Aufruf einer Aktivität.
Desweiteren verfügt eine Aktivität über die Möglichkeit Entscheidungen zu treffen,
wie in Abbildung 3.3 dargestellt:
Entscheidung An diesem Punkt wird festgestellt in welchem ausgehenden Kontroll-
fluss fortgefahren wird.
Zusammenführung Vereint die einzelnen Kontrollflüsse einer (oder mehrerer)
Entscheidung(en).
Parallelität kann mit den in Abbildung 3.4 verwendeten Elementen beschrieben
werden:
Teilung An diesem Punkt wird der einzelne Kontrollfluss in mehrere, parallele
Kontrollflüsse aufgeteilt.
3.2 Framework 13
Teilung Synchronisation
Abbildung 3.4: Parallelität in einem UAD.
Abbildung 3.5: Objektflüsse in einem UAD.
Synchronisation Synchronisation und Vereinigung von parallelen Kontrollflüssen
zu einem einzelnen Kontrollfluss.
Um die Bewegung von Objekten zu beschreiben, gibt es in Abbildung 3.5 eine
Erweiterung: Aktionen, die Objekte generieren, besitzen einen Output-Pin, welcher
das Objekt unter dem festgelegten Namen zur Verfügung stellt. Der Objektfluss zeigt
in eine andere Aktion, welche einen Input-Pin besitzt. Durch den Objektfluss wird
das Objekt vom Output-Pin zum Input-Pin der Zielaktion transportiert und unter
dem festgelegten Namen des Input-Pins zur Verfügung gestellt.
3.2.2 Extensible Stylesheet Language Transformation (XSLTs)
Das Framework arbeitet, anders als das UML-Entwicklungstool Papyrus, mit einem
proprietären, Resource Description Framework (RDF)-basierten Format. Daher kann
es die UML-Dateien, die von Papyrus abgelegt werden, und ein komplettes UAD
enthalten, nicht direkt verwenden, obwohl beide in einem XML-basierten Format
vorliegen. Letztere Eigenschaft hat jedoch einen großen Vorteil im Bezug auf die
Konvertierung zwischen beiden Dateiformaten. Mit Hilfe der XSLT lassen sich im
XML-Format diverse Konvertierungsregeln festlegen, um Dateien von einem in ein
anderes XML-basiertes Format zu übersetzen.
Diese Methode wird hier angewendet, und verwandelt die von Papyrus abgelegte
UML-Datei in eine UAD-Datei des Frameworks, welche dann in dem von Damm [5]
3.2 Framework 14
definierten, RDF-basierten Format vorliegt. Die Konvertierung selber führt das Open-
Source-Tool xsltproc [12] durch, welches die XSLT-Regeln, sowie die UML-Datei, als
Kommandozeilenparameter übergeben bekommt, und diese dann, den XSLT-Regeln
entsprechend, umwandelt.
Die Semantik, also der grundlegende Aufbau des UADs, bleibt mit der Konvertierung
erhalten. Die meisten unnötigen Daten werden verworfen und die wichtigen Daten in
das gewünschte Format gewandelt. Das Tool arbeitet nur in der Abstraktionsschicht
2 (siehe Tabelle 2.1), sieht die Dateien selbst nur als einen XML-Baum, welcher
durch die XSLT-Regeln in eine andere Form gebracht wird. Es findet in diesem Tool
zu keiner Zeit eine Verarbeitung in einer höheren Abstraktionsschicht statt.
3.2.3 Core
Das konvertierte UAD durchläuft im Framework drei wichtige Schritte: Zuerst wird
die UAD-Datei eingelesen und vom Parser zerteilt. Das Ergebnis wird in abstrakter
Form im Speicher des Sun SPOTs abgelegt und anschließend, auf Befehl, von dem
internen Interpreter ausgeführt.
Parser Da es sich bei den konvertieren UADs um XML-Dateien in einem RDF-
basierten Format handelt, ist das Parsen dieser Dateien einfach. Es gibt bereits fertig
implementierte XML-Parser für Java, welche unter offenen Lizenzen stehen und
frei nutzbar sind. Der Klassenbibliothek der eingeschränkten Java ME, welche auf
den Sun SPOTs läuft, fehlen leider die Java-eigenen XML-Parser aus den Paketen
javax.xml.*. Daher verwendet das Framework die Bibliothek KXML [13].
Der Parser geht dabei alle Tags in der Reihenfolge, wie sie in der UAD-Datei auf-
gelistet sind, nach dem Prinzip der Tiefensuche durch. Dabei wird der komplette
Baum, der in der UAD-Datei im RDF-Format abgelegt ist, in abstrakter Form, linear
im Speicher abgelegt.
Speicherstruktur Der vom XML-Parser ausgelesene „Baum“ wird durch die im
Framework verwendete lineare Speicherstruktur wieder zu einem gerichteten Gra-
phen gewandelt. Dabei wird ein UAD selbst, sowie jeder Knoten- und Kantentyp
durch eine eigene Klasse repräsentiert, welche von der abstrakten Klasse Node
bzw. Edge abgeleitet ist. Eine Übersicht der korrespondierenden Java-Klassen ist in
Tabelle 3.1 aufgelistet.
3.2 Framework 15
Tabelle 3.1: Java-Klassen zur Repräsentation von Knoten und Kanten in einem UAD
Knoten-/Kantentyp korrespond. Java-Klasse
Startknoten InitialNode
Endknoten FinalNode
Ablaufende FlowFinalNode
Aktion (elementar) RootActionNode
Aktion (UML-Aktivität) UMLActionNode
Entscheidung DecisionNode
Zusammenführung MergeNode
Teilung ForkNode
Synchronisation JoinNode
Parametereingang ActivityParameterInNode
Parameterausgang ActivityParameterOutNode
Kontrollfluss Edge
Objektfluss ObjectFlow
Die komplette Speicherrepräsentation eines UADs erhält das Framework durch die
Rückgabe einer Referenz auf ein Activity-Objekt vom Parser. Dieses bietet dem
Framework Methoden zum Zugriff auf jeden Knoten und jede Kante des UADs über
die eindeutige ID des jeweiligen Objekts. Außerdem können die Eigenschaften einer
Aktivität, wie zum Beispiel der Name, festgelegt werden. Im Folgenden eine Liste,
der für diese Arbeit wichtigsten verfügbaren Methoden der Klasse Activity:
• addNode()
• addStartNode()
• addActivityParameterInNode()
• addActivityParameterOutNode()
• addEndNode()
• getStartNodes()
• getNode()
• setName()
3.2 Framework 16
• getName()
• setOption()
• getOption()
Dies ermöglicht allen Bereichen des Frameworks auf jedes Element eines UADs
zuzugreifen und dieses zu verändern. Beispielsweise lässt sich mit Hilfe der Methode
getStartNodes() eine Liste der Startknoten eines UADs auslesen, von welchen
aus, mit Hilfe von weiteren Methoden, sich der komplette Graph des UADs verfolgen
lässt. Zu erwähnen ist jedoch, dass der Graph nicht komplett mit Objektreferenzen
auf Kanten und Knoten miteinander verbunden ist, wie es durch etwas „Nacharbeit“
durchaus möglich wäre, sondern es besitzen lediglich Knoten eine Referenz auf die
angrenzenden Kanten. Umgekehrt ist ein Zwischenschritt über die eindeutige ID des
angrenzenden Knotens, und die getNode()-Methode des zugehörigen Activity-
Objekts nötig. Dies erschwert eine semantische Modifikation, da jede Verknüpfung
sowohl in den Objekten selber (die Referenzen innerhalb der Knoten auf die an-
grenzenden Kanten), als auch in den Hashtables der Aktivität, zum Auflösen der
eindeutigen ID in ein Objekt, verändert werden müsste.
Da es bei dieser Arbeit jedoch um die syntaktische Veränderung von UADs geht, und
die Verbindungen zwischen den Knoten nicht modifiziert werden, wird die oben
beschriebene Lösung beibehalten.
Interpreter Nachdem das komplette UAD geparst und im Speicher, in Form einer
Instanz der Klasse Activity, abgelegt und verfügbar ist, kann dieses bei Bedarf
interpretiert werden. Der Interpreter geht dabei so vor, dass er sich mit Hilfe der
Methode getStartNodes() alle Startknoten zurückgeben lässt, und an diesen die
parallele (sofern es mehrere sind) Ausführung beginnt. Es wird dabei pro Startkno-
ten ein eigener Programmfaden (Thread) gestartet. Dabei wird den Knoten und
Kanten von jedem Startknoten aus so lange logisch gefolgt, bis alle Programmfä-
den einen Endknoten erreicht haben. Die auf dem Weg betretenen Knoten werden
sinngemäß interpretiert und ausgeführt.
Kapitel 4
Umsetzung
4.1 Veränderung/Optimierung durch XML-Konverter
Wie in Abschnitt 3.2.2 beschrieben, müssen mit Papyrus erstellte UADs zuerst mit
Hilfe von XSLT-Regeln in ein RDF-basiertes Dateiformat des Frameworks umgewan-
delt werden.
Alle Objekte des UAD erhalten ursprünglich im UML-Dateiformat eine eindeutige,
aus genau 23 Buchstaben und Zahlen bestehende, kryptische Identifikation. Diese
ist nötig, um Verbindungen zwischen Knoten und Kanten zu beschreiben. Mit der
Konvertierung durch die XSLT-Regeln werden die langen Identifikationen 1:1 über-
nommen, welches in keiner Weise dem minimalistischen Prinzip entspricht, und
daher mehr Speicher als nötig verbraucht.
Eine Verbesserung der XSLT-Regeln erlaubt es, diese eindeutige Identifikation auf ein
Minimum zu reduzieren. Letztendlich werden Knoten mit n1, n2, n3, ... und Kanten
mit e1, e2, e3, ... benannt. Das Präfix n für Knoten bzw. e für Kanten ist notwendig,
da mit dieser Umsetzung der XSLT-Regeln ansonsten eine eindeutige Benennung
aller Elemente nicht möglich ist. Trotzdem ist eine Verkürzung der Anzahl der für
den Namen eines Elements verwendeten Zeichen von im Schnitt 87% bei größeren,
und bis zu maximal 91% bei kleineren UADs möglich.
Diese Einsparung ergibt sich konkret aus folgender Berechnung: Bei einer klei-
nen Anzahl an Elementen, es wird von maximal 9 Knoten und 9 Knoten ausge-
gangen, besteht die Identifikation eines Elements lediglich aus jeweils 2 Zeichen
(n1,n2,n3,...,n9 und e1,e2,e3,...,e9). Damit lässt sich die prozentuale Einsparung
an Zeichen durch den Quotient Eingespar te ZeichenZeichen vorher
berechnen. Konkret ergibt sich
17
4.1 Veränderung/Optimierung durch XML-Konverter 18
dabei, mit der Zeichenlänge von 23 zur Identifikation vor der Änderung, folgender
Wert: 23−223= 21
23≈ 91,3%. Für eine größere Anzahl an Elementen in einem UAD
wurde eine Menge von 99 Elementen angenommen. Dabei haben nur die Identifika-
tion 9 Kanten und 9 Knoten die Länge 2, alle anderen Identifikationen haben die
Länge 3. Die Berechnung erfolgt analog zu der Berechnung für die kleine Anzahl an
Elementen.
Listing 4.1: XSLT: Generieren der Identifikation der Knoten
1 <xsl:attribute name="rdf:about">2 <xsl:value -of select="concat('n',position ())" />3 </xsl:attribute >
Im Beispiel von Listing 4.1 wird die Identifikation der Knoten mit n und der Posi-
tion innerhalb der Datei festgelegt. Anschließend müssen noch alle Verbindungen,
die durch Kanten gegeben sind, angepasst werden. Hierbei ruft die entsprechende
Regel das Template fetchnodeid, wie in Listing 4.2, mit der alten Identifikation
als Parameter auf.
Listing 4.2: XSLT: Auflösen der alten Identifikation in die neue Bezeichnung
1 <xsl:call -template name="fetchnodeid">2 <xsl:with -param name="nodeid" select="@source" />3 </xsl:call -template >
Das Template fetchnodeid aus Listing 4.3 iteriert nun durch alle Knoten
innerhalb der Datei und gibt die Identifikation des Knotens (die ja laut Listing 4.1
aus n und der Position innerhalb der Datei besteht) zurück, dessen ehemalige
Identifikation mit dem übergebenen Parameter übereinstimmt.
Listing 4.3: XSLT: Template zum Auflösen der alten Identifikation in die neueBezeichnung
1 <!--find and resolve compact node id -->2 <xsl:template name="fetchnodeid">3 <xsl:param name="nodeid" />4 <xsl:for -each select="//node">5 <xsl:if test="@*[name()='xmi:id ']=$nodeid">6 <xsl:value -of select="concat('n',position ())" />7 </xsl:if >8 </xsl:for -each >9 </xsl:template >
Mit Hilfe dieser kleinen Verbesserung ist es möglich, die Dateigröße der aus der
Konvertierung resultierenden UAD-Datei geringfügig zu senken. Da der Speicher
auf Sensorknoten im Allgemeinen knapp bemessen ist, und auch die Rechenzeit
4.1 Veränderung/Optimierung durch XML-Konverter 19
sehr beschränkt ist, ist diese Optimierung ein Schritt, wenn auch nur ein kleiner, zur
effizienteren Nutzung der Systemresourcen.
4.2 Regelbasierte Veränderungen im Framework
Bevor die neuen Funktionen in das bestehende Framework eingebaut werden
können, mussten zuerst einige wichtige Anpassungen vorgenommen werden. So
ist zu beachten, dass die grundsätzlichen Regeln des objektorientierten Program-
mierens eingehalten wurden und werden, um Schwierigkeiten bei Erweiterungen
des Codes, wie sie im Zuge dieser Arbeit notwendig wurden, zu vermeiden. Da-
bei ist zu erwähnen, dass unbedingt abstrakte Klassen, welche im gesamten Pro-
grammablauf nicht instanziiert werden können, mit dem Schlüsselwort abstract
gekennzeichnet werden sollten. Konkret trifft das bei dem Framework auf die
Klassen Node, JoinableNode, ActionNode, ActivityParameterNode und
DecisionableNode zu. Diese Klassen wurden also korrekterweise als abstrakt
gekennzeichnet. Als Ergebnis wurde damit die Arbeit im folgenden Punkt sehr
erleichtert, da ansonsten für die Einführung des Besucher-Entwurfsmusters in Ab-
schnitt 4.2.1 eine Menge an Methoden eingeführt werden müsste, die niemals
aufgerufen werden würde, da diese (abstrakten) Klassen niemals in einem UAD
auftauchen, und somit auch niemals instanziiert werden würden.
4.2.1 Besucher-Entwurfsmuster
Für die Abarbeitung einzelner Schritte im Folgenden wird das Besucher-Entwurfs-
muster [14] für alle Klassen, die ein UAD beschreiben, eingeführt. Zu diesem Zweck
wurde die Schnittstelle VisitInterface aus Listing 4.4 angelegt, welches für alle
Klassen eines UADs eine Implementierung der Methode
accept(AbstractVisitor v) fordert.
Listing 4.4: VisitInterface.java
1 public interface VisitInterface {2 public abstract void accept(AbstractVisitor v);3 }
Die Implementierung der Methode in den einzelnen Klassen ist immer gleich:
Es wird die visit-Methode des im Parameter v übergebenen Objekts aufgerufen.
Diese Methoden unterscheiden sich innerhalb des AbstractVisitor durch die
4.2 Regelbasierte Veränderungen im Framework 20
Signatur. Abhängig von dem aufrufenden Objekt wird die passende visit-Methode
gewählt und ausgeführt.
Der auf den ersten Blick einfachere Weg wäre, jedem zu verarbeitenden Objekt eines
UADs eine eigene Methode für jeden möglichen Verarbeitungsschritt hinzuzufügen.
Allerdings müssten zu diesem Zweck viele (unnötige) get- und set-Methoden im-
plementiert werden, um auf die lokalen Variablen der jeweiligen Objekte zugreifen
zu können. Außerdem ist die Funktionsweise im Endeffekt dezentral untergebracht,
welches sich negativ auf die Übersichtlichkeit und die Verständlichkeit des Codes
auswirkt, und damit die Fehleranfälligkeit erhöht.
Daher hat die Implementierung des Besucher-Entwurfmusters einen großen Vorteil
gegenüber anderen Lösungen: Jeder Schritt der Verarbeitung kann als eigene Kind-
klasse des AbstractVisitor implementiert werden. Es ergibt sich eine sinnvolle
Abgrenzung des Codes der einzelnen Schritte voneinander, und dieser ist zentral, in
seiner eigenen Klasse, untergebracht.
Dazu kommt, dass jede Besucherklasse ihre eigenen (privaten) Variablen führen
kann, die für den Schritt nötig sind, ohne dabei Zugriff an andere Teile des Pro-
gramms bieten zu müssen. Die Daten werden zentral in dem Objekt des Besuchers
abgelegt und nicht verstreut in den einzelnen Klassen des UADs.
4.2.2 Regelsprache
Zur Beschreibung von Veränderungen eines UAD wird eine Regelsprache mit gewis-
sen Anforderungen entwickelt:
• kompakt, um so wenig (unnötigen) Speicherplatz zu belegen wie möglich
• verständlich, um Veränderungen in der Regelsprache einfach ausdrücken zu
können
• logisch, sinnvolle Aufteilung der Bereiche einer Regelsprache
Zur Auswahl steht ein XML-basiertes und ein eigenes Format:
Die Vorteile des XML-basierten Formats unterliegen jedoch den Nachteilen: So ist
zwar ein Standard durch die Wahl des Formats, und damit eine bessere Kompatibili-
tät durch Editoren, Konverter und andere (Hilfs-)Programme, gegeben. jedoch hat
XML den gewaltigen Nachteil einen sehr großen Overhead zu haben. Für die An-
wendung in einem Sensorknoten mit geringen Systemresourcen ist dies ungeeignet,
4.2 Regelbasierte Veränderungen im Framework 21
Tabelle 4.1: Auswahlgründe für die Regelsprache
XML Eigene Sprache
Pro
• standardisiert
• Parser bereits vorhan-den
• kompakt (minima-ler Overhead)
• Syntax aus der natür-lichen Sprache abge-leitet
Contra
• Overhead
• Syntax sehr umständ-lich
• kein Parser vorhan-den
und fällt im Anforderungspunkt „kompakt“ durch.
Die Wahl fällt also auf eine eigene Regelsprache. Diese wird so entworfen, dass
sie alle Anforderungen erfüllt. Dafür muss allerdings ein eigener Parser entwickelt
werden. Das ist mit Hilfe eines Parsergenerators kein größeres Problem. Mehr dazu
in den folgenden Abschnitten.
Als Grundlage ist die textbasierte Regelsprache eine leichte Anlehnung an die
Update-Klausel von SQL [15], eine bewährte, standardisierte Sprache zur Abfrage
und Modifikation von Daten in einer Datenbank. Sie ist mengenbasiert und besteht
aus zwei Bereichen: Der Auswahl einer Menge von Knoten und/oder Kanten, und
der Modifikation der ausgewählten Menge. Diese logisch sinnvolle Teilung wird hier
übernommen.
Dadurch, dass es sich weitestgehend um Befehle des englischen Wortschatzes han-
delt, kann man mit Hilfe der natürlichen Sprache intuitiv einfache Regeln der
Regelsprache verstehen und auch schreiben. Der Overhead ist im Gegensatz zu
einem XML-basierten Format deutlich geringer, da sehr wenige überflüssige Zeichen,
also Zeichen, die nicht zwingend zur Erhaltung der Semantik der Regel notwendig
sind, vorhanden sind.
Eine Zusammenfassung ist in Tabelle 4.1 zu finden.
4.2 Regelbasierte Veränderungen im Framework 22
4.2.2.1 Auswahl
Der erste Teil einer Regel ist die Beschreibung einer Menge an Knoten und Kanten
des UAD, die im Anschluss vom zweiten Teil, modifiziert werden sollen. Hierbei
sind vielerlei Arten der Auswahl von Kanten und Knoten möglich. Daher zuerst eine
kurze Übersicht, wie sich die Auswahlregeln beschreiben lassen:
Syntax:
find
[edge edge_selection of] node node_selection | *
[contains variable variable_selection ]
[and ...]
Das Schlüsselwort find leitet die Auswahl der Knoten und Kanten innerhalb der
Regel ein. Daher muss eine Regel immer mit find beginnen.
Der Teil [edge edge_selection of] ist nur nötig, sofern angrenzende Kanten, an die
im Folgenden ausgewählten Knoten, selektiert werden sollen. Die Ergebnismenge
enthält dann jedoch ausschließlich Kanten, nicht mehr die im Folgenden gewählten
Knoten.
edge_selection ist eine durch Komma getrennte Liste an Eigenschaften, von denen
mindestens eine auf die auszuwählenden Kanten zutreffen muss. Dabei wird der
Kantentyp aus Sicht des gewählten Knotens mit Hilfe der Schlüsselworte in (einge-
hende Kante), out (ausgehende Kante) oder * (alle Kanten) bestimmt. Gezieltere
Auswahl kann durch Angabe von Eigenschaften getroffen werden. Diese werden in
einer mit eckigen Klammern umschlossenen, von Komma getrennten Liste hinter
dem Kantentyp festgelegt. (Beispiel: in[guard="<20"] Es werden alle eingehen-
den Kanten ausgewählt, welche die Eigenschaft guard="<20" besitzen.) Eine Liste
an möglichen Eigenschaften ist in Tabelle 4.2 zu finden.
node_selection setzt sich so ähnlich zusammen wie die Auswahl der Kanten. Hier
kann der Knotentyp anhand der internen Bezeichnung ausgewählt werden. Eigen-
schaften lassen sich ebenfalls, mit einer in eckigen Klammern angehängten, durch
Komma getrennten Liste, zum Auswählen festlegen. (Beispiel: ForkNode[@in="1"]
Es werden alle Knoten vom Typ ForkNode ausgewählt, welche genau eine Eingangs-
kante haben.) Eine Liste der internen Bezeichnungen der einzelnen Knotentypen,
sowie deren Eigenschaften sind in Tabelle 4.2 zu finden.
4.2 Regelbasierte Veränderungen im Framework 23
Eine Besonderheit bietet sich noch bei der Auswahl der Knoten: Es kann berück-
sichtigt werden, mit welchen Knoten der auszuwählende Knoten verbunden ist. So
kann man nur Knoten auswählen, die vor/nach/inmitten einer Reihung bestimmter
Knoten(typen) mit bestimmten Eigenschaften liegen. Dazu lässt sich eine ganze
Kette an Knotentypen, verbunden mit einem ->, festlegen, die dem auszuwählenden
Knoten vorausgehen und/oder folgen. Der auszuwählende Knoten ist dabei mit
einem @ zu kennzeichnen.
(Beispiel: ForkNode[@in="1"] -> @ActionNode -> JoinNode[@out="1"]
Es werden alle Knoten vom Typ ActionNode ausgewählt, die als Vorgänger einen
Knoten vom Typ ForkNode besitzen, welcher genau eine Eingangskante hat, und
einen Nachfolgeknoten vom Typ JoinNode, welcher genau eine Ausgangskante
besitzt.)
Mit Hilfe von [contains variable variable_selection ] lassen sich die bereits
ausgewählten Knoten und Kanten nach dem Vorkommen einer (oder mehrerer)
Variablen durchsuchen. Sofern mindestens eine Eigenschaft eines Knotens oder einer
Kante eine der in variable_selection festgelegten Variablen enthält, wird diese(r)
ausgewählt. Variablen werden mit einem führenden $ identifiziert. Sollen mehrere
Variablen in variable_selection aufgeführt werden, so müssen die Variablen mit Kom-
ma getrennt aufgelistet werden.
Das Ergebnis der Auswahl ist eine Menge an Knoten und/oder Kanten, die die
genannten Bedingungen erfüllen.
4.2.2.2 Modifikation
Der zweite Teil einer Regel ist mindestens eine Aktion, die auf die im ersten Teil
ausgewählte Menge angewendet wird um diese zu modifizieren.
Syntax:
action
set property property_assignment
| replace variable variable_assignment
Das Schlüsselwort action leitet eine Modifikation aller im vorherigen Teil aus-
gewählter Knoten und Kanten innerhalb der Regel ein. Es können auch mehrere
Modifikationen auf dieselbe Auswahlmenge angewendet werden, dafür wird der
4.2 Regelbasierte Veränderungen im Framework 24
Tabelle 4.2: Eigenschaften von Knoten und Kanten in einem UAD
Eigenschaft Beschreibung
Startknoten (InitialNode)
id Eindeutige (interne) ID-Nummer@out Anzahl der ausgehenden Kanten
Endknoten (FinalNode)Ablaufende (FlowFinalNode)
id Eindeutige (interne) ID-Nummer@in Anzahl der eingehenden Kanten
Aktion (elementar) (RootActionNode)Aktion (UML-Aktivität) (UMLActionNode)
id Eindeutige (interne) ID-Nummername Name der aufzurufenden Aktionallocated Zuweisung der Aktion an einen anderen Sensor-
knoten@in Anzahl der eingehenden Kanten@out Anzahl der ausgehenden Kanten
Entscheidung (DecisionNode)
id Eindeutige (interne) ID-Nummer@else 0 = keine Else-Kante, 1 = Else-Kante vorhanden@in Anzahl der eingehenden Kanten@out Anzahl der ausgehenden Kanten
Zusammenführung (MergeNode)Teilung (ForkNode)
Synchronisation (JoinNode)
id Eindeutige (interne) ID-Nummer@in Anzahl der eingehenden Kanten@out Anzahl der ausgehenden Kanten
Parametereingang (ActivityParameterInNode)Parameterausgang (ActivityParameterOutNode)
id Eindeutige (interne) ID-Nummername Name des Parameters@out Anzahl der ausgehenden Kanten
Kontrollfluss/Objektfluss
type ControlFlow für Kontrollfluss, ObjectFlowfür Objektfluss
from ID-Nummer des Quellknotensto ID-Nummer des Zielknotensguard Bedingung bei einer Entscheidunginputname Name des Objekts am Quellknoten (nur Objekt-
fluss!)outputname Name des Objekts am Zielknoten (nur Objekt-
fluss!)
4.2 Regelbasierte Veränderungen im Framework 25
abgeschlossenen action-Anweisung eine weitere action-Anweisung angehängt.
Nach dem Schlüsselwort action muss die Art der Modifikation festgelegt werden.
Derzeit sind lediglich zwei Arten der Modifikation implementiert. Weitere Arten
können aber nachträglich durch Erweiterung der Grammatik um entsprechende
Schlüsselworte, sowie Einführung der dazugehörigen Abstract Syntax Tree (AST)-
Klassen, hinzugefügt werden.
Die Aktion set property weist den Knoten und Kanten der Auswahlmenge eine
Eigenschaft zu. Welche(r) Knoten/Kante welche Eigenschaften besitzt und welche
verändert werden können, ist in Tabelle 4.2 abzulesen. Wichtig: Alle Eigenschaften
mit einem führenden @ sind abgeleitete Eigenschaften. Diese ergeben sich aus den
Zuständen des Objekts und können logischerweise nicht verändert werden!
Mit replace variable lässt sich eine Variable durch einen vorgegebenen Wert
ersetzen. Dabei können sowohl Bedingungen hinter Entscheidungsknoten verändert
werden, als auch der Name einer Aktivität oder sogar Parameternamen. replace
variable durchsucht alle Eigenschaften eines Knotens/einer Kante und ersetzt
dort auftretende Variablen durch den zugeordneten Wert.
4.2.3 Regelparser/-grammatik
Um Veränderungsregeln, die in der in Abschnitt 4.2.2 festgelegten Regelsprache
verfasst wurden, erfolgreich einlesen, zerteilen und sinngemäß interpretieren zu
können, ist eine zur Regelsprache passende Grammatik und der dazugehörige Parser
notwendig. Mit Hilfe eines Parsergenerators kann der Parser aus einer entsprechend
beschriebenen Grammatik erstellt werden. Da es sich bei dem Sourcecode des Frame-
works um Java-Code handelt, wurde ein Parsergenerator aus der Java-Community
gewählt, dessen generierter Code zur Laufzeit ohne weitere Bibliotheken auskommt.
Die Wahl fiel auf JavaCC [16], obwohl einige kleinere Änderungen am Sourcecode
nötig waren, um die Kompatibilität mit der auf den Sun SPOTs laufenden Java-
Version zu gewährleisten. Folgende Änderungen mussten an JavaCC durchgeführt
werden:
• Die JavaVM der Sun SPOTs bietet keine Methode System.getProperty()
mit der Signatur String, String. Stattdessen wird nur die Methode mit der
Signatur String angeboten. Da der zweite String lediglich einen Standard-
wert festlegt, der zurückgegeben wird, sofern die angeforderte Eigenschaft
4.2 Regelbasierte Veränderungen im Framework 26
Parser(Java-Code)
JavaCC
Schritt 3:Erweiterung der
JavaCC-Grammatik um Javacode für AST
Schritt 2:Umsetzen der Regeln in eine
JavaCC-Grammatik
Schritt 1:Theoretischer
Entwurf(Backus-Naur-Form)
Framework
Abbildung 4.1: Die notwendigen Schritte zur Entwicklung eines Parsers mit Hilfe vonJavaCC. Der von JavaCC erstellte Parser ist direkt in die Erweiterung des Frameworkseingebettet.
nicht vorhanden ist, lässt sich das gleiche Verhalten durch eine zusätzliche
if-Abfrage ersetzen.
• Die Schnittstelle java.io.Serializable befindet sich nicht in der Klas-
senbibliothek der JavaVM auf den Sun SPOTs. Die Implementierung dieser
Schnittstelle in der erzeugten Klasse Token kann hier jedoch ohne Probleme
entfernt werden.
• Als interne Liste wird die Klasse ArrayList verwendet. Diese Klasse ist
ebenfalls nicht in der Klassenbibliothek zu finden. Der Sourcecode wurde
hier so verändert, dass stattdessen die Klasse Vector verwendet wird. Hier-
bei waren einige weitere Änderungen nötig, da die Klasse Vector andere
Methodennamen verwendet, als die Klasse ArrayList. Beispielsweise die
Methode clear() zum Leeren der ArrayList, entspricht der Methode
removeAllElements() bei der Klasse Vector.
Der erste Schritt zum Parser nach Abbildung 4.1 ist die vollständige Spezifizie-
rung einer Grammatik, die die Regelsprache beschreibt. Konkret ergibt sich aus den
in Abschnitt 4.2.2 festgelegten Eigenschaften der Regelsprache folgende Grammatik
in einer (modifizierten) Backus-Naur-Form (Schritt 1):
rule -> find ( action )+ ";"
find -> "find" find_chainfind_chain -> find_expression ( "and" find_chain )?find_expression -> ( "*" | edge_selection? node_selection ) variable_selection?edge_selection -> "edge" edge_filter "of"edge_filter -> ( "*" | "in" | "out" ) select_properties?select_properties -> "[" select_property ( "," select_property )* "]"select_property -> PROPERTY "=" STRINGnode_selection -> "node" ( node_filter_chain1 | node_filter )node_filter_chain1 -> node_filter "->" node_filter_chain1 | node_filter_chain2node_filter_chain2 -> "@" node_filter node_filter_chain3?node_filter_chain3 -> "->" node_filter node_filter_chain3?node_filter -> ( "*" | NODE_NAME ) select_properties?
4.2 Regelbasierte Veränderungen im Framework 27
variable_selection -> "contains" "variable" variable_filter_listvariable_filter_list -> VARIABLE ( "," variable_filter_list )?
action -> "action" ( action_set_property | action_replace_variable )action_set_property -> "set" "property" property_assignmentaction_replace_variable -> "replace" "variable" variable_assignmentproperty_assignment -> PROPERTY "=" STRINGvariable_assignment -> VARIABLE "=" STRING
Es handelt sich dabei erstmal um den theoretischen Entwurf dieser Grammatik. Für
die weitere Verwendung muss diese in eine andere Form gebracht werden.
Alle Werte in Anführungszeichen, sowie groß geschriebene Platzhalter, sind Termi-
nalsymbole. Alle klein geschriebenen Platzhalter sind Nichtterminale, welche mit
Hilfe von weiteren Regeln zu Terminalen aufgelöst werden können. Als Startsymbol
der Grammatik gilt das Nichtterminal rule.
Zur Beschreibung von Wiederholungen, Alternativen oder optionalen Ausdrücken,
werden, wie in der Theoretischen Informatik üblich, reguläre Ausdrücke [7] ver-
wendet. So werden mit | Alternativen abgegrenzt und die folgenden Quantoren
hinter einem Ausdruck verwendet, um mit * keine oder beliebig viele, mit + min-
destens eine, und mit ? eine oder keine, die Anzahl der möglichen Reihungen des
vorausgehenden Ausdrucks festzulegen.
Diese Produktionen der festgelegten Grammatik aus dem theoretischen Ansatz
lassen sich nun entsprechend des zweiten Schritts aus Abbildung 4.1, in einer Java-
ähnlichen Syntax von JavaCC schreiben, damit JavaCC daraus einen entsprechen-
den Parser erstellen kann. Aus der Produktion find_expression -> ( �*�|
edge_selection? node_selection ) variable_selection? wird
beispielsweise in der Syntax von JavaCC:
Listing 4.5: Schritt 2 nach Abbildung 4.1: Grammatik in JavaCC-Syntax
1 void findExpression () :2 {3 }4 {5 (6 <C_WILDCARD >7 |8 (9 edgeSelection ()
10 )?11 nodeSelection ()12 )13 (14 variableSelection ()15 )?16 }
4.2 Regelbasierte Veränderungen im Framework 28
Terminale werden vorher explizit als TOKEN definiert und können mit der Verwen-
dung des festgelegten Namens in spitzen Klammern eingesetzt werden. So wird in
diesem Beispiel vorher das Terminal „*“ als <C_WILDCARD> definiert und kann mit
eben diesem Ausdruck verwendet werden.
Jede Produktion wird außerdem zu einer eigenen Java-Methode. Die Syntax ähnelt
der Definition einer solchen. Jedes verwendete Nichtterminal wird zu einem Me-
thodenaufruf mit nachgestelltem (). Einzig die Zeichen der Regulären Ausdrücke
bleiben wie und wo sie sind.
Hier ist es auch möglich Java-Code bei dem Zutreffen einer Regel auszuführen.
Dieser wird wie ein Java-Block, mit geschweiften Klammern von dem Code der
Grammatik separiert, an die entsprechende Stelle geschrieben. Dies ist notwendig
(siehe Schritt 3 in Abbildung 4.1) um den im nächsten Abschnitt beschriebenen
Regelbaum aufbauen zu können. Außerdem ist es möglich einer Regel einen Rück-
gabewert zuzuweisen. Dieser kann mit einer direkten Variablenzuweisung bei der
Definition einer Regel aufgefangen und verwendet werden. Ein Beispiel hierzu ist
der endgültige, allerdings leicht vereinfachte Ausschnitt aus der Grammatik für die
Produktion find_expression:
Listing 4.6: Schritt 3 nach Abbildung 4.1: Grammatik in JavaCC-Syntax mit Java-Code zum Erstellen des AST
1 /* Rückgabewert vom Typ ASTAbstractFilterNode */2 ASTAbstractFilterNode findExpression () :3 {4 /* Variablendeklarationen in Java */5 ASTAbstractFilterNode filter;6 ASTAbstractChainedFilterNode edgeFilter;7 ASTAbstractChainedFilterNode varFilter;8 }9 {
10 (11 <C_WILDCARD >12 {13 /* etwas Java -Code */14 }15 |16 (17 /* Zuweisen des Rückgabewertes von edgeSelection */18 edgeFilter=edgeSelection ()19 )?20
21 /* Zuweisen des Rückgabewertes von nodeSelection */22 filter=nodeSelection ()23
24 {25 /* Java -Code zum Umsortieren der Kantenauswahl */26 if(edgeFilter != null) {27 /* weiterer Java -Code (siehe Beispiel) */
4.2 Regelbasierte Veränderungen im Framework 29
28 }29 }30 )31
32 (33 /* Zuweisen des Rückgabewertes v. variableSelection */34 varFilter=variableSelection ()35 {36 /* anderer Java -Code */37 }38 )?39
40 {41 /* Rückgabe des Wertes der Java -Variable filter */42 return filter;43 }44 }
4.2.4 Regelbaum
Die Grammatik und der mit Hilfe von JavaCC erzeugte Java-Code hat die Funktion
eine Eingabe entsprechend der Vorgabe der Grammatik zu zerteilen und einen AST
zu erzeugen. Intern erzeugt der Parser zuerst während des Parsens einen weiteren
Baum, wie in Abbildung 4.2 zu sehen (Dort wird die Eingabe find edge * of
node DecisionNode->@* action replace variable $var="wert"; ver-
arbeitet). Aus diesem internen Strukturbaum wird, mit Hilfe der eigenen Codestücke
innerhalb der JavaCC-Grammatik, der AST erzeugt. Der AST ist ein abstrakter Teil-
baum des internen Strukturbaums des Parsers, und ist damit eine objektorientierte
Repräsentation der Eingabe in Baumform. Es werden dort alle Schlüsselwörter,
welche zur Erhaltung der Bedeutung der Eingabe erforderlich sind, durch Objekte
repräsentiert und entsprechend miteinander verknüpft. Mit jeder Transformation in
die nächste Abstraktionsebene (Eingabe -> interner Strukturbaum -> AST) bleibt
die Bedeutung erhalten, jedoch wird dieser intern anders und größtenteils kompak-
ter repräsentiert.
Bei der Transformation vom internen Strukturbaum (Abbildung 4.2) zum AST (Ab-
bildung 4.3) ist es teilweise nötig die Reihenfolge einzelner Knoten zu vertauschen.
Dies ist deswegen erforderlich, weil die Grammatik zugunsten der Verständlichkeit
der Filterregeln, einen etwas anderen Aufbau des entstehenden internen Struktur-
baums hat als der AST. Mit Hilfe des Java-Codes innerhalb der Grammatik ist diese
Umsortierung möglich. Ein Beispiel hierfür ist der Java-Code aus Listing 4.6 zum
Umsortieren einer Kantenauswahl:
4.2 Regelbasierte Veränderungen im Framework 30
Listing 4.7: Beispiel: Java-Code zum Umsortieren einer Kantenauswahl (ein Aus-schnitt aus Listing 4.6)
1 /* Java -Code zum Umsortieren der Kantenauswahl */2 if(edgeFilter != null) {3 /* sofern eine Kantenauswahl vorhanden */4 ASTAbstractChainedFilterNode filter2;5 if(edgeFilter instanceof ASTFilterPropertiesNode) {6 filter2 = (ASTAbstractChainedFilterNode)edgeFilter.↘
→getChildFilterNode ();7 } else {8 filter2 = edgeFilter;9 }
10
11 /* umsortieren */12 filter2.setChildFilterNode(filter);13 filter = edgeFilter;14 }
Das Ergebnis ist, dass der linke Ast von find_expression in Abbildung 4.2 vor
den rechten Ast gezogen wird, und im AST in Abbildung 4.3 genau so zu finden ist.
Eine Übersicht aller Klassen, welche in einem AST verwendet werden können,
und deren Beziehungen zueinander, ist in Abbildung 4.4 zu sehen.
AbstractVisitor Alle Klassen des AST implementieren die Schnittstelle
AbstractVisitor, welche in Abschnitt 4.2.1 eingeführt wurde. Dies ist essenziell,
da jeder Knoten des AST zum Anwenden der einzelnen Regeln auf diese Weise
besucht wird, und somit seinen Teil der Funktionalität an der gesamten Regel
anwenden kann.
ASTRuleSet Eine Eingabe kann aus mehr als einer Regel bestehen. Die Klasse
ASTRuleSet sammelt eine Menge an Regeln, welche durch Objektinstanzen der
Klasse ASTRule repräsentiert werden, und führt diese sequenziell aus.
Von der Klasse ASTRuleSet ist stets nur eine Objektinstanz vorhanden. Sie ist die
Wurzel des AST und wird von der Regel ruleset der Grammatik zurückgegeben,
welche auch gleichzeitig das Startsymbol der Grammatik ist.
ASTRule Jede Regel wird durch ein eigenes Objekt der Klasse ASTRule repräsen-
tiert und wird von der Regel rule der Grammatik zurückgegeben.
ASTAbstractActionNode Kindklassen der abstrakten Klasse
ASTAbstractActionNode sind für die Aktionen zuständig, die eine Filterregel auf
4.2 Regelbasierte Veränderungen im Framework 31
KW_F
IND
findKW_E
DGE
edgeC_W
ILDCARD
*KW_O
Fof
KW_N
ODE
nodeS_D
ESCRIPTOR
DecisionN
odeC_S
INGLE
_ARROW
->C_M
ARKER
@C_W
ILDCARD
*KW_A
CTION
actionKW_R
EPLA
CE
replaceKW_V
ARIABLE
variableS_V
ARIABLE
$varC_E
QUAL
=C_S
EMICOLO
N;
node_filter
node_filter_chain2
node_filternode_filter_chain1
node_filter_chain1edge_filter
node_selectionedge_selection
find_expressionvariable_assignm
ent
S_S
TRING
"Wert"
action_replace_variablefind_chain
findaction
rule
Abbildung 4.2: Ein Beispiel für einen internen Strukturbaum des Parsers. Blau sindalle Nichtterminale, rule ist das Startsymbol, Grau sind alle Terminalen und Schwarzam unteren Rand die dazugehörige Eingabe.
4.2 Regelbasierte Veränderungen im Framework 32
ASTRule
ASTFilterEdgesOfNodeNode
ASTFilterNodeSelectorNodeASTFilterNodeSelectorNode
ASTFilterBaseNode
ASTActionReplaceVariable
1
2
3
5
9
6
7
4
810
Abbildung 4.3: Der AST zum Strukturbaum von Abbildung 4.2 mit der Aufrufrei-henfolge der einzelnen Knoten. Der farblich markierte Teil ist in Abbildung 4.6 imDetail dargestellt.
die Menge an Knoten und Kanten, welche von der Regel nach Abschnitt 4.2.2.1 aus-
gewählt wurden, anwendet. Dabei gibt es, wie in Abschnitt 4.2.2.2 aufgeführt, die
Aktion set property, welche durch die Klasse ASTActionSetProperty implemen-
tiert, sowie die Aktion replace variable, welche durch die Klasse
ASTActionReplaceVariable implementiert wird.
ASTAbstractFilterNode Kindklassen sind für die, wie in Abschnitt 4.2.2.1 erwähn-
te, Auswahl an Knoten und Kanten zuständig. Es besteht dabei die Möglichkeit,
nachdem alle Objekte einer Aktivität besucht wurden, eine Ergebnismenge der auf
die Auswahlkriterien zutreffenden Knoten und Kanten in Form einer Enumeration
zu erhalten.
ASTFilterBaseNode Dies ist die einzige direkte Kindklasse des
ASTAbstractFilterNode. Sie ist immer ein Blatt eines AST und liefert die Grund-
menge an Knoten und Kanten, welche durch die Angabe des Schlüsselwortes node
(nur Knoten) oder der Wildcard * (sowohl Knoten als auch Kanten) bestimmt wird.
ASTAbstractChainedFilterNode Abgeleitet von der ASTAbstractFilterNode
ist diese abstrakte Klasse eine Erweiterung, um innere Knoten in einem AST beschrei-
4.2 Regelbasierte Veränderungen im Framework 33
+visit()
«interface»AbstractV
isitor
ASTAbstractA
ctionNode
+evaluate()
+addR
esult()+clearR
esult()+em
ptyResult()
ASTAbstractF
ilterNode
+getC
hildFilterN
ode()+setC
hildFilterN
ode()+evaluate()
ASTAbstractC
hainedFilterN
ode
+visit()
+addA
ssignment()
ASTActio
nReplaceV
ariab
le
+visit()
+addP
roperty()
ASTActio
nSetP
roperty
+visit()
ASTFilterB
aseNode
+visit()
+evaluate()
ASTFilterM
ergeNode
+visit()
+addV
ariable()
ASTFilterC
ontain
sVariab
leNode
+visit()
ASTFilterE
dgesO
fNodeNode
+visit()
+setN
odeType()
+setLeftF
ilterNode()
+setR
ightFilterN
ode()+evaluate()
ASTFilterN
odeSelecto
rNode
+visit()
+addP
roperty()
ASTFilterP
ropertiesN
ode
+visit()
+evaluate()
+addA
ction()
ASTRule
+visit()
+addR
ule()
ASTRuleSet
Abbildung 4.4: Verwendete Klassen zur Repräsentation eines AST und deren Bezie-hungen
4.2 Regelbasierte Veränderungen im Framework 34
ben zu können. Sie besitzt zu diesem Zweck Methoden, um den untergeordneten
Teilbaum des AST festlegen oder auslesen zu können. Alle folgenden Filterklassen
sind Kindklassen dieser abstrakten Klasse.
ASTFilterMergeNode Das Schlüsselwort and verknüpft die Ergebnismengen zwei-
er Auswahlregeln. Es werden jeweils beide Teilbäume des AST, und somit bei-
de Auswahlregeln, ausgewertet und die Vereinigungsmenge gebildet. Duplikate
sind damit ausgeschlossen. Ein Teilbaum kann allerdings auch mit einem weiteren
ASTFilterMergeNode beginnen, was der Fall ist bei mehr als einer Verwendung
von and.
ASTFilterContainsVariableNode Die Schlüsselwörter contains variable, gefolgt
von einer Liste von Variablen, können die Menge an Knoten und/oder Kanten
dezimieren. Jedes Element der Menge wird nach dem Vorkommen mindestens
einer der angegebenen Variablen untersucht. Es werden nur die Elemente in die
Ergebnismenge übernommen, die diese Variable(n) enthalten.
ASTFilterEdgesOfNodeNode Die Schlüsselwörter edge ... of beschreiben eine
Transformation der Menge an Knoten in eine Ergebnismenge an Kanten. Mit Hilfe
der Schlüsselwörter in, out oder der Wildcard *, bei der hier mit ... abgekürzten
Kantenauswahl, wird festgelegt, welche Kanten der Knoten in die Ergebnismenge
übernommen werden. Auch hier wird wieder die Vereinigungsmenge aller nach den
Kantenauswahlregeln selektierten Kanten gebildet, damit es zu keiner Duplikatbil-
dung kommt.
ASTFilterPropertiesNode Diese Klasse ist für die Prüfung und Filterung der Eigen-
schaften bei der Knoten- und/oder Kantenauswahl zuständig. Eingeleitet durch die
Schlüsselzeichen [...] werden alle Vergleichsbedingungen als kommagetrennte Liste
innerhalb der eckigen Klammern aufgelistet. Es werden nur Knoten und Kanten in
die Ergebnismenge übernommen, für die alle aufgelisteten Eigenschaften existieren
und die festgelegten Bedingungen erfüllt sind.
ASTFilterNodeSelectorNode Die Regeln sehen vor, Knoten auch durch ganze Ket-
ten an Knoten spezifizieren und selektieren zu können. Dies bedarf bei dieser Klasse
4.2 Regelbasierte Veränderungen im Framework 35
ModifikationSelektion Menge anKnoten & Kanten
Abbildung 4.5: Aufteilung eines AST und Mengenbewegung
zusätzlicher Arbeit. Zentraler Ausgangspunkt ist der letztendlich auszuwählende
Knoten. Markiert wird dieser in einer Auswahlregel mit dem @, sofern die Regel
eine Auswahlkette verwendet. Die Klasse besitzt zu diesem Zweck zwei Referenzen
auf Teilbäume, die die Auswahlkette jeweils „vor“ und „nach“ dem aktuellen Knoten
repräsentieren.
Für jeden Knoten wird hier zuerst eine Menge aller Vorgänger erstellt, diese an
den „linken“ Nachbarn in der Auswahlkette übergeben und das Ergebnis betrach-
tet. Sofern es einen „linken“ Nachbarn gibt und die Ergebnismenge nicht leer ist,
oder kein „linker“ Nachbar existiert, wird der gleiche Vorgang mit dem „rechten“
Nachbarn und allen Nachfolgern des aktuellen Knotens durchgeführt. Ist auch diese
Ergebnismenge nicht leer, oder existiert kein „rechter“ Nachbar, so wird der Knoten
in die Ergebnismenge übernommen.
4.2.5 Ablauf
Nachdem der Parser seine Arbeit beendet hat bleibt der in Abschnitt 4.2.4 beschrie-
bene AST übrig, welcher die eigentliche Aufgabe zur Veränderung eines UADs nach
den in der Eingabe vorgegebenen Regeln ausführt. Dieser ist, wie in Abbildung 4.5
zu sehen, in zwei Teile aufgeteilt: Die Selektion und die Modifikation. Bei beiden
Teilen handelt es sich um einen Teilbaum, genauer gesagt um (mindestens) einen
vollständigen Ast des AST.
Selektion Die Selektion ist genau ein vollständiger Ast des AST. Es gibt pro Regel
genau eine Menge an Knoten und Kanten die ausgewählt werden kann. Diese Menge
wird in dem Ast des AST, der für die Auswahl zuständig ist, bestimmt. Dazu wird der
erste Teil der Regel aus Abschnitt 4.2.2.1 verwendet, welcher mit dem Schlüsselwort
find eingeleitet wird. Dieser beschreibt genau welche Knoten und Kanten in die
4.2 Regelbasierte Veränderungen im Framework 36
Auswahlmenge fließen und wird durch den Teilbaum im AST repräsentiert. Es findet
also auch intern, in der abstrakten Form, genau die gleiche Abgrenzung zwischen
Selektion und Modifikation statt, wie bei der Regelsprache selbst.
In Abbildung 4.6 ist in einer schematischen Darstellung dargestellt, wie die
Auswahl der Menge an Knoten und Kanten mit Hilfe des AST erstellt wird. Jeder
Knoten des AST besitzt eine Ergebnismenge, welche im Zuge der Auswertung gefüllt
wird, und hat zudem Zugriff auf die Ergebnismenge aller direkten Kindknoten,
sofern es sich bei dem Knoten nicht um einen Blattknoten handelt.
Der AST ist so aufgebaut, dass die Auswertung Top-down nach dem Prinzip der
Tiefensuche erfolgen muss, damit die einzelnen Knoten in der korrekten Reihenfolge
durchlaufen werden und sich die endgültige Ergebnismenge am Wurzelknoten
des AST befindet. Um diese zu erstellen wird rekursiv vom Wurzelknoten aus die
Befüllung der Ergebnismenge des Kindknotens angefordert. Dies geschieht, wie in
Abbildung 4.6 dargestellt, über die Methode evaluate() und wird, um auch eine
Eingangsmenge zum Verarbeiten vorzufinden, durch einen rekursiven Aufruf bis zu
den Blattknoten durchgeführt. Ist die Ausführung der Methode beendet, so steht
dem Vorgängerknoten die Ergebnismenge bereit, und dieser kann alle Elemente,
die sich in der Ergebnismenge befinden, über die Methode accept()/visit()
besuchen, und damit der Regel entsprechend die eigene Ergebnismenge befüllen.
Nachdem der gesamte Ast der Selektion besucht und verarbeitet wurde, kann der
Wurzelknoten die Menge an Knoten und Kanten aus der Ergebnismenge des ersten
Knotens extrahieren und bei Bedarf an die Äste für die Modifikation weitergeben.
Modifikation Alle weiteren Äste des AST sind Äste, die zur Modifikation der aus
der Selektion erhaltenen Menge dient. Jeder AST besitzt mindestens einen Modifi-
kationsast. Wie bei der Selektion wird die Modifikation bei einer Regel ebenfalls mit
einem Schlüsselwort eingeleitet. Dies ist action und kann in einer Regel mehrfach
verwendet werden. Dadurch werden, abhängig von der Anzahl der verwendeten
action-Schlüsselwörter, mehrere Äste im AST zur Modifikation erzeugt und diese
werden nacheinander, in der bei der Regel verwendeten Reihenfolge, auf die Ergeb-
nismenge der Selektion durchlaufen.
Ein Modifikationsast im AST besteht (derzeit) nur aus einem einzigen Blattknoten.
Dieser implementiert, wie in der Klassenübersicht in Abbildung 4.4 dargestellt,
4.2 Regelbasierte Veränderungen im Framework 37
ASTKnoten
ASTKnoten(Blatt)
visit()
visit()
evaluate()
evaluate()
Ergebnismenge
Ergebnismenge
Abbildung 4.6: Ablauf der Selektion in einem AST, der rot markierte Ausschnitt ausAbbildung 4.3. Der Aufruf erfolgt rekursiv bis zum Blattknoten des AST, welcherdas Rekursionsende ist.
4.2 Regelbasierte Veränderungen im Framework 38
Filterregel
Parser
ASTUADvorher
UADnachher
ActivityManager
Abbildung 4.7: Überblick des Ablaufs bei der Anwendung einer Filterregel auf einUAD.
die Methoden der Schnittstelle AbstractVisitor. Die Elemente der übergebe-
nen Menge werden dort nacheinander von dem entsprechenden Knoten über die
visit()-Methode besucht und modifiziert.
4.2.6 Schnittstelle
Eine konkrete Anwendung der neuen Erweiterung des Frameworks wurde für diese
Arbeit nicht definiert, daher ist eine offene Schnittstelle implementiert, um auf
die Erweiterung zur Veränderung von UADs an nahezu jeder Stelle des Frame-
works zugreifen zu können. Die Schnittstelle ist in Form einer eigenen Klasse
namens ActivityManager im Paket de.fau.i7.acoowee.core.uml.rules
ausgeführt.
Eine Instanz von ActivityManager kann mit einem bereits geparsten UAD,
durch Übergabe eines Activity-Objekts, oder aber durch ein noch zu parsendes
UAD, durch Übergabe eines Reader-Objekts, welches eine UAD-Datei liefert, erzeugt
werden. Im letzteren Fall wird dieses zuerst geparst und das daraus resultierende
Activity-Objekt intern abgelegt. Nun bietet der ActivityManager diverse Me-
thoden an, um dieses intern referenzierte Activitiy-Objekt zu modfizieren oder
darauf zuzugreifen:
4.2 Regelbasierte Veränderungen im Framework 39
• public ActivityManager(Reader r)
Konstruktor: Erzeugt ein Activity-Objekt aus einer UAD-Datei und legt die
Referenz auf dieses intern ab. (Parsen der UAD-Datei)
• public ActivityManager(Activity activity)
Konstruktor: Legt die Referenz auf das Activity-Objekt intern ab.
• public Activity getActivity()
Erhalten der in diesem ActivityManager abgelegten Referenz auf das
Activity-Objekt.
• public void exportActivity(Writer w)
Zurückschreiben des Speicherabbildes eines UADs in eine UAD-Datei. (Die
Funktionsweise wird in Abschnitt 4.3 erklärt)
• public void renameActivity(String name)
Umbenennen eines UADs, und somit auch umbenennen des Activity-Objekts.
• public void modifyActivity(String s)
Veränderung eines UADs mit Hilfe der in dem String s aufgelisteten Regeln.
• public void modifyActivity(Reader r)
Veränderung eines UADs mit Hilfe der, in der zu Reader r gehörenden Datei,
aufgelisteten Regeln.
• public ActivityManager cloneActivity()
Eine Kopie der aktuellen Instanz von ActivityManager erzeugen mit allen
seinen Inhalten.
• public ActivityManager cloneActivity(String name)
Eine Kopie der aktuellen Instanz von ActivityManager erzeugen mit allen
seinen Inhalten, und anschließend den Namen name zuweisen.
Die Möglichkeit ein UAD zu verändern ist also mit Hilfe der Schnittstelle auf die
einfachste Weise reduziert worden und hat gleichzeitig den Vorteil eine Application
Programming Interface (API) nach „außen“ hin anzubieten, die immer die gleiche
Zugriffsmöglichkeit bietet, auch wenn sich intern die Programmteile der neuen
Erweiterung verändern. Eine Übersicht zum internen Ablauf ist in Abbildung 4.7
zu finden: Der ActivityManager bekommt ein UAD, und Filterregeln, welche auf
4.2 Regelbasierte Veränderungen im Framework 40
das UAD angewendet werden sollen, übergeben. Intern kümmert sich dieser darum,
dass die Filterregeln geparst und auf das UAD angewendet werden. Anschließend
kann das veränderte UAD ausgegeben werden.
4.3 Veränderung/Optimierung durch Besucher
Eine weitere Möglichkeit der Optimierung eines UADs ist das Entfernen von un-
nötigen bzw. unerreichbaren Abschnitten innerhalb des Diagramms. So können
sich zum Beispiel Knoten und Kanten in einer Aktivität befinden, die jedoch keine
Verbindung zu einem Startknoten besitzen. Diese Knoten und Kanten können nie-
mals vom Interpreter erreicht werden. Es ist daher auch vollkommen unnötig diese
Knoten und Kanten in der entsprechenden UAD-Datei aufzubewahren. Dieser Fall
tritt derzeit jedoch nur durch Unaufmerksamkeit des Erstellers des UADs auf. In
einer Weiterentwicklung des Filter-Frameworks ist auch eine Aktion geplant, die
semantische Veränderungen an einem UAD durchführen kann: Also Knoten oder
Kanten ersetzen oder löschen. Dies kann auch zu dem genannten Effekt führen.
Zu diesem Zweck wurde ein weiterer Besucher, der UADExportVisitor, geschaf-
fen, der eine (veränderte) Aktivität wieder in XML-Form ausgeben kann. Um dabei
auch wirklich nur die Knoten und Kanten zu verarbeiten und auszugeben, die durch
den Interpreter erreichbar sind, verhält sich der Benutzer genau wie der Interpreter:
Er läuft von allen Startknoten aus alle möglichen Verbindungen ab und sammelt
dabei eine Liste an Knoten und Kanten, die er auf dem Weg erreichen konnte. Diese
Liste an Knoten und Kanten wird letztendlich ausgegeben. Damit werden keine
Knoten und Kanten mehr in der UAD-Datei abgelegt, die nicht vom Interpreter er-
reichbar sind. Es verkleinert sich die UAD-Datei also, sofern das UAD unerreichbare
Teile enthielt, auf die tatsächlich notwendige Größe.
Kapitel 5
Beispiele & Anwendungen
5.1 Beispiele
Beispiel 1: Einfaches Auswählen und Ersetzen von Aktivitätsnamen
In dem in Abbildung 5.1 abgebildeten Beispiel, welches auf dem vom Lehrstuhl
üblicherweise verwendeten UAD NetTemp [17] basiert, soll der Name aller Aufrufe
der Aktivität SpotTemp in NeuTemp geändert werden. Die betroffenen Elemente
sind in Abbildung 5.1 rot markiert.
Um das gewünschte Ziel zu erreichen ist folgende Regel erforderlich:
find node UMLActionNode[name=�SpotTemp�]
action set property name=�NeuTemp�;
Die Auswahl der nötigen Knoten erfolgt alleine durch die Spezifikation des Kno-
tentyps (UMLActionNode) und dessen Eigenschaften ([name=�SpotTemp�]).
Die selektierten Knoten werden daraufhin mit Hilfe des Befehls set property
name=�NeuTemp� wie gewünscht modifiziert.
Beispiel 2: Suchen und Ersetzen von Variablen
In Abbildung 5.2 dargestellt, wurden diesmal zwei Variablen in dem UAD eingesetzt,
$actname und $temp, welche zur Laufzeit durch einen Aktivitätsnamen und eine
Entscheidungstemperatur ersetzt werden sollen.
Um das gewünschte Ziel zu erreichen ist folgende Regel notwendig:
find * contains variable $actname, $temp
action replace variable $actname=�SpotTemp�
41
5.1 Beispiele 42
find node UMLActionNode[name="SpotTemp"]action set property name="NeuTemp";
Abbildung 5.1: Beispiel 1: Einfaches Auswählen und Ersetzen von Aktivitätsnamen
5.1 Beispiele 43
[result>=$temp]
find * contains variable $actname, $tempaction replace variable $actname="SpotTemp"action replace variable $temp="30.0";
Abbildung 5.2: Beispiel 2: Suchen und Ersetzen von Variablen
5.1 Beispiele 44
find node DecisionNode->@*->FinalNodeaction set property name="Dummy";
Abbildung 5.3: Beispiel 3: Definition von Auswahlketten
action replace variable $temp=�30.0�;
Die Auswahl wird durch das Auftreten der gesuchten Variablen getroffen. Es wird
nach beiden Variablen gesucht und diese anschließend durch die vorgegebenen
Werte ersetzt.
Beispiel 3: Definition von Auswahlketten
Bei dieser Regel sollen, wie in Abbildung 5.3 zu sehen, zwei Aufrufe einer Aktivität
ausgewählt und verändert werden. Wie diese verändert werden, ist in diesem
Beispiel nicht relevant: Es wird exemplarisch der Name der aufzurufenden Aktivität
verändert.
5.1 Beispiele 45
Es gibt verschiedene Möglichkeiten diese Knoten auszuwählen. Hier wird die Eigen-
schaft ausgenutzt, dass sich diese beiden Knoten direkt vor einem Endknoten und
hinter einem Entscheidungsknoten befinden. Anhand dieser Bedingungen werden
die beiden Knoten ausgewählt. Dazu wird folgende Regel verwendet:
find node DecisionNode->@*->FinalNode
action set property name=�Dummy�;
Durch die Auswahlkette DecisionNode->@*->FinalNode werden alle Knoten
ausgewählt die zwischen einem Entscheidungsknoten und einem Endknoten sind.
Dies ist auch mit jeder anderen Kombination möglich. Es können auch längere
Ketten spezifiziert werden und zudem noch Eigenschaften der einzelnen Knoten als
Auswahlbedingung hinzugefügt werden.
Beispiel 4: Kanten auswählen und verändern
Zuletzt soll die rot markierte Kante in Abbildung 5.4 ausgewählt und verändert
werden. Dabei soll der Parametername am Eingang des Zielknotens von val4 zu
val5 geändert werden.
Bei diesem Beispiel wird die Möglichkeit der Kettenauswahl von Knoten aus Beispiel
3 verwendet. Zuerst werden alle Aktivitäten aus Beispiel 1 selektiert, mit Hilfe der
Kantenauswahl wird aus allen ausgehenden Kanten dieser Knoten die gewünschte
Kante ausgewählt. Folgende Regel führt die Auswahl durch:
find edge out[outputname=�val4�] of node ForkNode->@*
action set property outputname=�val5�;
Alle hier aufgeführten Beispiele dienen lediglich zur Demonstration einzelner Funk-
tionen. Es ist auch möglich diese Funktionen sinnvoll miteinander zu kombinieren.
5.2 Anwendungen
Für die Erweiterung des Frameworks um die Funktion der Modifikation von Ak-
tivitäten gibt es zahlreiche praktische Anwendungsmöglichkeiten. Durch die in
Abschnitt 4.2.6 festgelegte Schnittstelle ist die Erweiterung an jeder Stelle des
5.2 Anwendungen 46
find edge out[outputname="val4"] of node ForkNode->@*action set property outputname="val5";
Abbildung 5.4: Beispiel 4: Kanten auswählen und verändern
5.2 Anwendungen 47
Frameworks einsetzbar.
Derzeit wird die Modifikation nach dem eigentlichen Lade- und Parsevorgang eines
UADs ausgeführt. Dies ist eine von vielen Möglichkeiten, die lediglich zur Demons-
tration und zu Testzwecken implementiert wurde. Interessant ist vor allem zuerst
die Frage zu welchen Zwecken in der Praxis Modifikationen an UADs durchgeführt
werden können und sollen. Die beiden gewichtigsten Verwendungszwecke sind die
Möglichkeit der Generalisierung und anfallende Veränderungen der Umgebung.
Generalisierung bedeutet im Blick auf die UADs die Herstellung von universellen
UADs, welche an die Umgebungsbedingungen angepasst werden. Diese universellen
UADs sind in einer Form, in der sie von dem Interpreter des Frameworks nicht
ausgeführt werden können, da sie Variablen enthalten. Ein Beispiel hierfür ist in
Abbildung 5.2 (Beispiel 2 in Abschnitt 5.1) aufgeführt. Diese Variablen werden vor
dem Starten des Interpreters mit Hilfe der Regeln modifiziert, sodass die Variablen
durch sinnvolle Werte ersetzt werden. Die ersetzenden Werte sind jedoch abhängig
von den in dem jeweiligen Sensorknoten gespeicherten Ersetzungsregel(n) und
damit den Umgebungsbedingungen. Variablen können an allen möglichen Stellen
in einem UAD eingesetzt werden: Bedingungen für Entscheidungen (oder Teile
davon), Namen von aufzurufenden Aktivitäten, Namen von Objektflüssen oder
Adressen zur entfernten Ausführung von Aktivitäten. Jeder Sensorknoten kann diese
Variablen also individuell ersetzen und damit das UAD entsprechend an die eigenen
Bedürfnisse und Umgebungsbedingungen anpassen.
Veränderungen der Umgebung können sich auf verschiedenste Art und Weise
ergeben: Ein Sensorknoten in der Nachbarschaft ist ausgefallen, dieser ist jedoch
für die Ausführung wichtig, da auf ihm Aktivitäten entfernt ausgeführt werden. Der
ausgefallene Sensorknoten wird durch einen neuen Knoten ersetzt, welches jedoch
die Anpassung der Adressen zur entfernten Ausführung der Aktivität auf diesem
Knoten notwendig macht. Ein weiteres Szenario ist, gerade in der Entwicklungszeit
des Frameworks, die Änderung des Namens einer (Root-)Aktivität - womöglich nur
auf einzelnen Sensorknoten. Ohne die Möglichkeit, den Namen einer auszuführen-
den Aktivität noch zur Laufzeit in einem UAD ersetzen zu können, müsste für jeden
Sensorknoten mit der veränderten Aktivität das UAD manuell angepasst, konvertiert
und übertragen werden. Die Ersetzungsregeln erlauben diese Veränderung zur Lauf-
5.2 Anwendungen 48
zeit, ohne das UAD manuell anpassen zu müssen.
Kleine Fehler treten immer wieder in Programmen auf. Dies kann bei größeren
Mengen an Sensorknoten, mit womöglich noch (leicht) unterschiedlichen Varianten
des verwendeten UADs, zu hohem Aufwand in der Fehlerbehebung führen. Bisher
war es notwendig, das UAD im Modellierungstool zu korrigieren, anschließend er-
neut zu transformieren und auf die Sensorknoten zu verteilen. Einfacher ist es, den
Fehler mit Hilfe von Filterregeln zu beheben, indem das fehlerhafte UAD modifiziert
und damit korrigiert wird. Durch geschicktes Wählen der Filterregel(n) ist es oftmals
sogar möglich den gleichen Fehler in veränderten Varianten des UADs zu finden und
zu beheben.
Desweiteren können UADs nicht nur nach dem Laden und Parsen modifiziert
werden, sondern auch bei bestimmten Ereignissen. So lassen sich Ersetzungsregeln
auf ein UAD anwenden, welches gerade per Funk an den lokalen Knoten übertragen
wurde. Dank der Erweiterung des Frameworks im Zuge der Studienarbeit von
Büttner [18] wird auch die permanente Speicherung eines solchen modifizierten
UADs möglich. Ebenso kann auch ein UAD vor dem Weiterversenden an einen
anderen Knoten modifiziert werden.
Als Erweiterung ist auch noch vorgesehen, die Modifikation durch eine Root-Aktivität
auszulösen. Dies würde die Veränderung eines beliebigen UADs sowohl lokal, als
auch auf einem entfernten Sensorknoten, durch ein UAD selbst erlauben. Leider ist
eine Umsetzung zum aktuellen Zeitpunkt nicht möglich, da das Framework (noch)
keine Übergabe von statischen Parametern, also die Übergabe eines Dateinamens
oder womöglich sogar ganzer Regeln, für eine Aktivität erlaubt und spezifiziert.
Kapitel 6
Zusammenfassung
Vor dieser Studienarbeit gab es in dem Framework des Lehrstuhls keinerlei Möglich-
keit ein UAD zur Laufzeit zu verändern. Wollte man kleine Änderungen durchführen,
so musste dies über die UML-Modellierungssoftware geschehen, das UAD anschlie-
ßend transformiert und auf den Sensorknoten überspielt werden.
Mit dieser Arbeit wurde die Möglichkeit eingeführt, Eigenschaften einzelner Ele-
mente eines UADs zur Laufzeit anhand von Regeln zu verändern. Zu diesem Zweck
wurde eine eigene Regelsprache definiert, mit welcher sich alle möglichen Änderun-
gen ausdrücken lassen. Die Regelsprache ist dabei in zwei Teile geteilt: Die Auswahl
von Elementen und anschließend die Veränderung der ausgewählten Elemente. Als
Auswahlmöglichkeit lassen sich sowohl Eigenschaften von Knoten und Kanten, das
Vorkommen von Variablen, als auch deren Vorgänger oder Nachfolger spezifizieren.
Als Veränderung ist das Festlegen von Eigenschaften oder das Ersetzen von Variablen
möglich.
Durch die Möglichkeit des Ersetzens von Variablen ist eine Generalisierung von UADs
möglich, welche von dem einzelnen Sensorknoten entsprechend angepasst werden.
Dabei werden Variablen eingesetzt, welche von den Sensorknoten individuell ersetzt
werden. Es lässt sich damit auch schnell auf mögliche Veränderungen, sowohl der
physikalischen, als auch der programmtechnischen Umgebung reagieren. Außerdem
lassen sich kleinere Fehler einfach und mit geringerem Aufwand korrigieren.
Zum schnellen Zugriff auf die neuen Funktionen im Framework wurde eine ein-
fach zu bedienende Schnittstelle geschaffen, die dem Programmierer erlaubt eine
Veränderung jedes beliebigen UADs an jede Stelle des Frameworks, ohne großen
Aufwand, einzufügen.
49
6 Zusammenfassung 50
Zusätzlich wurden zwei Maßnahmen ergriffen um die Dateigröße von UADs (ge-
ringfügig) zu verkleinern: Die Transformation eines UADs wurde angepasst, sodass
die transformierten Dateien, je nach Größe des UADs, um einige Byte kleiner sind.
Außerdem werden, sofern der Ersteller eines UADs Elemente eingebaut hat, welche
niemals erreichbar sind, diese bei einer Veränderung entfernt.
Im Ausblick auf mögliche Erweiterungen, wurde die Regelsprache so entworfen, dass
neue Funktionen mit einfachen Schritten eingefügt werden können. Außerdem wä-
ren kleinere semantische Änderungen, wie zum Beispiel das Entfernen oder Ersetzen
von Knoten, als zusätzliche Funktion, denkbar. Es bieten sich auch zahlreiche Ereig-
nisse im Framework an, bei denen eine Veränderung angestoßen werden könnte.
Dies eröffnet dem Entwickler ganz neue Möglichkeiten, da sich beispielsweise UADs
vor dem Versenden an andere Sun SPOTs innerhalb des Sensornetzes verändern
lassen, und damit eine gewisse selbstständige Anpassung der UADs möglich wird.
Abkürzungsverzeichnis
API Application Programming Interface
AST Abstract Syntax Tree
RDF Resource Description Framework
UAD UML2-Aktivitätsdiagramm
UADs UML2-Aktivitätsdiagramme
UML Unified Modeling Language
XMI XML Metadata Interchange
XML Extensible Markup Language
XSLT Extensible Stylesheet Language Translation
51
Abbildungsverzeichnis
3.1 Sun SPOTs neben einer AA-Batterie . . . . . . . . . . . . . . . . . . . . . 10
3.2 Die Grundelemente eines UML2-Aktivitätsdiagramms. . . . . . . . . . 12
3.3 Entscheidungen in einem UAD. . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Parallelität in einem UAD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Objektflüsse in einem UAD. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Die notwendigen Schritte zur Entwicklung eines Parsers mit Hilfe von
JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Ein Beispiel für einen internen Strukturbaum des Parsers. . . . . . . . 31
4.3 Der AST zum Strukturbaum von Abbildung 4.2. . . . . . . . . . . . . . 32
4.4 Verwendete Klassen zur Repräsentation eines AST. . . . . . . . . . . . 33
4.5 Aufteilung eines AST und Mengenbewegung . . . . . . . . . . . . . . . 35
4.6 Ablauf der Selektion in einem AST. . . . . . . . . . . . . . . . . . . . . . 37
4.7 Ablauf bei der Anwendung einer Filterregel auf ein UAD. . . . . . . . 38
5.1 Beispiel 1: Einfaches Auswählen und Ersetzen von Aktivitätsnamen . 42
5.2 Beispiel 2: Suchen und Ersetzen von Variablen . . . . . . . . . . . . . . 43
5.3 Beispiel 3: Definition von Auswahlketten . . . . . . . . . . . . . . . . . . 44
5.4 Beispiel 4: Kanten auswählen und verändern . . . . . . . . . . . . . . . 46
52
Tabellenverzeichnis
2.1 Abstraktionsschichten eines UADs . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Java-Klassen zur Repräsentation von Knoten und Kanten in einem UAD 15
4.1 Auswahlgründe für die Regelsprache . . . . . . . . . . . . . . . . . . . . 21
4.2 Eigenschaften von Knoten und Kanten in einem UAD . . . . . . . . . . 24
53
Literaturverzeichnis
[1] G. Fuchs and R. German, “Uml2 activity diagram based programming of wire-
less sensor networks,” in SESENA ’10: Proceedings of the 2010 ICSE Workshop
on Software Engineering for Sensor Network Applications. New York, USA-NY:
ACM, 2010, pp. 8–13.
[2] OMG Object Management Group, “OMG Unified Modeling Language (OMG
UML), Superstructure, V2.1.2,” OMG Available Specification without Change
Bars formal/2007-11-02, 2007.
[3] M. L. Crane and J. Dingel, “Towards a uml virtual machine: implementing an
interpreter for uml 2 actions and activities,” in CASCON ’08: Proceedings of
the 2008 conference of the center for advanced studies on collaborative research.
New York, USA-NY: ACM, 2008, pp. 96–110.
[4] OMG Object Management Group, “Semantics of a Foundational Subset for
Executable UML Models (FUML), FTF - Beta 2,” OMG Available Specification
without Change Bars ptc/2009-10-05, Oct. 2009.
[5] C. Damm, “Implementierung und Bewertung eines RDF-basierten Frameworks
zur Interpretierung und Ausführung von UML2-Aktivitätsdiagrammen auf
Sensorknoten,” Diplomarbeit, University of Erlangen-Nuremberg, Computer
Science, Chair for Computer Networks and Communication Systems; Germany,
Sep. 2008.
[6] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “A Survey on
Sensor Networks,” IEEE Communications Magazine, vol. 40, no. 8, pp. 102–116,
August 2002.
[7] U. Hedtstück, Einführung in die Theoretische Informatik. Oldenbourg Wis-
sensch.Vlg, 2007.
54
Literaturverzeichnis 55
[8] S. Microsystems, “Sunspotworld - general faq,” http://www.sunspotworld.
com/docs/general-faq.html [web: 2010/10/22].
[9] ——, “The squawk virtual machine,” http://labs.oracle.com/projects/squawk/
squawk-rjvm.html [web: 2010/10/22].
[10] S. Gérard, “Papyrus UML,” http://www.papyrusuml.org/ [web: 2010/10/22].
[11] B. Oestereich, Die UML 2.0 Kurzreferenz für die Praxis, 4th ed. Munich, DE-BY:
Oldenbourg Wissenschaftsverlag GmbH, 2005.
[12] D. Veillard, “The xsltproc tool,” http://www.xmlsoft.org/XSLT/xsltproc2.html
[web: 2010/10/22].
[13] S. Haustein, “kXML,” http://kxml.sourceforge.net/ [web: 2010/10/22].
[14] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides, Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994.
[15] F. Müllmerstadt and G. Kuhlmann, SQL: Der Schlüssel zu relationalen Daten-
banken. rororo Verlag, 1999.
[16] “Java compiler compiler (javacc) - the java parser generator,” http://javacc.
dev.java.net/ [web: 2010/10/22].
[17] G. Fuchs, C. Damm, and R. German, “Poster: Programming Wireless Sensor
Networks using UML2 Activity Diagrams,” in The Fifth International Conference
on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP
2009), PhD/ECR Forum, Melbourne, AU-VIC, Dec. 2009.
[18] L. Büttner, “Erweiterung eines auf UML2-Aktivitätsdiagrammen beruhenden
Programmier-Frameworks für drahtlose Sensornetze um dynamische, profilba-
sierte Reprogrammierung,” Studienarbeit, Lehrstuhl Informatik 7 (Rechnernet-
ze und Kommunikationssysteme), Universität Erlangen-Nürnberg, Erlangen,
DE-BY, (in Arbeit).
Recommended
