Home

ScatterClipse: Architekturzentrierte Plattform und Werkzeuge für

1. 67 Receive Await Radio Packet Action Sending Node 1 Addressed Node 3 Packet Type 150 Timeout 1 000 Additional Checking false Processing Time BEFORE ReceivedDataOnOneNodeOnly Assertion Log Labels ReceivedDataOnNode2 ReceivedDataOrode3 o data was received by any data sink Abbildung 39 Markierungen zur Visualisierung der Testergebnisse in der Modellentitat Paketkopfes oder auch die Nutzdaten protokolliert werden sollen Die Parametrisie rung der Modellentit ten hilft damit dem Softwaretester die Feink rnigkeit der Protokollierung auf Modellebene auf die Anforderungen des Testfalls abzustimmen Damit die Protokolleintr ge effizient von den Pr froutinen der ScatterUnit Testau tomation bearbeitet werden k nnen verf gen sie ber eine festgelegte Struktur Diese sieht aus wie folgt 1 ID des Sensorknotens auf dem der Protokolleintrag erstellt wird 2 Der Zeitstempel der vom Synchronisationsdienst verwaltet wird dient zur Bestimmung des Zeitpunkts des Auftretens des mit dem Eintrag protokollier ten Ereignisses um die Protokolleintr ge in eine chronologische Ordnung zu bringen 3 Typ des Protokolleintrags zur Identifikation auf Editorebene zum Zweck der Visualisierung 4 Anzahl aufeinander folgender Bytes in der Bytefolge 5 Bytefolge d h die protokollierten Daten Deckt die zust ndige Pr froutine anhand eines im Protokoll analysierten Log Eintrags e
2. Abbildung 77 Austausch der Routinginformationen ber den Zielknoten Knoten 4 Kame08 Schritt 7 ben tigte Zeit ca 75 Minuten 126 Die kritische Frage ist nun ob Knoten 1 die bereits in Schritt zwei aktualisierten korrekten Routinginformationen mit denen von Schritt vier f lschlich berschreibt Denn eine erneute berschreibung w rde zu einem nicht korrekten Eintrag bez glich des Next Hops f hren bei dem Knoten 2 als Next Hop erfasst wird Um diese Bef rchtung in eine aussagekr ftige Hypothese zu fassen wurde das zuletzt erweiterte Detaildiagramm InitlUndWarte erneut um eine Log Funktionalit t erg nzt RoutingTabelleneintragDavor und RoutingTabelleneintragDanach wodurch der Eintrag vor und nach dem Empfang der betroffenen Routinginformationen protokolliert wird vgl Abbildung 78 Die Beobachtung nach mehrfacher Durchf hrung des erweiterten Testfalls ergab dass die Routinginformationen nicht berschrieben wurden Somit wurde die aufgestellte Hypothese nicht erf llt Der Fokus der Fehlersuche muss daher auf andere Aspekte gerichtet werden um neue Hypothesen aufstellen zu k nnen Daher wurde zun chst der Protokollierungsdienst ankommender Pakete von ScatterUnit aktiviert um sicherzustellen dass die versendeten Routinginformationen korrekt beim Empf nger ankommen Nach der Durchf hrung des Testfalls mit aktiviertem Dienst wurden keine falschen ankommenden Routinginformationen festgestellt Nun stellte sich di
3. 5 Testfall ausf hrung eingesetztes Werkzeug produziert Ergebnis gt protokoll wird verarbeitet von 6 Darstellung der Testergebnisse Graphischer Editor eingesetztes Werkzeug Zeigt Testergeb nisse an in Integrations Plug In Abbildung 15 Aktivit ten beim Einsatz von Visual ScatterUnit Kame08 31 E Java platform resource Diagrams Demo MovingDataSource testcase_diagram _n9BFEO eEdyTp_kbIKG5fq Eclipse SDK xj File Edit Refactor Diagram Navigate Search Project Run Window Help SHS im O Q seseo Sev x T or 7 ES Debug i Java Ce icc 3 i Package Explorer cam A d default wsn_diagram d MovingDataSource testcase_diagram ld MovingDataSource testcase_diagram 2 xD el B g7 A Palette gt Ef Diagrams X ao 2 8 Demo b default wsn E Note id default wsn_diagram Sensor Node B MovingDataSource testcase Initial Node f d MovingDataSource testcase_diagr Final Node wsn properties 5 S W E DSDV Branching Point WES ScatterWeb2 platform F Control Action E E Test A Event iB Receive Await Radio Packet Action H Log Action Sending Node 1 aein Addressed Node 2 2 Packet Type 150 ey To Eiti Timeout 1 000 WB Await Radio Packet Additional Checking false Action Processing Time BEFORE it Rede ree FR Radio Packet Log Action eived Radio Packet Received Event 4 Link
4. pand Codevorlagen anlegen tend Erweiterungen k EMOF pet p Checks Constraints OGL oes ae EMEF Checks a A en En A N Ins N Instanz N Een a oes sedi XMI A D code N EMOF YOR Modelle Eee ScatterModeller gt oAW Ba C Code q 4 N p W er y A Instanzen von Abbildung 13 Die in ScatterClipse eingesetzten Werkzeuge und Technologien im Kontext des MDD Prozesses 2 6 Zusammenfassung Das Kapitel widmete sich dem modellgetriebenen Entwicklungsprozess sowie der Werkzeuge die zur Realisierung des Prozesses im Rahmen der ScatterClipse Werk zeugkette eingesetzt werden Zun chst wurde auf den in der Arbeit verfolgten archi tekturzentrierten Ansatz eingegangen und dieser im modellgetriebenen Paradigma eingeordnet Ferner wurde dieser Ansatz der modellgetriebenen Architektur gegen bergestellt um zu zeigen warum sich gerade die Architekturzentrierung f r die Herausforderung der Automatisierung als L sung optimal eignet Ferner wurden die zur Realisierung der architekturzentrierten generativen Infrastruktur eingesetz ten Technologien und Werkzeuge von denen jedes f r eine Phase des modellgetrie benen Prozesses zust ndig ist genauer unter die Lupe genommen Mit der Behand lung jedes Werkzeuges wurden zugleich die in der jeweiligen Phase stattfindenden Abl ufe und Aktivit ten geschildert Das Resultat eines Werkzeuges bildet oft die Eingabe des darauf folgenden Auf B
5. BEO WE Abbildung 16 Der generative Editor von Visual ScatterUnit Der Einsatz von eng an die UML angelehnten Aktivit tsdiagrammen innerhalb der eigenen DSL statt einer eins zu eins bernahme der Diagramme aus der UML selbst bzw aus deren Werkzeugen erm glicht einerseits einen gel ufigen Modellie rungsstandard da man sich an die Notation als Standard h lt andererseits wird eine ma geschneiderte Verwendung dieser Modellinstanzen speziell f r die eigene Modellierungsbelange im Kontext der selbstentworfenen Dom nensprache erreicht Demgem ist es beispielsweise m glich interaktiv und flexibel mit einfachem Dop pelklick die Aktivit tsdiagramme zu verfeinern und innerhalb ihrer Aktionen zu navigieren um die Fehler zu isolieren die Testergebnisse zu visualisieren und an richtiger Stelle in die Modelle einzubetten All dies w re werkzeugbedingt mit her k mmlichen UML Diagrammen kaum machbar Hier zeigt sich zum einen die St r ke des Ansatzes generative Editoren auf Basis des DSL Meta Modells einzusetzen und zum anderen dom nenspezifisch zu modellieren Dies zeigt sich ebenfalls an hand der dom nenspezifischen Just in time Validierung auch Live Validierung ge nannt der Modelle die durch die Definition mit Hilfe der Checks Sprache erm g licht wird Dies wird wie bereits in 2 5 beschrieben durch den von openArchitectu reWare gelieferten GMF Adapter bewerkstelligt Abbildung 17 zeigt ein Beispiel ei nes Akt
6. Broc99 Broch J Johnson D B Maltz D A The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks Internet Draft 1999 URL http www cs cmu edw dmaltz dsr html Kame07 Kamenzky N Realisierung einer Testinfrastruktur f r drahtlose Sensornetzwerke und Konzeption einer modellgetriebenen Testfallentwicklung Unpublizierte Studienarbeit Betreuer Mohammad Al Saad Freie Universit t Berlin 2007 Kame08 Kamenzky N Entwicklung einer modellgetriebenen Testumgebung zur Unterst tzung des Testprozesses von Anwendungen drahtloser Sensornetze Unpublizierte Diplomarbeit Betreuer Mohammad Al Saad Freie Universit t Berlin 2008 Kuor05 Kuorilehto M H nnik inen M H m l inen T D A Survey of Application Distribution in Wireless Sensor Networks In EURASIP Journal on Wireless Communications and Networking Issue 5 774 788 2005 Lenz07 Lenz Ch Chimiak Opoka J Breu R Model Driven Testing of SOA based Software In Luebke D ed Workshop on Software Engineering Methods for Service Oriented Architecture CEUR Workshop Proceedings vol 244 pp 99 110 Hannover 2007 Levi03 Levis P Lee N Welsh M Culler D TOSSIM Accurate and Scalable Simulation of Entire TinyOS Applications In 1st International Conference on Embedded Networked Sensor Systems pp 126 137 ACM New York 2003 Losi07 Losilla F Vicente Chicote C Alvarez B Iborra A Sanchez P Wireless Sensor Ne
7. 1 g ANDOR and or h TIMEPERIOD from TIME to TIME i TIME int_hour int_min j MEASUREMENT1 temp batt k MEASUREMENT2 micr vabr irmo Tabelle 1 Die kontextfreie Grammatik Ding07 Abbildung 65 zeigt ein Beispiel des unten stehenden Alarmausdrucks und dessen Herleitung auf Basis der obigen Grammatik Hierzu wird der zugeh rige Syntaxbaum aufgestellt Bei jedem Herleitungsschritt werden die darauf angewandten Produktionsregeln angegeben alarm 23 34 if temp 212 and micr detect from 12 30 to 14 50 107 ALARMSYSTEM a ANDOR CONSTRAINTS a Fre COMPARE 12 CONDITION eal h a ms ae gt ha MEASUREMENT2 detect from TIME TIME F i li Me 12 30 14 a Abbildung 65 Beispiel eines Alarmausdrucks oben und dessen Syntaxbaum unten Ding07 Der Ausdruck gibt eine Randbedingung fiir den Alarm vor so dass dem Benutzer eine Benachrichtigung geliefert wird sobald das folgende Pr dikat bei den angegebenen Sensorknoten 23 und 34 erf llt ist Falls eine Temperatur von einem der zwei Sensorknoten gemessen wird die gr er oder gleich 12 C ist und mindestens einer der zwei Sensoren eine Stimme w hrend der Zeitspanne 12 30 bis 14 50 registriert Dieser rekursive und zusammengesetzte Aufbau der Alarmsprache erleichtert dem Benutzer die Formulierung von Alarmausdr cken Abbildung 66 zeigt drei unterschiedliche Alarmausdr cke die demonstrieren wie die Komposition der Alarmpr
8. ScatterWeb Event h l Scatter Web Process c build xml makefile amp System amp bin 2 amp lib 3 src doxywarn log Idscript x m build properties Abbildung 45 Die generierten Artefakte in ScatterFactory Hent06 e NO_COMMANDS Hierdurch werden s mtliche auf Konsolekommandos be zogene Codezeilen im Template bei der Einbindung des Codes nicht in Be tracht gezogen e NO_SERIAL Diese Filterregel bewirkt dass die Kommandozeilen f r die se rielle Schnittstelle bei der Einbindung des Codes nicht herausgefiltert wer den die brigen Kommandozeilen werden herausgefiltert e MIN_COMMANDS Nur signifikante oft verwendete Kommandos wie das Setzen der ID werden eingebunden Dadurch wird ein gro er Anteil von Kommandozeilen herausgefiltert Die Realisierung der Filterregeln in den Xpand Templates des oAW fu t auf der Verwendung von Erweiterungen Extentions die in den Templates unterst tzt werden Ihre Technik wurde in 2 5 er rtert Solche Erweiterungen werden berall innerhalb des Templates aufgerufen und zwar unmittelbar bevor eine betroffene zu filternde Kommandozeile aufgefunden wird Die aufgerufene Erweiterung bekommt hierf r den Namen der Filterregel als formalen Parameter Im Programmauszug 14 wird ein Ausschnitt eines Templates gezeigt in dem die Filterregel NO_SERIAL verwendet wird lt lt IF containsCommandFilter Sensor gt gt lt lt IF sensor filterRules rule exists e e toStri
9. Dieses Kapitel befasst sich mit den Technologien und Werkzeugen des modellgetrie benen Prozesses wobei jedes Werkzeug f r eine bestimmte Phase dieses Prozesses zust ndig ist Ferner wird die Integration der beschriebenen Werkzeuge behandelt welche eine erfolgreiche Zusammenarbeit im Rahmen einer einzigen Werkzeugkette erm glicht Es geht speziell um diejenigen Werkzeuge welche zur Realisierung der generativen Infrastruktur von ScatterClipse zum Einsatz kommen Zun chst wird jedoch auf den architekturzentrierten Ansatz des modellgetriebenen Paradigmas eingegangen und auf die Frage wie dieser sich von der modellgetriebenen Architek tur abgrenzt 2 1 Das architekturzentrierte modellgetriebene Paradigma W hrend die Objektorientierung gegenw rtig den Softwareentwicklungsprozess dominiert h lt ein neues Paradigma sowohl in der Industrie als auch in der For schung Einzug Der Ansatz der in aller Munde ist lautet modellgetriebene Soft wareentwicklung MDSD WebMDSD Neu ist dabei dass Modelle nicht nur zum Zweck der Dokumentation bzw Visualisierung eingesetzt werden Die semantikbe hafteten und ausdrucksstarken formalen Modelle fungieren auch als Technik um Schl sselkonzepte und Randbedingungen der Dom ne Plattform vollst ndig und pr gnant zu repr sentieren Um diesen Entwicklungsprozess f r die Industrie ein satzfahig zu machen wurde von der OMG eine Initiative von 800 Unternehmen WebOMG die modellgetriebene Arch
10. ScatterwebBatchErrors gt lt expression value model eAllContents gt lt component gt lt component id generator class org openarchitectureware xpand2 Generator skipOnErrors true gt lt metallodel class org openarchitectureware type emf EmfMetaModel gt lt metalodelFile values metamodel metamodel ecore gt lt metallodel gt lt expand value templates Root Root FOR model gt lt genPath value sre gen gt lt pr rePaths value sre gen gt lt prDefaultExcludes value false gt lt component gt lt component class org openarchitectureware xpand2 Generator dvice adviceTarget generator gt amp lt advices value templates Logging gt lt component gt lt vork lows gt Abbildung 12 Die Workflow Konfiguration von ScatterFactory Hent06 1 Da der Ausgangspunkt des Generierungsprozesses das eingegebene Modell ist wird dieses als erstes durch das Property Element in der Workflow Datei festgelegt Zugleich wird auch das Zielverzeichnis angegeben in das die aus dem zuvor festgelegten Modell generierten Softwareartefakte das Ergebnis des Generierungsprozesses geschrieben werden 2 Um das im ersten Schritt angegebene Modell bearbeiten zu k nnen muss wie bereits geschildert das eingegebene Modell auf Basis des Metamodells 24 Die Workflow Datei hat immer die Endung oaw 22 instanziiert werden Durch metaModelPackage wird der Pfad des Metamo dells
11. Thoms K V lter M Sch nbach P Eysholdt M openArchitecture User Guide 2008 URL http apps eclipse org gmt oaw doc 4 3 openArchitectureWare 4 3 Reference pdf Evan03 Evans E Domain Driven Design Tackling Complexity in the Heart of Software Addison Wesley Longman Amsterdam 2003 Gane03 Ganeriwal S Kumar R Srivastava M B Timing sync protocol for Sensor Networks In 1st International Conference on Embedded Networked Sensor Systems pp 138 149 ACM New York 2003 Garc08 Garcia E M Serna M A Berm dez A Casado R Simulating a WSN Based 177 Wildfire Fighting Support System In IEEE International Symposium on Parallel and Distributed Processing with Applications pp 896 902 IEEE CS Press Washington 2008 Gay03 Gay D Levis P von Behren R Welsh M Brewer E Culler D The nesc language A holistic approach to networked embedded systems In Conference on Programming Language Design and Implementation pp 1 11 ACM New York 2003 Gokh04 Gokhale A Balasubramanian K Balasubramanian J Krishna A Edwards G T Deng G Turkay E Parsons J Schmidt D C Model Driven Middleware A new paradigm for deploying and provisioning distributed real time and embedded applications Journal of Science of Computer Programming Special Issue on Foundations and Applications of Model Driven Architecture MDA Volume 73 Issue 1 pp 39 58 Elsevier Amsterdam 2008
12. lt lt Protokolleintrag gt gt lt lt Protokolleintrag gt gt Nutzlast des Datenpaketes Nutzlast des Datenpaketes Markierung Nutzlast 1 Markierung Nutzlast lt lt Pr froutine gt gt lt lt Pr froutine gt gt Nutzlast verf lscht Nutzlast verf lscht Markierung Nutzlast y Markierung Nutzlast Abbildung 32 Die Markierungen hier Nutzlast fungieren als Bindungsmechanismus zwischen den Protokolleintr gen und deren Pr froutinen Die Meldungen der Uberpr fungen werden anschlie end im Modell angezeigt rechts Kame08 Ein Beispiel hierzu sind die Modellentit ten Warten auf Paket und ndern der Topologie aus Abbildung 33 bei denen es sich um oft zu verwendende Funktionali t ten in der WSN Dom ne handelt Diese werden daher als Dienste ScatterUnits angeboten wobei sie als fixer Bestandteil der Dom nensprache unterst tzt werden was bedeutet dass f r solche Dienste Metamodellinstanzen definiert werden Die Modellkonstrukte solcher Dienste stehen somit dem Nutzer in der Palette des gene rativen Editors zur Verf gung vgl Abbildung 34 da der generative Editor wie in Kapitel 4 erw hnt aus dem Metamodell auf einfache Weise erneut automatisiert generiert werden kann Damit passt sich die Struktur des Editors den nderungen der Anforderungen an die entstehen wenn unterschiedliche Anwendungen getestet werden Ergeben sich neue Anforderungen in der Testdom ne so werden die ent sprechenden Dienste von
13. m nenspezifische Randbedingungen berpr ft Programmauszug 13 zeigt einen Ausschnitt einiger Checks Ausdr cke der ScatterFactory Editing constraints context Sensor ERROR Sensors schould have a name sensorName compareTo null gt 0 context Sensor ERROR Sensors need an application sensorApplicationConnection compareTo null gt 0 context Application ERROR Applications need to be connected to at least one Container applicationContainerConnections size compareTo 0 gt 0 context Application ERROR Applications need a Name containerName compareTo null gt 0 context Container ERROR Containers must contain at least one Component components size compareTo 0 gt 0 context UserdefinedComponent ERROR User defined components need to be named componentName compareTo null gt 0 context Port ERROR Ports cannot be provided and required at the same time portConnections select e e ConnectionType toString matches PROVIDEDPORT to intersect portConnections select e e ConnectionType tostring matches REQUIREDPORT toPort size gt 2 domain specific constraints context Port ERROR Port Actor need not be connected to port defined in the Timers module portName matches Actor s portConnections exists e e toPort portName matches AddTimers le toPort portName matches ModifyTimers context Port ERROR Port Events must be connected to ports defin
14. select e e metaType WSN Library amp amp e name scatterweb size gt 0 context WSN Link ERROR The source node of this link is not specified this source null context WSN Link ERROR The target node of this link is not specified this target null context WSN TestCase ERROR A test case must be assigned to at least one sensor node this linkedNodes select e e metaType superTypes contains WSN SensorNode size gt 0 context WSN TestCase 168 ERROR Some sensor node ids are assigned to more than one sensor node this outgoing size this incoming size 0 true Set WSN LabeledLink this outgoing union this incoming label hasDuplicateIds false 169 11 6 ScatterClipse im Einsatz Vielf ltige Einsatzbeispiele der unterschiedlichen Komponenten der ScatterClipse Werkzeugkette sowie deren Zusammenarbeit finden sich im vierteiligen Screencast unter http page mi fu berlin de saad ScatterClipse video htm Dabei wird jeder einzelne Schritt ausf hrlich kommentiert und erl utert Ferner finden sich weitere Beispiele im mehrteiligen Entwickler bzw Benutzerhandbuch welches von der Webseite des Projektes heruntergeladen werden kann Die Seite des ScatterClipse Projektes findet sich unter http page mi fu berlin de saad ScatterClipse scatterclipse htm 170 11 7 Verzeichnisse 11 7 1 Abbildungsverzeichnis Abbildun
15. 132 diese Vorteile bereits w hrend der Entwicklung eines einfachen Testfalls deutlich Die N tzlichkeit erweist sich jedoch besonders w hrend der Fehlersuche da in dieser Phase der Testfall st ndig neu ausgef hrt und erweitert wird Bei der bisherigen Evaluierung handelt es sich eher um eine funktionale Beurteilung der ScatterClipse Werkzeuge Eine qualitative Beurteilung ihrer Eigenschaften erfolgt im Zusammenhang der Darstellung verwandter Arbeiten im n chsten Kapitel um den spezifischen Beitrag von ScatterClipse im Forschungsspektrum darzulegen 133 9 Verwandte Arbeiten Auf der ICSNC Konferenz WebICSNC im Oktober 2008 auf welcher der gr te Teil der ScatterClipse Werkzeugkette weitestgehend vorgestellt wurden wurde interessanterweise von Teng et al eine Studie Teng08 ber die in der aktuellen Forschung vorhandenen repr sentativen Werkzeuge und Umgebungen zur Entwicklung von Softwareanwendungen f r drahtlose Sensorknoten pr sentiert und die jeweiligen Ans tze verglichen Hierzu wurden zun chst die an solche Werkzeuge zu stellenden Anforderungen formuliert um auf dieser Basis einen Vergleich zwischen den Werkzeugen bzw Ans tzen vornehmen zu k nnen Zun chst stellt die Unterst tzung einer ausdruckstarken Modellierungstechnik eine essentielle Anforderung an solche Werkzeuge dar wodurch eine Abstraktion von technischen Belangen bewirkt wird Ferner wird erwartet dass die Werkzeuge Simulationsfunktionalit ten mit
16. Anschlie end wird dieses Log von verschiedenen Pr froutinen auf vor gekommene Fehler berpr ft Jede solche Routine ist f r eine bestimmte Fehler klasse zust ndig Beispielsweise berpr ft die Pr froutine CheckPacketIntegri ty im Diagramm der vorherigen Abbildung 23 die Integrit t der Nutzlast des ver sendeten Pakets F r den Fall dass die Nutzlast besch digt wurde wird dies von derjenigen Pr froutine gemeldet die die berpr fung zur Evaluierung der gelogg ten Daten bearbeitet hat Um eine optimierte Pr fung spezifischer Fehler durch die korrespondierende Pr froutine zu erreichen m ssen zwei T tigkeiten ausgef hrt werden Zuerst wer 43 den w hrend der Ausf hrung des Testfalls die Testdaten als Aktionen geloggt aus denen R ckschl sse auf das Auftreten des gesuchten Fehlers gezogen werden k n nen Daher wird das Testfallmodell um entsprechende Log Aktionen gem dem je weiligen unterliegenden Testszenario vom Entwickler erweitert Zweitens werden die gesammelten Informationen anhand dieser Logs evaluiert Daher werden die re levanten Logeintr ge aus dem Logstrom ausgesucht um sie bei der entsprechenden Routine zu analysieren Um dies technisch zu bewerkstelligen m ssen die Lo geintr ge entsprechend den Anforderungen der Pr froutinen aufbereitet werden Zu diesem Zweck wird das Testfallmodel zus tzlich zu den Logaktionen mit den korres pondierenden Markierungen log labels versehen So gibt die Aktio
17. For any real world application a robust hardware platform is required that allows gearing into all important hardware parameters to achieve optimum results in software applications For this reason we created the ScatterWeb hard ware platform called the embedded sensor board ESB in 2003 The success of the platform led to the spin off of ScatterWeb GmbH in 2005 Based on the know how and experiences gained an industrial platform was designed and certified for radio spectrum and electro magnetic compatibility Since demands are manifold and rapidly changing a new research platform the modular sensor board MSB has been created While still based on an MSP430 series microcontroller the layout and peripherals have been completely redesigned to better fit research needs of the near future The new platform is available to the public since the beginning of 2007 through the ScatterWeb GmbH Baar07 59 Die Anpassungen hinsichtlich der MSB Eigenschaften zeigen sich deutlich im Metamodell von ScatterFactory2 Eine Darstellung des Metamodells in UML Notation findet sich in Ab bildung 89 im Anhang 11 4 82 bern die dynamisch zur Laufzeit eingebunden werden k nnen Demzufolge k nnen Firmwaremodule Infrastrukturcode f r eine Anwendung ma geschneidert gene riert werden Daher ist es naheliegend die Laufzeitumgebung einer auf einem MSB laufenden Anwendung als formales Modell zu repr sentieren durch das eine dyna mische Konfi
18. Instanz im Instanzdiagramm zu modellieren wobei die Assoziationen zwischen den einzelnen Sensorknoten bzw Instanzen spezifiziert werden m ssen Dies zeigt sich anhand des Instanzdiagramms f r das Anwendungsszenario welches von den Autoren zur Darstellung der Modellierungssprache vorgestellt wird Es reichen lediglich zehn Sensorknoten im Anwendungsbeispiel um die Lesbarkeit des dazugeh rigen Instanzdiagramms so gut wie unm glich zu machen Umso komplexer d rfte seine Erstellung sein Dieses Paradebeispiel macht deutlich wie schnell UML basierte Diagramme zu einer hohen Komplexit t neigen was ihre Handhabung und Modellierbarkeit erschwert An dieser Stelle zeigt sich die St rke des ma geschneiderten Entwurfs der DSL in ScatterClipse welche beispielsweise die Sensorknoten mittels deren IDs ber die entsprechenden Assoziationen den jeweiligen generischen Beh lterdiagrammen Knotenlaufzeitkonfigurationen NodeA und NodeB zuweist vgl Abbildung 47 in 5 6 9 1 Zusammenfassung Da die ScatterClipse Werkzeugkette umfangreiche und vielf ltige Funktionalit ten anbietet f r deren Einsatz jeweils unterschiedliche Techniken und Methoden verwendet werden wurden die verwandten Arbeiten gem ihrem jeweiligen Einsatzzweck untergliedert und von unterschiedlichen Blickwinkeln betrachtet Weil die ScatterClipse Werkzeugkette im Gro en und Ganzen der Anwendungsentwicklung f r drahtlose Sensornetze dient wurden zun chst allgemein Entwi
19. RS 232 hardware serial ports and limited access to IEEE 1284 parallel ports SPP mode WebJavaComm 33 angeschlossen ist als Java Objekt repr sentiert ber das die Daten textbasiert ausgetauscht werden Sobald der Testfall vollst ndig erstellt wurde kann er mit Hilfe der Eclipse basierten Umgebung C Development Tool CDT kompiliert werden Anschlie end wird mit Hilfe des Ant Plugins das als Hex File vorliegende Code Image auf die je weiligen Sensorknoten entweder seriell oder drahtlos ausgebracht 2 Im Weiteren wird nun der Test auf den Knoten ausgef hrt und w hrenddessen werden die f r die Testevaluierung relevanten Informationen protokolliert Nach der Beendigung des Tests werden die soeben protokollierten Informationen an das Rahmenwerk mittels der COM PORT Bibliothek bermittelt Die Daten werden an die entsprechende berpr fungsroutine bergeben die sie ihrerseits interpretiert und aufbereitet Dabei markiert die Pr froutine die gesammelten Daten des Test protokolls entsprechend der aufgefundenen Fehler Nun k nnen die analysierten und markierten Daten des Testprotokolls vom Visualisierungs Plugin geladen wer den wodurch die Testdaten an den richtigen Stellen innerhalb der formalen Modelle des eben protokollierten Testfalls im grafischen Editor visualisiert werden 3 2 Die Testautomatisierungsschicht ScatterUnit F r den Entwurf der Testautomatisierungsschicht ScatterUnit spielen die Anforde rungen der E
20. Synchronisation PROVIDEDPORT Aggregation System REQUIREDPORT serae Threading Assoziation Time Klasse Timers n Userdefined Attribut NONE Enumeration Abbildung 41 Das Metamodell von ScatterFactory Hent06 73 Betrachtet man die gesamte Struktur der Software eines einzelnen Sensorkno tens so unterscheidet man dabei zwischen zwei Ebenen der auf dem Knoten lau fenden Anwendung und den daf r ben tigten Firmwaremodulen Letzere werden wie zuvor geschildert durch die Definition bzw die Verwendung passender Contai ner im Modell zusammen gef gt F r die Modellierung der Anwendung steht die Klasse Application zur Verf gung die als Verkn pfung zwischen dem Sensor und den darauf installierten Firmwarecontainern fungiert Die Anwendung stellt den Bereich in der modellierten Software dar in dem der Entwickler den Code manuell implementiert Daf r werden zur automatisierten Codegenerierung auf Template Ebene die in 4 3 erl uterten gesch tzten Bereiche Protected Regions eingesetzt Allerdings kann der Code einer Anwendung zun chst einmalig entwickelt und dar aufhin in korrespondierenden Templates abgelegt werden was eine Wiederverwen dung des Codes erm glicht Um auf die zugeh rigen Templates einer Anwendung w hrend der Codegenerierung zugreifen zu k nnen verf gen die Anwendungen ber eindeutige Bezeichner und zwar den Namen angegeben durch das Attribut na mespace im Metamodell und eine m gliche zus
21. UINTS sAppConfig sizeof appconfig_t gt bin GS out S E src Sensor event handler 9 Scatterweb Ev void handleEvent void sdata 9 ScatterWeb Ev sdata_t data sdata_t sdata A Scatterweb Prc if AppConfig announceFlags AF_SERIAL Comm_print e r n data 3 ESB veproj if AppConfig announceFlags amp AF_RADIO gt ESB vcproj AMD17C packet_t p E flash bat to BROADCAST makefile type SENSOR_PACKET EI makefile xml header_length 0 ESB ncb data UINTS data gt ESB sin data_length sizeof data ESB suo et_send sp NULL gt aopy gt DirectedDiffusion B E DSDv DSR eDHCP efile A ie E gt EEPROMTest exec text hex filename amp mp2 exec 34062 BaSa out out elf 4 E gt MD4 4 exec ROM usage is text data RAM usage is data bss gt mos BUILD SUCCESSFUL Total time 6 seconds a gt MMSGate Picturelt Abbildung 84 Das ScatterFlash Plugin zur Kompilierung und Initialisierung der generierten Softwareartefakte Ding07 Zu diesem Zweck unterst tzt das Ant Plugin sogenannte Targets die als XML Elemente vorliegen In solchen Targets k nnen beliebige Aktionen bzw Steuerbefehle angegeben werden die externe Dienste bzw Funktionalit ten aufrufen Hierzu werden mittels der Targets diejenigen Aktionen der Makfiles angegeben die die entsprechenden Funktionalit ten zur Kompilierung und zum seriellen Flashing der mspgcc Software aufrufen Dabei handelt es
22. Wikipedia Art Pervasive Computing http en wikipedia org wiki Pervasive_Computing WebProfiles OMG Profiles Spezifikation http www omg org spec UML 2 1 2 Infrastructure PDF WebCSMA CA Computerlexikon CSMA CA http www computerlexikon com begriff csma ca highlight Netzwerk WebRMI Sun Remote Methode Invocation whitepaper http java sun com javase technologies core basic rmi index jsp WebRMIWikipedia Wikipedia Art Remote Methode Invocation http de wikipedia org wiki Remote_Method_Invocation WebSadilek Sadilek D A Test Driven Language Modeling o J http www2 informatik hu berlin de sadilek Homepage Thesis_Subject html WebSall Sallai J Balogh G Dora S TinyDT Institute of Software Integrated Systems 0 J http tinydt sourceforge net index html WebTestfall Wikipedia Art Testfall http de wikipedia org wiki Testfallhttp en wikipedia org wiki Test_case WebTestProfile Testing Profile OMG http www omg org technology documents formal test_profile htm WebUML UML OMG http www uml org WebUUID Wikipedia Universally Unique Identifier UUID 182 http de wikipedia org wiki Universally_Unique_Identifier WebViptos Viptos http ptolemy berkeley edu viptos WebWSN Simu Table comparing simulation tools for Wireless Sensor Networks http www comnets uni bremen de mab cruise simulation tool comparison matrix html WebXMI OMG MOF 2 0 XMI Mapping Specification
23. dass vom Routingprotokoll nach der Topologie nderung erwartet wird 47 ChangeTopology Ea AssertForwarding AwaitSecondPacket AssertNoForwarding Abbildung 27 Das verfeinerte Diagramm des Testfalls Kame08 das Paket ber diesen Sensorknoten weiterzuleiten Die dem Sensorknoten 3 zuge wiesene Pr froutine bewirkt das Gegenteil Hier wird ein Fehler berichtet in dem Fall dass das Paket ber diesen Sensorknoten weitergeleitet wird Nach der Ausf hrung und der daran anschlie enden berpr fung des verfeiner ten Testfalldiagramms wird m glicherweise festgestellt dass das Paket wie erwar tet durch den benachbarten Sensorknoten 2 weitergeleitet wurde In diesem Fall muss die aufgestellte Hypothese revidiert werden Eine M glichkeit ist nun dass dieser benachbarte Knoten nicht in der Lage war das korrekt empfangene Paket seinerseits weiterzuleiten Um diese neue Hypothese zu verifizieren muss eine wei tere Verfeinerung des Testfallmodells vorgenommen werden Das entsprechende Di agramm wird um Aktionen erweitert durch die die Routingtabelle von Sensorkno ten 2 geloggt wird und zwar zu dem Zeitpunkt in dem der Sensorknoten versucht das betroffene Datenpaket weiterzuleiten Wenn daraufhin festgestellt wird dass die Route zu Zielknoten 4 in der Tabelle nicht existiert ist unsere Annahme zutreffend und hat uns auf die richtige Spur ge bracht Die Stelle der Fehlerursache im Code ist jedoch l ngst noch
24. erm glicht Solche dom nenspezifischen Modellierungssprachen haben gegen ber den in der MDA Petr06 verwendeten UML Modellen Rupp05 den Vorteil dass sie sich von Grund auf an die bereits vorhandene Dom ne anlehnen da deren Entwurf und Auf bau ma geschneidert auf die Randbedingungen der Dom ne ausgerichtet sind Da mit kann man auf einfache Weise die verschiedenen Aspekte der Dom ne in korres pondierenden Modellen nahtlos und pr zise erfassen So gew hren sie einen hohen Abstraktionsgrad und bleiben zugleich bez glich der Dom ne konkret Anders ist es bei den schnell komplex werdenden UML Modellen die auf Grund ihrer eher uni versellen Motivation den Entwickler relativ schnell in die Lage bringen sich mit mehrseitigen Modellkonstrukten simultan auseinander setzen zu m ssen was die Modellierungskomplexit t deutlich erh ht Aufgrund ihrer universellen Natur m ssen UML Modelle nachtr glich der unter liegenden Dom ne leichtgewichtig und somit bedingt angepasst werden was der an gestrebten dom nennahen Modellierung entgegenwirkt Die dadurch verminderte Ausdruckkraft hinsichtlich der Dom ne weitet sich zu einer semantischen L cke zwischen der Modellierungssprache und den daraus zu generierenden Codeartefak ten aus Dies hat zur Folge dass im Kontext der MDA der Transformationsprozess keinen direkten Modell zu Code sondern eine Modell zu Modell zu Code berf hr ung durchlaufen muss um die entstandene semantische L cke
25. jedoch durch ein Urteil vom 26 Oktober 2006 Akz 2 Ni 2 05 EU f r nichtig WebFAT 62 Die Erweiterung zeigt sich anhand der Testfall Instanz im Metamodell von ScatterFacto ry2 vgl Abbildung 89 im Anhang 11 4 Die Testfall Instanz steht dann f r einen konkreten mit Visual ScatterUnit entwickelten Testfall der mit der Laufzeitumgebung von ScatterFac tory2 verkn pft werden muss um die Integration beider zu erreichen 84 sen wird Dies zeigt Abbildung 47 eines erweiterten Diagramms von ScatterFacto ry2 das veranschaulicht wie die Assoziation zwischen dem Testfall und der Lauf zeitumgebung unter Betrachtung der beteiligten Sensorknoten vonstatten geht E TestCollectionProcess TestCase 12 a 3 Measures sensory data E and sends ittoa B NodeA MSB a NodeB MSB Stores the data received DataSink application by DataSource instance application instances on the SD card J DataSource Application J DataSink Application Driver to access Driver to access the several sensors on board SD card SensorBoard Library D SD Library 19 scatterweb Library CC1020 Library Abbildung 47 Eine Laufzeitumgebung mit einem assoziierten Testfall Kame08 Wie aus dem obigen Modell ersichtlich wird ist der mittels Visual ScatterUnit ent wickelte Testfall TestCollection Process mit den jeweiligen Instanzen der Knotenlauf zeitkonfigurationen NodeA und NodeB verbunden Diesen Verbindungen werden dann konkrete Sensorknoten a
26. rungen gerecht zu werden und unerw nschte Einflu nahmen zu vermeiden Ausschlaggebend ist dabei die m glichst minimale Beanspruchung des Funkka nals Dies ist vor allem durch eine Minimierung der Anzahl der versendeten Nach richten durch local logging das unten erl utert wird zu erreichen Jeder Sensor knoten verf gt aus diesem Grund schon vor Beginn der Ausf hrung des Testfalls ber eine vorkonfigurierte Menge von sogenannten Steuerbefehlen Solche Steuerbe fehle k nnen verschiedene Funktionen zur Testdurchf hrung durchf hren wie bei spielsweise den Aufruf einer Prozedur um ein Paket mittels eines zu testenden Rou tingprotokolls zu versenden bzw auf den Empfang eines Pakets zu lauschen Weite re Funktionen solcher Steuerbefehle k nnen die Aktivierung entsprechender Proze duren der Dienste von ScatterUnit sein um deren Funktionalit ten zum Zwecke der Testdurchf hrung in Anspruch zu nehmen wie z B bestimmte Dienste zu Simulati on und Protokollierung Um die Testdurchf hrung auf Basis des Testfalls automatisiert auf Sensorebene auszuf hren werden die notwendigen Aktionen zur Bewerkstelligung des dem Test unterliegenden Testfalls sowie zur Inanspruchnahme der Testinfrastrukturdienste in entsprechende Steuerbefehle berf hrt Solche Steuerbefehle werden wie oben erw hnt durch ein spezielles auf dem Sensorknoten laufendes Skript realisiert Da her haben solche Testskripte vor allem die Aufgabe die Ausf hrung des Tes
27. vorhandene L sungen zum Softwaretest drahtloser Sensorknoten besprochen andererseits sind modellgetriebene Testwerkzeuge unter die Lupe zu nehmen bei denen der Fokus auf dem Aspekt der Modellierung und Automatisierung liegt Hierbei wurde die schnell wachsende Komplexit t der eingesetzten Modellierungstechniken festgestellt welche einen Engpass darstellt Es wurde deutlich gezeigt welchen Vorteil eine purpose built Dom nensprache mit sich bringt 145 Ferner wurden einige modellgetriebene Werkzeuge f r drahtlose Sensornetze besprochen die sich lediglich mit der Anwendungserstellung besch ftigen ohne den Testprozess solcher Anwendungen in Betracht zu ziehen Solche Arbeiten wurden abschlie end vorgestellt und diskutiert wobei deutlich wurde inwiefern ScatterClipse sich von diesen unterscheidet Alle vorgestellten WSN Werkzeuge haben eines gemeinsam Die Integration eines automatisierten Testprozesses in den Prozess der Anwendungsentwicklung wird nicht unterst tzt Dies ist ein pr gnantes Merkmal der ScatterClipse Werkzeugkette mit dem sie sich von anderen abgrenzt 146 10 Fazit und Zusammenf hrung Mit zunehmender Vielfalt und Komplexit t des Einsatzes drahtloser Sensornetze steigen die Anforderungen an die auf den Sensorknoten laufende Software Je anspruchsvoller die Verwendung solcher ressourcenschwacher Netze wird desto robuster zuverl ssiger und effizienter muss die Entwicklung ihrer Softwareanwendungen vonstat
28. 3 Die Codegenerierung Nach Beendigung der Modell Validierung ist gew hrleistet dass die formalen Mo delle weder die syntaktischen noch die semantischen Randbedingungen der unter liegenden Dom ne verletzen Erst danach wird der Codegenerierungsprozess ange sto en indem die f r das Modell ben tigten Templates eingebunden werden Wie in 2 5 beschrieben beinhalten die Templates des oAW Rahmenwerks die notwendigen Anweisungen um die Codegenerierung zu steuern Dies bewirkt dass die zum jewei ligen Modell geh renden Codeartefakte aus den Templates emmitiert und zusam mengef gt werden So erzeugt beispielsweise das folgende Template vgl Pro grammauszug 8 die Initialisierungsroutine zur Topologie nderung des WSNs vgl 3 3 um den Testfall des DSDV Routingprotokolls anzusto en lt lt DEFINE mainFile FOR Integer gt gt lt lt FILE main c gt gt include main h bool Test SetUp lt lt IF changingTopology gt gt PosSim on lt lt ENDIF gt gt return True lt lt ENDFILE gt gt lt lt ENDDEFINE gt gt Programmauszug 8 Template der Initialisierungsroutine zur Topologie nderung des WSNs Ka me08 62 Die f r die Topologie nderung zust ndige SetUp Methode wird in die Zieldatei main c geschrieben Die Methode liefert einen wahren Wert und veranlasst die Topo logie nderung im Fall dass die changingTopology Anweisung ebenfalls als wahr ausgewertet wird Dies f hrt
29. 5 3 Die Modellvalidierung Analog zu Visual ScatterUnit basiert die Livevalidierung in ScatterFactory auf der Zusammenarbeit zwischen dem oAW Generator und dem EMF GMF Editor die durch den oAW GMF Adapter vgl 2 5 erreicht wird Ebenfalls wie bei Visual Scat terUnit erfolgt die Formulierung der Randbedingungen mittels der vom oAW Rahmenwerk unterst tzten Checks Sprache F r ScatterFactory wurde das Plugin ScatterValidator entwickelt um die definierten Checks Ausdr cke mit dem Editor zu verbinden Hierzu erweitert das Plugin mittels der Klasse ScatterWebValida teAction den Erweiterungspunkt Extension Point des EMF Metamodells org eclipse emf validation constraintProviders um den oAWConstraintsProvider Damit stellt die Klasse die notwendigen Methoden zur Verfiigung um dem EMF GMF Editor einen Zugang auf die im Ordner scatterweb chk abgelegten Checks Ausdr cke zu verschaffen damit diese gegen jegliche Modell nderungen im Editor berpr ft werden k nnen Konzeptionell handelt es sich bei den spezifizierten Checks Ausdr cken um zwei Kategorien Bei der ersten befassen sich die Ausdr cke mit der berpr fung von syntaktischen Bedingungen der Dom nensprache Mit anderen Worten die Zielset zung ist es zu gew hrleisten dass die Modellelemente richtig editiert werden Bei der zweiten Klasse in der Regel die umfangreichere der Checks Ausdr cke geht es um semantische Aspekte der Dom ne Hierbei wird die Modellierung gegen do
30. 94 LEDs movement microphone vibration N battery temperature Abbildung 56 Visualisierung der Sensorknoten im Main View Mysl06 Dies ist optimal wenn das WSN aus einer gro en Anzahl von Knoten besteht und der Benutzer die Visualisierung aller Sensoren nicht berblicken kann So wird es dem Benutzer erm glicht die f r ihn nicht relevanten Knoten punktorientiert darstellen zu lassen und so seinen Fokus auf diejenigen Knoten zu legen die seine momentane Fragestellung betreffen Die punktorientierte Darstellung optimiert auf diese Weise die Interaktion mit dem Benutzer und tr gt durch die selektive Visualisierung wesentlich zu einer h heren Effizienz bei der rechenaufwendigen grafischen Darstellung der Knoten bei 6 4 Das Statistik View Mit Hilfe des Statistik Views k nnen die von den Sensorknoten erfassten Daten statistisch analysiert und entsprechend mathematisch visualisiert werden In bestimmten Szenarien ist es sehr hilfreich die von einem Sensor erfassten und bearbeiteten Daten statistisch zu analysieren um R ckschl sse auf die Messgenauigkeit der Sensorik der einzelnen Sensorknoten ziehen zu k nnen Dem gem kann ein Ausrei er in einer Serie aufeinander folgender Messwerte eines Sensorknotens ein Hinweis darauf sein dass die Sensorik des Knotens zum betroffenen Zeitpunkt fehlerhaft gemessen hat Die H ufigkeit des Auftretens solcher Ausrei e
31. Ausf hrung der Anwendung notwendig ist eine zentrale Rolle Das Ziel ist dabei genau den Code automatisiert zu generieren der f r die Anwendung relevant ist Zu diesem Zweck muss die Codegr e bei den durch ScatterFactory und ScatterFactory2 erstellten Anwendungen genauer untersucht werden Was die Testautomatisierung anbelangt muss sich die Bewertung auf zwei Ebenen beziehen Einerseits ist der erzielte Automatisierungsgrad bei der Erstellung der Testf lle mit Hilfe von Visual ScatterUnit von gro er Wichtigkeit anderseits ist der von ScatterUnit ben tigte Verbrauch an Betriebsmitteln zur Bereitstellung der Testautomatisierungsdienste auf Sensorebene relevant Hier muss vor allem die durch ScatterUnit verursachte Instrumentierung der Laufzeitumgebung der Sensorarchitektur genauer unter die Lupe genommen werden 8 1 Die Codegr e der in ScatterFactory erstellten Anwendungen Wie bereits geschildert dient die modellgetriebene Codegenerierung bei der Anwendungsentwicklung auch der ma geschneiderten Codeerzeugung die nur so viel Code f r die Sensorknoten erzeugen soll wie f r deren jeweilige Rolle erforderlich ist Dadurch wird nicht nur der knappe Speicherplatz optimiert sondern zugleich unn tige rechen und energieintensive Softwaremodule vermieden Der sinkende Anteil an manuellem Code reduziert zugleich die Gefahr von Fl chtigkeitsfehlern der Programmierer Im Folgenden werden drei repr sentative mit Hilfe von ScatterFactory er
32. ControlPath testcase ControlPath this branch target getDeploymentIdForFirstAction this deploymentld true context testcase BranchingPoint ERROR A branching point must only be linked to control pathes which are executed on different sensor nodes this branch null amp amp this branch target metaType testcase SyncNode List testcase ControlPath testcase SyncNode this branch target outgoing t arget select ele metaType testcase ControlPath getDeploymentIdForFirstAction notExists e e this deploymentlId true context testcase Assertion 164 ERROR An assertion must at least apply one log label hasReferencedLogLabels this referencedLogLabels context testcase Assertion ERROR Log labels referenced by an assertion must be provided by log actions this validateReferencedLogLabels context testcase SyncNode ERROR A sync node must have at least one incoming link this incoming size gt 0 context testcase SyncNode ERROR A sync node must have at least one outgoing link this outgoing size gt 0 context testcase SyncNode ERROR A sync node must not be linked to another sync node this outgoing target select e e metaType testcase SyncNode size 0 context testcase SyncNode WARNING A sync node should have at least two both incoming or both outgoing links this incoming
33. Der Pfad des automatisierten Anwendungstests in ScatterClipse ist durch das ge nerative modellgetriebene Rahmenwerk Visual ScatterUnit realisiert Kame07 Kame08 Das Rahmenwerk stellt ein umfassendes Verfahren zur Verf gung das Komponenten und Systemtests der auf den Sensorknoten laufenden Anwendungen 26 Ubiquitous computing ubicomp is a post desktop model of human computer interaction in which information processing has been thoroughly integrated into everyday objects and activities As opposed to the desktop paradigm in which a single user consciously engages a single device for a specialized purpose someone using ubiquitous computing engages many computational devices and systems si multaneously in the course of ordinary activities and may not necessarily even be aware that they are doing so WebPerv 27 Home automation also called domotics is a field within building automation specializing in the specific automation requirements of private homes and in the application of automation techniques for the comfort and security of its residents Although many techniques used in building automation are also used in home automation additional functions in home automation can include the control of multi media home entertainment systems automatic plant watering and pet feeding automatic scenes for dinners and parties and a more user friendly control interface WebHome 26 automatisiert erm glicht Um nun den oben
34. Empfang der Nachricht wird durch die Methode received bewerkstelligt Gem dem modularen Aufbau der Node Klasse korrespondiert jede empfangene Nachricht mit einem in der Node Klasse vorhandenen Modul durch das die Nachricht bearbeitet wird Eine solche Nachricht bewirkt in der Regel die Anderung der Attribute eines Moduls Infolgedessen feuert das betroffene Modul ein Ereignis vom Typ NodeEvent Jedes Objekt bzw jede Schnittstelle in der Emulationsinfrastruktur die dieses Ereignis implementiert wird nun tiber die sich eben ereignete Wirkung der Nachricht benachrichtigt und kann entsprechend darauf reagieren Ein weiterer hilfreicher Aspekt beim Nachrichtenaustausch in ScatterWeb for Java ist die F higkeit den Nachrichtenverkehr zu protokollieren loggen Hierzu wurden diverse f r diesen Zweck hilfreiche Java basierte Technologien eingesetzt Es handelt sich hier um zwei Kategorien von Daten die protokolliert werden Einerseits muss der gesamte Datenverkehr der vom Netz versendeten bzw empfangenen Nachrichten protokolliert werden andererseits muss der sich durch die Wirkung dieses Nachrichtenaustausches st ndig ndernde Status des Sensornetzes mit s mtlichen Entit ten eGate Knoten usw protokolliert werden F r ersteres wird Log4j WebLog4j von Apache verwendet wodurch die zu protokollierenden Nachrichten nach einem zuvor vom Benutzer in einer zentralen Datei festgelegten Format abgelegt werden die in der Log4j mit Properties
35. FinalNodeOfTheTestCase H CustomControlAction TopologyChangeAction links 1 1 source H ActivityNode yn f t target incoming controlPathes outgoing subLinks H ControlNode 0 sublnitialNode E ControlPath H BranchingPoint name 0 0 1 H InitialNodeOfAControlPath subFinalNode sensorNodes 0 branchingPoints H SensorNode deploymentid H FinalNodeOfAControlPath 0 1 H AwaitRadioPacketAction H CustomEvent H RadioPacketReceivedEvent oppositeNode sendingNode reportedBy applyOn addressedNode enable packetType timeoutinMilliseconds applyAdditionalChecking eventProcessingTime ConnectionEnd LOCAL_NODE en TEMPORAL RELATION BOTH_NODES BEFORE AFTER 0 H Link 0 0 0 ActionNode name controlActions H ControlAction H Event H LogAction H Assertion logLabel referencedLogLabels 0 0 0 0 events logActions assertions H RadioPacketLogAction detail H CustomLogAction RadioPacketDetail HEADER_ONLY DATA_ONLY ALL Abbildung 89 Das Metamodell der DSL zum automatisierten Anwendungstest in Visual ScatterUnit Kame08 161 11 5 Die in Checks formulierten Randbedingungen 11 5 1 Randbedingungen in Visual ScatterUnit Im Folgenden wird eine breite Auswahl der in Visual ScatterUnit definierten Checks Ausdr cke aufgelistet Kame08 Die in den Ausdr cken vorkommenden Modellvariablen beziehen sich auf di
36. IT Spezifikationen f r allgemein kompatible bertragbare und 153 wiederverwendbare Unternehmensanwendungen in verteilten und heterogenen Umgebungen Mitglieder sind sowohl Verk ufer von Informationstechnologie Endbenutzer Regierungsbeh rden als auch Hochschulen WebOMG Remote Method Invocation RMI RMI bietet ein einfaches und direktes Modell f r verteilte Anwendungen mit Hilfe von Java Objektinstanzen Java unterst tzt das Einmal Schreiben berall Verwenden Modell RMI erweitert das Java Modell damit es entfernt in Anspruch genommen werden kann Da von den technischen Details der Verteilung abstrahiert wird versetzt Java RMI den Entwickler in die Lage auf einfache Art verteilte Java basierte Klient Server Anwendungen zu erstellen WebRMI Software Entwicklungsprozess Ein spezielles Vorgehensmodell das der Steuerung der Softwareentwicklung von der Konzeption bis zum Einsatz im Echtbetrieb inklusive der im Echtbetrieb anfallenden Anpassungen einer Software dient Beispiele sind Wasserfallmodell Spiralmodell Rational Unified Process RUP modellgetriebene Softwareentwicklung gt MDSD etc WebEntwicklungsprozess Testfall In der Softwareentwicklung ist ein Testfall ein Set von Bedingungen oder Variablen unter denen ein Tester bestimmt ob eine Anwendung oder ein Softwaresystem korrekt arbeitet oder nicht Der Testfall realisiert das vom Softwaretester entworfene Testszenario Es kann eine Vielzahl von Testf
37. Mit anderen Worten die Informationen zur Reihenfolge der verteilten Ausf hrung der Aktionen sowie deren Zuordnung zu den jeweiligen Knoten m ssen aus dem Testszenario hervorgehen damit auf dieser Basis der zugeh rige Testfall konkretisiert werden kann Um den Testfall zu implementieren sind f r die Testschicht des Rahmenwerks ScatterUnit zwei Module genannt node scripts vonn ten die auf den jeweiligen Sensorknoten ausgef hrt werden Die Skripte werden aus dem formalen Modell des 28 Siehe Glossar 27 zugeh rigen Testfalls mit Hilfe des Codegenerators automatisiert generiert Jedes dieser Skripte simuliert die von einem Sensorknoten in Abh ngigkeit von seiner Rol le erfassten Daten Demnach simuliert das auf dem ersten Sensorknoten ausgef hr te Skript die Daten der folgenden Aktion Die Person betritt den ersten Raum und schaltet die Anlage an Das auf dem zweiten Knoten laufende Skript simuliert die Aktion dass die Person den ersten Raum verl sst und den zweiten betritt Um die Reihenfolge des Auftretens der voneinander abh ngigen Aktionen zu gew hrleisten muss der Ablauf der Aktionen nach ihrem Eintreten koordiniert werden Die Erstel lung des dazu ben tigten Codes wird nun gem dem modellgetriebenen Paradigma an den Codegenerator des Visual ScatterUnit Rahmenwerks delegiert Der Code wird aus dem formalen Modell des Testfalls generiert der den Verlauf des Testszenarios repr sentiert Abschlie end werden die von
38. Modellvalidierung Gebrauch gemacht wird Import Example Context Bicycle ERROR Fahrr der m ssen einen Fahrer haben Bicycle eContents driver lt gt Null Programmauszug 1 Ein einfacher Checks Ausdruck Hent06 Innovativ ist die Unterst tzung von just in time Validierung bzw Live Validierung des Modells anhand der daran gebundenen Checks Randbedingungen Dies wird durch den GMF Adapter erm glicht den oAW seit der Version 4 1 anbietet Dabei ist es m glich durch einen Watchdog jegliche nderung der Modellkonstrukte im Editor zu berwachen und w hrenddessen in Abh ngigkeit der vollzogenen Modell nderungen die Einhaltung der zentral gehaltenen Checks Randbedingungen zu berpr fen Abbildung 10 zeigt die bei der Live Validierung beteiligten Architektur komponenten bindet verwendet Per ruft auf Visueller Editor GMF Adapter a Randbedingungen generiert mit GMF geliefert von oAW omponen Checks Ausdr cke geliefert von oAW Abbildung 10 Die Architektur der Live Validierung Nun kann die Codegenerierung angesto en werden indem aus den Templates je weils der f r die Modellkonstrukte korrespondierende Code emitiert wird Als Temp late Sprache wird in oAW Xpand WebXpand eingesetzt eine einfache deklarative Skript Sprache Der Inhalt der Templates kann beliebig sein So k nnen unter schiedliche Softwareartefakte automatisiert aus den Templates generiert werden variierend vom Code hoher
39. Programmiersprachen bis zu Makefiles und Konfigurati onsdateien 19 Durch die Import Anweisung kann das betreffende Metamodell importiert werden das im obigen Beispiel in Abbildung 9 Example hei t 20 Dies ist die Fehlermeldung die im GMF Editor visuell w hrend der Live Validierung an gezeigt wird Dies ist m glich dank des GMF Adapters der seit oAW Version 4 1 unterst tzt wird 21 Analog zu Checks bietet oAW einen gesonderten Editor f r Xpand mit Codevervollst ndi gung und dem Hervorheben von Syntaxelementen 19 Die Sprache bietet verschiedene Funktionalit ten um den Generierungsprozess zu optimieren Ein Feature wurde jedoch absichtlich ausgelassen die Bestimmung der Terminierung des Generierungsprozesses die beim Entwurf von Xpand auf die Checks Ebene ausgelagert wurde Dass ein korrekter Code nach Beendigung des Generierungsprozesses aus dem zugeh rigen Modell entsteht ist die Aufgabe des davor erfolgten Validierungsschrittes Somit findet einerseits eine scharfe Teilung von Belangen statt anderseits wird die Struktur der Templates einfach gehalten was deren Bearbeitung z B Parsen erheblich vereinfacht Dies f hrt zu einer deut lichen Optimierung der Leistungsf higkeit der Codegenerierung An dieser Stelle ist die Behandlung der stufenweisen Einbettung der verschiede nen Validierungsrandbedingungen entlang der Ebenen der Werkzeugkette in Erin nerung zu rufen vgl Abschnitt 2 3 Wie er rtert dient die Validie
40. ScatterUnit einmalig implementiert und ins Metamodell eingebettet Daraus wird der Editor automatisiert erneut erstellt und die neuen Dienste stehen dem Nutzer in Form von visuellen Modellen in der Palette des Edi tors zur Verf gung Die Offenheit der Architektur der Testinfrastruktur steigert sich dadurch deutlich 56 manuell implementierter Steuerbefehl Steuerbefehl Anderung der Topologie entfernterSensorknoten Integer FilterAnwendenAuf lokal entfernt beide FilterAnschalten Boolean Warten auf Datenpaket Absender Integer Adressat Integer Pakettyp Integer Timeout Integer ManuellePakettyppr fung Boolean Pr fungszeitpunkt Vorher Nachher manuell implementiertes Ereignis Ereignis Empfang des erwarteten Datenpaketes manuell implementierter Protokolleintrag Protokollierung des empfangenen Datenpaketes detail Paketkopf Nutzlast Alles Protokolleintrag K Abbildung 33 Ausschnitt des attributierten Metamodells des Detaillierungsdiagramms Kame08 57 id ChangedTopology testcase_diagram 5 2 Lt iB AwatSecondPacket Await Radio Packet Action Sendina Node 1 Addressed Node 4 H PacketTvoe 101 Timeout 1 000 Additional Checkina false Processina Time AFTER F LogRadioPacket Radio Packet Log Action Loa Label SecondRadioPacket Detail ALL CheckPacketintegnty Assertion Loa Labels SecondRadioPacket Palet
41. Score Test BEN Covariance 16 20 16 30 16 40 Min 20 0 Correlation Time Roots Regression 8 Temperature Extreme Values lt lt 2006 12 19 15 47 58 609 OK 2006 12 19 16 47 58 609 gt b Wahl beliebiger statistischer Operationen sowie deren Ermittlung bzw Visualisierung im GUI Problems Javadoc Declaration Console Statistik Median 21 5 35 Temperature series 35 8 Ternperature n PPPE TITTIES Mean 21 553571428571427 e BEER BeBe ss tdunnunnn Length 28 Std Dev 0 4083784509296169 Max 22 0 Min 21 0 18 20 18 30 18 40 18 50 19 00 19 10 Time Roots m 35 Temperature 35 8Temperature Extreme Values 2006 12 20 18 04 59 188 2006 12 20 19 30 59 188 c Gruppierung mehrerer statistischen Messserien siehe 1 Abbildung 57 Merkmale des Statistik Views Mysl06 97 La 4 3 NodeListener Y Series ModuleHistory E ModifiedZScoreTest s i TimeSerieEx lt 9 ModuleHistoryListener jE JFreeChart Abbildung 58 Kommunikation zwischen Statistik View und JfreeChart Mysl06 6 5 Zusammenfassung Neben Basisdiensten wie der Konfiguration von Sensorknoten stellt ScatterPlug auch komplexe Dienste zur Verf gung wie die Emulation und Modellierung der Knoten des WSNs im objektorientier
42. Testinfrastruktur wurde allgemein f r Ad hoc Netze entworfen bei denen die Ressourcen im Vergleich zu drahtlosen Sensornetzen weniger beschr nkt sind Bei drahtlosen Sensornetzen ist hingegen zu beobachten dass die bertragung eines Pakets bei einem Sensorknoten durchaus fehlschlagen kann wenn der Funkkanal zu oft von einem anderen Knoten belegt ist Ein Grund k nnte die dadurch verursachte h ufige Kollision auf dem Funkkanal sein Daher ist ein solcher ressourcenintensiver zentralistischer Kommunikationsmechanismus nicht optimal geeignet Aus diesem Grund wurde ein dezentraler Steuerungsmechanismus zur Ausf hrung des Testverlaufs in der Testschicht ScatterUnit verfolgt um diesen unerw nschten 140 Effekt m glichst minimal zu halten Dies wurde wie erl utert vor allem dadurch erreicht dass die durch local logging protokollierten Daten erst nach dem Ende der verteilten Testdurchf hrung an die auf der Infrastruktur laufenden Pr froutinen versendet werden Ferner werden die Kontrollbefehle zur Koordination des verteilten Testverlaufs zusammen mit den Codeartefakten des Testfalls einmalig in der Form von Testskripten unmittelbar vor dem Start der Testausf hrung auf die jeweiligen Sensorknoten ausgebracht Was das SeNeTs Werkzeug anbelangt so gilt zudem dass selbst die Codierung von Testf llen auf Basis des Testwerkzeugs ein schwieriges Unterfangen bleibt Zwar wird die Durchf hrung des Tests durch das Werkzeug automatisiert bewerkst
43. Transformierung dynamisch zu binden Dadurch k nnen beispielsweise Readme Dateien mit Hilfe des Logging xpt Temp late f r den Nutzer mitgeneriert werden Die in der Workflow Datei auftretenden Elemente spiegeln die zahlreichen beteiligten Werkzeuge und Technologien wider die in diesem Kapitel behandelt wurden und aus denen die ScatterClipse Werkzeug kette aufgebaut ist Die folgende Abbildung 13 entspricht der Abbildung 2 in Ab schnitt 2 1 allerdings werden hier statt der verwendeten Konzepte im MDSD Prozess die zur Realisierung dieser Konzepte eingesetzten Rahmenwerke und Tech nologien dargestellt Um nun die Tauglichkeit dieser Rahmenwerke f r den MDSD Prozess n her zu betrachten ist es an dieser Stelle unerl sslich einen tieferen Einblick in den Ein satz der Rahmenwerke zu geben der eine aussagekr ftige Beurteilung erm glicht Dies soll anhand des Erfahrungsberichts ber ein selbst entwickeltes Rahmenwerk im folgenden Kapitel geleistet werden Dieser dient dem Zweck die Tauglichkeit der behandelten Rahmenwerke im Kontext des MDSD Prozesses zu demonstrieren und ihre Robustheit zu beurteilen Bei dem folgenden Erfahrungsbericht handelt es sich jedoch nicht um eine Beurteilung der ScatterClipse Plattform Eine fundierte Eva luation von ScatterClipse findet sich in Kapitel 8 25 Im Falle von SactterFactory handelt es sich wie erw hnt um ein mit EMF definiertes Eco re Metamodell Daher wird emf XmiReader in oAW aktiviert 23
44. WSN Model Test Case Model Application Group Connection default wsn Broadcast testcase DataSink Configure Channels Edit Create Select Edit Create Select Build amp Flash Wireless Sensor Network Code Generation Code Generation Create Edit ScatterWeb2 Test Automation Open Terminal View Select Project Generate Select Project Generate Open Tuning View Open Statistics View Node Script Sensor node 3 DataSink Select Build amp Flash Test Case Execute Load Testlog Abbildung 82 Die ScatterClipse Assembly Line Kame08 Insgesamt repr sentiert die ScatterClipse Assembly Line die Machtigkeit der Werkzeugkette gibt dem Benutzer einen berblick ber die zur Verf gung stehenden Funktionalit ten und erleichtert den Zugriff auf sie Die einfache Zugriffsm glichkeit motiviert dar ber hinaus dazu alle Werkzeuge von ScatterClipse zusammen zu benutzen Alles in allem wurde mit ScatterClipse eine neuartige Anwendung des modellgetriebenen Paradigmas auf die anspruchsvolle Dom ne der drahtlosen Sensornetze erfolgreich demonstriert Einerseits demonstriert diese Anwendung das Potential des modellgetriebenen architekturzentrierten Ansatzes und anderseits wurde gezeigt welch hoher Bedarf besteht gegenw rtig neu entwickelte Ans tze in solch sensitiven Dom nen wie drahtlosen Sensornetzen anzuwenden Der zweigleisige Einsatz der Modelle bestehend aus der Kombination der Visualisierung des Anwendungsverhaltens einerseit
45. chst werden die zu beobachtenden Messgr en im Alarmeditor 2 selektiert Die ausgew hlten Messgr en werden dann gem der vorgestellten Grammatik der Alarmsprache mittels Vergleichsoperatoren verkn pft 3 wodurch sich Alarmpr dikate bilden Dann werden den ausgew hlten Messgr en eindeutige Werte zugewiesen 3 Zuletzt wird die Zeitspanne definiert innerhalb derer das Alarmpr dikat erf llt werden muss 4 Jedes formulierte Alarmpr dikat kann mit den Operatoren OR und AND an ein weiteres gekn pft werden 5 158 11 3 5 Benutzerinteraktion im entfernten Modus Ein weiterer Aspekt zur Steigerung der Sicherheitsbelange beim Einsatz des entfernten Modus ist die Funktionalit t der serverseitigen Firewall Dies zeigt sich deutlich anhand der IP Liste 2 in der Abbildung 88 die einen Bildschirmabzug der serverseitigen Konfigurationsfunktionalit t f r die Klientenzugriffsverwaltung zeigt Java makefile xml Eclipse SDK File Edit Navigate Search Project Run Window Help wi m 30 2 86 89 ile FEY amp Java Resource aly Efe C C Problems Javadoc Declaration Search Console BRETTEN lea ScatterFlasher ScatterServer ScatterTerminal Connection Property Terminal Alarm Log OTA Flashing Server Configuration Change Password Input your Password Input new Password Save Changes Repeat new Password Set Firewall List of IPs Selection Options 1D IP Address No Filtering 1 12 12 12 12
46. dazu dass die Anweisung PosSim_on aufgerufen wird die die Aktivierung des Simulationsdiensts der ScatterUnit veranlasst Es stellt sich nun die Frage warum vor dem Aufruf von PosSim_on die Anweisung changingTopology aufgerufen wird vgl Programmauszug 9 Bei changingTopolo gy handelt es sich um eine Xtend Anweisung eine Erweiterung die vom oAW Co degenerator unterst tzt wird Das Konzept wurde bereits in 2 5 erl utert Hier findet sich ein anschauliches Anwendungsbeispiel zum Einsatz dieser Erweiterun gen wodurch die Codegenerierung effizienter vonstatten geht Der Auszug zeigt die Implementierung der changingTopology Erweiterung Dadurch wird im zugrunde liegenden formalen Modell berpr ft ob sie die Entit t vom Typ TopologyChan geAction enth lt wodurch der Code zur Inanspruchnahme des Simulationsdiens tes generiert wird Ist dies der Fall wird PosSim_on aufgerufen um den Dienst zu aktivieren Somit wird deutlich welchen Beitrag Erweiterungen hinsichtlich der Modellanalyse zum Zweck der Steuerung der Codegenerierungsdirektiven leisten Boolean changingTopology model controlPathes sensorNodes controlActions exists e e metaType TopologyChangeAction Programmauszug 9 Definition von gesch tzten Bereichen innerhalb des Templates Kame08 Insgesamt wird also mittels Xtends die Xpand Sprache auf eine modulare Weise o perativ erweitert so dass die Funktionalit ten von Xtends separat und ohne
47. den verschiedenen Sensorknoten ausgef hrt werden Um die richtige Reihenfolge der Befehle beizubehalten muss die verteilte Ausf hrung der Testskripte koordiniert werden Anschlie end muss der Benutzer nach der Testdurchf hrung die geloggten Testergebnisse manuell im textuellen Protokoll berpr fen um seine Hypothesen hinsichtlich der Fehlerursache treffen zu k nnen Es liegt nun auf der Hand die Automatisierung weiter zu treiben indem solche komplexen und fehlerfl chtigen T tigkeiten an einen Codegenerator gem dem modellgetriebenen Paradigma delegiert und somit dem Entwickler abgenommen werden Aufgrund der steigenden Komplexit t des Einsatzes von Sensorknoten und der auf ihnen laufenden Anwendungen bedarf die Testdurchf hrung einer ad quaten Abstraktion von den technischen Belangen Dies ist durch die Verwendung ausf hrbarer visueller Modelle m glich aus denen einerseits die n tigen Codefragmente zur Testdurchf hrung generiert werden und durch die andererseits das Verhalten der zu testenden Anwendung visuell dargestellt wird Durch die mit dem Einsatz ausf hrbarer formaler Modelle erzielte Abstraktion werden die komplexen Anforderungen beherrschbarer Um ScatterUnit um diese Merkmale zu erg nzen wurde das architekturzentrierte modellgetriebene Rahmenwerk Visual ScatterUnit entwickelt mit dessen Hilfe das Testszenario als formales Testfallmodell repr sentiert werden kann ohne dass die verteilte Ausf hrung der auf den Sensork
48. der Fokus breiter auf die Wirkung der Live Validierung gerichtet werden Es sind 136 unter 58 schiedliche Checks Ausdr cke in Visual ScatterUnit definiert worden die gemein sam eine umfassende Beherrschung der Charakteristika der unterliegenden Dom ne auf hoher abstrakter Ebene n mlich der DSL erm glichen Da selbstverst nd lich nicht auf jeden einzelnen Ausdruck eingegangen werden kann werden im Fol genden pr gnante Randbedingungen sowie deren Effekte diskutiert So wird beispielsweise durch die Definition des folgenden Checks Ausdrucks ge w hrleistet dass Bezeichner von Aktivit ten im Modell keine Sonderzeichen enthal ten vgl Abbildung 35 und Programmauszug 5 4 The name must only contain alphabetic and numeric letters Abbildung 35 Live Validierung deckt den ung ltigen Namen einer Aktivit t auf context testcase ControlPath ERROR The name must only contain alphabetic and numeric letters this name matches p Alpha p Digit Programmauszug 5 Checks Ausdruck zur syntaktischen Priifung Kame08 Eine solche Einschr nkung ist unerl sslich da die Namen der Aktivit ten des Mo dells in den Methodennamen im generierten Code vorkommen W rde dies zur Mo dellierungszeit der Live Validierung nicht berpr ft lie en sich die betroffenen Me thoden nicht kompilieren Hier sieht man erneut wie die Modell Validierung im Kontext des modellgetriebenen Paradigmas we
49. der Software Deployment Im ersten Teil der Abbildung 85 von ScatterFlash wird der package explorer gezeigt in dem die aus dem automatisierten Codegenerierungsprozess resultierenden Dateien abgelegt werden 1 In 2 sieht man den Editor des Plugins in dem der Code der Sensorknoten bearbeitet werden kann W hrend der Bearbeitung werden verschiedene Dienste durch das ScatterFlash Plugin zur Hilfestellung angeboten So ist es m glich den Quellcode durch Hervorheben von Syntaxkomponenten zu editieren Fehlermeldung werden w hrend des Kompilierungsprozesses im Konsolefenster von Eclipse angezeigt 4 Des Weiteren wurde das ANT Plugin in ScatterFlash als Standardkomponente integriert 3 um eine bessere Handhabung der Kompilierung und Ausbringung des Codes in die Sensorknoten ber die serielle Schnittstelle zu erreichen Java ScatterWeb Event c Eclipse SDK File Edit Refactor Navigate Search Project Run Window Help Clee fm i O Q i Be oG OAF HE Package Explorer 2 Hierarchy O fel Scatterweb Event c os La Scatterweb Event h Y Loads application config from EEPROM Ox0000 EEPROM sizeof appcon Te scatterweb void appconfig_load S E Applications IO_read EADR_APPCONFIG UINTS sAppConfig sizeof appconfig_t S E EMPTY 3 G amp ECR clean flash E eGate Saves application config AppConfig to EEPROM O0x0000 EEPROM sizeo S S ESB void appconfig_save S E ess IO_write EADR_APPCONFIG
50. deren Hilfe gewisse Abl ufe simulativ vonstatten gehen k nnen zur Verf gung stellen um den Entwicklungsprozess leistungsf higer zu gestalten berwachungsfunktionalit ten durch die das Verhalten der Knoten und deren Umgebung n her beobachtet werden kann werden ebenso als unerl lich eingestuft Weiterhin wird ein ad quater Kompilierungsprozess der zus tzlich durch Debugging Funktionalit ten unterst tzt wird als unverzichtbar f r die Robustheit und die korrekte Ausf hrung der zu entwickelnden Anwendungen angesehen Eine Reihe weiterer Komponenten wird genannt die die Architektur der Werkzeuge mitliefern muss um den Entwicklungsprozess abzurunden Die Werkzeuge sollen den entsprechenden Editor f r die visuelle Modellierung bzw textuelle Anwendungscodierung mitliefern die Ausbringung der Codeartefakte auf die Sensorknoten erm glichen einen Projekt Manager zur Verwaltung der Dateien der erstellten Anwendungen sowie einen Burner zur Verf gung stellen mit dem aus den verschiedenen kompilierten Quelldateien ein gemeinsames ausf hrbares Codegef ge Code Image automatisiert erstellt werden kann Dies ist die Voraussetzung daf r die Codeartefakte auf die jeweiligen Sensorknoten ausbringen zu k nnen Im Folgenden werden die einzelnen Werkzeuge die in der Studie ber cksichtigt wurden beurteilt Burr et al von der ETH Z rich stellten im Juni 2006 YETI vor Burr06 YETI ist analog zu ScatterClipse eine auf Basis von Eclipse erst
51. dies der Fall muss der zweiten M glichkeit nachgegangen werden indem berpr ft wird ob eine Beeintr chtigung bei der Da ten bermittlung zur Senke vorliegt Angenommen es handelt sich bei der Fehlerur sache um die erste M glichkeit so wurde derjenige Teil der Anwendung identifi ziert auf den das Versagen zur ckzuf hren ist Dies ist dasjenige Segment des An wendungscodes das f r die Datenerfassung bzw Speicherung der aufgenommenen Daten zust ndig ist lt Testfall im plementieren Testfall ausf hren Defekt bereinigen Defekt lokalisieren Kein Versagen aufgedeckt Abbildung 25 Iterative Vorgehensweise bis der Fehler im Code aufgefunden wurde Kame08 Versagen aufgedeckt Nun kann der Fokus noch feink rniger gelegt werden indem die Fehlerlokalisierung weiter geteilt und berpr ft wird ob es an dem Modul der Speicherung oder dem denen zur Datenerfassung liegt 3 Diese Vorgehensweise wird nun sukzessiv betrieben bis schlie lich die Fehlerursache im Code lokalisiert wurde Der Prozess der Fehlerisolierung im Implementierungscode der Anwendung ist eine recht anspruchsvolle kognitive Aktivit t die stark auf den Annahmen des Tes ters beruht Der Tester stellt Hypothesen bez glich des Fehlers auf und verifiziert diese iterativ Xu04 Danach wird entsprechend dem Teile und Herrsche Ansatz vorgegangen wobei bei jeder vom Tester aufgestellten Hypothese eine Iterationsstu fe
52. different characteristics and properties of WSN visually and interactively In order to improve the platforms productivity its main features can be accessed in local as well as in remote or internet based mode The eclipse based plug in oriented architecture encourages the enhancement of the toolchain when new questions concerning WSN arise On the one hand the user can operate certain plug ins functionalities independent from each other so that a separation of concerns is achieved and on the other hand the user can navigate the different plug ins collaboratively at the same time whereby coherence is achieved ScatterClipse is based wholly on open source components which are available at no extra cost Inhaltsverzeichnis 1 Einleitung 1 1 _ Forschungsdiskussion und Anforderungen 1 2 Zielsetzung und Vorhaben 1 3 Aufbau der Arbeit I Allgemeines 2 Verwendete Technologien und Werkzeuge 2 1 Das architekturzentrierte modellgetriebene Paradigma 2 2 Die Eclipse Plattform 2 3 Das Eclipse Modeling EMF 2 4 Graphical Modeling GMF 2 5 openArchitectureWare 0A W 2 6 Zusammenfassung II Die generative Infrastruktur 3 Der Pfad des Anwendungstests Visual ScatterUnit 3 1 Architektur des Rahmenwerks Visual ScatterUnit 3 2 Die Testautomatisierungsschicht ScatterUnit 3 3 Die Implementierung des Testfalls in ScatterUnit 3 4 Modellgetriebenes Testen in Visual ScatterUnit 3 5 Der visuelle automatisierte Debuggingp
53. dikate strukturiert ist 1 Dieser Ausdruck steht f r eine regul re Randbedingung mit einer vorgegebenen Zeitspanne 2 Dieser zusammengesetzte Ausdruck besteht aus der Verkn pfung mehrerer Alarmpr dikate 3 Bei diesem rekursiven Ausdruck werden die Alarmrandbedingungen verkettet Constraint vn alarm 8 irem 2 from 12 00 to 23 00 Condition Timeperiod Constraint alarm 8 ha cash i Condition 108 Constraint Constraint I a 3 alarms temp gt 20 rom 12 00 to 23 00 vibr detect Condition Timeperiod Condition Abbildung 66 Drei rekursive Ausdriicke der Alarmsprache Ding07 7 3 Internetintergration in ScatterEditor Sensornetze werden oft in Gebieten eingesetzt zu denen Menschen nur einen begrenzten Zugang haben wie z B Naturreservate oder Regionen in einem extremen Klima u 4 Es erscheint daher sinnvoll ScatterEditor mit dem Internet zu verbinden um den Zugriff auf die ScatterEditor Dienste durch einen oder mehrere entfernte Rechner zu erm glichen Zur Realisierung der Internetintegration wird wie zu Beginn des Kapitels besprochen eine herk mmliche IP basierte Klient Server Architektur auf Basis der Java RMI Technologie verfolgt Zu diesem Zweck wurde ein eGate Server implementiert der auf einem entfernten Rechner l uft und fiir den berechtigten Klienten zugriffsbereit ist An diesen Rechner ist auch die eGate Hardware direkt angeschlossen Der Server bernimmt somit die di
54. durch den sie unmittelbar in der Eingabeleiste zur Verf gung stehen 65535 rid 65535 rid Stack B i 65535 rid swr 5 swg 3 w Stack A Stack B Abbildung 64 Stapeldatenstruktur zur Verwaltung der bereits eingegebenen Befehle Ding07 65535 rid 7 2 4 Aktualisierung der Softwaremodule via Funkkanal Over The Air Software Updates Wie in 3 4 erl utert bedingt der kognitive iterative Debuggingprozess im Rahmen des modellgetriebenen automatisierten Testprozesses eine mehrfache Verfeinerung des Testfallmodells wobei bei jedem Verfeinerungsschritt der korrespondierende auf den Sensorknoten auszuf hrende Infrastrukturcode neu generiert wird Dieser Proze wird durch eine flexible Ausbringung des neu generierten Codes auf die jeweiligen Sensorknoten auf denen das verfeinerte Testszenario ausgef hrt wird abgerundet Darin besteht die Funktionalit t des Over The Air Flashing Reiters Ebenfalls kommt die Funktionalit t des OTA Flashing dem Generat von ScatterFactory zu Gute wodurch die automatisiert generierten Codeartefakte der im Editor modellierten Anwendungen optimal an die ihnen im Modell zugewiesenen Sensoren ber den Funkkanal ausgebracht werden Wie in 5 6 geschildert k nnen in einem einzigen Modell der DSL mehrere Anwendungen zusammen formal modelliert werden wobei deren Code jeweils generiert wird Es w re daher sehr praktisch wenn der Benutzer in die Lage v
55. eine Aktivit t keinen Vorg nger besitzt context testcase ControlPath ERROR A control path must have one incoming link this incoming size 1 context testcase ControlPath ERROR A control path must have at maximum one outgoing link this outgoing size lt 1 context testcase TestCaseDiagram ERROR Exactly one initial node must exist this initialNode null context testcase InitialNodeOfTheTestCase ERROR The initial node must not have any incoming links this incoming size 0 context testcase TestCaseDiagram ERROR Exactly one final node must exist this finalNode null context testcase FinalNodeOfTheTestCase ERROR The final node must not have any outgoing links this outgoing size 0 Programmauszug 6 Checks Ausdruck zu Abbildung 36 Kame08 60 Des Weiteren werden parallel laufende Abl ufe w hrend des Testfalls erm glicht Dabei muss jedoch beachtet werden dass jeder individuelle Sensorknoten aus tech nischen Gr nden keine parallele Abarbeitung der auf ihm laufenden Prozesse un terst tzt Daher k nnen verschiedene f r den Test n tige simultane Aktivit ten nur auf unterschiedlichen Sensorknoten verteilt ausgef hrt werden Demgem muss die Live Validierung gew hrleisten dass parallel laufende Aktivit ten im Aktivit tsdiagramm unterschiedlichen Sensorknoten zugewiesen sind vgl Abbil dung 37 und Programmauszug 7 The control path
56. eine optimierte Automatisierung der Codeer 5 Architecture Centric Model Driven Software Development AC MDSD 6 Siehe Glossar 7 Siehe Glossar 8 Siehe Glossar CIM Computation Independent Model Grundlage f r PIM Platform Independent Model wee ape Mapping _ Mapping pa S a a PSM PSM Platform Specific Model Platform Specific Model Mapping Oe Mappings d SK de A EDM A EDM e Code Gener g Code Gener g t Enterprise Deployment Model en u Enterprise Deployment Model Code Generierun3 Pr Code Generierung Plattform Plattform NET Java Abbildung 1 Der MDA Prozess Hent06 stellung Zugleich wird die Steigerung der Softwarequalit t durch eine erh hte Wie derverwendbarkeit der Codeartefakte angestrebt Daher liegt wie der Name zum Ausdruck bringt das Hauptaugenmerk auf der unterliegenden Dom ne Architektur f r die gezielt modelliert wird Folglich wird im Gegensatz zu MDA anstelle der Generierung derselben Softwareartefakte f r unter schiedliche Plattformen die automatisierte Generierung vielf ltiger Softwarevariati onen Softwarefamilien einer bestimmten Dom ne angestrebt Das Ziel architek turzentrierter modellgetriebener Softwareentwicklung lautet also Ganzheitliche Automation bei der Erstellung von Infrastrukturcode bzw Minimierung von redun dantem technischem Code in der Anwen
57. gt gt Das f r ein Modellkonstrukt emittierte Artefakt wird innerhalb des Blocks der Anweisung DEFINE gehalten In dem Beispieltemplate in Abbildung 11 wird Java Code generiert und in einer Datei ausgeschrieben die nach der Konvention von Java denselben Namen wie die Klasse hat Dies wird durch die Anweisung FILE bewerkstelligt Der Name wird dabei dynamisch be stimmt Im Beispieltemplate wird der Name der Klasse durch das entsprechende Attribut im Modellkonstrukt bestimmt Des Weiteren ist es durch die EXPAND Anweisung m glich dass ein Template von einem anderen aufgerufen wird was deren Verschachtelung w hrend des Gene rierungsprozesses erm glicht Ferner k nnen mit der Sprache Xtend 2 WebXtend formulierte Erweiterungen Extensions durch die EXTENSION Anweisung in ein Template dynamisch eingebettet werden 2 Erweiterungen sind ein weiteres n tz 22 Analog zu Checks und Xpand bringt oAW einen extra Editor f r Xtend Anweisungen mit Funktionen zum Vollst ndigen von Code und dem Hervorheben von Syntaxelementen 23 Mit Xtends formulierte Anweisungen k nnen ebenfalls in Checks Bl cke eingebettet wer den 20 D Main xpt amp 3 q o j 8z Outline 8 Sd IMPORT mydsl ia zS DEFINE main FOR Model mydsl EXPAND javaBean FOREACH types typeSelect Entity main Model ENDDEFINE ur javaBean Entity DEFINE javaBean FOR Entity FILE name java public class name FOREACH fea
58. gt daher ber einen Dienst zur Koordination der sensor bergreifenden Aktionen Rafi03 Wie sieht nun das korrespondierende Testszenario in ScatterUnit konkret aus Zu Beginn wird das drahtlose Sensornetz mit der in Abbildung 19 links dargestellten Topologie konfiguriert Zun chst sendet Sensorknoten 1 ein Paket an Sensorknoten 4 Sensorknoten 4 empf ngt das von Sensorknoten 1 versendete Paket Danach n dert sich die Topologie des Netzes vgl Abbildung 19 rechts so dass sich auch der Pfad zwischen den beiden Sensorknoten 1 Sender und 4 Empf nger ndert Dabei bewegt sich Sensorknoten 4 au erhalb der Reichweite von Sensorknoten 3 und tritt in die Reichweite des Sensorknotens 2 ein Eine solche Topologie nderung zu Test zwecken kann mittels einer entsprechenden Paketfilterung mit Hilfe eines speziel len Dienstes von ScatterUnit bewerkstelligt werden Nun sendet Sensorknoten 1 ein weiteres Paket an Sensorknoten 4 und Sensorknoten 4 empf ngt das Paket erneut Abbildung 19 nderung der Topologie w hrend der Testdurchf hrung Kame08 37 Aufgrund der Topologie nderung des Netzes muss das Routingprotokoll beim Versenden des zweiten Pakets von Knoten 1 zu 4 einen anderen Pfad zwischen den beiden betroffenen Knoten finden Falls Sensorknoten 4 das zweite Paket nicht emp f ngt bedeutet dies dass das Routingprotokoll die Topologie nderung nicht abge fangen hat was zu einem Fehler im Testverlauf f hrt Der Testfall wurde
59. in der Datenbank gespeichert Auf eine nderung des Nachrichtenprotokolls im WSN kann zu jeder Zeit entsprechend reagiert werden indem die erforderliche Anpassung des Musters der betroffenen Felder in der Properties Datei vollzogen wird Diese muss der Benutzer nur ein einziges Mal vornehmen Die Speicherung der WSN Konfiguration wie z B die Formatierung und Skalierung der Grafik des Feldes in dem die Knoten platziert werden die Positionierung der Knoten im Feld sowie der Status jedes einzelnen Sensorknotens werden mit Hilfe des Castor Rahmenwerks realisiert vgl Abbildung 52 Dabei werden wie die folgende Abbildung veranschaulicht s mtliche als Objekte vorliegende Daten durch das Castor Rahmenwerk WebCastor nach dem XML Format bzw dem Schema rationaler Datenbanken automatisiert abgebildet damit diese f r weitere Verarbeitungsschritte durch andere Programme z B andere Plugins zur Verf gung stehen Somit findet eine automatisierte und den Bed rfnissen des Benutzers angepasste Serialisierung der WSN Daten statt Dies stellt einen weiteren Vorteil der Emulation des WSNs im objektorientierten Paradigma dar da solche Technologien optimal auf Objektinstanzen operieren 2 Diese sind einige Funktionalit ten des Root Plugins die ausf hrlicher im kommenden Abschnitt behandelt werden 91 Field Type Null Key id int 11 NO PRI nodename varchar 200 YES NULL LogModuleMapping xml
60. ma geschneiderten Codeerzeugung so dass nur so viel Code f r die Sensorknoten erzeugt wird wie f r ihre jeweilige Rolle erforderlich ist Die Automatisierung erstreckt sich dar ber hinaus nicht nur auf die Anwendungserstellung sondern auch auf die Testdurchf hrung hinsichtlich der Versagenspr fung sowie der Fehlerlokalisierung im Code der zu erstellenden Anwendung Gerade die steigende Komplexit t des Einsatzes drahtloser Sensornetze erfordert eine robustere Erstellung der Softwareartefakte die sich ad quat testen lassen m ssen Um diesen Anforderungen zu begegnen wurde zun chst die 147 Testautomatisierungsschicht ScatterUnit entwickelt welche den verteilten Testverlauf auf Sensorebene automatisiert durchf hrt Zu diesem Zweck wurde ein dezentralisierter Ansatz verfolgt um mittels local logging den Testverlauf zu protokollieren damit dieser erst nach Beendigung der Testausf hrung mittels spezieller Pr froutinen evaluiert und auf Fehler berpr ft wird Hierzu m ssen Testskripte implementiert werden die auf den verschiedenen Sensorknoten des Netzes nebenl ufig ausgef hrt werden um die dezentrale Testausf hrung zu koordinieren und zu steuern Solche Funktionalit ten werden durch die verschiedenen Dienste ScatterUnits automatisch zur Verf gung gestellt Damit m ssen Dienste die f r verschiedene Testf lle mehrfach verwendet werden nicht erneut f r jeden Testfall implementiert werden Als Resultat wird die Entwicklung ei
61. nnen wurde der Terminal Reiter entwickelt welcher eine befehlsorientierte Konfiguration der Sensorknoten erm glicht Eine weitere wichtige Funktionalit t des Reiter orientierten ScatterEditors ist die F higkeit die auf den Knoten laufenden Softwareartefakte per 110 Funk zu aktualisieren Es wurde geschildert wie dies mit Hilfe des Reiters Over The Air Flashing OTA Flashing bewerkstelligt wird Ein umfangreicher Abschnitt des Kapitels widmete sich dem berwachungssystem welches durch den Alarm Reiter realisiert wurde Ferner wurden die rekursive Syntax der Alarmsprache sowie deren Semantik er rtert wobei anhand zahlreicher Alarmausdr cke illustriert wurde wie sich Dank des strukturierten Sprachenaufbaus die Alarmausdr cke auf bersichtliche und einfache Art und Weise formulieren lassen 111 8 Beurteilung und Auswertung der Werkzeugkette Um eine umfassende und aussagekr ftige Bewertung der ScatterClipse Werkzeugkette zu treffen m ssen in erster Linie die Komponenten die das R ckgrat der gesamten Werkzeugkette ausmachen evaluiert werden vgl Hent06 Kame07 Kame08 Dabei geht es vor allem um den erzielten Effekt der angewandten Automatisierung und die Frage wie dieser sich hinsichtlich des Einsatzes der Werkzeugkette auswirkt Demzufolge sind an dieser Stelle zwei Aspekte von Bedeutung die Anwendungsentwicklung und die Testautomatisierung Im Kontext der Anwendungsentwicklung spielt die Gr e des Codes der f r die
62. oder mehreren Prozessen wobei ein Prozess einen Fluss von im Netz stattgefundenen Aktionen bzw Ereignissen darstellt Hiermit verf gt der Verlauf eines Prozesses analog zu den Aktivit tsdiagrammen ber einen Start und einen Endknoten Prozesse k nnen dabei parallel oder sequenziell ablaufen Ferner unterst tzt die Modellierungssprache die Gruppierung einzelner Ereignisse bzw Aktionen um logische Zusammenh nge im Netz zu modellieren z B geografische Lage Zugeh rigkeit der betroffenen Endger te zu einer Person etc In dem Beitrag wird zwar ein modellgetriebener Prozess zur Anwendungsentwicklung von Sensorknoten propagiert die Autoren betrachten jedoch lediglich den Aufbau der Modellierungssprachen und deren Eigenschaften Weitere f r den modellgetriebenen Entwicklungsprozess essentielle Bausteine wie die Metamodellierung die Validierung der Modellierungssprache und der Codegenerierungsprozess werden nicht ber cksichtigt Die Modellierungssprache sollte jedoch im Kontext des modellgetriebenen Prozess dargestellt und nicht isoliert sondern zusammen mit den eben erw hnten Komponenten betrachtet werden Denn erst dadurch kann eine ad quate Beurteilung hinsichtlich der Realisierbarkeit und Einsatztauglichkeit der vorgestellten Modellierungssprache getroffen werden Der einzige Aspekt des modellgetriebenen Prozesses der neben der Modellierungssprache angesprochen wird ist die M2M Transformation durch die das PSM aus dem PIM
63. senden muss das Paket zuvor erstellt und anschlie end die entsprechende Methode des Routingprotokolls aufge rufen werden Eine solche Aktion ist eng an die zu testende Anwendung gebunden Solche anwendungsspezifischen Aktionen werden daher vom Entwickler manuell implementiert Es w re nicht sinnvoll jegliche m gliche Aktion zu modellieren um daraus den zugeh rigen Code zu generieren da ein solcher Code nicht ber einen statischen Charakter verf gt Solche feink rnigen Codesegmente richten sich stark nach der zu testenden Anwendung und weil das Spektrum der in ScatterUnit zu testenden Anwendungen uneingeschr nkt bleiben sollte werden solche anwen dungsspezifischen Aktionen dem Entwickler berlassen um diese dann nach seiner Intention ma geschneidert umzusetzen Der hier verfolgte hybride Ansatz verleiht dem Rahmenwerk einen hohen Grad an Offenheit bez glich der potentiell zu tes tenden WSN Anwendungen Dieser Ansatz wurde durch den angef hrten Testfall illustriert The authors use an example test case to illustrate the approach and im prove understanding of the reader The explanation helps to understand where the manual step is involved in the test case generation Also the authors provide a good reason as to why this manual code is needed 37 E SendSecondPacket Control Action Abbildung 22 Verfeinertes Diagramm der Aktivit t SendSecondPaket 37 Ein anonymer Reviewer des Papers Visual ScatterUnit in ACM IEEE
64. sich um drei Targets siehe Abbildung 85 oben rechts 1 build zur Kompilierung des C Quellcodes eines ausgew hlten Ordners 2 flash zur Ausbringung von kompilierten Codeartefakten Hex Files auf den Sensorknoten ber die serielle Schnittstelle 3 clean zur L schung aller bereits kompilierten Artefakte 156 11 3 3 OTA Flashing Abbildung 86 zeigt einen Bildschirmabzug der Benutzerschnittstelle des OTA Flashings Java Eclipse SDK File Edit Navigate Search Project Run Window Help my nn O Qa BEO OF le E amp Java Problems Javadoc Declaration REE ScatterServer Connection Property Terminal Alarm Log OTA Flashing Server Configuration File Path Sensor IDs C Dokumente und Einstellungen Jintao Desktop diplom s Open File COCO Load to EEPROM 23 34 2089 10938000736C72001431737772002431726C670045 2090 109390005831726C79007C31736C67009031736C54 2091 109340007900443173776700443173777900B031FF 2092 1093B00073627000CE3172747000E6317374700045 2093 1093C000FE3172667200143273667200303272724D 2094 1093D0007000463252535400583272737000743227 2095 1093E00075706402CC3264636F00443374696D00DD 2096 1093F000043474697300343474697 4008034606570 2097 109400006D00E63470636C001E356C737402D235E7 2098 1094100072627S500FE35727662001E3672766500E5 2099 109420003E36726D6D00543673693200006272749C 2100 1094300074002265666C78022865657374022E6577 2101 1094400066737402826873636F029074746D72023D 2102 109450006E
65. sowohl im lokalen als auch entfernt im internetbasierten Modus in Anspruch genommen werden So kann der Benutzer mit Hilfe von ScatterFactory und Visual ScatterUnit die Codeartefakte einer Anwendung und deren 149 Testf lle automatisiert erstellen und anschlie end mit Hilfe von ScatterEditor die generierten Codeartefakte internetbasiert auf ausgew hlten Sensorknoten im drahtlosen Netz per Funk ausbringen Ferner k nnen parallel zur automatisierten Erstellung und zum Test einer Anwendung eines bestimmten Sensorknotens die Hardware bzw Firmwareflaggen z B die Sendest rke mit Hilfe von ScatterEditor passend zum jeweiligen Testfall konfiguriert werden Der Fokus von ScatterEditor liegt neben der Verbindung zwischen IP und ScatterWeb auf der Schnittstelle zwischen Mensch und Maschine bei drahtlosen Sensornetzen ScatterEditor bietet die M glichkeit verschiedene Charakteristika und Eigenschaften der WSNs illustrativ und interaktiv zu testen und zu untersuchen Neben den Basisdiensten wie Programmierung und Konfiguration von Sensorknoten bietet ScatterPlug auch komplexere Dienste an wie die Emulation und Modellierung von ausgebrachten drahtlosen Sensornetzen im objektorientierten Paradigma die statistische Analyse der WSN Umgebung ebenso wie die Visualisierung der analysierten Daten aus dem WSN und des Status der einzelnen Sensoren Die statistische Analyse der von einem Sensor erfassten und bearbeiteten Daten in ScatterPlug kann sehr hilfrei
66. ten unabh ngig von den anderen bedienen wodurch ein separation of concerns erreicht wird andererseits kann er zwischen den verschiedenen Plugins navigieren was die Koh renz erh ht Nichts desto trotz ist f r die interaktive Navigation des Benutzers zwischen den vielseitigen sich erg nzenden Komponenten der Werkzeugkette ein Gef ge notwendig innerhalb dessen der Benutzer die jeweils ben tigten Komponenten zielgerichtet und mit besserer Orientierung hinsichtlich seines Gesamtvorhabens bedienen kann Daher sollten der Zugriff und die Nutzung der unterschiedlichen Plugins bzw Komponenten der Werkzeugkette zentral geschehen und einer einheitlichen Vorrichtung unterliegen Zu diesem Zweck wurde die ScatterClipse Assembly Line entwickelt die wie der Name vermuten l sst als ein integriertes View Plugin realisiert wurde welches die bet tigten Aktivit ten der Werkzeugkette in chronologisch strukturierte Abschnitte aufteilt Jeder Abschnitt besteht aus verschiedenen Aktivit ten wobei jede Aktivit t durch ihr spezielles Plugin realisiert wird Somit findet eine Visualisierung der Zusammenarbeit der verschiedenen Komponenten der Werkzeugkette w hrend ihrer Inanspruchnahme statt wodurch dem Benutzer stets die Gesamt bersicht erhalten bleibt Dies verdeutlicht Abbildung 83 die einen Bildschirmabzug der ScatterClipse Assembly Line zeigt 150 f ScatterClipse Assembly Line 53 Development Testing Deployment Monitoring
67. to be published by IN TECH end of 2009 Al Saad M Fehr E Kamenzky N Schiller J Model Driven Visual Testing and Debugging of WSN Applications In Journal of Networks JNW VOL 4 NO 7 Academy Publisher 2009 Proceedings Conferences Workshops Al Saad M Hentrich B Schiller J ScatterFactory An Architecture Centric for Wireless Sensor Networks In International Conference on New Technologies Mobility and Security pp 12 32 Springer Netherlands 2007 Al Saad M Mysliwiec L Schiller J ScatterPlug A Plug in Oriented for Prototyping Programming and Teaching Wireless Sensor Networks In 2nd International Conference on Systems and Networks Communications pp 37 47 IEEE CS Press 2007 Al Saad M Ding J Schiller J ScatterEditor An Eclipse based Tool for Programming Testing and Managing Wireless Sensor Networks In International Conference on Sensor Technologies and Applications pp 59 69 IEEE CS Press 2007 Best Paper Award Al Saad M Kamenzky N Schiller J Visual ScatterUnit A Visual Model Driven Testing of Wireless Sensor Networks Applications In 11th ACM IEEE International Conference on Model Driven Engineering Languages and Systems pp 751 765 LNCS Vol 5301 Springer Berlin Heidelberg 2008 Al Saad M Fehr E Kamenzky N Schiller J Automated Testing of WSN Applications In 3nd International Conference on Systems and Networks Communications pp 157 167 IEE
68. tzliche Spezifikation wie beispiels weise die Version Dies wird im Metamodell durch das Attribut der Application Klasse Stereotype angegeben 5 2 Die Modellierungsebene Das Herzst ck der Modellierung in ScatterFactory ist der generative Editor in dem die Metamodellelemente auf eine bersichtliche Weise wiedergegeben werden Dies erm glicht dem Benutzer eine ad quate Zusammenstellung der Modellkonstrukte zur grafischen Anwendungserstellung Abbildung 42 zeigt einen Bildschirmabzug des generativen Editors und seine wesentlichen Elemente In der Abbildung sieht man unter 1 die Palette in der s mtliche Elemente des Metamodells zur Auswahl durch den Benutzer aufgelistet sind Des Weiteren wer den die aufgelisteten Elemente gem ihrer Kategorisierung im Metamodell in der Palette aufgeteilt So befinden sich in der oberen Kategorie alle Modellelemente zur Wahl einer Sensorinstanz 5 In der mittleren Gruppe stehen die Softwaremo dellinstanzen zur Auswahl und zwar von der Anwendung hin bis zu den Ports In der unteren Gruppe finden sich alle Arten von Verkn pfungen durch die die Mo dellelemente logisch verbunden werden Ferner kann durch die Zoomfunktion die Gr e des Modells in der Modellierungsfl che vom Benutzer beliebig eingestellt werden Alternativ zur Palette k nnen Modellelemente ber dem Kontextmen sie he 2 direkt ins bereits bestehende Modell in der Modellierungsfl che eingef gt wer den Das Men wird angezeigt sob
69. und semantische dom nenspezifische Randbedingungen unten Programmauszug 14 Einsatz von Filterregeln bei der Codegenerierung Programmauszug 15 Generierung eines alternativen Firmwaremodules 174 64 64 68 77 80 81 11 7 3 Tabellenverzeichnis 1 Tabelle 1 Die kontextfreie Grammatik 110 2 Tabelle 2 Gr e des generierten Codes nach dem Kompilierungsprozess mit und ohne Filterregeln 116 3 Tabelle 3 Messung des Verarbeitungsaufwands empfangener Datenpakete in ScatterUnit 118 4 Tabelle 4 Beanspruchung der Betriebsmittel eines Sensorknotens ESB 120 5 Tabelle 5 Tabelleninformationen nach erneuter Testdurchf hrung 130 6 Tabelle 6 Vergleich der WSN Entwicklungsumgebung nach der Studie von Teng141 175 11 8 Literaturverzeichnis Agan02 Agans D Debugging The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems Mcgraw Hill Professional Columbus 2002 Akyi02 Akyildiz I F Su W Sankarasubramaniam Y Cayirci E Wireless sensor networks a survey Computer Networks 38 4 pp 393 422 2002 Alsa07a Al Saad M Hentrich B Schiller J ScatterFactory An Architecture Centric Framework for Wireless Sensor Networks In International Conference on New Technologies Mobility and Security pp 12 32 Springer Netherlands 2007 Alsa07b Al Saad M Mysliwiec L Schiller J ScatterPlug A Plug in Oriented Framework for Prototyping Programming and Teaching
70. unterst tzt was sicherlich einen gravierenden Mangel in der Ausdrucksm chtigkeit der Modellierungssprache darstellt Um die bereits angesprochene semantische L cke zu reduzieren wird f r jede Zielplattform ein zugeh riges plattformspezifisches Modell PSM zur Verf gung gestellt in welches das jeweilige Modell der universellen Modellierungssprache transformiert wird Zur Unterst tzung jeder unterliegenden Plattform bedarf es daher einer entsprechenden Model zu Model Transformation M2M Dabei werden die Transformationsvorschriften mit Hilfe der deklarativen imperativen ATL Transformationssprache WebATL spezifiziert welche es erm glicht Zuordnungen zwischen verschiedenen Modellkonstrukten festzulegen Aus dem jeweiligen PSM wird anschlie end mit Hilfe des MOFScript Plugins von Eclipse der zugeh rige Code generiert Leider wird in dem Beitrag nicht genauer darauf eingegangen wie die Codegenerierung mit Hilfe des Plugins vonstatten geht Zwar soll der Beitrag der Arbeit eine universelle Modellierungssprache f r WSN sein die Phasen des modellgetriebenen Prozesses werden jedoch anhand eines Beispiels f r eine Plattform n mlich TinyOS illustriert Es wird nicht gezeigt wie aus demselben universellen Modell unterschiedliche Codeartefakte f r deren jeweilige Plattformen generiert werden obwohl dieser Aspekt die Arbeit von anderen abgrenzen soll Die Beschr nkung auf TinyOS dominiert die Vorstellung der Konzepte des Rahmenwerks was d
71. v2 1 1 OMG o J http www omg org technology documents formal xmi htm WebXMI XMI Spezifikation der OMG http www omg org spec XMI 2 1 1 PDF index htm WebXpand XPand Language Reference http www openarchitectureware org pub documentation 4 1 r20_xPandReference pdf WebXtend Extend Language Reference http www openarchitectureware org pub documentation 4 0 r25_extendReference pdf Weis91 Weiser M The Computer for the Twenty First Century Scientific American pp 94 100 1991 URL http www ubiq com hypertext weiser SciAmDraft3 html Witt06 Wittenburg G Schiller J Running Real World Software on Simulated Wireless Sensor Nodes In ACM Workshop on Real World Wireless Sensor Networks pp 7 11 ACM New York 2006 Xu04 Xu S Rajlich V Cognitive process during program debugging In 3rd IEEE International Conference on Cognitive Informatics pp 176 182 IEEE CS Press New York 2004 Zand05 Zander J Dai Z R Schieferdecker I Din G From U2TP Models to Executable Tests with TTCN 3 An Approach to Model Driven Testing In 17th IFIP International Conference on Testing Communicating Systems pp 289 303 LNCS Vol 3502 Springer Berlin Heidelberg 2005 183 11 9 Aus der Arbeit entstandene Publikationen Journals Book Chapters Al Saad M Schiller J Fehr E Automated Testing and Development of WSN Applications Book chapter for Wireless Sensor Network ISBN 978 3 902613 49 3
72. verteilt auszuf hrende Anwendung ein schwieriges Unterfangen Hier war eine Steigerung der Automatisierung von N ten um diese Aufgabe so weit wie m glich an einen Codegenerator zu delegieren damit der Anwendungsentwickler sich st rker der Konzeption und dem Entwurf des Testfalls widmen kann anstatt den technischen Belangen Hierzu wurde das mo dellgetriebene Visual ScatterUnit entwickelt was im Abschnitt 4 vorgestellt wurde Der Fokus des folgenden Abschnitts lag in der Analyse der protokollierten Tester gebnisse nach Beendigung der Testausf hrung um eine tiefere Einsicht in das Ver halten der zu testenden Anwendung zu erhalten So wurde gezeigt wie die im Sinne der MDSD ausf hrbaren formalen Modelle zweigleisig eingesetzt werden k nnen indem einerseits der Code f r den Anwendungstest durch sie generiert werden kann andererseits sie aber auch eingesetzt werden um das Verhalten der zu testenden Anwendung zu visualisieren Dies f hrte zu der berlegung wie von den analysierten und visualisierten Testergebnissen hinsichtlich der Fehlerlokali sierung Gebrauch gemacht werden kann Es wurde illustriert wie mit Hilfe der mo dellgetriebenen Visual ScatterUnit die formalen Modelle wiederholt schrittweise verfeinert werden k nnen um zutreffende Hypothesen bez glich der Versagensur sache treffen zu k nnen Auf diese Weise zeigte sich dass sich der modellgetriebene Ansatz kombiniert mit einer entsprechenden Visualisierung ausgezeic
73. vorhandene Zyklen in eine endlose Schleife zu geraten Neben der Reduzierung der Komplexit t des Codegenerierungsprozesses leistet die Live Validierung einen wesentlichen Beitrag zur Steigerung der Qualit t des f r den Testfall ben tigten Codes Betrachtet man beispielsweise die benutzerdefinier ten Protokolleintr ge Log Aktionen zur Fehlersuche im Detaillierungsdiagramm so kann durch die Live Validierung garantiert werden dass an jeden solchen Proto kolleintrag die korrespondierende Pr froutine durch das entsprechende Markie rungslabel gebunden wird Au erdem berpr ft sie dass die im Modell verwendeten Markierungslabel ber unterschiedliche Bezeichner verf gen Infolgedessen erwartet jede Pr froutine w hrend der Analyse der Testergebnisse nach Ausf hrung des Tests ihre zugeh rigen Protokolleintr ge Erh lt sie diese nicht kann angenommen werden dass der Testverlauf oder die Sammlung der Testresultate nicht ordnungsgem stattgefunden hat Entsprechend kann eine im Generat f r diesen Fall ma geschneiderte Fehlermeldung automatisiert generiert werden Durch die Garantie dass lediglich diejenigen Logaktionen im Test ausge f hrt werden die tats chlich im formalen Modell vorkommen wird die Robustheit des Testverlaufs erh ht Andernfalls deckt die Live Validierung den entsprechenden Fehler auf wodurch der dazugeh rige Code automatisiert gem dem Testverlauf generiert wird was dessen Qualit t merklich erh ht 4
74. zu berwinden Die ser Sachverhalt f hrt nicht nur zu einem schwerer zu beherrschenden Modellie rungsmechanismus sondern steigert die Komplexit t des Prozesses zur automati sierten Gewinnung der Dom nensoftwareartefakte aus den abstrakten Modellen Evan03 Insgesamt kann die Zielsetzung des AC MDSD Paradigmas mit der Verwendung von modernen Produktlinien in der Automobilindustrie verglichen werden vgl Ab bildung 2 Am Anfang steht der Prototyp Reference Implementation der die wich tigsten Konzepte beinhaltet Der Prototyp zeigt wie das zu produzierende Fahrzeug aussehen soll Der Konstruktionsplan Modell dient als Ausgangsbasis fiir das End produkt generiertes Artefakt und gibt an welche Einheiten Komponenten notwen dig sind Um die Konstruktion der Produktlinie generative Architektur ebenso wie die sp tere Produktion Codegenerierung zu vereinfachen werden logisch zusam mengeh rende Komponenten zu Produktionseinheiten zusammen gefasst Produkti onseinheiten die nicht automatisiert werden oder f r die Automatisierung zu kom pliziert sind werden in Handarbeit entwickelt manueller Code Um eine breite Produktpalette anzubieten Systemfamilie werden die Komponenten im Regelfall w hrend des Produktionsprozesses variiert w hrend die Produktionsplattform als solche unver ndert bleibt Hent06 9 Siehe Glossar Randbedingungen Chdeverlagen Constraints N Instanz Instanz D Exp
75. zum Zweck des Tests der Mobilit t der Sensorknoten im Netz eingesetzt wurden Ein solcher Versuch Malt00 wurde von einer Forschergruppe der Universit t Carnegie Mellon unternommen um das Dynamic Source Routing Protokoll DSR Broc99 Perk01 zu testen Hierzu wurde zum Testzweck ein drahtloses Sensornetz erstellt wobei zwischen den Senderknoten und dem Empf nger f nf Zwischenknoten gesetzt wurden W hrend sowohl der Sender als auch der Empf ngerknoten ihre Position nicht nderten wurden die f nf Zwischenknoten jeweils in einem fahrenden Fahrzeug platziert Das Fahrverhalten jedes einzelnen Fahrzeugs wurde der jeweiligen Verkehrslage spontan angepasst wodurch das Bewegungsmuster jedes Wagens und des sich in ihm befindlichen Sensorknotens nicht im Voraus bestimmt 139 werden konnte So variierte die Fahrgeschwindigkeit der einzelnen Wagen zwischen 25 und 40 km h The road we use is open to general vehicle traffic and has several Stop signs so the speed of each node varies in a complex fashion just as it would in any real network Malt00 Das versendete Paket soll nun anhand des Routing Protokolls seinen Weg unter real nicht vorhersehbaren Testbedingungen zum Empf nger finden With the vehicles radios and site used in our testbed we forced the protocols to operate in an environment in which all links between nodes change status at least every 220 seconds Ignoring the additional factor of packet loss due to wireless errors o
76. 05 Ulbr05a Ulbrich A Weis T M hl G Geihs K Application Development for Actuator and Sensor Networks In R mer K ed 4 GI ITG KuVS Fachgespr ch Drahtlose Sensornetze Technischer Bericht TR 481 pp 38 43 ETH Z rich 2005 URL http www vs inf ethz ch events fg2005 fgsn05 pdf Ulbr05b Ulbrich A Weis T Geihs K A Modeling Language for Applications in Pervasive Computing Environments In 2nd Workshop on Model based Methodologies for Pervasive and Embedded Software pp 109 123 TUCS Turku 2005 URL http www tucs fi publications attachment php fname G39 pdf Ulri99 Ulrich A W Zimmerer P Chrobok Diening G Test architectures for testing distributed systems In 12th International Software Quality Week pp 24 26 San Jose California 1999 Wada07 Wada H Boonma P Suzuki J Modeling and Executing Adaptive Sensor Network Applications with the Matilda UML Virtual Machine In 11th IASTED International Conference on Software Engineering and Applications SEA Cambridge MA 2007 URL http www cs umb edu shu papers sea07 pdf Web b m b m Engineering http www engineering bmiag de WebActivity Wikipedia Art Activity Diagramm http en wikipedia org wiki Activity_diagram WebAlsa Al Saad M ScatterClipse http page mi fu berlin de saad ScatterClipse scatterclipse htm WebANT Apache Software Foundation Ant Projekt http wwwant apache org WebATL Atlas Trans
77. 5 Zusammenfassung Der erste Abschnitt des Kapitels besch ftigte sich mit der Struktur der Dom nen sprache DSL zur Testautomatisierung Hierzu stand der Aufbau des Metamodells im Zentrum Es wurde geschildert dass der Entwurf der spezifischen Dom nen sprache eine offene Struktur aufweist welche die Testfallentwicklung nicht einengt Einerseits steht f r jeden technischen Aspekt wie Steuerbefehle Ereignisse und Protokolleintr ge des automatisierten Tests jeweils eine korrespondierende Modell entit t in der DSL zur Verf gung deren zugeh riges Codeartefakt vom Nutzer ge m der gerade zu testenden Anwendung manuell angepasst werden kann Ande rerseits bleibt die Option offen durch strukturierte Erweiterung des Metamodells h ufig verwendete Konstrukte in der DSL fest zu verankern so dass deren Code voll automatisiert generiert werden kann Ein Diagramm welches das gesamte Meta modell veranschaulicht ist im Anhang 11 4 zu finden Im zweiten Abschnitt wurde geschildert wie die Validierung der mit Hilfe der DSL erstellten formalen Modelle vonstatten geht Um die Qualit t des generierten Codes und damit des Testfalls sicherzustellen wird das Testfallmodell hinsichtlich seiner syntaktischen und semantischen Regeln in Form von Bedingungen berpr ft Dies erfolgt nicht nur wenn das Testfallmodell generiert wird sondern auch w h rend der Modellierung des Testfalls Da die Modellvalidierung mit Hilfe des openAr chitectureWare Ra
78. 7B72616600AE7B73616600087C72731E 2103 0E9460006D00C47C73736D009E7F61 70700040 Abbildung 85 Der OTA Flashing Reiter Ding07 Wie in Abbildung 61 gezeigt wurde werden bei der Bet tigung der Refresh Funktion s mtliche Sensorknoten IDs in der Tabelle aufgelistet die vom eGate aus erreichbar sind Nun kann der Benutzer im Reiter des OTA Flashings die IDs derjenigen Sensorknoten eingeben zu denen die Softwareartefakte ausgebracht werden sollen 3 Die Auswahl der Softwareartefakte findet mit Hilfe einer Auswahl des Verzeichnisbaums file chooser 1 statt die es dem Benutzer erm glicht flexibel und berschaubar zwischen den unterschiedlichen generierten Softwareartefakten zu navigieren da diese wie in 5 4 erl utert nach dem Generierungsprozess in spezifische Verzeichnisse geschrieben werden die vom Benutzer innerhalb der Templates festgelegt werden Nach der Auswahl des als Hex File vorliegenden Softwareartefakts aus dem entsprechenden Verzeichnis wird dieses zuerst in den EEPROM des eGates geladen Der Benutzer kann das Voranschreiten des Ladevorgangs mittels der progress bar verfolgen 2 W hrenddessen werden in diesem Zusammenhang relevante Nachrichten in 4 ausgegeben Abschlie end kann das Softwaremodul Inhalt des EEPROMs des eGates per Funk zu den in 3 ausgew hlten Sensorknoten gesendet werden Der daraus entstehende Nachrichtenaustausch wird in 4 ausgegeben Soll das Softwaremodul ins eGate selbst installiert werden s
79. 8 Schi05 Schiller J Liers A Ritter H Winter R Voigt T ScatterWeb Low Power Sensor Nodes and Energy Aware Routing In 38th Annual Hawaii International Conference on System Sciences vol 9 pp 286c IEEE CS Washington 2005 Schi07 Schiller J Funksensornetze von der Forschung zum realen Einsatz Vortrag in der Ringvorlesung Selbstorganisierende Systeme am 26 4 07 an der Humboldt Universit t URL http www2 informatik hu berlin de daeumlic files rvselbstorganisierendesysteme RV Bericht pdf Sch 97 U Sch ning Theoretische Informatik kurzgefasst Spektrum Akademischer Verlag Heidelberg 1997 179 Sobe05 Sobeih A Chen W Hou J C Kung L Li N Lim H Tyan H Zhang H J Sim a simulation environment for wireless sensor networks In 38th Annual Simulation Symposium pp 175 187 IEEE Washington DC 2005 Stah05 Stahl T V lter M Modellgetriebene Softwareentwicklung Techniken Engineering Management Dpunkt Verlag Heidelberg 2005 Teng08 Teng G Zheng K Dong W A Survey of Available Tools for Developing Wireless Sensor Networks In 3rd International Conference on Systems and Networks Communications pp 139 144 IEEE CS Press Washington 2008 Titz05 Titzer B Lee D Palsberg J Avrora Scalable sensor network simulation with precise timing In 4th International Conference on Information Processing Sensor Networks pp 477 482 IEEE CS Press 20
80. Codeanteil ist darauf zur ckzuf hren dass bei der modellgetriebenen Testdurchf hrung etliche Funktionalit ten zur Verf gung stehen die bei der manuellen Variante nicht vorhanden sind So geht die gesamte Bearbeitung und Analyse der gesammelten Log Eintr ge voll automatisiert vonstatten Des Weiteren wird die Visualisierung des Verhaltens des Testobjekts auf Basis der zuvor analysierten Log Eintr ge ebenfalls modellgetrieben und somit automatisiert realisiert Es ist weiterhin hervorzuheben dass diese automatisiert generierten zus tzlichen Codeartefakte ausschlie lich auf dem Werkzeug und nicht auf den Sensorknoten ausgef hrt werden Daher tragen solche Funktionalit ten in jedem Fall zu einer gesteigerten Leistungsf higkeit bei ungeachtet dessen welcher Codeanteil f r ihre Realisierung n tig ist Nun stellt sich die Frage inwieweit sich die Fehlersuche im modellgetriebenen Visual ScatterUnit automatisieren l sst d h ob sich die in ScatterUnit angebotenen Dienste vgl 4 4 zur automatisierten Testdurchf hrung auf Sensorebene selbst automatisieren lassen Solche Codeartefakte werden ausschlie lich auf den Sensorknoten ausgef hrt Wie die Grafik in Abbildung 80 veranschaulicht konnten nahezu alle Codeartefakte zur Fehlersuche automatisiert generiert werden Bei dem kleinen nicht automatisierbaren Codeanteil ca 5 handelt es sich um anwendungsspezifischen Code Alle restlichen Codeartefakte dienen der Automatisierung der Fehlersuc
81. Communication via 2 und COM 3 eingegeben werden siehe oberer Bildschirmabzug in Abbildung 61 Anhand von 1 kann festgelegt werden ob die Kommunikation im lokalen oder im entfernten internetbasierten Modus vonstatten gehen soll Im Falle des internetbasierten Modus wird die Verbindung zum lauschenden Server aufgebaut wodurch sich der Klient einen Zugang zum WSN verschafft Andernfalls wird ein bidirektionaler textorientierter Kommunikationskanal zur Senke aufgebaut durch den die aus und eingehenden Nachrichten von und zum WSN ausgetauscht werden Die Festlegung ob es sich bei der Senke um ein EGate oder einen SuperNode handelt wird durch 2 angegeben Mittels 3 wird die Nummer des Ports der seriellen Schnittstelle des Rechners angegeben an dem die Senke angeschlossen wird Soll der Rechner auch als Server anderer ScatterEditor Klienten gem der Beschreibung im letzten Abschnitt fungieren so muss festgelegt werden ob der Terminaldienst im lokalen oder entfernten Modus laufen soll Falls der lokale Modus f r das Terminal gew hlt wird 4 werden die korrespondierenden Daten lediglich lokal auf demselben Rechner angezeigt Ansonsten wird die entfernte Konfiguration des Terminals aktiviert und die Daten werden beim Rechner des Klienten angezeigt Die Unterscheidung ist hier wichtig da je nach Konfiguration des Terminals die Form festgelegt wird in der die Daten angezeigt werden Beim entfernten Modus werden auf Grund entfernter und so
82. DES Enable false el EnterRangeOfNode2 Topology Change Action Opposite Node 2 Apply On BOTH_NODES Enable true Abbildung 21 Das verfeinerte Diagramm der Aktivit t Change Topology aus Abbildung 20 40 Das Diagramm zeigt zwei Aktionen Die erste Aktion bezieht sich auf den Austritt des Sensorknotens 4 aus der Reichweite des Sensorknotens 3 und die zweite auf den Eintritt des Knotens 4 in die Reichweite des Knotens 2 Dies sind die beiden Aktio nen welche die Topologie nderung zur Folge haben Da die Aktionen sich innerhalb des Aktivit tsknotens von Sensorknoten 4 im Diagramm befinden werden sie die sem Knoten zugewiesen Infolgedessen werden die dazu ben tigten Codeartefakte als Teil der Testskripte von Sensorknoten 4 generiert Allerdings wird wie bereits erw hnt nicht immer der f r die Testskripte zust n dige Code ausschlie lich aus dem Diagramm des Testfalls vollst ndig generiert In der Regel sind bestimmte Aktionen manuell zu implementieren Ein Beispiel einer solchen Aktion sieht man im Diagramm der folgenden Abbildung 22 Das Diagramm ist zust ndig f r die Aktivit t SendSecondPacket die im Aktivit tsdiagramm des Testfalls vgl Abbildung 20 modelliert ist Im Diagramm ist nur eine einzige Aktion enthalten Dies liegt daran dass die brigen Aktionen von manuell implementier tem Code ausgef hrt werden Um ein Datenpaket ber den Funkkanal mit Hilfe des Routingprotokolls die zu testende Anwendung zu
83. Da es in der Studie ber cksichtigt wurde soll es an dieser Stelle behandelt werden und nicht in dem Abschnitt der sich mit modellgetriebenen Werkzeugen f r Anwendungsentwicklung besch ftigt GRATIS befindet sich mittlerweile in der zweiten Version Die Modellierungsmethode folgt der klassischen modellbasierten Entwicklung wobei aus den formalen Modellen der zugeh rige Code automatisiert f r TinyOS und die darauf gest tzten Anwendungen generiert werden kann Die Entwickler bezeichnen ihr Werkzeug zwar als modellbasiert allerdings ist es auch als modellgetrieben einzustufen da der Code aus den formalen Modellen automatisiert generiert wird OS and application component interfaces along with their interdependencies are captured in a graphical environment and the glue code that ties together the application and OS components are automatically generated WebGRATIS Ferner geschieht die Modellierung gem dem modellgetriebenen Paradigma auf Basis einer komponentenbasierten Dom nensprache f r die ein Metamodell und ein spezieller Editor entwickelt wurden Beide sind mit Hilfe von Generic Modeling Environment GME WebGME entwickelt worden mit deren Hilfe Metamodelle zur Entwicklung dom nenspezifischer Sprachen und deren zugeh rige Editoren realisiert werden k nnen Aus eigener in der Lehre gewonnener empirischer Erfahrung mit GME stellt das robuste Rahmenwerk starke Merkmale f r den modellgetriebenen Prozess zur Verf gung insbeso
84. E CS Press 2008 Al Saad M Fehr E Kamenzky N Schiller J ScatterClipse A Model Driven Tool Chain for Developing Testing and Prototyping Wireless Sensor Networks In 6th IEEE International Symposium on Parallel and Distributed Processing and Applications pp 871 886 IEEE CS Press 2008 21 Jede der aufgelisteten Ver ffentlichungen wurde von mir in der jeweiligen Konferenz pr sentiert 184
85. ETs durch die weitaus m chtigere oAW Engine und der EMF Editor durch das Graphical Modeling GMF abgel st Dies entspricht auch der Zusammensetzung der Werkzeuge der generativen Infrastruktur von ScatterClipse 2 4 Graphical Modeling GMF Wurde das Metamodell einer DSL definiert w re es optimal einen auf das Metamo dell zugeschnitenen Editor f r die DSL automatisiert zu erzeugen Dies bewerkstel list das im Juni 2006 ver ffentlichte Graphical Modeling GMF das mit dem im letzten Abschnitt behandelten EMF zusammenarbeitet Die enge Zusammenarbeit wird in erster Linie vom Common Layer der Runtime Component im GMF abgewickelt Dies wird durch die F higkeit der Runtime Com ponent erm glicht die entsprechenden Dienste vom EMF in Anspruch zu nehmen und diese in Verbindung mit den eigenen Funktionalit ten einwandfrei auszuf h ren Die erfolgreiche Zusammenarbeit zwischen den beiden Werkzeugen zeigt sich insbesondere an der Unterst tzung der grafischen Validierung von Ecore basierten Modellen im GMF Editor wodurch die Modellintegrit t gew hrleist wird Um die auf Basis des Ecores definierten Modelle mit einer ausdrucksstarken Semantik zu formalisieren erm glicht es GMF dom nenorientierte Randbedingungen an die je weiligen Modelle zu binden Hierzu werden die Randbedingungen mit Hilfe von Ausdr cken der Object Constraint Language OCL WebOCL spezifiziert Die OCL Ausdr cke werden dann mit Hilfe eines zugeh rigen Wizards an da
86. Freie Universitat Dissertation zur Erlangung des akademischen Grades eines Doktors der Naturwissenschafen im Fachbereich Mathematik und Informatik der Freien Universitat Berlin ScatterClipse Architekturzentrierte Plattform und Werkzeuge f r Entwicklung Test und Verwaltung drahtloser Sensornetze Disputationsvortrag 12 02 2010 Bearbeitet von Mohammad Al Saad Kniephofstra e 23a 12157 Berlin Gutachter Prof Dr Ing Jochen Schiller Prof Dr rer nat habil Jochen Seitz Eidesstattliche Erkl rung Hiermit erkl re ich an Eides statt dass ich die vorliegende Arbeit selbst ndig und ohne fremde Hilfe verfasst habe und keine anderen als die angegebenen Hilfsmittel verwendet habe Die Arbeit wurde in gleicher oder hnlicher Form keiner anderen Pr fungsbeh rde vorgelegt Berlin den 9 November 2009 Mohammad Al Saad Danksagung Zuerst danke ich Herrn Prof Schiller dass er es erm glicht hat dieses Projekt zu verfolgen und mich w hrend meiner Promotion betreut und begleitet hat Des Weiteren danke ich mich bei Frau Prof Fehr f r ihre Unterst tzung und Zusammenarbeit in den letzten f nf Jahren in denen ich diese Arbeit abschlie en konnte Mein Dank geht auch an Herrn Prof Seitz f r seine Bereitschaft das Zweitgutachten f r die Dissertation zu erstellen Dr Hartmut Ritter danke ich seine Mitwirkung an der Entstehung dieser Arbeit Mit Liebe danke ich meiner Mutter die mir aus der Ferne beigestan
87. GRATIS http w3 isis vanderbilt edu projects nest gratis WebHome Wikipedia Art Home Automation http en wikipedia org wiki Home_automation WebICSNC 3rd International Conference on Systems and Networks Communications http www iaria org conferences2008 ICSNC08 html WebITU International Telecommunication Union http www itu int en pages default aspx WebTTCN Testing and Test Control Notation http www tten 3 org WebJavaCom Sun The Java Communications API http java sun com products javacomm WebJeck Jeckle M XML Metadata Interchange XMI www jeckle de xmi htm WebJFreeChart JFreeChart http www jfree org jfreechart 181 WebJ Unit Wikipedia Art JUnit http en wikipedia org wiki JUnit WebLog4j Log4j Rahmenwerk http logging apache org log4j WebMDA Model driven Architecture MDA http www omg org mda WebMDSD Model Driven Software Development www mdsd info WebMOF OMG Meta Object Facility MOF http www omg org mof WeboAW OpenArchitectureWare oAW http www openarchitectureware org WeboAWDoc oAW Dokumentation Version 4 2 http www openarchitectureware org pub documentation 4 2 html contents index html WebOCL OMG Object Constraint Language Specification OCL v2 0 http www omg org technology documents formal ocl htm WebOMG Object Management Group OMG http www omg org WebOSGI Seite der OSGI Allianz http www osgi org Main HomePage WebPerv
88. Klassendiagramm des zu testenden Systems dargestellt werden W hrend der Ausf hrung des Tests ruft der generierte Testfall die modellierten Methoden auf die durch eine vom Modell des getesteten Systems generierte Adapter Klasse implementiert werden In diese systemabh ngigen Adapter Klassen muss der Benutzer den ad quaten Code f r das jeweilige System einmalig manuell implementieren Somit fungieren die UML basierten Aktivit tsdiagramme zum Einen als Abstraktionsmechanismus zur plattformunabh ngigen Testdurchf hrung f r SOA gest tzte Anwendungen und zum Anderen wird die verteilte technologieunabh ngige Testdurchf hrung koordiniert Betrachtet man die Spezifikation des UML Testing Profiles so handelt es sich um ein 113 Seiten umfassendes Papier dessen Handhabung ein recht komplexes Unterfangen ist Oft werden nicht alle im Profil angebotenen Eigenschaften zum unterliegenden Testszenario ben tigt Nichts desto trotz muss man sich zun chst mit dem gesamten Profil befassen um zu den relevanten Aspekten zu gelangen die verwendet werden sollen Dar ber hinaus haben die recht komplexen UML basierten Modelle gegen ber einer dom nenspezifischen Sprache DSL wie sie in Visual ScatterUnit eingesetzt wird den Nachteil dass sie nicht ber ein so ausf hrliches Wissen der Dom ne verf gen wie die in DSL erzeugten Modelle Da die Modellelemente der DSL f r konkrete architektonische Konzepte oder Aspekte der Dom ne stehen bietet ein in DSL
89. Konfiguration der Laufzeitumgebung werden mit Hilfe von Scat terFactory2 diverse Hilfsdateien mitgeneriert wie XML Build f r das ANT Plugin sowie die n tigen Makefiles f r den Kompilierungsprozess In der bisherigen Behandlung des automatisierten Testprozesses in Visual Scat terUnit wurde stets vorausgesetzt dass die zu testende Anwendung also das Test objekt bereits vorliegt Daher wurde die M glichkeit dass eine Anwendung gleich zeitig entwickelt und getestet wird bisher nicht behandelt Eine umfassende Hand habung des Entwicklungsprozesses der Anwendung verlangt jedoch die Anwen dungsentwicklung und den Anwendungstest auch gemeinsam zu betrachten da da durch die Effizienz des gesamten Prozesses optimiert wird Da in ScatterFactory2 die Laufzeitumgebung einer Anwendung f r verschiedene Sensoren unterschiedlich konfiguriert werden kann muss man im Modell eindeutig ausdr cken k nnen mit welcher Laufzeitkonfiguration der Testfall einer Anwendung assoziiert ist Es ist beispielsweise m glich dass nicht alle zu modellierenden Sensoren eines WSNs ber die gleiche Hardwareausstattung verf gen was zur Folge hat dass ihre Laufzeit umgebung entsprechend unterschiedlich im Diagramm modelliert werden muss Je doch unterliegen die Sensorknoten dem gleichen Testszenario und somit dem glei chen Testfall zu dem sie alle im Modell assoziiert werden m ssen Umgekehrt gilt auch dass bestimmte Testf lle eine gewisse Konfiguration der
90. LL CheckPacketintegrity Assertion Log Labels SecondRadioPacket Abbildung 24 Visualisierung der Fehlermeldung im Modell durch den Einbau von entsprechenden Icons Links der Aktionen Damit sind die fiir den Test relevanten Informationen fiir den Benutzer leicht hand habbar so dass er auf tibersichtliche Weise zwischen den Diagrammen zwecks In formationsgewinnung zum Ausgang des Testverlaufs navigieren kann Ohne die Vi sualisierung der Fehlermeldungen durch die Verbindung zwischen den aufgetrete nen Fehlern und deren korrespondierenden Modellkonstrukten im Testfalldia gramm m sste der Benutzer um die protokollierten Informationen des Testverlaufs nachvollziehen zu k nnen die Eintr ge des textuellen Logs selbst in den Kontext des Testszenarios einbetten was eine recht komplexe und zeitaufw ndige T tigkeit w re Die optimierte Lesbarkeit der Testresultate vereinfacht ebenfalls den Einsatz von Log Aktionen um die Nachvollziehbarkeit der Fehlermeldungen zu verbessern Er h lt man die Testresultate wie in Abbildung 24 gezeigt stellt man m glicherweise bei der Begutachtung der f r die Aktion LogRadioPacket geloggten Daten fest dass die Nutzlast abgesehen vom letzten Byte das bei der bertragung verloren ge gangen ist unbesch digt ist Dies f hrt beim Benutzer zu der Vermutung dass beim Versenden des Pakets die L nge der Nutzlast m glicherweise falsch angegeben wurde Er erh lt so einen Anhaltspunkt wo er im Code des
91. Laufzeitumgebung voraussetzen So kann ein Testfall der die Simulation von Sensormessungen ben tigt nur mit denjenigen Sensorknoten assoziiert werden die ber die entsprechende Konfiguration dieser Module verf gen Kann eine fehlerfreie Verkn pfung zwischen den Testf llen und ihren korrespon dierenden Laufzeitkonfigurationen der unterschiedlichen Sensorknoten modelliert werden so ist die gew nschte Integration des Testprozesses im Kontext der Soft warefamilienfertigung erreicht Daher wurde die Modellierung in ScatterFactory2 derart erweitert dass Instanzen die konkrete Testf lle repr sentieren mit den in diesen Testf llen involvierten Sensorknoteninstanzen im Modell verbunden werden k nnen wobei diesen ihre Laufzeitkonfiguration jeweils im selben Modell zugewie 61 Das File Allocation Table FAT auf Deutsch etwa Dateizuordnungstabelle ist ein Da teisystem und wurde von Microsoft entwickelt FAT ist die einzige bedeutende Neuerung von QDOS gegen ber CP M Nach langen Rechtsstreitigkeiten und einem zweij hrigen Pa tentierungsverfahren wurde am 10 Januar 2006 das Patent und die damit verbundene e norme Marktmacht f r FAT FAT12 16 32 etc der Herstellerfirma Microsoft zugespro chen Das deutsche Bundespatentgericht erkl rte eines der beiden diesen Schutz begr n denden Patente bzgl eines gemeinsamen Speicherbereiches f r lange und kurze Dateina men DE 69429378 bzw EP 0618540 oder US 5 758 352
92. Models 08 41 Abbildung 23 zeigt ein Diagramm das die Aktionen der Aktivit t AwaitSecond Packet beinhaltet Sobald das erwartete Paket empfangen wurde wird der daf r in ScatterUnit zust ndige Dienst abgefragt um die entsprechende Benachrichtigung abzuschicken Diese Benachrichtigung wird anhand eines Ereignisses namens Se condPacketReceived repr sentiert Dann folgt die Aktion AbortIfTimeOut f r die der Code manuell implementiert werden muss um die Ausf hrung des Testfalls abzubrechen wenn das Datenpaket nicht empfangen wurde Manuell zu implemen tierende Aktionen werden im Diagramm durch eine graue Schattierung gekenn zeichnet Wenn das Paket empfangen wird und somit kein Fehler diesbez glich in der Anwendung aufgetreten ist wird dessen Inhalt anhand der Aktion LogRadio Packet geloggt Mit der Log Marke Log Label SecondRadioPacket wird auf die Aktion Bezug genommen und so kann die Integrit t der Aktion mit der Pr froutine Assertion CheckPacket Integrity berpr ft werden WH AwaitSecondPacket Await Radio Packet Action Sending Node 1 Addressed Node 4 Packet Type 101 Timeout 1 000 Additional Checking false Processing Time AFTER H SecondPacketReceived Radio Packet Received Event E AbortifTimedOut Control Action Mr LogRadioPacket Radio Packet Log Action Log Label SecondRadioPacket Detail ALL fe CheckPacketintegrity Assertion Log Labels SecondRadioPacket Abbildung 23 Verfein
93. OM RAM Speicher Speicher ScatterWeb Firmware 032752 Bytes 001402 Bytes ScatterWeb Testing Layer 006386 Bytes 000134 Bytes EMPTY Anwendung 1376 Bytes 000002 Bytes DSR Routing Protokoll 3132 Bytes 000470 Bytes Directed Diffusion Routing 21426 Bytes 000458 Bytes Protokoll Testfallcode Beispiel 490 Bytes 000004 Bytes Verf gbarer Speicher 61440 Bytes 002048 Bytes Tabelle 4 Beanspruchung der Betriebsmittel eines Sensorknotens ESB Kame07 In der Tabelle werden neben dem fixen Speicherverbrauch der Firmware und der Testautomatisierungsschicht drei unterschiedliche repr sentative Testobjekte ber cksichtigt Es handelt sich dabei um die Referenzanwendung EMPTY das Directed Diffusion Ablaufprotokoll und das DSR Ablaufprotokoll W hrend der Speicherplatzverbrauch des Testobjektes je nach Gr e der zu testenden Anwendung variiert ist er sowohl bei Firmware als auch bei der Testautomatisierungsschicht eine feste Gr e die stets in Betracht gezogen werden muss Dies zeigt Abbildung 71 die veranschaulicht welchen festen Speicherverbrauch bez glich des RAM und ROM Speichers die Firmware und die Testautomatisierungsschicht ben tigen Der brigbleibende Speicherplatz steht dem Bedarf der zu testenden Anwendung und dem Testfallcode zur Verf gung Wie der Grafik zu entnehmen ist ben tigt die Firmware ca 53 und die Testautomatisierungsschicht weitere 10 des 60 KB gro en ROM 10 Die Untersuchung bezieht sich auf die ESB Scatt
94. Plattform konfrontiert wird Dadurch entfernt sich der Fokus von der eigentlichen Problemstellung n mlich dem optimalen Entwurf f r einen Testverlauf aus dem sich im Laufe der Testdurchf hrung pr zise Hypothesen formulieren lassen mit denen die Versagensursache lokalisiert werden kann Zwar bietet die manuelle Testdurchf hrung nur eine eingeschr nkte Palette an Funktionalit ten hinsichtlich der Fehlersuche jedoch wurden schlie lich s mtliche Fehler in der Implementierung des Routingprotokolls aufgefunden Sicherlich spielt hier eine wesentliche Rolle dass die Fehler durch die zuvor durchgef hrte Fallstudie bereits bekannt waren Dennoch wurden aussagekr ftige Erkenntnisse gewonnen gerade wenn man den Aufwand der manuellen Testdurchf hrung mit der modellgetriebenen Testdurchf hrung vergleicht Dies zeigt Abbildung 79 in der angegeben wird wie viele Codezeilen notwendig waren um den Testfall des gleichen Testobjekts einmal manuell und einmal automatisiert durchzuf hren 129 600 manuell erstellter Code E generierter Code 450 300 150 modeligetrieben manuell Abbildung 79 Ben tigte Codegr e in Codezeilen fiir die Testfallentwicklung Kame08 Betrachtet man den ben tigten Code beider Varianten wird schnell ersichtlich dass bei der modellgetriebenen automatisierten Variante insgesamt wesentlich mehr Code notwendig ist Dies ist jedoch kein Indiz daf r dass der Test dadurch aufwendiger wird Der gr ere
95. Positionen entsprechenden Koordinaten vom Benutzer platziert Hierf r stellt das Plugin die entsprechenden Wizards und Funktionalit ten zur Verf gung die im Anhang 11 3 1 veranschaulicht werden S mtliche aus dem Wizard entstandenen Konfigurationsdateien z B f r Castor und Log4j werden nun automatisch im Verzeichnis des WSN Projekts in der Eclipse Umgebung abgelegt vgl Abbildung 53 So kann der Benutzer mehrere Sensornetze mit unterschiedlichen 92 Java Eclipse SDK File Edit Source Refactor Navigate Search Damen Run Window Help ri on 0 q k KAD Close Project Tv Build Working Set v Build Automatically Develop C Generate Javadoc Project directory of the created WSN Scatterweb a Scan Network Properties X Stop Network Start Network add Sensor Abbildung 53 Eclipse Projekt f r das ScatterWeb WSN Mysl06 Konfigurationen kreieren und bersichtlich verwalten Desweiteren kann der Benutzer mittels des Root Plugins eine Verbindung zu jedem beliebigen WSN aufbauen und das WSN nach neu hinzu kommenden bzw nicht mehr vorhandenen Knoten scannen Neue Knoten werden flexibel vom Benutzer ins WSN aufgenommen Die gesamte Konfiguration des WSNs wie die Daten des Grundrisses Pfad Gr e die Koordinaten der vom Benutzer platzierten Sensorknoten sowie der Status jedes einzelnen Knotens k nnen nun mit Hilfe des CastorRahmenwerks im XML Format abgelegt werden Die XML Se
96. Routingprotokolls nach der Fehlerursache suchen kann Dieses Beispiel zeigt wie man im Modell flexibel anhand der benutzerdefinierten Log Aktionen navigiert um die Fehler im Code der zu testenden Anwendung zu lokalisieren Nachdem ein Fehler nach der Ausf hrung des Testfalls erkannt wurde ist der folgende Schritt die Korrektur des Fehlers Bevor jedoch die betroffene Codestelle korrigiert werden kann muss die Ursache der Fehlerentstehung innerhalb des Co des lokalisiert werden Dies wird im Allgemeinen bewerkstelligt indem die Code stelle fortschreitend isoliert wird bis der Fehler zielgenau lokalisiert wurde Der Ab lauf dieser Aktivit t wird in Abbildung 25 veranschaulicht Agans in Agan02 emp fiehlt an dieser Stelle einen Teile und Herrsche Ansatz Corm90 Um das oben beschriebene Vorgehen zu illustrieren betrachten wir das folgende im Kontext des Routings bliche Szenario Angenommen der Testfall entdeckt einen Fehler in der Anwendung der darin besteht dass nicht alle Sensordaten zur Senke korrekt bertragen wurden Die Ursache kann m glicherweise auf ein Versagen bei der Erfassung der Umgebungsdaten der jeweiligen Sensorknoten zur ckzuf hren sein Eine weitere m gliche Ursache liegt in der bertragung der Daten Um nun 45 festzustellen welche der beiden M glichkeiten die Ursache war muss zun chst berpr ft werden ob die vom Sensorknoten erfassten Daten im Sensorknoten selbst vollst ndig gespeichert wurden Ist
97. Texten existieren mittlerweile diverse andere Editoren z B zur Bearbeitung von Audio und Grafikdateien sowie von Webseiten Je komplexer das zu bearbeitende Element ist desto h her sind die Anforderungen an den jeweiligen Editor F r gute Editoren gilt dass sie dem Benutzer die Arbeit erleichtern Dieses Prinzip l sst sich auf WSNs bertragen die in der gegenw rtigen ra des ubiquitous and pervasive computing eine zentrale Rolle spielen und immer mehr Anwendungsbereiche finden Die Herausforderungen hinsichtlich ad quater Steuerung und berwachung der sich im Betrieb befindenden Sensorknoten sowie der Fehlerbehebung steigen entsprechend und damit die Anforderungen an die dazugeh rigen Werkzeuge ScatterEditor Ding07 ist ein solches Werkzeug das die genannten Dienste auf eine illustrative Weise zur Verf gung stellt und so den Benutzer in die Lage versetzt sie interaktiv in Anspruch zu nehmen und damit das WSN zu editieren ScatterEditor ist ein Eclipse basiertes Rahmenwerk mit einer Plugin orientierten Architektur Durch die Kombination der Plugins erm glicht ScatterEditor die Over The Air Konfigurierung Steuerung und berwachung der Sensorknoten bereits w hrend ihres Betriebes Diese Merkmale k nnen dank der Internet Integration von ScatterEditor sowohl im lokalen Modus als auch entfernt im Internet basierten remote Modus genutzt werden Neben der Integration von IP und ScatterWeb wird bei der Gestaltung von Scatter Edit
98. The IP from the list are allowed to connect 5 1927168 0 3 The IP from the list are denied to connect Remove IP from the List 1 mom Renee Insert IP to the List Abbildung 87 Serverkonfiguration zur Klientenverwaltung Ding07 In 1 wird dem Administrator die M glichkeit gegeben das automatisch generierte Passwort zu ndern In 3 kann die Firewall eingestellt werden indem festgelegt wird nach welchem Modus die eingehenden IPs der anfragenden Klienten gefiltert werden So ist es m glich die in der Liste eingetragenen IPs auszuschlie en so dass alle von ihnen stammenden Nachrichten zur ckgehalten werden Alternativ k nnen nur diejenigen Anfragen zugelassen und somit bearbeitet werden die aus Rechnern stammen deren IPs in der Liste 2 eingetragen sind Die Eingabe und Entfernung der IPs aus der Liste geschieht der Reihe nach mittels der Funktionen 4 und 5 159 11 4 Das Metamodell der Dom nensprache Igel mm yumpajage H yur H asepisal H x0 bulwodul lt 0 Buliono JINOS yab e sul UOIUYEP m y H JSW 0 0 sajnysay iy sajnyseriy Aresqgiy H vonesuddy H aponsosuses H dea dea SWeU m aponwesbeig H x0 saponweibeip WEIBEIQ4YJOMISNJOSUSSSSIjaIIM H Abbildung 88 Das Metamodell der DSL in ScatterFactory2 Kame08 160 H TestCaseDiagram syncNodes 0 t N initialNode El SyncNode finalNode H InitialNode 0 1 H InitialNodeOfTheTestCase FinalNode 5
99. Wesley Longman Amsterdam 2001 Perk94 Perkins C Bhagwat P Highly Dynamic Destination Sequenced Distance Vector routing DSDV for mobile computers ACM SIGCOMM Computer Communication Review 24 4 234 244 1994 Petr06 Petrasch R Meimberg O Model Driven Architecture Eine praxisorientierte Einf hrung in die MDA Dpunkt Verlag Heidelberg 2006 Rafi03 Rafiq O Cacciari L Coordination algorithm for distributed testing The Journal of Supercomputing 24 pp 203 211 2003 Rome04 Romer K Mattern F The Design Space of Wireless Sensor Networks IEEE Wireless Communications 11 6 pp 54 61 2004 Rupp05 Rupp C Hahn J Queins S Jeckle M Zengler B UML 2 glasklar Praxiswissen fiir die UML Modellierung und Zertifizierung Hanser Miinchen 2005 Rupp07 Rupp C Queins S Zengler B UML 2 Glasklar Praxiswissen fiir die UML Modellierung Hanser M nchen 20073 Sadi07 Sadilek D A Prototyping Domain Specific Languages for Wireless Sensor Networks In Favre J M Gasevic D L mmel R Winter A eds 4th International Workshop on Software Language Engineering Engineering of Metamodels Schemas Grammars and Ontologies Informatik Bericht Nr 4 pp 76 91 Mainz 2007 Sadi08 Sadilek D A Domain Specific Languages for Wireless Sensor Networks In K hne T Reisig W Steimann F eds Modellierung 2008 LNI 127 pp 237 241 Gesellschaft f r Informatik Bonn 200
100. Wireless Sensor Networks In 2nd International Conference on Systems and Networks Communications pp 37 47 IEEE CS Press 2007 Alsa07c Al Saad M Ding J Schiller J ScatterEditor An Eclipse based Tool for Programming Testing and Managing Wireless Sensor Networks In International Conference on Sensor Technologies and Applications pp 59 69 IEEE CS Press 2007 Alsa08a Al Saad M Kamenzky N Schiller J Visual ScatterUnit A Visual Model Driven Testing of Wireless Sensor Networks Applications In 11th International Conference on Model Driven Engineering Languages and Systems pp 751 765 LNCS Vol 5301 Springer Berlin Heidelberg 2008 Alsa08b Al Saad M Fehr E Kamenzky N Schiller J Automated Testing of WSN Applications In 3rd International Conference on Systems and Networks Communications pp 157 167 IEEE CS Press 2008 Alsa08c Al Saad M Fehr E Kamenzky N Schiller J ScatterFactory2 An Architecture Centric Framework for New Generation ScatterWeb In 2nd International Conference on New Technologies Mobility and Security 6 Pages IEEE Xplorer 2008 Alsa08d Al Saad M Fehr E Kamenzky N Schiller J ScatterClipse A Model Driven Tool Chain for Developing Testing and Prototyping Wireless Sensor Networks In 6th IEEE International Symposium on Parallel and Distributed Processing and Applications pp 871 886 IEEE CS Press 2008 Baar07 Baar M K ppe E Lier
101. aktiv operieren wobei f r jeden Befehl die dazugeh rige Meldung vom adressierten Knoten in Abh ngigkeit von dessen Status versendet wird Das folgende Beispiel demonstriert wie die Terminalbefehle verwendet werden 21 stp 99 Die ID des adressierten Knotens folgt dem Zeichen Im Falle des Nichtvorhandenseins des Zeichens und somit auch der ID wird das eGate adressiert Nach der Adressierung folgt dann der Befehl Im hier behandelten Beispiel ist dies stp Set Transmission Power der bewirkt dass die Sendest rke des Sensorknotens konfiguriert wird 99 steht f r den Parameter der seinem Befehl stets folgt Es ist au erdem m glich einem Befehl mehrere Parameter zu bergeben 104 Java Eclipse SDK File Edit Navigate Search Project Run Window Help DE Di O A amp i SHO AV iG E amp va Problems Javadoc Declaration BRETTEN eae ScatterServer Connection Property Terminal Alarm Log OTA Flashing rst UNKNOWN COMMAND DCO CF BCS B7 Id 1 transmitPower 99 rxReceiveLimit 2200 logLevel rlo 01 NO rlb 00 DISABLED FirmwareFlags rff 03 PROGRAMMABLE DCOCHECKER ImageData FLASH eGate eGate 3 00 1600 970C Jun 23 2006 20 32 08 ImageData EEPROM eGate eGate 3 00 1600 970C Iun 23 2006 20 32 08 Commands list Please click a Command For more details est Command Details Command Parameter Location ECR est ScatterWeb Sys X Description prin
102. ald der Benutzer zur Modellierungszeit mit der Maus ber das Modelldiagramm navigiert Diese Funktionalit t dient der besseren Handhabung bei der Zusammenstellung der Modellkonstrukte w hrend der Model lierung In 4 ist das Problem View des Eclipse Rahmenwerks zu sehen in dem die gem dem Metamodell definierten Attribute eines Modellelements angezeigt wer den wenn das betroffene Modellelement im Diagramm in der Editorfl che ausge w hlt wird 53 Die MSBs kommen hier noch nicht in Betracht da das gesamte Rahmenwerk hinsichtlich der neuen Generation der MBS Sensorknoten optimiert wurde was sp ter in diesem Kapitel in einem eigenen Abschnitt ausf hrlich behandelt wird 74 M model scatterweb_diagram X B Outline 33 Palette ug I Select Zoom Note 2Scaterweb Pt ESB pee ECR Filterrule nz Containers amp Compo amp Application Container UserdefinedComponent Comm Component Configuration Component w uses gt Connections SimpleContainer SensorApplicationCon gt App provided Port E Connection required Port nd a1 tnt 0 Problems Javadoc Declaration Console F Properties 5 Core Application EMPTY 3 Appearance lt a fai Property Container Name Namespace Stereotype ll m 3 3 a a M Abbildung 42 Der ScatterFactory Editor Hent06 Somit kann der Benutzer neben der g
103. ald man jedoch das erste Modellkonstrukt des Aktivit tsdiagramms gebildet hat muss unmittelbar danach auf die in diesem Zusammenhang getroffene semantische Regel verwiesen werden Hier kommt die Livevalidierung des Modells zum Zuge Zu diesem Zweck m ssen die entsprechenden Randbedingungen mittels der Sprache Checks vgl Kapitel 2 5 definiert werden Im Programmauszug 2 werden die dazu notwendigen Checks Ausdr cke aufgelistet Ein wichtiger semantischer Aspekt des Aktivit ts ber sichtsdiagramms ist die Struktur der Assoziation Verbindung zwischen den Dia grammelementen Abbildung 29 zeigt den relevanten Ausschnitt des Metamodells Analog zur editorbedingten Besonderheit l sst das Metamodell beliebig viele ein und ausgehende Assoziationen f r jede Diagrammentit t zu Jedoch d rfen zum Startknoten keine Assoziationen eingehen und aus dem Endknoten keine ausgehen Diese Modellierungsvorgabe muss auf Editorebene eingehalten werden Um dies zu gew hrleisten werden entsprechende OCL Randbedingungen an die Metamodell konstrukte gebunden vgl Programmauszug 3 Dies bewirkt dass jegliche falsche Assoziation bei den betroffenen Diagrammentit ten von vornherein im Editor aus geschlossen wird 39 Eine Auflistung der in Visual ScatterUnit definierten Randbedingungen findet sich im Anhang 11 5 1 51 context testcase Testverlauf Uebersichtsdiagramm ERROR Es muss genau ein Startknoten existieren this startknoten
104. and hnlich wie in 2 Re ee DD Sensorknoten 1 bricht die Ausf hrung des Testfalls nach time out ab Das Log wird durch verschiedene Pr froutinen bearbeitet wobei jede Pr froutine f r die berpr fung bestimmter Arten von Fehlern zust ndig ist Somit wird eine Separierung von Belangen bei der Analyse und Auffindung der Fehler erreicht was zu einer optimierten und strukturierten Bearbeitung des Logs f hrt So meldet bei spielsweise eine der Pr froutinen dass Sensorknoten 1 das zweite Datenpaket nicht erfolgreich versenden konnte Das besondere dabei ist dass diese Aktivit t unmit telbar nach der Topologie nderung ausgef hrt wurde Um die korrekte Ordnung der dezentralen Ausf hrung der Aktionen zu gew hrleisten wird ein spezieller Dienst in ScatterUnit zur Verf gung gestellt n mlich der Befehle Dienst Command Servi ce Nach der Ausf hrung einer Aktion auf einem Sensorknoten wird ein dazu de signierter Befehl Signalisierung an denjenigen Sensorknoten verschickt auf dem die n chste Aktion ausgef hrt wird Solche Signalisierungen fungieren als Markierungen zur Koordination des auf verschiedene Knoten verteilten Testverlaufs Auf der Grundlage solcher Signalisie rungsbefehle kann nach der Beendigung des Tests ein koh rentes Log konstruiert 36 Eine Auflistung der unterschiedlichen Dienste von ScatterUnit findet sich in 4 4 in dem die technische Realisierung der Testautomatisierungsschicht ScatterUnit erl utert wir
105. anderen OMG Modellierungsstandards gt OMG angefertigt wurden k nnen auf nahezu jeder Plattform realisiert werden Die Modelle werden in einer Sequenz von Modelltransformationen in ausf hrbaren Code transformiert WebMDA Model Driven Software Development Modellgetriebene Softwareentwicklung MDSD MDSD ist ein gegenw rtig von Entwicklern und Forschern stark beachtetes Entwicklungsparadigma MDSD bezeichnet die Verwendung von Dom nensprachen DSL um Modelle zu erstellen welche die Struktur oder das Verhalten einer Anwendung in einer effizienten und problemorientierten Art und Weise ausdr cken Stah06 Object Constraint Language OCL OCL ist eine formale Sprache die zum Ausdruck von UML Modellen gt UML eingesetzt wird Diese Ausdr cke spezifizieren typischerweise unver nderliche Bedingungen die f r das modellierte System oder f r Anfragen ber an das Modell gebundene Entit ten eingehalten werden m ssen Wenn OCL Ausdr cke bewertet werden haben sie keine Nebeneffekte d h ihre Bewertung kann den Status des dazugeh rigen ausf hrenden Systems nicht ver ndern OCL Ausdr cke werden oft in UML Modellen verwendet um semantische und syntaktische Randbedingungen zu spezifizieren was als Standardtechnik von UML Profiles gt UML Profiles verwendet wird WebOCL Object Management Group OMG OMG ist ein 1989 gegr ndetes gemeinn tziges Konsortium f r IT Standards mit offener Mitgliedschaft Sie unterst tzt
106. arbeiten Im Rahmen der Testfallerstellung ist vor allem die Verringerung der dazu ben tigten Entwicklungszeit entscheidend da die Gew hrleistung der Qualit t der zu testenden Anwendung durchaus die Implementierung mehrerer Testf lle verlangen kann Was die Lokalisierung der Fehler anbelangt steht vor allem die Reduktion der dabei entstehenden Komplexit t im Fokus Da die Fehlerlokalisierung pr zisere Informationen verlangt m ssen hierzu die betreffenden Testf lle graduell erweitert werden um n here Informationen zur Fehlerlokalisierung zu gewinnen Die Kom plexit t muss also reduziert werden um den Entwickler in die Lage zu versetzen die Testf lle entsprechend flexibler zu modifizieren Diese Komplexit tsreduzierung wird durch Automatisierung erreicht Welche Abl ufe und Aktivit ten durch die erzielte Automatisierung beim Einsatz von Visual ScatterUnit stattfinden und wie die einzelnen Komponenten des Rahmenwerks zusammenarbeiten und untereinan der ihre Daten austauschen zeigt die Abbildung 15 Zu Beginn modelliert der Entwickler den Ablauf des Tests wodurch der Fluss und die Gliederung der f r den Testverlauf erforderlichen Aktivit ten festgelegt werden Die Modellierung geschieht mit Hilfe der speziell zu diesem Zweck entworfenen Do m nensprache DSL Dazu steht ein GMF basierter grafischer Editor zur Verf gung Abbildung 16 zeigt einen Bildschirmabzug des Editors Die Konstruktion der Dom nensprache d h die Festle
107. as Paket ScatterWeb math implementiert welches zahlreiche statistische Operationen und deren grafische Darstellung zur Verf gung stellt Diese reichen von einfachen Operation wie der Ermittlung des Medians und extremer Werte bis zur Ermittlung von Ausrei ern Korrelation Regression Trendlinien Standardabweichung und Interpolation um bestimmte Statistiken als glatte Kurve darstellen zu k nnen etc 95 Serie mathematisch gruppiert werden Dadurch ist es beispielsweise m glich eine komplexe Messserie durch die Gruppierung mehrerer Messserien z B zur Temperatur zu bilden die von unterschiedlichen Sensorknoten in unterschiedlichen Zeitspannen gemessen wurden Die Knoten k nnen dabei in verschiedenen Regionen platziert sein Die Streuung des Ortes und der Zeit wird bei der Berechnung der Statistik in Betracht gezogen Hinzugef gt werden k nnen Messserien die on the fly ermittelt werden w hrend die statistischen Operationen und deren zugeh rige Darstellung parallel darauf angewendet werden Folglich kann der Benutzer auch gegenw rtig im WSN ablaufende Ereignisse statistisch untersuchen und darstellen lassen Die Implementierung des Statistik Views beruht nicht nur auf der Eclipse Grafikbibliothek SWT vgl 2 1 sondern auch auf der Swing Bibliothek von Java Dies geht auf die Verwendung des JfreeChart Werkzeugs WebJFreeChart zur mathematischen Visualisierung der Statistikgrafiken zur ck JFreeChart ist ein Swing basiertes Opensour
108. asierte Rahmenwerk verf gt wie ScatterPlug ber eine Plugin orientierte Architektur und besteht aus kostenfreien Open Source Komponenten Neben der Integration in die Eclipse Plattform ist es m glich die zentralen Dienste von ScatterEditor sowohl im lokalen als auch im internetbasierten remote Modus in Anspruch zu nehmen Der webbasierte Zugriff macht es m glich die von ScatterEditor angebotenen Dienste auf die ScatterWeb Sensorknoten unter Bedingungen anzuwenden die den Einsatzszenarien von WSNs sehr nahe kommen So k nnen die Sensorknoten an einem beliebigen Ort dem f r das Experiment gew hlten Feld Sensingfield in Betrieb genommen werden w hrend man an einem anderen Ort diese Sensorknoten illustrativ und interaktiv berwachen programmieren und verwalten kann Der in Reiter Tabfolder aufgeteilte Aufbau bietet dem Benutzer die M glichkeit die jeweils ben tigten Dienste so zu kombinieren dass die sich erg nzenden Reiter in ihrer Gesamtheit als ein koh rentes Ganzes funktionieren Die verschiedenen Reiter bieten zahlreiche Funktionalit ten zur Konfiguration Steuerung und berwachung der sich im Betrieb befinden Sensorknoten So steuert der Connection Reiter den Verbindungsaufbau und die Kommunikation zum drahtlosen Sensornetz Der Property Reiter ist f r die Visualisierung des Status jedes sich im Betrieb befindenden Sensorknotens im WSN zust ndig Damit die Knoten auf einfache Weise w hrend des Betriebs konfiguriert werden k
109. asis des mit dem EMF erstellten Metamodells wurde gezeigt wie ein generativer dom nenspezifischer grafischer Editor mit Hilfe von GMF automatisiert erzeugt werden kann Da die dom nenspezifischen Sprachen DSL nicht in einem Guss entworfen sondern eher iterativ konstruiert werden zeigt sich die St rke der har monischen Integration beider Werkzeuge So ist es m glich den generativen DSL Editor GMF nach jeder Verfeinerung des Metamodells EMF automatisiert zu ge nerieren Die durch den Editor modellierten Konstrukte der Dom nensprache werden vom Generatorrahmenwerk openArchitectureWare oAW eingelesen validiert und im Anschluss auf deren korrespondierende Templates abgebildet um dann den Code generierungsprozess anzusto en Bei der Darstellung dieses Prozesses standen der Templates gest tzte Codegenerierungsprozess und dessen Bewerkstelligung mit Hilfe der von oAW gelieferten unterschiedlichen Arten von Templates im Mittel punkt Des Weiteren wurde auf die Validierung der Modelle der Dom nensprache eingegangen die durch die unterst tzte Integration zwischen EMF GMF auf der ei nen Seite und dem oAW Generatorrahmenwerk auf der anderen erm glicht wird Diese Integration verdankt sich dem vom oAW mitgelieferten GMF Adapter Dabei 24 wurde geschildert wie durch einen Watchdog alle nderungen der Modellkonstruk te im Editor zur Modellierungszeit berwacht werden und gleichzeitig in Abh ngig keit der vollzogenen Modell nderun
110. ausgestattet sind Ihre Energieversorgung erfolgt durch eine Batterie oder durch Mechanismen mit denen Energie aus der Umwelt bezogen wird Schi05 Die meisten WSN Anwendungen haben die berwachung oder Erkennung bestimm ter Ph nomene zum Ziel So werden in einer Vielzahl von Anwendungen zur ber wachung des Lebensraums von Wildtieren Naum08 Haushaltsautomatisierung Waldbranderkennung Garc08 und zur milit rischen berwachung WSNs einge setzt Die r ckg ngigen Kosten f r Sensorknoten erm glichen den Einsatz von WSN Anwendungen die gr ere R ume mit einer h heren Knotendichte abdecken Der Einsatz von Sensornetzwerken erfolgt bereits mit gro angelegten Netzwerken die aus Hunderten oder sogar Tausenden von Knoten bestehen Das Spektrum f r den Einsatz drahtloser Sensornetze wird im Laufe der Zeit noch komplexer und viel f ltiger Kuor05 Diese Steigerung von Ma stab und Komplexit t machen die An wendungsentwicklung f r WSN zeitaufw ndiger und fehleranf lliger Die Heraus forderungen bez glich Programmierung und Testen von WSN Anwendungen und damit die Anspr che an die dazugeh rigen Entwicklungsplattformen steigen ent sprechend Je anspruchsvoller die Verwendung der ressourcenschwachen drahtlosen Sensor netze wird desto robuster zuverl ssiger und effizienter muss die Entwicklung ihrer Softwareanwendungen vonstatten gehen Unerl sslich wird die Optimierung der Anwendungsentwicklung vor dem Hintergrund der erw hnte
111. bare Serie visualisiert Da jedoch die Objekte der Serie Klasse aus Kompatibilit tsgr nden nicht durch JFreeChart direkt geplottet werden k nnen wurde dieses Hindernis mittels der Implementierung der Schnittstelle TimeSerieEx bew ltigt Schritt 6 Diese erbt von der Klasse TimeSerie die von der JfreeChart mitgeliefert und somit visualisiert werden kann Schritt 7 5 Die Funktionalit t der NodeListener Klasse wurde in 6 1 bei der Behandlung der Kommunikationsschicht er rtert 96 J Remove Sensors Statistics i Battery i Beeper i GreenLED i Light i Microphone RedLED Problems Javadoc Declaration Console lul Statistics View 53 Sensor Module Statistik ian 1 00 Mean 0 75 Length 5 Std Dev g 050 Max 0 25 Min 0 00 20 00 00 00 04 00 08 00 12 00 T PORE Time Extreme Values Ss 2006 1219 16 15 58 609 OK 2006 12 20 16 15 58 609 ee a Auswahl des Sensorknoten und des Typs des zu messenden Wertes z B Temperatur Problems Javadoc Declaration Console Sensor Module Statistik Median 23 5 8 Temperature trend 8 Temperatu Mean 22 692307692307693 Ad Length 13 arene Std Dev 1 4215168163520255 Remove Serie e a Combine Series Modified Z
112. be executed on the same sensor node to report the event this hasPrecedingAwaitRadioPacket Action context testcase RadioPacketLogAction ERROR A preceding radio packet received event must be executed on the same sensor node this hasPrecedingRadioPacketReceivedEvent 163 context testcase BranchingPoint ERROR A branching point must not have any incoming links this incoming source forAll e e metaType testcase InitialNodeOfTheTestCase amp amp e metaType testcase SyncNode amp amp e metaType testcase ControlPath context testcase BranchingPoint ERROR A branching point must have at maximum one outgoing link this viewableOutgoingSuper size lt 1 context testcase BranchingPoint ERROR A branching point must not be linked to the final node this outgoing size gt 0 this outgoing target forAll e e metaType testcase FinalNodeOfTheTestCase true context testcase BranchingPoint ERROR A branching point must not be linked to the final node this outgoing size gt 0 this outgoing target select e e metaType testcase SyncNode outgoing notExists e e target metaType testcase FinalNodeOfTheTestCase true context testcase BranchingPoint ERROR A branching point must only be linked to a control path which is executed on a different sensor node this branch null amp amp this branch target metaType testcase
113. bestehen die meisten statischen Modelle berwiegend aus den folgenden Grundelementen Klassen As soziationen Attribute Aufz hlungstypen und Typisierungen der Attribute Dies ist hnlich bei Ecore Die gerade erw hnten Grundelemente entsprechen in der Ecore Klassenhierarchie den folgenden Klassen der Reihe nach EClass EReference EAttribute EEnum und EDataType Hiermit stehen die erforderlichen Schl sselkonzepte zur Verf gung um die abs trakte Syntax von eigens erstellten dom nenspezifischen Sprachen festzulegen Zur Bearbeitung von Ecore Modellen liefert EMF den entsprechenden Editor An dieser Stelle stellt sich die Frage wie man der durch EMF definierten abstrakten Syntax eine korrespondierende statische Semantik verleihen kann Auf der bislang betrachteten Ebene ist es durch EMF m glich die auf Basis von Ecore erstellten Modelle begrenzt auf deren semantische Korrektheit zu pr fen Da her werden lediglich z B die Korrektheit der Attributierung der Klassen bzw die Endungen der Assoziationen berpr ft Diese Beschr nkung ist jedoch bewusst im Entwurf von EMF enthalten um die Komplexit t der anspruchsvollen T tigkeit der Metamodellierung zu reduzieren Weitere fortgeschrittene Semantikdefinitionen werden auf die Modellierungsebene verlagert f r die eine Vielzahl von Wizards und Hilfswerkzeugen f r diverse Aufgaben vorhanden ist Andere komplexe Randbedin gungen die spezifische Eigenschaften und Gegebenheiten der dar
114. bezeichnet wird Abbildung 51 veranschaulicht diesen Vorgang 1 Die Strukturierung der Node Klasse in vom Benutzer beliebig konfigurierbare Module entspricht dem modularen Aufbau auf Hardwareebene bez glich der neuen Knoten Generation MSB Modular Sensor Board Dieser Aspekt war ausschlaggebend f r die Entwurfsentscheidung 90 Gan Log4j properties log4j rootLogger INFO log4j logger eGateLogger INFO eGateAppender log4j appender eGateAppender org apache log4j jdbc JDBCAppender log4j appender eGateAppender URL xxx eGate log4j appender eGateAppender user xxx a log4j appender eGateAppender password xxx Pa receive log4j appender eGateAppender sql nn NSERT INTO egatemsg VALUES NULL d yyyy MM dd HH mmiss m fa 2 3 log4j appender eGateAppender layout org apache W Patter Layout gt Logger info 4 d aD wy y 5 ur Logger info a D B Ce gt 4 SS Abbildung 51 Einsatz von Log4j zur Protokollierung der Nachrichten Mysl06 Zuerst wird die vom WSN stammende Nachricht s siehe 1 via eGate 2 mit Hilfe ihrer receive Methode 3 empfangen und anschlie end f r das Logger Modul aufbereitet Das Logger Modul transformiert die empfangene Nachricht gem dem vom Benutzer individuell definierten Muster in der Properties Datei zu s 4 diese wird abschlie end mittels der Logger info
115. bjekt sowie das Testobjekt selbst gemeinsam auf bersichtliche Weise modellierbar zu machen wodurch der ben tigte Code in einem Guss generiert werden kann Demzufolge ist die Testfallentwicklung nicht isoliert sondern im Kontext der Anwendungserstellung von Softwarefamilien zu betrachten Wie dies vonstatten geht wurde ebenfalls an einem Beispiel erl utert 87 6 ScatterPlug Der Pfad zur WSN Visualisierung und Analyse Mit ScatterPlug Mysl06 wird ein Plugin orientiertes Rahmenwerk f r die Sensorknoten der WSN ScatterWeb Plattform auf der Basis von Eclipse vorgestellt Neben Basisdiensten wie der Konfiguration von Sensorknoten stellt ScatterPlug auch komplexe Dienste zur Verf gung wie die Emulation und Modellierung der Knoten des WSNs im objektorientierten Paradigma die statistikorientierte Analyse der WSN Umgebung sowie die Visualisierung der analysierten WSN Daten und des Status der einzelnen Sensorknoten In den folgenden Abschnitten des Kapitels werden die Realisierung und die Merkmale der einzelnen Komponenten von ScatterPlug vorgestellt die Kommunikationsschicht die als Br cke zwischen dem Eclipse Rahmenwerk und der ScatterWeb Plattform fungiert das Root Plugin das als Grundger st der Architektur dient das Main View und das Statistic View die auf Basis des vorher behandelten Root Plugins arbeiten sowie deren Zusammenarbeit 6 1 Die Kommunikationsschicht Eine Br cke zur bidirektionalen Kommunikation zwischen dem Ecl
116. ce Werkzeug das im Vergleich zu anderen verwandten Opensource Werkzeugen eine starke Stabilit t im Einsatz aufweist Ausschlaggebend f r den Erfolg der Integration von JFreeChart in das Statistik View ist die Kommunikation zwischen beiden Seiten Abbildung 58 zeigt wie diese vonstatten geht sowie die daran beteiligten Komponenten Wird beispielsweise die Temperatur innerhalb einer bestimmten Zeitspanne untersucht so wird eine Schnittstelle vom Typ ModuleHistory erzeugt deren Aufgabe es ist die notwendigen Daten aus der Datenbank bereitzustellen Schritt 4 im Bild Sobald jedoch das angegebene Zeitfenster die aktuelle Zeit berschreitet werden alle vom WSN via eGate Schritt 1 ankommenden relevanten Daten direkt on the fly selektiert und zur Visualisierung verarbeitet Hierf r wird mit Hilfe der ModuleHistory eine Nodelistener Instanz erzeugt die gem der Benutzeranfrage die relevanten ankommenden Nachrichten herausfiltert Schritt 2 und anschlie end f r die folgenden Schritte als verarbeitbare Messserien zur Verf gung stellt Schritt 3 Die Messserien werden durch die Serie Klasse in der Datenstruktur repr sentiert Die Klasse Serie bildet die kanonische mathematisch zu verarbeitende Entit t Die ModuleHistory stellt die jeweilige Serie f r das entsprechende Modul des ScatterWeb math Pakets zur statistischen Berechnung bereit Schritt 5 Im Folgenden wird die aus dem vorausgegangenen Berechnungsschritt resultierende bzw bearbeit
117. ch da Aktionen die mit einem Richtungspfeil im Modelldia gramm verbunden sind zugleich in eben diesem Modelldiagramm ihren verschiede nen Sensoren eindeutig zugeordnet werden Wie man hier sehen kann wird die recht komplexe Aufgabe der technischen Realisierung der koordinierten Ausf hrung der Aktionen vom Codegenerator bernommen Der f r die Bewerkstelligung der Ausf hrungsanordnung automatisiert generier te Code ist das Herzst ck des Infrastrukturcodes der unterliegenden Dom ne in diesem Zusammenhang der automatisierte Test der ScatterWeb Anwendungen Denn dieser Code muss in Anspruch genommen werden um Testf lle mit Scatter Unit zu erstellen Demzufolge kann der Anwendungsentwickler bzw Tester den Fo kus auf den Entwurf des Testszenarios richten um den Testverlauf zu optimieren w hrend die komplexen technischen Details Erstellung des Infrastrukturcodes an den Codegenerator delegiert werden Neben diesem Infrastrukturcode zur Koordi nierung des Testverlaufs ist es in Visual ScatterUnit m glich den der Evaluierung der Testresultate korrespondierenden Infrastrukturcode ebenfalls automatisiert zu generieren Dies erm glicht einen visuellen automatisierten Debuggingprozess der ScatterWeb Anwendungen 3 5 Der visuelle automatisierte Debuggingprozess Nach der Terminierung der Ausf hrung des Testfalls steht ein Log zur Verf gung das s mtliche relevante Ereignisse enth lt die w hrend des Testablaufs stattgefun den haben
118. ch ausgef hrt werden konnte das Datenpaket beim Empf nger jedoch nicht ankam was darauf hinweist dass der Defekt bei der Weiterleitung des Pakets entlang der Route liegt Daher wurde eine weitere Verfeinerung des Testfallmodells vorgenommen indem eine Pr froutine zur berpr fung der Next Hop Informationen in der Tabelle vgl Abbildung 75 hinzugef gt wurde Nach dieser Modellerg nzung wurde der Testfall erneut durchgef hrt und es wurde anhand der neu definierten Pr froutine tats chlich ein fehlerhafter Eintrag bez glich des Next Hops festgestellt Die aufgestellte Hypothese hatte sich somit bewahrheitet Schritt 4 ben tigte Zeit ca 90 Minuten Die Beobachtung im vorherigen Schritt f hrte zur Erkenntnis dass das Versagen entweder an dem Austausch der Informationen unter den Routingtabellen der beteiligten Knoten oder an der Verarbeitung wie dem Auslesen bzw Eintragen der Tabelleninformationen liegen muss Diese Erkenntnis bestimmte den Verlauf der weiteren Schritte zur Durchf hrung des Testfalls um die Fehler zu lokalisieren So wurde zun chst das Testfallmodell um eine weitere Pr froutine namens WarteAufRoutingInfo erg nzt vgl Abbildung 76 die ein Anhalten im sendenden Knoten Knoten 1 bewirkt und zwar genau w hrend der Initialisierungsphase des Routingprotokolls da in dieser Phase der Austausch der Routingtabelleninformationen zum ersten Mal erfolgt Dieser Wartevorgang soll sicherstellen dass der sendende Knoten u
119. ch sein um R ckschl sse auf die Messungsgenauigkeit der Sensorik der einzelnen Sensorknoten zu ziehen Der Benutzer kann mittels Visual ScatterUnit visuell und automatisiert die Versagensursache in der Anwendung lokalisieren und parallel mit Hilfe der statistischen Analyse gesammelter Sensordaten in ScatterPlug berpr fen ob das Versagen etwa doch auf die Hardwaresensorik des Knotens zur ckzuf hren ist und nicht auf die Implementierung der darauf laufenden Anwendung Ein weiteres wichtiges Merkmal von ScatterPlug ist die F higkeit die gesamte Konfiguration des erstellten drahtlosen Netzes im XML Format zu speichern Somit k nnen die verschiedenen Plugins die XML Daten untereinander importieren bzw exportieren Wie man sieht arbeiten die Verwaltungsfunktionalit ten von ScatterPlug und ScatterFactory Hand in Hand mit den Funktionalit ten des modellgetriebenen Prozesses und erg nzen daher den Prozess der Softwareentwicklung Diese Zusammenarbeit welche ein wichtiges Kennzeichen der Plattform darstellt wurde architektonisch durch den Plugin orientierten Aufbau der ScatterClipse Werkzeugkette gem der Eclipse Plattform realisiert Folglich weist die Architektur der Plattform einen hohen Grad an Offenheit auf was ihre Interoperabilit t deutlich steigert Diese Eigenschaft ist essentiell insbesondere da in der dynamischen WSN Dom ne immer neue Fragestellungen auftauchen Der Benutzer kann sich einerseits bestimmter Plugins Funktionalit
120. che zur Anwendungsmodellierung festgelegt wird Die visuelle modellbasierte Erstellung der Anwendung geschieht mittels des generativen Editors GMF F r die berpr fung der Randbedingungen an die das jeweilige Modell gebunden ist wurde eine Echtzeit Validierung in den 86 Editor auf Basis der Checks Sprache integriert um den Entwicklungsprozess robus ter zu gestalten Des Weiteren wurde ScatterFactory2 vorgestellt das Nachfolgerahmenwerk das speziell f r die zweite Sensorknotengeneration optimiert wurde Es wurde ferner geschildert wie mit Hilfe der modularen formalen Modelle die Laufzeitumgebung der zu entwickelnden Anwendung vollst ndig und dynamisch konfiguriert werden kann Alle ben tigten Artefakte Firmwaremodule Treiber und Bibliotheken k nnen automatisiert erstellt werden So dient die automatisierte Laufzeitkonfiguration weiterhin der ma geschneiderten Codeerzeugung wodurch nur so viel Code f r die Sensorknoten erzeugt wird wie f r ihre jeweilige Rolle erforderlich ist Dadurch wird nicht nur der knappe Speicherplatz optimiert sondern es werden unn tige rechen und energieintensive Softwaremodule vermieden Der sinkende Anteil an manuellem Code reduziert zugleich die M glichkeit von Fl chtigkeitsfehlern der Programmierer Die gr te Leistung von ScatterFactory2 liegt in der F higkeit der Integration der Testfallmodelle in die formalen Modelle der Laufzeitumgebung Somit wird es m glich den Testcode f r das Testo
121. chner laufenden Pr froutinen sind f r die Ana lyse des Protokolls der Testergebnisse sowie die Aufdeckung der im Test auftre tenden Fehler zust ndig Insgesamt ist der effiziente Ablauf des Tests zwischen den beteiligten Sensorknoten vor allem auf die libScatterUnit Bibliothek zur ck zuf hren mit der die Laufzeitumgebung der Sensorknoten erweitert wird wo durch eine simultane Ausf hrung des Testobjekts und des dazu n tigen Testcodes erm glicht wird vgl Abbildung 38 Anwendung Testfall Testobjekt code ScatterUnit ScatterWeb Firmware Abbildung 38 Die Laufzeitumgebung der Sensorknoten ohne links und mit Erweiterung rechts Kam08 ScatterWeb Firmware Wahrend des Testverlaufs werden alle fiir das Verhalten der Anwendung relevanten Ereignisse auf dem jeweiligen Sensorknoten protokolliert Erst nach der Beendigung des Tests liest ScatterUnit Testautomation die Protokolleintr ge von jedem Sensor und erstellt daraus ein kollektives chronologisch geordnetes Protokoll zusammen Nun wird dieses Protokoll mit Hilfe spezieller Pr froutinen des Testautomation Rahmenwerks von ScatterUnit evaluiert und entsprechende Markierungen bzw Fehlermeldungen an den betroffenen Fehlerstellen im Protokoll eingef gt Auf Basis dieser Markierungen werden nun die Fehler und die protokollierten Daten vom Vi sualisierungs Plugin mit Hilfe der Blitz und i Symbole im Modelldiagramm an den entsprechenden Stellen illustriert vgl Abbild
122. chnischen Belangen wird oft mittels ei ner gesondert entwickelten Middleware Schicht bewerkstelligt Jedoch bleibt auch dann eine effektive Softwaremethodik und die dazugeh rigen Werkzeuge zur An wendungsentwicklung unverzichtbar However middleware trades off resource consumption for abstraction and programming convenience Some devices might not even be capable of hosting a middleware layer Therefore application development for AS NETs requires an extended software development methodology and tools in addition to existing software engineering techniques Ulbr05a Eine weitere Anforderung besteht hinsichtlich unterst tzender Funktionalit ten welche die erwarteten Werkzeuge dem Benutzer zur Verf gung stellen sollen um ihn bei der Bew ltigung der wachsenden Komplexit t zu unterst tzen In addition 1 Siehe Glossar to programming WSN application development involves a series of labor intensive tasks Application developers need to manually work on these tasks in ad hoc manners with various tools Those tools are often not interoperable and not well chained to improve developers productivity As a result it takes considerable time through a long sequence of tasks until developers run their applications The agility of WSN application development remains very low Wada07 Den Aspekt der Op timierung des Softwareentwicklungsprozesses drahtloser Sensornetze betonen auch Losilla et al in ihrem im September 2007 ver ff
123. cklungswerkzeuge bzw Umgebungen f r drahtlose Sensornetze in Betracht gezogen Dabei lag die Studie von Teng et al zugrunde Teng08 welche Ende Oktober 2008 auf ICSNC 08 vorgestellt wurde der gleichen Konferenz auf der auch gro e Teile der ScatterClipse Werkzeugkette vorgestellt wurden In dieser Studie wurden aktuell in der Forschung vorhandene repr sentative Werkzeuge und Umgebungen zur Entwicklung von Softwareanwendungen f r drahtlose Sensorknoten pr sentiert und die jeweiligen Ans tze verglichen Hierzu wurden zun chst die an solche Werkzeuge zu stellenden Anforderungen formuliert um auf dieser Basis einen Vergleich zwischen den Werkzeugen bzw Ans tzen vornehmen zu k nnen Anhand der in der Studie vorgenommenen Untersuchungen wurde klar dass die Entwicklungswerkzeuge den Testprozess der auf den Knoten laufenden Anwendungen so gut wie ausblenden was die Robustheit des gesamten Entwicklungsprozesses einschr nkt Ferner zeigte die Studie dass berwachungsfunktionalit ten w hrend der Anwendungsentwicklung in den Werkzeugen kaum unterst tzt werden Beides der automatisierte Test sowie die berwachung werden von ScatterClipse in den modellgetriebenen Softwareentwicklungsprozess nahtlos intergriert Danach wurden verwandte L sungsans tze diskutiert die sich dem Gebiet der Anwendungstests widmen Diese Beitr ge waren anhand von zwei Gesichtspunkten in Bezug auf die ScatterClipse Werkzeugkette zu untergliedern Einerseits werden
124. ckrat jeglicher Dom nensprache zu bewerkstelligen ist Es muss daher an dieser Stelle genauer unter die Lupe genommen werden wie das Aktivit tsdiagramm zum Zweck der Koordination des verteilten Testverlaufs auf Metamodellierungsebene konzipiert wird Abbildung 28 zeigt den f r den Auf bau des Aktivit tsdiagramms relevanten Ausschnitt des Metamodells der Dom nen sprache Dem Ausschnitt des Metamodells entsprechend ben tigt jedes Aktivit ts bersichtsdiagramm einen Startzustand zur Generierung des Initialisierungscodes des Tests Die Entit t Startknoten besitzt jedoch die Kardinalit t 0 1 anstelle von 1 was bedeutet dass das Vorhandensein eines Startknotens im Aktivit tsdiagramm nicht zwingend ist was offensichtlich semantisch nicht korrekt ist 50 Startknoten Verbindung Testverlauf Ubersichts diagramm Ablaufstrang2 Ablaufstrang Abbildung 28 Der relevante Ausschnitt des Metamodells links das die Entit ten des Aktivit tsdia gramms rechts sowie deren Zusammenh nge veranschaulicht Kame08 Dahinter verbirgt sich der Umstand dass editorbedingt ein mit Hilfe des generati ven Editors neu zu erstellendes Diagramm anfangs keine Diagrammkonstrukte be inhalten kann Da nun das Metamodell als Grundlage f r die automatisierte Erstel lung des generativen Editors fungiert muss man dieser technischen Herausforde rung bereits auf Metamodellebene begegnen Zwar wird dies syntaktisch zugelassen sob
125. d 38 werden das den verteilten Testablauf bez glich aller im Netzwerk beteiligten Sen sorknoten als geschlossenes und geordnetes Gef ge repr sentiert Dieser Vorgang ist offensichtlich eine recht komplexe Aufgabe insbesondere wenn man umfassende Tests durchf hren will Folglich erschwert sich f r den Entwickler die Implementierung des Testszenarios das als Leitfaden des gesamten Testver laufs fungiert erheblich Ist man in der Lage diesen komplexen Vorgang dem Ent wickler durch Automatisierung abzunehmen und ihn an einen Codegenerator zu de legieren erleichtert dies die Implementierung des Testszenarios erheblich wobei alle mit ScatterUnit erreichten Vorteile erhalten bleiben An dieser Stelle setzt das modellgetriebene Paradigma an was im kommenden Abschnitt n her behandelt wird Dabei muss sich der Entwickler lediglich auf den Entwurf des Leitfadens kon zentrieren also das passende Modell des Testszenarios erstellen dessen Imple mentierung weitestgehend automatisiert vonstatten geht Wie dies zu realisieren ist wird im folgenden Abschnitt genauer erl utert 3 4 Modellgetriebenes Testen in Visual ScatterUnit Das Hauptanliegen beim modellgetrieben Testen in Visual ScatterUnit ist die for male Modellierung des Testfalls um daraus den Code f r die von ScatterUnit ben tigten Testskripte automatisiert zu generieren Daher liegt der zentrale Punkt des mit Visual ScatterUnit verfolgten modellgetriebenen Ansatzes in
126. d im Modell angezeigt rechts Abbildung 33 Ausschnitt des attributierten Metamodells des Detaillierungsdiagramms Abbildung 34 Der generative Editor des Rahmenwerks Abbildung 35 Live Validierung deckt den ungiiltigen Namen einer Aktivitat auf Abbildung 36 Live Validierung deckt auf dass eine Aktivit t keinen Vorg nger besitzt Abbildung 37 Live Validierung entdeckt eine unzul ssige parallele Ausf hrung Abbildung 38 Die Laufzeitumgebung der Sensorknoten ohne links und mit Erweiterung rechts Abbildung 39 Markierungen zur Visualisierung der Testergebnisse in der Modellentit t Abbildung 40 Die Architektur von ScatterFactory Abbildung 41 Das Metamodell von ScatterFactory Abbildung 42 Der ScatterFactory Editor Abbildung 43 Modellierungsbeispiel einer Anwendung Abbildung 44 Gleichzeitiger Ablauf des Modellierungs und des Generierungsprozesses innerhalb von Eclipse Abbildung 45 Die generierten Artefakte in ScatterFactory Abbildung 46 Das Modell einer Laufzeitumgebung zweier MSB Anwendungen Abbildung 47 Eine Laufzeitumgebung mit einem assoziierten Testfall Abbildung 48 Das mit der Laufzeitumgebung assoziierte Diagramm des Testfalls TestCollectionProcess Abbildung 49 Das Datenmodell in ScatterWeb for Java Abbildung 50 Nachrichtenaustausch in ScatterWeb for Java Abbildung 51 Einsatz von Log4j zur Protokollierung der Nachrichten Abbildung 52 Automatisierte Datenserialisierung mit Hilfe des Castor Rahmenwerks Abbildung 53 Eclipse Proj
127. d verursacht Die gemessene Gesamtzeit die der Durchlauf eines Paketes ben tigte betrug 133 Millisekunden wobei 0 3 Millisekunden f r jeden Bearbeitungsschritt ben tigt werden was eine Erh hung von 0 2 Millisekunden pro Bearbeitungsschritt ausmacht Betrachtet man nun die minimal ben tigte Gesamtzeit des Bearbeitungsaufwands von 30 Millisekunden bei Deaktivierung s mtlicher Dienste zur Testautomatisierung und demgegen ber die maximal gemessene Zeit des Bearbeitungsaufwands von 153 Millisekunden bei Aktivierung des ereignisbasierten Wartedienstes und des Dienstes zur simulierten Konfiguration der Netztopologie w hrend des gesamten Testverlaufs so betr gt die maximale Steigerung an zeitlichem Verarbeitungsaufwand insgesamt ca 120 Millisekunden pro relevantem Datenpaket Dies stellt f r Nichtechtzeitanwendungen eine unerhebliche Gr e dar Neben der Verarbeitung der Pakete ist ein weiterer Einflussfaktor die Protokollierung eingehender Pakete um das local logging zu bewerkstelligen Um eine Oberschranke der m glichen Beeinflussung zu erfassen wurde ebenfalls vom schlimmsten Fall ausgegangen und bei der Messung Protokolleintr ge mit einer Datenmenge von jeweils 50 Bytes pro Log Eintrag gew hlt was eine recht umfangreiche Gr enordnung darstellt Die Messergebnisse haben gezeigt dass die Erstellung jedes Log Pakets ca 14 5 Millisekunden dauerte Dies verursacht ebenfalls keinen bemerkenswerten Einfluss insbesondere wenn man beden
128. dargestelltes Modell einen h heren Abstraktionsgrad und ist zugleich konkret Die semantische L cke zwischen Modell und Code wird auf diese Weise kleiner Als Nebeneffekt vereinfacht dies die Umwandlung der Modelle in Code da die schrittweise Transformation der Modelle zu Code oft bersprungen werden kann weil die unterliegende Plattform bekannt und eindeutig eingegrenzt ist 17 Siehe Glossar 141 Eine Testsprache die auch ber eine breite Unterst tzung der Toollandschaft verf gt ist TTCN Testing and Test Control Notation WebTTCN Diese liegt aktuell in der dritten Version vor weshalb oft von TTCN 3 gesprochen wird W hrend sich TTCN bislang vor allem auf den Test von Kommunikationsprotokollen beschr nkte unterst tzt TTCN 3 den Softwaretest von Sensoren und Aktuatoren die ber Bussysteme angeschlossen werden TTCN 3 sieht drei Techniken vor die gemeinsam zur Modellierung der Testf lle zum Einsatz kommen So werden die Testf lle textuell tabellarisch und grafisch je nach Fragestellung spezifiziert TTCN 3 wird von der International Telecommunication Union ITU WebITU betreut und es werden Zertifizierungsprogramme f r den Einsatz angeboten Der Bedarf an Zertifizierungsma nahmen verweist allerdings auf einen erheblichen Grad der Modellierungskomplexit t was eine hohe Lernkurve zur Folge hat und somit die Handhabung der Modellierungsprache erschwert Dies ist sicherlich auf die vielf ltigen und unterschiedlichen Modellieru
129. date bigint 20 YES NULL lt field na id t integer gt module varchar 100 YES NULL ne ns lt sql name id type integer gt wert double YES NULL lt field gt nodeid int 11 NO NULL lt field name nodeld type integer gt lt sql name nodeid typ e integer gt lt field gt lt field name name typ e string gt lt sql name nodename typ e varchar gt public class ModuleLoggerEntity lt field gt lt field name module typ e string gt 3 lt sql name module type varchar gt private int id lt field gt private a gt lt field name wert type double gt private String module j A i x the eS lt sql name wert typ e double gt private long date lt field gt private String name lt field name date type long gt lt sql name date typ e bigint gt lt field gt Abbildung 52 Automatisierte Datenserialisierung mit Hilfe des Castor Rahmenwerks Mysl06 6 2 Das Root Plugin Das Root Plugin ist das Herzstiick des gesamten ScatterPlug Rahmenwerks Aus der Sicht des Benutzers ist das Root Plugin der Ausgangspunkt um das WSN Eclipse integriert zu planen einzurichten und zu konfigurieren Mit Hilfe des Root Plugins kann die Grafik des WSN Grundrisses definiert und gem der Entfernungen in der Realit t zweidimensionaler Raum individuell skaliert und angepasst werden Im Folgenden werden mittels des Plugins die Sensorknoten in der Grafik an den ihrer realen
130. de Diagramm in Abbildung 9 zeigt das Beispielmodell in der UML Notation Hent06 B Car H Bicycle H Vehicle drive driver H Person age Abbildung 9 Ein einfaches mittels Checks zu validierendes Modell Hent06 17 oAW bietet auch den dazu geh rigen Editor der z B Codevervollstandigung und Hervor heben von Syntaxelementen unterst tzt Dadurch k nnen die mit Checks formulierten Randbedingungen robuster geschrieben werden 18 Hier sieht man ein Beispiel f r den Nutzen den die vorliegende Java Repr sentation des betreffenden Modells mit sich bringt 18 Anhand der im Ecore Modell standardm ig unterst tzten internen Referenzen bzw Collection kann auf wichtige Informationen der Ecore Objekte zugegriffen wer den wodurch deren Kontext bez glich der definierten Checks Randbedingungen be stimmt wird So kann mittels der Referenz eContainer eines Ecore Objektes dessen Vaterobjekt im Modellbaum ermittelt werden Durch die Collection eContents k n nen s mtliche Kinderobjekte eines Objektes geliefert werden Mit diesem Mechanismus kann man auf einfache Art und Weise den gesamten Modellbaum traversieren und w hrenddessen die jeweiligen Objekte und die zwi schen ihnen im Modell sich befindenden Assoziationen bearbeiten und berpr fen Das folgende Beispiel in Programmauszug 1 zeigt einen einfachen Check Ausdruck der an das in Abbildung 9 gezeigte Modell gebunden ist Dabei wird illustriert wie z B vom eContainer zwecks
131. den Dom nenexperten Die DSL wird allerdings nicht in einem Guss entworfen sondern mehr oder weniger iterativ nach dem Wasserfallprinzip konstruiert Hier zeigt sich die St rke der harmonischen Integration der beteiligten Rahmenwerke der Werkzeugkette Ein Beispiel daf r ist die M glichkeit den ge nerativen DSL Editor GMF nach jeder Verfeinerung des Metamodells EMF automatisiert zu generieren 14 Data Component w Connections E runs SensorApplicat ComponentCo Applicationexte EMPTIO ApplicationCon lt provided Port Connection required Port E Connection roblems 33 Javadoc Declaration Console Properties ors O warnings O infos scription Errors 3 items Applications need to be connected to at least one Container Containers need a name Sensors need an application Abbildung 6 Modell Validierung im GMF Editor Hent06 eingeblendeten Fehleranzeige angegeben z B ob es sich um einen Modellierungs fehler eine Warnung oder einen Tipp handelt Bislang wurde noch nicht tiber die Erstellung des generativen Editors in GMF ge sprochen Dieser Vorgang beruht wiederum auf dem Graphical Editing Die Reali sierung des Editors nur mit Hilfe von GEF gestaltet sich sehr umst ndlich da auf Grund des importierten Ecore Metamodells die notwendigen abstrakten Klassen er zeugt werden die dann vom Entwickler manuell implementiert werden m ssen Es ist daher nahe
132. den beiden Sensor knoten mit Hilfe der Skripte w hrend des Testverlaufs gesammelten Daten der oben beschriebenen Aktionen vom Rahmenwerk analysiert und in den Modellen visuali siert Beim Testverlauf werden auch die Fehler protokolliert Es stellt sich die Fra ge wie man die betreffenden Codestellen die die Fehler verursacht haben in der Anwendung lokalisieren kann Zu diesem Zweck werden die Modelle iterativ verfei nert um graduell die f r die Fehler verantwortlichen Codestellen zu isolieren Bei jedem solchen Schritt wird der notwendige Infrastruktur Code an den Codegenera tor erneut delegiert und die gegebenenfalls neu entstehenden Fehler erneut in den dazugeh rigen Modellkonstrukten visualisiert Wie dies im Rahmen von Visual ScatterUnit genau vonstatten geht wird im Laufe des Kapitels ausf hrlich darge stellt 3 1 Architektur des Rahmenwerks Visual ScatterUnit Zu Beginn wurde die Testinfrastruktur ScatterUnit als erster Baustein der Archi tektur des Rahmenwerks entwickelt ScatterUnit erm glicht eine effiziente Testau tomatisierung der auf den Sensorknoten laufenden Anwendungen was deren Sys tem und Integrationstests umfasst Dabei kann der Testverlauf sich auf eine Viel zahl von beteiligten Sensorknoten erstrecken Wie ein Debugger kann ScatterUnit Testszenarien ablaufen lassen in die viele Sensorknoten involviert sind Diese Test infrastruktur ist vergleichbar mit der JUnit f r Java Anwendungen die es erm g licht de
133. den hat und in Gedanken immer bei mir war wie auch meine Geschwister Ebenso geht mein Dank an meine Schwiegereltern die mich moralisch w hrend meiner Promotion unterst tzt haben Zuletzt danke ich meiner Frau Silvie die mich w hrend meiner gesamten Promotion unterst tzt hat und mir mit Liebe und viel Geduld zur Seite stand Bei ihr kann ich mich nicht genug bedanken Ein Dicker Kuss geht an meinen Sohn Khaloude aus dessen L cheln ich Freude sch pfe Es bleibt mein Vater der uns vor 8 Jahren verlassen hat Ihm widme ich diese Arbeit in Liebe und Dankbarkeit Zusammenfassung ScatterClipse ist eine plugin orientierte Werkzeugkette f r automatisiertes Testen Entwicklung und Verwaltung von auf drahtlosen Sensornetzen laufenden Anwendungen Das Hauptziel ist die automatisierte Generierung von Software Systemfamilien f r die ScatterWeb Sensorknoten F r die Automatisierung wird die architekturzentrierte Methode des modellgetriebenen Paradigmas eingesetzt Der neue Ansatz von ScatterClipse liegt in der Integration von visueller automatisierter Fehlersuche und WSN Verwaltungseigenschaften innerhalb des modellgetriebenen Anwendungsentwicklungsprozesses der Sensorknoten Zus tzlich zur Automatisierung liegt der Fokus auf dem Aspekt der Mensch Maschine Schnittstelle human computer interfaces f r WSN So bietet ScatterClipse die M glichkeit verschiedene Charakteristika und Merkmale des WSN visuell und interaktiv zu testen und
134. der Bestimmung der Schl sselaspekte des Testfalls welcher in einer abstrakten Weise modelliert wird Ein solches formales Modell stellt eine direkte Repr sentation des Testszena rios dar in dem die korrespondierenden Aktionen deren Zuweisung zu den jeweili gen Sensorknoten sowie die Festlegung ihrer Ausf hrungsreihenfolge eindeutig durch das Modell spezifiziert werden m ssen Denn auf Basis der durch das Modell vorgegebenen Informationen kann der Codegenerator automatisiert mittels der von ihm generierten Testskripte und den darin enthaltenen Signalisierungsbefehlen gem des im letzten Abschnitt dargestellten local logging ein Log f r den gesam ten verteilten Testverlauf erstellen Dies erm glicht die Evaluierung des Tests f r alle beteiligten Knoten Bei der Modellierung eines Testfalls in Visual ScatterUnit ist der Ausgangspunkt wie erw hnt ein Aktivit tsdiagramm Ein Beispiel eines solchen Diagramms zeigt Abbildung 20 wobei das Diagramm sich auf das im letzten Abschnitt diskutierte Testszenario des DSDV Routingprotokolls bezieht Die Notation des formalen Mo dells hnelt stark den UML Aktivit tsdiagrammen Der Hauptunterschied betrifft die Rolle der Aktivit ten innerhalb des Diagramms Eine Aktivit t repr sentiert ei ne Gruppe von Aktionen die einem bestimmten Zweck dienen wie z B der nde rung der Topologie des Netzes Desweiteren wird in der internen Darstellung einer Diagrammaktivit t spezifiziert auf welchem Sens
135. der Fallstudie und die dabei zu testende Anwendung hinsichtlich der Fehlersuche und deren Lokalisierung realen Testbedingungen was die Aussagekraft und Authentizit t der durch die Fallstudie erhaltenen Resultate deutlich erh ht Die Abbildungen 72 und 73 veranschaulichen die w hrend der Fallstudie entstandenen Diagramme zur Modellierung des obigen Testszenarios das in 3 3 ausf hrlich erl utert wurde 119 Init1UndWarten E ErstesPaketErwarten 4 weitesPaketSenden weitesPaketErwarten b Ablaufstrang Diagramm des Ablaufstrangs Init Und Warten Abbildung 72 Diagramme des entwickelten Testfalls Kame08 120 Packet Type 100 Timeout 2 000 Additional Checking false Sending Node 1 Addressed Node 4 7 Warten Await Radio Packet Action Processing Time AFTER Empfangen Radio Packet Received Event E AbbruchWennTimeout Control Action e Opposite Node 3 Apply On BOTH_NODES Enable false Opposite Node 2 Apply On BOTH_NODES Enable true 10SekundenWarten Control Action T BereichKnoten3Verlassen Topology Change Action T BereichKnoten2Betreten Topology Change Action g en d Ablaufstrang Diagramm des Ablaufstrangs TopologieAendernUndWarten mpfangen Radio Packet Received Event Detail DATA_ONLY Log Label Nutzlast Log Labels Nutzlast t 32 23 2g 33 Additional Checking false Processing Time AFTER F Nut
136. der Sensorarchitektur mit b und ohne a Testautomatisierung Kame07 1 Herausfilterung eingehender relevanter Datenpakete f r die Realisierung des Simulationsdienstes z B die Anderung der Netztopologie 2 Analyse des Paketinhaltes bez glich der Erf llung eines im Testfallmodell definierten Ereignisses z B f r die Realisierung des Wartevorgangs 3 Protokollierung jedes eingehenden Datenpakets das an die Anwendung gerichtet ist Hierbei handelt es sich jedoch um einen nicht standardm ig laufenden Dienst der gesondert im grafischen Modell vom Benutzer aktiviert werden muss Die obigen Schritte welche die Datenpakete zum Zweck des Anwendungstests zuerst durchlaufen m ssen werfen die Frage auf inwieweit die Instrumentierung der ScatterUnit Testautomatisierungsschicht das Verhalten der zu testenden Anwendung beeinflusst Zwar handelt es sich sowohl im Kontext der ScatterWeb Plattform als auch der ScatterClipse Werkzeugkette um keine Echtzeitanwendungen dennoch sollte der Betriebseffekt der Testautomatisierungsschicht minimal gehalten werden so dass das Verhalten der zu testenden Anwendung unber hrt bleibt Hierzu spielt die durch die obigen Bearbeitungsschritte verursachte Einflussnahme eine entscheidende Rolle Um diese zu beurteilen wurde eine Reihe relevanter Messungen der ben tigten Zeit durchgef hrt die von den entsprechenden ScatterUnit Diensten zur Realisierung der jeweiligen oben aufgelisteten Bearbeitungsschritte beansp
137. der Werkzeugkette von ScatterClipse Der Syntaxbaum des eingelesenen formalen Modells liegt wie erw hnt als bear beitbares Objektgeflecht von Java Instanzen vor Daher spricht man in diesem Zu sammenhang von einem instanziierten Modell Bevor der eigentliche Codegenerie rungsprozess angesto en wird wird die Integrit t der Objekte des gerade instanzi ierten Modells verifiziert Die Modellintegrit t ist erhalten wenn der Syntaxbaum des formalen Modells tats chlich eine Instanz des Metamodells darstellt Zus tzlich muss die zugeh rige formalisierte Semantik erf llt sein Diese berpr fung geschieht mit Hilfe der von oAW gelieferten Sprache Checks WebCheck Die Checks Ausdr cke mit denen die Semantik des Metamodells for muliert wird werden in einer zentralen Datei chk gehalten Damit k nnen diese einerseits f r verschiedene Metamodelle derselben Dom ne wiederverwendet wer den andererseits k nnen sie leichter vom Benutzer verwaltet und von der Architek tur bearbeitet werden Um die Modellintegrit t Semantik berpr fung bez glich der Checks Ausdr cke zu berpr fen m ssen die Objekte des instanziierten Mo dells diesen zentral gehaltenen Randbedingungen zug nglich gemacht werden Die Checks Ausdr cke m ssen in der Lage sein auf die Methoden und Attribute des Ob jektgeflechtes des Modells zuzugreifen Dies soll anhand des Beispiels eines einfa chen Ecore konformen Modells demonstriert werden Das folgen
138. der verschiedenen Connections Auspr gungen 15 e Das Mapping Model gmfmap und das Generator Model gmfgen gmfgraph und gmftool fungieren als Eingabe f r das Mapping Model das diese dann unter Betrachtung der vom Benutzer im Audit Container spezifi zierten Semantik zusammenfiigt Das Resultat ist das vom Benutzer zwecks Editoreinstellung individuell konfigurierbare Generator Model aus dem dann unmittelbar der generative Editor entsteht graphische definition GMF Projekt Meta Modell ecore Mapping definition guufinap Abbildung 7 Die automatisierte Erstellung des Editors im GMF Hent06 2 5 openArchitectureWare oAW Das Hauptaugenmerk fiir die Erzielung der angestrebten Vorteile im modellgetrie benen Softwareentwicklungsprozess liegt auf der Durchfiihrung der entsprechenden Automatisierung Dafiir ausschlaggebend ist eine optimierte Codegenerierung der Softwareartefakte welche durch die DSL modelliert werden Das Vorhandensein einer solchen Komponente zur automatisierten Codegenerierung ist fiir den MDSD Prozess daher unerl sslich Das von b m Informatik AG Web b m entwickelte und im Jahr 2003 ver ffent lichte opensource Rahmenwerk ist eine solche Komponente Das Hauptziel von o penArchitectureWare ist es eine u erst flexible Plattform f r MDSD Prozesse zu bieten Es versteht sich als Template basiertes Rahmenwerk zur Erstellung eigener Generatoren nach dem Model to Code An
139. die Versendung des Datenpakets zu initiieren und die Knoten senden Informationen ber alle relevanten Ereignisse zur ck an die Basisstation Diese Informationen entstehen durch die Protokollierung des Testverlaufs von jedem im Netz beteiligten Sensorknoten Hierzu bedienen sich die Sensorknoten eines separaten Kommunikationskanals um die Test Meta daten zu verschicken The secondary communication channel is an administration channel only used by SeNeTs components This channel transmits controlling and logging messages It is independent of the primary communication channel and uses a different communication method e g Ethernet or Ultrasound Blum04 Drahtgebundene Kommunikation zur bertragung der Testinformationen beschr nkt jedoch die Realit tsn he der Testdurchf hrung Der Einsatz einer zus tzlichen Kommunikationsmethode speziell zum Zweck der bertragung der Testdaten erfordert die Best ckung jedes einzelnen Sensorknotens mit einem entsprechenden Funkmodul Ferner werden die w hrend des Voranschreitens der Testdurchf hrung von den einzelnen Knoten st ndig versendeten Nachrichten von auf der Basisstation laufenden Modulen analysiert um R ckschl sse hinsichtlich des Verhaltens der zu testende Anwendung ziehen zu k nnen Demgem wird ein zentralistischer Ansatz bei der Protokollierung und Evaluierung der Testinformationen verfolgt was in der sensitiven Dom ne drahtloser Sensornetze schnell zum Engpass wird Denn die SeNeTs
140. die operationale Semantik der Dom nensprache vollst ndig durch die zentral abgelegten Checks Ausdr cke definiert wird Wie bereits in 2 5 geschildert kann man auf die semantischen Ausdr cke mit dem GMF Adapter dynamisch zur Modellierungszeit zugreifen und sie interpretieren Demgem k nnen bei jedem Iterationszyklus flexibel und ohne weiteren Aufwand w hrend der Weiter Entwicklung der Dom nensprache entsprechende Checks Ausdr cke verfeinert bzw neu definiert werden Ferner sind die Autoren der Ansicht dass die automatisiert aus der Dom nensprache generierten Artefakte nicht direkt auf den Sensorknoten auszuf hren sind da dies nur schwer m glich sei Daher schlagen sie vor die Artefakte lediglich auf einer Simulationsumgebung auszuf hren deploying and testing programs on the target platform is very costly This means that it s not feasible to test programs written in the DSL directly on the target platform especially in the early rounds of the prototyping cycle when the DSL is used more for the purpose of evaluating the DSL itself than of developing the system Therefore it is necessary that the DSL can be simulated Sadi07 Die Entwicklung der Dom nensprache auf Basis einer Simulationsumgebung um dann die DSL erst nach ihrer Entwicklung direkt auf den Sensorknoten einzusetzen entspricht nicht der Anforderung der realit tsnahen Entwicklung einer dom nenspezifischen Modellierungssprache Die Argumentation dass die Ausbringu
141. dienen als Log Mechanismus zur Protokollierung relevan ter Informationen des Testverlaufs Zwar werden alle Steuerbefehle und Er eignisse standardm ig mit Hilfe entsprechender Dienste von ScatterUnit protokolliert jedoch handelt es sich hier um zus tzliche anwendungsspezifi sche Informationen die entsprechend der zur Fehlersuche aufgestellten Hy pothesen angegeben werden 4 Pr froutinen sind auf dem Rechner laufende Module welche die von den Pro tokolleintr gen eingehenden Informationen auf deren Korrektheit pr fen Somit fungieren die Pr froutinen als Pr fmechanismen anhand derer die zur Fehlersuche aufgestellten Hypothesen verifiziert werden Das Ergebnis wird dann in entsprechenden Modellkonstrukten visualisiert F r jeden Typ eines Protokolleintrags ist eine bestimmte Pr froutine zust ndig Daher muss die Dom nensprache DSL die eindeutige Zuordnung der einzelnen Protokolleintr ge und ihrer Pr froutinen auf Modellebene gew hrleisten Dies geschieht durch eindeutige Modellmarkierungen in den jeweiligen Mo dellkonstrukten wie in Abbildung 32 skizzenhaft veranschaulicht wird Da der berwiegende Codeanteil der Modellentit ten automatisiert generiert wird m ssen die Modellentit ten ber bestimmte Parameter verf gen die als Ein gabe f r den Codegenerator fungieren um ihren Code auf Basis der korrespondie renden Templates vollst ndig automatisiert zu generieren Abbildung 33 zeigt eine Erg nzung des Metamodella
142. dingungen wie oben beschrieben mit Hilfe von OCL Ausdr cken formuliert um deren Modellierbarkeit im Editor auszuschlie en Dies f hrt dazu dass die betroffenen Modellentit ten im Editor mit der Maus nicht verkn pft werden k nnen vgl Abbildung 30 52 Ra Ablaufstrana Ablaufstrana 1 Ablaufstranal Abbildung 30 Verbindungen d rfen bei keinem Startknoten enden links Verbindungen d rfen ihren Ausgangspunkt nicht in einem Endzustand haben rechts Kame08 Ferner muss gew hrleistet werden dass beispielsweise im Fall des Startknotens genau eine ausgehende Assoziation definiert wird Obwohl dies analog zum letzten Beispiel mit Hilfe von OCL Ausdr cken bewerkstelligt werden k nnte wurden die semantischen Regeln dazu mittels der Livevalidierung spezifiziert da diese eine vi suelle Fehlermeldung im Editor geben kann vgl Programmauszug 4 context testcase Startknoten ERROR Der Startknoten muss genau eine ausgehende Verbindung haben this ausgehend size 1 Programmauszug 4 OCL Ausdruck zum Start und Endknoten des Aktivit tsdiagramms Kame08 Die zweite Diagrammart der Dom nensprache modelliert die Detaillierung eines Ablaufstrangs in dem zus tzlich die w hrend des Tests entstandenen Ergebnisse eines Sensorknotens abschlie end visualisiert werden Da jeder Ablaufstrang eine Aktivit t des Testfalls repr sentiert werden durch das Detaillierungsdiagramm die technischen Aspekte modell
143. dungsentwicklung Stah05 Dieses Bestreben ergibt sich in erster Linie aus der Beobachtung dass der oft mehrmalig und berlappend verwendete Infrastrukturcode einen beachtlichen An teil am gesamten Code verschiedener Anwendungen derselben Dom ne ausmacht W hrend dieser Anteil in der E Kommerz Dom ne bei etwa 70 liegt steigt er bei der hardwarenahen Programmierung in der Dom ne eingebetteter Systeme auf 90 bis 100 Czar00 Daher liegt es auf der Hand die Erstellung gerade dieser Art von Code durch Codegeneratoren zu automatisieren so dass der Entwickler sich auf den eigentlichen Problembereich n mlich die Anwendungslogik konzentrieren kann Dadurch richtet sich der Fokus des Entwicklers auf die Gegebenheiten der Dom ne und kann sich von den damit verbundenen vielseitigen technischen Belangen l sen Deren Realisierung wird durch den Infrastrukturcode bewerkstelligt dessen Erstel lung an den Codegenerator delegiert wird Die Voraussetzung daf r ist eine balan cierte Abstraktion von der unterliegenden Dom ne die dem Entwickler die Konfron tation mit den technischen Belangen der Dom ne erspart die architektonischen Randbedingungen der Dom ne jedoch erfasst Dies verlangt eine ad quate Modellie rung bei der die Dom ne im Mittelpunkt steht Im Kontext der AC MDSD erfolgt dies durch den Entwurf einer entsprechenden dom nenspezifischen Modellierungs sprache Domain Specific Language DSL die eine dom nennahe Modellierung
144. durch vier Testskripte implementiert Zuerst ruft ScatterUnit kurz vor der Testausf hrung eine Initialisierungsmethode set up Methode dieser Testskripte auf Dadurch werden verschiedene f r den Testverlauf notwendige Dienste von ScatterUnit aktiviert Sobald Sensorknoten 4 von 1 das Datenpaket empfangen und dem eigenen Skript diese Aktion mitgeteilt hat sendet Sensorkno ten 1 nach der Topologie nderung das zweite Paket Schl gt das Versenden von ei nem der Datenpakete fehl beispielsweise nach time out so wird die Ausf hrung des Testfalls abgebrochen Die Logs aller am Testfall beteiligten Sensorknoten wer den w hrend der Ausf hrung des Testverlaufes akkumuliert und nach seiner Been digung zur Analyse an den zentralen Rechner geschickt auf dem das Rahmenwerk l uft wo die verschiedenen Logs zu einem zeitlich geordneten kollektiven Log Protokoll zusammengef gt werden Ein solches Log enth lt im Wesentlichen die fol genden Informationen Aktionen des Testverlaufs und zwar f r den Fall dass das Versenden des zweiten Pakets nach der Topologie nderung fehlgeschlagen ist 1 Die Ausf hrung des Testfalls ist gestartet Sensorknoten 4 beginnt zu warten Sensorknoten 1 sendet das erste Datenpaket Sensorknoten 4 empf ngt das erwartete Datenpaket von Sensorknoten 1 Sensorknoten 4 verl sst die Reichweite des Sensorknotens 3 Sensorknoten 4 begibt sich in die Reichweite des Sensorknotens 2 Sensorknoten 4 geht in den Wartezust
145. e Entit ten des f r Visual ScatterUnit definierten Metamodells welches in der Abbildung 90 dargestellt wurde context testcase TestCaseDiagram ERROR Exactly one initial node must exist this initialNode null context testcase TestCaseDiagram ERROR Exactly one final node must exist this finalNode null context testcase TestCaseDiagram ERROR At least one control path must exist this controlPathes size gt 0 context testcase TestCaseDiagram ERROR Circular links are not allowed this initialNode null this initialNode checkForCircularLinks false true context testcase InitialNodeOfTheTestCase ERROR The initial node must not have any incoming links this incoming size 0 context testcase InitialNodeOfTheTestCase ERROR The initial node must have exactly one outgoing link this outgoing size 1 context testcase FinalNodeOfTheTestCase ERROR The final node must have exactly one incoming link this incoming size 1 context testcase FinalNodeOfTheTestCase ERROR The final node must not have any outgoing links this outgoing size 0 context testcase Link ERROR The source node of this link is not specified this source null context testcase Link ERROR The target node of this link is not specified this target null 162 context testcase ControlPath ERROR A control path must have o
146. e Frage warum die betroffenen Routinginformationen beim Sender des Datenpakets verf lscht werden obwohl sie bei ihm korrekt ankommen Diese Fragestellung legte nahe als n chstes zu untersuchen welche Eigenschaften bzw Muster die falschen Eintr ge aufwiesen anstatt zuerst zu berpr fen wie es zur unerw nschten Datenmanipulation kam Daher wurde der Testfall mehrfach durchgef hrt und jeweils die Eintr ge der Routingtabelle des Senders Knoten 1 genauer unter die Lupe genommen Dies war m glich da bereits in Schritt drei das Detaildiagramm um die entsprechende Log Funktionalit t erweitert wurde mit der die gesamte Tabelle protokolliert werden kann Nach jedem Testdurchlauf wurde festgestellt dass der Eintrag zum Next Hop immer dann wenn Knoten 3 und 4 die Empf nger sind mit dem Wert der eigenen Sensor ID beschrieben wurde Dies veranschaulicht Tabelle 5 Empf nger Next Hop Distanz 1 1 0 2 2 1 3 1 1 4 1 2 Tabelle 5 Tabelleninformationen nach erneuter Testdurchfiihrung Kame08 127 7 WarteAufFalscheRoutingInfo Await Radio Packet Action Sending Node 0 Addressed Node 0 Packet Type 6 Timeout 5 000 Additional Checking true Processing Time BEFORE arr t FalscheRoutingInfoEmpfangen Radio Packet Received Event EIERN e a a GEBE WERDE F FalscheRoutingInfo Radio Packet Log Action Log Label FalscheRoutingInfo Detail ALL FM RoutingTabelleneintragDavor Log Acti
147. e Mensch Maschine Schnittstelle human computer interface f r ScatterWeb realisiert wird 103 Java Eclipse SDK File Edit Navigate Search Project Run Window Help wil B B Ov Q 8 O A le E L tava Problems Javadoc Declaration E eiad ScatterServer gt g Gomnection Property Terminal Alarm Log OTA Flasting Select Sensor Change Sensor ID eGate SuperNode Information 1 3 v Refresh New 10 EN Set Flags Configuration LEDs Reset Beeper 6 Announce Flags 7 Firmware Flags 4 5 Red E Yellow Green B Serial m Radio m Programmable m DCO Checker m 9 Sensor values Transeiver and Power Microphone Silent Temperature 26 00 28 Jan 2007 00 55 13 ransceiver 10 Power Supply Voltage Movement Detect Vibration Silent Transmit Power 99 Battery Receive Limit 2200 Figure Information Foray way Abbildung 62 Property Reiter Ding07 7 2 3 Das Terminal Das Terminal bietet die M glichkeit die einzelnen Sensorknoten im WSN w hrend ihres Betriebs auf einfache Weise ber das eGate zu konfigurieren Abbildung 63 zeigt einen Bildschirmabzug der Benutzerschnittstelle des Terminals Die Konfiguration erfolgt indem nach einem strukturierten Muster aufgebaute Befehle an die Sensorknoten abgesetzt werden Diese Befehle verf gen ber ein spezifisches aber einfaches Format was ihre Formulierung erleichtert ber diese kann der Benutzer auf den laufenden Sensorknoten inter
148. e Werkzeugkette ist Die Entwicklungsarbei ten an ScatterClipse begannen bereits im Mai 2005 zu einem Zeitpunkt als diese Notwendigkeit in der Forschung gerade erst erkannt und diskutiert wurde vgl R me04 Ulbr05a 1 1 Forschungsdiskussionen und Anforderungen Auf das Fehlen ad quater Programmierungsans tze und entsprechender Werkzeuge angesichts der steigenden Komplexit t des Einsatzes von Sensornetzen machen z B Wada et al in ihrem im November 2007 erschienenen Beitrag Wada07 aufmerk sam The complexity of WSN application development derives from two major is sues 1 a lack of adequate abstractions in application development and 2 a lack of coherent tool chains for application development Wada07 Daher stellen sie ein modellgetriebenes Werkzeug zur Anwendungserstellung drahtloser Sensornetze vor auf das in Kapitel 9 bei der Behandlung verwandter Arbeiten n her eingegangen wird Diverse weitere Beitr ge der Forschung weisen auf die wachsende Notwendig keit integrierter Werkzeuge zur leistungsf higeren realit tsnahen Entwicklung von auf den Sensorknoten laufenden Softwareanwendungen hin What type of software is needed and what requirements have to be met R me04 Au erdem sollen weitere Schnittstellen und Entwicklungsunterst tzung angeboten werden Was we niger dringend ben tigt wird sind neue Algorithmen f r Routing die eine Verbesse rung von wenigen Prozent versprechen Schi07 D
149. e m glich zu bean spruchen Die LibScatterUnit bietet die folgenden Dienste an 1 Chronological synchronization service Dieser Service erm glicht die Syn chronisation der Uhren aller Sensorknoten Dies ist notwendig da die Ereig nisse auf den verschiedenen Sensorknoten in chronologischer Abfolge proto kolliert werden m ssen 2 Setup service Der Service ruft die Setup Methode des Testfallcodes auf je dem Sensorknoten auf um die notwendigen Vorbereitungen zu treffen 3 Start service Dieser Service startet den Testablauf auf allen Sensorknoten zur gleichen Zeit 46 Dabei macht es keinen Unterschied ob der Testfall vollst ndig manuell implementiert wurde oder mit Hilfe der modellgetriebenen Visual ScatterUnit generiert wurde 47 Die Testergebnisse werden aus Performanzgr nden nicht fortlaufend w hrend des Test verlaufs an die Senke verschickt sondern einmalig nach Beendigung der Ausf hrung des Testfalls gesendet 65 4 Teardown service Dieser Service startet die Teardown Methode des Testfall codes auf allen Sensoren um nach dem Testablauf den Ausgangszustand wieder herzustellen 5 Reporting service Dieser Service erm glicht unter anderem dass die Proto kolle der Sensorknoten nach dem Testablauf zur Senke gesendet werden Der komplette Test wird somit automatisiert durchgef hrt Der direkt auf den Sensorknoten laufende Testfallcode kontrolliert den Testverlauf mit Hilfe der libScatterUnit und die auf dem Re
150. eiderten Codeerzeugung durch die nur so viel Code f r die Sensorknoten erzeugt wird wie f r ihre jeweilige Rolle erforderlich ist Dadurch wird nicht nur der knappe Spei cherplatz optimiert sondern es werden unn tige rechen und energieintensive Soft waremodule vermieden Der sinkende Anteil an manuellem Code reduziert zugleich die M glichkeit von Fl chtigkeitsfehlern der Programmierer Dabei spielt die Vali dierung auf Modellebene eine wesentliche Rolle denn je fr her die Fehler im Ent wicklungsprozess entdeckt werden desto robuster und verl sslicher wird er Zum Zweck der Automatisierung wurde eine generative Infrastruktur Visual ScatterUnit und ScatterFactory entwickelt die das R ckgrat der Plattform bzw der Werkzeugkette bildet Zur Modellierung wurde ein graphischer Editor auf Basis des Eclipse Modeling Frameworks WebEMF und des Graphical Modeling Frame works WebGMF entwickelt F r die berpr fung der Randbedingungen die an das jeweilige Modell gebunden sind wurde eine Echtzeit Validierung in den Editor integriert um den Entwicklungsprozess robuster zu gestalten Als Codegenerator wird openArchitecureWare WeboAW verwendet um aus den eingelesenen Model len den korrespondierenden Code automatisiert zu generieren und diesen dann auf die installierten Sensorknoten auszubringen Alle verwendeten Rahmenwerke sind Opensource Projekte der Eclipse Plattform WebEcli Wie erw hnt liegt ein weiterer Fokus auf der Integrati
151. eil an ben tigtem Code der in ScatterFactory automati 75 siert generiert wirdt und durch den die Realisierung einer herk mmlichen Aufgabe eines Sensorknotens im WSN erm glicht wird Wie erw hnt fungiert die Anwen dung als Bindeglied zwischen der Sensorinstanz und dem Container In diesem Bei spiel beinhaltet der Container sechs Firmwaremodule von insgesamt 11 welche f r die Anwendung ben tigt werden Bei der Instanz des Sensors sind zwei Spezifi kationen angegeben USE_DUMMIES und NO_COMMANDS Diese sind soge nannte Filterregeln zur Optimierung des Codegenerierungsprozesses hinsichtlich der gerade modellierten Anwendung Sie sorgen daf r dass w hrend der Codegene rierung unn tige Codesegmente f r die jeweilige modellierte Anwendung innerhalb der Templates herausgefiltert werden insbesondere solche der im Quellcode der Firmwaremodule verstreut eingeflochtenen Steuerbefehle Insofern fungieren die Filterregeln als Technik welche die Herausforderung der Codevermischung im Hin blick auf eine optimierte Codegr e der modellierten Anwendung auf Template Ebene elegant l st Dieser Aspekt wird in Abschnitt 6 4 bei der Betrachtung des Co degenerierungsprozess ausf hrlich behandelt uses Minimal_Container Abbildung 43 Modellierungsbeispiel einer Anwendung Hent06 54 Die genaue Gr e zum ben tigten Code im Vergleich zu anderen Anwendungen wird in 8 1 bei der Evaluierung angegeben 76
152. einen Eingriff in den strukturellen Aufbau der Xpand Sprache und damit den Templates eingesetzt werden k nnen Dies erleichtert die Programmierung solcher Templates erheblich Ein weiteres wichtiges Merkmal der Xpand Sprache sind die so genannten ge sch tzten Bereiche protected regions Dies sind im Generat ausgewiesene Bereiche die beim erneuten Generierungsdurchlauf nicht berschrieben werden Der Block der gesch tzten Bereiche wird vor der erneuten Codegenerierung durch das Gene rierungs Rahmenwerk gepuffert und erst danach wieder an seiner vorgesehenen Stelle in den neu generierten Code integriert Daher muss jedes Segment eines ge sch tzten Bereichs eindeutig identifizierbar sein Dies wird durch die Markierung der Segmente mittels Universally Unique Identifier UUID erreicht Solche ge sch tzten Bereiche sowie deren Inhalt werden vom Benutzer manuell festgelegt Daher werden sie insbesondere daf r verwendet den manuellen Codeanteil vom au tomatisierten auf flexible Art deutlich zu trennen 44 Siehe dazu das Diagramm des Metamodells von Visual ScatterUnit vgl Abbildung 90 im Anhang 11 4 in dem der Typ der Entit t definiert wird 45 Ein UUID besteht aus einer 16 Byte Zahl die in f nf Gruppen unterteilt wird In ihrer Normalform sieht eine UUID so aus 550e8400 e29b 11d4 a716 446655440000 Daher k nnen UUIDs beliebig ohne zentrales Kontrollorgan erzeugt und zur Kennzeichnung einge setzt werden ohne Gefahr zu la
153. eit in Anspruch nahm Analyse der Testergebnisse und daraus hervorgehend die Aufstellung von Hypothesen ber die Fehlerursache und deren berpr fung Dar ber hinaus wurde das Ablaufprotokoll durchgesehen um seine Funktionsweise zu verstehen Besonders zeitintensiv war es das Protokoll durchzusehen und Hypothesen aufzustellen Der Grund hierf r liegt darin dass die berpr fung der Hypothesen und die Erweiterung des Testfalls so schnell vonstatten ging Die Ursache daf r liegt im Einsatz der Codegenerierung F r die Erweiterung des Testfalls wird lediglich eine einfache Erweiterung des Testfallmodells und die folgende Hinzuf gung eines kleinen Anteils von manuellem Code ben tigt Da der Testfall Code die Testergebnisse produziert und im Testfallmodell visualisiert wird blieb der Zeitaufwand f r die berpr fung der Hypothesen gering da die Testergebnisse ohne Schwierigkeiten gelesen werden konnten Die modellgetriebene Testumgebung macht daher eine zeitsparende Testfallentwicklung m glich indem sie einen gro en Teil des Codes generiert Die Testfallentwicklung weist dar ber hinaus eine Robustheit gegen ber Fehlern auf weil der Code erst nach der Validierung von einem Testfallmodell generiert wird so dass Fehler zu einem fr heren Zeitpunkt entdeckt werden Wie die Fallstudie zeigt werden 11 Hier handelt es sich wie in Abbildung 80 um die Codeartefakte zur automatisierten Fehlersuche welche auf den Sensorknoten ausgef hrt werden
154. ekt f r das ScatterWeb WSN Abbildung 54 XML als Austauschformat in der Plugin orientierten Architektur Abbildung 55 Main View Abbildung 56 Visualisierung der Sensorknoten im Main View Abbildung 57 Merkmale des Statistik Views Abbildung 58 Kommunikation zwischen Statistik View und JfreeChart Abbildung 59 Architektur von ScatterEditor Abbildung 60 Internetbasierter Zugriff auf die Dienste von ScatterEditor Abbildung 61 Connection Reiter vor oben und nach unten dem Verbindungsaufbau Abbildung 62 Property Reiter Abbildung 63 Der Terminal bietet eine befehlsgest tzte Konfiguration der Sensorknoten Abbildung 64 Stapeldatenstruktur zur Verwaltung der bereits eingegebenen Befehle Abbildung 65 Beispiel eines Alarmausdrucks oben und dessen Syntaxbaum unten Abbildung 66 Drei rekursive Ausdr cke der Alarmsprache 172 56 57 58 59 60 61 66 67 71 73 75 76 79 80 83 85 86 89 90 91 92 93 93 94 95 97 98 101 102 104 106 107 108 110 111 67 Abbildung 67 Einsatz von ScatterEditor als Klient 68 Abbildung 68 Die Modelldiagramme der Anwendungen Empty oben und Actor unten 69 Abbildung 69 Die Laufzeitumgebung der Sensorarchitektur mit b und ohne a Testautomatisierung 70 Abbildung 70 Erweiterte Laufzeitumgebung des Sensorknotens zur Testautomatisierung 71 Abbildung 71 Speicherplatzbedarf der Testautomatisierung 72 Abbildung 72 Diagramme des entwickelten Testfalls 73 Abbildun
155. ell konfigurieren indem er ihre jeweiligen Module gem ihrer Hardwareausstattung individuell festlegt Dies veranschaulicht Abbildung 55 Rede Reset Sensor Microphone r b 1 Remove Sensor Light P Beeper b r b r Green LED Battery ee a ooo Update Remove Yellow LED wibrator Abbildung 55 Main View Mys106 Des Weiteren werden s mtliche aus den im WSN aktiven Sensorknoten ankommenden Nachrichten in der jeweiligen Knotendarstellung des Main Views visualisiert so dass der Benutzer ber jede Status nderung der Knoten und deren Module direkt informiert wird Eine weitere Aufgabe des Main Views ist die Visualisierung des Status der einzelnen Module Abbildung 56 zeigt verschiedene Varianten der Visualisierung der Sensorknoten sowie deren Module Links im Bild wird angezeigt wie die ID des Sensorknotens dem Benutzer angezeigt wird sobald er mit der Maus ber die entsprechende Sensordarstellung f hrt Im mittleren Bild wird die Visualisierung von Modulen illustriert sobald diese im realen Netz einen Wert messen oder ein Ereignis aufsp ren Im rechten Bild wird die M glichkeit der punktorientierten Darstellung der Knoten im Main View gezeigt Die gew hlten Knoten k nnen lediglich als Punkte repr sentiert werden ohne dass deren Module visualisiert werden m ssen 3 Werden bestimmte Knoten nach dem Scannen des Netzes nicht erreicht so werden diese als rote Punkte angezeigt
156. elligt jedoch m ssen die dazugeh rigen Testf lle manuell vom Benutzer entwickelt werden Hierzu muss sich der Entwickler mit verschiedenen technischen Belangen des Tests befassen um richtige Testf lle zu entwickeln wodurch eine robuste Testdurchf hrung gew hrleistet werden kann Diese recht komplexe und fehleranf llige T tigkeit wird in ScatterUnit dem Benutzer abgenommen und durch die modellgetriebene Entwicklung der Testfallmodelle an den Codegenerator delegiert Dies wurde mittels der Erg nzung Visual ScatterUnit erreicht wozu bislang offenbar kein Pendant in der WSN Dom ne existiert Es finden sich jedoch verwandte Testwerkzeuge hinsichtlich der Verwendung von Aktivit tsdiagrammen bei der Modellierung der Testf lle Ein Vertreter ist das in Lenz07 vorgestellte Werkzeug Lenz et al entwickelten ein modellgetriebenes Werkzeug das die Modellierung von Testf llen f r Anwendungen erm glicht die gem der dienstorientierten Architektur SOA entwickelt wurden Die Modellierung der Testf lle st tzt sich hnlich wie in ScatterClipse auf den Einsatz von UML basierten Aktivit tsdiagrammen Dies geschieht mit Hilfe des UML Testing Profiles WebTestProfile Die Schl sselidee des Ansatzes ist die Entwicklung von Testfallmodellen unabh ngig von der Technologie die f r die Dienstaufrufe benutzt wird Zu diesem Zweck enthalten die Sequenz Diagramme technologieunabh ngige Methodenaufrufe wobei diese Methoden in einem UML
157. ellte Plugin orientierte Entwicklungsumgebung die speziell f r das TinyOS WebTinyOS WSN Betriebssystem entwickelt wurde Nebst Standardmerkmalen einer Entwicklungsumgebung gerade aufgrund der Eclipse Integration wie CVS Unterst tzung Projekt Manager nesC 2 Editor sowie Kompilierung und Ausbringung der entwickelten Codeartefakte ist die gr te Leistung der Entwicklungsumgebung die grafische Darstellung der aktuell zu entwickelnden Anwendungen auf Basis des komponentenbasierten TinyOS This tool produces a graphical representation of the currently developed application and can be used to plot the relation between its modules Exploiting the hierarchical structure of TinyOS modules the user can decide on the graph s level of abstraction by expanding or collapsing some of the elements If required it is possible to expand the graph to show all modules forming the current application including the ones of the operating system Burr06 Zwar bietet die grafische Darstellung eine visuelle Darstellung der zu entwickelnden Anwendung jedoch findet hier keine Abstraktion in der Hinsicht statt dass die visuelle Darstellung auch als formale Modellierung fungiert aus der die zugeh rigen Codeartefakte automatisiert generiert werden k nnten Dies w re eine sehr 12 Dies ist die Programmiersprache des TinyOS Betriebssystems Es handelt sich um eine leichte Erweiterung der herk mmlichen Programmiersprache C zur Einbettung komponentenbasierter E
158. en die daraufhin e ventuelle Sendewtinsche zuriickstellen Die Empfangsstation sendet eine Sendebereitschaft CTS woraufhin die Stationen die Daten bertragen k nnen Das Ende der bertragung wird durch ein ACK Signal signalisiert Das kollisionsfreie Verfahren eignet sich besonders f r bertragungen auf Medien die nicht auf Kollisionen reagieren wie z B Funkkan le WebCSMA CA 8l 5 5 Kompilierung und Initialisierung der Software Deployment Abschlie end werden die aus den Templates generierten Codeartefakte kompiliert um dann auf die Sensorknoten ausgebracht zu werden Zu diesem Zweck wurde das ScatterFlash Plugin entwickelt vgl Anhang 11 3 2 das die notwendigen Funktio nalit ten zur Verf gung stellt Die Realisierung des Plugins basiert auf CDT Ec lipse C C Development Tools WebCDT da der generierte zu kompilierende Quellcode reiner C Code ist Somit kann der Quellcode der Sensorknoten mit Hilfe der CDT innerhalb der Eclipse Umgebung ohne weiteres editiert werden Die Steue rung des Kompilierungsprozesses wird mit Hilfe des in Eclipse standardm ig in tegrierten ANT Plugins erledigt Ferner k nnen die kompilierten Softwareartefakte Hex Files mit Hilfe des ANT Plugins auf die Sensorknoten ausgebracht werden Die Kompilierung der Softwareartefakte sowie ihre serielle Ausbringung serial Flashing auf die Sensorknoten erfolgt mit Hilfe der mspgec Software Webmspgcc Die Steuerung dieser Software zur Akt
159. en Compiler zusammenge 85 MeasureSomeSensoryData MeasureSomeMoreSensoryData CheckStoredData Abbildung 48 Das mit der Laufzeitumgebung assoziierte Diagramm des Testfalls TestCollectionProcess Kame08 f gt werden Diese Vorgehensweise der Modellierung einer Assoziation zwischen dem Testfall der zu testenden Anwendung und ihrer Laufzeitumgebungskonfigura tion als Softwarefamilie tr gt zu einer deutlichen Steigerung der Produktivit t des Testprozesses bei Der Benutzer muss sich nicht mehr darum k mmern dass die zahlreichen variierenden Codeartefakte Testskripte Treiber Bibliotheken etc entsprechend zusammengef gt und dem richtigen Zielsensorknoten zugewiesen werden Die hierzu ben tigten Informationen sind alle im Modell erfasst so dass die korrespondierenden Codeartefakte stets zusammengef gt werden 5 7 Zusammenfassung In diesem Kapitel wurde das modellgetriebene Rahmenwerk ScatterFactory behan delt Es wurde geschildert wie die auf den Knoten laufenden Anwendungen formal modelliert werden um aus den Modellen die entsprechenden Softwareartefakte der Anwendung automatisiert zu generieren und anschlie end auf die jeweiligen Sen sorknoten auszubringen Zum Zweck der Anwendungsmodellierung wurde eine Do m nensprache entwickelt auf die beispielhaft eingegangen wurde Hierzu wurde auf Basis von Ecore ein komponentenbasiertes Metamodell entwickelt mit dessen Hilfe die Semantik und Syntax der Dom nenspra
160. en Module in einem separaten Container repr sentiert was zu einer h heren Strukturierung bei der Modellierung der Anwendung beitr gt 112 Full_Firmware uses Container 1 Timers_Cont BE es requires Abbildung 68 Die Modelldiagramme der Anwendungen Empty oben und Actor unten Hent06 Hierzu wird ein Actor Port f r das Data Modul in Container1 angelegt der seinerseits den Port AddTimer des anderen Containers durch die entsprechende requires Assoziation in Anspruch nimmt Die Assoziation erm glicht dass der Code beider Module zusammen generiert wird Folglich wird nur dasjenige Codesegment des Data Modules generiert das f r passives Verhalten zust ndig ist F r die restlichen Funktionalit ten des Moduls werden Dummy Templates vgl Kapitel 5 4 eingebunden Gleiches gilt f r das Timer Modul bei dem der definierte AddTimer Port garantiert dass nur die entsprechenden Templates Ausschnitte eingebunden werden und f r die sonstigen nicht ben tigten Funktionalit ten des Moduls lediglich Dummy Templates verwendet werden Die LED Anwendung steht somit f r die minimale Gr e an Code die zur Realisierung einer Akteur Rolle eines Sensorknotens ben tigt wird 113 Wie bereits erw hnt ist die Codegr e ma geblich f r die Produktivit t der automatisierten Anwendungsentwicklung Tabelle 2 zeigt die ben tigte Gr e an generiertem Code in Bytes f r die drei oben besprochenen Anwendunge
161. ensorknoten mit spezieller Software die die Funktionalit ten des EGates unterst tzt und durch ein serielles Kabel mit dem Rechner verbunden ist Damit kann der SuperNode alternativ zum EGate die Rolle der Senke problemlos einnehmen Diese Entwurfsentscheidung erm glicht es dass ScatterEditor hinsichtlich der Kommunikation mit dem drahtlosen Netz sowohl ber die serielle als auch die parallele Schnittstelle betrieben werden kann Dies ist ausschlaggebend wenn man bedenkt dass oft andere Werkzeuge bzw Plugins der ScatterClipse Werkzeugkette nebenl ufig mit demselben WSN kommunizieren So k nnen die unterschiedlichen Werkzeuge und somit deren Funktionalit ten gleichzeitig in Anspruch genommen werden wobei eine 99 Lastbalancierung und eine Trennung von Belangen separation of concerns bez glich der Kommunikationsschnittstelle zwischen den Sensorknoten auf der einen und den auf dem Rechner laufenden Komponenten der Werkzeugkette auf der anderen Seite stattfinden Abbildung 59 veranschaulicht den Aufbau von ScatterEditor bez glich der Kommunikationsschicht zwischen dem WSN und den Komponenten des ScatterEditor Plugins Property al Alarm Verbindung Z OTA Serieller vat Port Supernode Terminal Abbildung 59 Architektur von ScatterEditor Ding07 Im Entwurf des Management Plugins findet mit der Aufteilung in Reiter eine Trennung von Belangen statt zugleich k nnen die verschiedenen Reiter jedoch gemeinsam benut
162. entlichten Beitrag Losi07 in dem sie ihr modellgetriebenes Werkzeug vorstellen mit dessen Hilfe Sensoranwendun gen komponentenbasiert unter Verwendung von UML WebUML erstellt werden Current proposals for WSN application development are mainly focused on imple mentation issues The lack of a Software Engineering methodology which sup ports the entire development life cycle of these applications commonly results in highly platform dependent designs difficult to maintain scale and reuse Losi07 Die Notwendigkeit von Entwicklungswerkzeugen fiir Anwendungen drahtloser Sensornetze wird auch von Teng et al in ihrer im Oktober 2008 ver ffentlichten Studie ber die bis dahin vorhandenen Werkzeuge behandelt Sie sehen einen ho hen Bedarf an leistungsf higeren L sungsans tzen zur Programmierung und Ver waltung von WSN Anwendungen Die Anforderung an solche Werkzeuge deren Ar chitektur und die angewandten Paradigmen listen Teng et al als Schlussfolgerung ihrer Studie auf So halten sie u a fest dass die Handhabbarkeit des vom Werkzeug verfolgten Mechanismus zur Anwendungsentwicklung der Sensorknoten ein uner l ssliches Merkmal sei ber das gegenw rtige Werkzeuge verf gen m ssen WSN development tools should simplify the development and management through its features Teng08 Ferner ist ein hoher Grad an Koh renz und Zusammenarbeit innerhalb des Werkzeugs zu gew hrleisten The current state of the art disjoi
163. er 87 Abbildung 87 Serverkonfiguration zur Klientenverwaltung 88 Abbildung 88 Das Metamodell der DSL in ScatterFactory2 89 Abbildung 89 Das Metamodell der DSL zum automatisierten Anwendungstest in Visual ScatterUnit 173 135 155 161 162 163 164 165 166 167 ee 10 11 12 13 14 15 11 7 2 Programmauszugsverzeichnis Programmauszug 1 Ein einfacher Checks Ausdruck Programmauszug 2 Ausdr cke der Sprache Checks zur berpr fung der semantischen Regel des Vorhandenseins eines Start und Endknotens im Aktivit tsdiagramm zur Modellierungszeit Programmauszug 3 OCL Ausdruck zum Start und Endknoten des Aktivit tsdiagramms Programmauszug 4 OCL Ausdruck zum Start und Endknoten des Aktivit tsdiagramm Programmauszug 5 Checks Ausdruck zur syntaktischen Pr fung Programmauszug 6 Checks Ausdruck zu Abbildung 36 Programmauszug 7 Checks Ausdruck zu Abbildung 37 Programmauszug 8 Template der Initialisierungsroutine zur Topologie nderung des WSNs 19 52 52 53 59 60 61 62 Programmauszug 9 Definition von geschiitzten Bereichen innerhalb des Templates 63 Programmauszug 10 Einsatz von geschtitzten Bereichen fiir den manuellen Code Programmauszug 11 Definition von geschiitzten Bereichen innerhalb des Templates Programmauszug 12 Ausschnitt eines um ad quate Fehlermeldungen erg nzten Protokolls Programmauszug 13 Einige Checks Ausdr cke in ScatterFactory syntaktische Randbedingungen oben
164. er Temperatur In diesem Kontext ist es sehr effizient dem Benutzer die M glichkeit zu geben selbst einfache Beobachtungsbedingungen zu definieren und zu formulieren um verschiedene Vorg nge der Umgebung nach Bedarf unter die Lupe zu nehmen Zur Realisierung des Alarmsystems und seinen speziellen Parsern wurde eine Alarmsprach mit einer kontextfreien Grammatik entwickelt Die Grammatik fungiert als semantisches und syntaktisches Vehikel bzw Ger st auf dessen Basis sich korrekte klar strukturierte Alarmausdr cke formulieren lassen Sei G N T P S eine Grammatik mit N als der Menge der nicht terminalen Symbole mit S als Startsymbol und T als der Menge der terminalen Symbole wobei P die Menge der Produktionsregeln Herleitungsregeln stellt so hei t die Grammatik G kontextfrei wenn jeder gebildete Satz aus T gem den Produktionsregeln aus P und beginnend mit dem Startsymbol S auf ein nicht terminales Symbol aus N zur ckgef hrt werden kann Dies l sst sich mathematisch wie folgt beschreiben Sch 97 S 13 V wi we e P wie N A wie N U T Die folgende Tabelle veranschaulicht den Aufbau der Grammatik der Alarmsprache vgl Tabelle 1 a ALARMSYSTEM alarm ID if CONSTRAINTS b ID int int ID c CONSTRAINTS CONSTRAINT CONSTRAINT CONSTRAINTS d CONSTRAINT CONDITION ANDOR CONSTRAINT CONDITION TIMEPERIOD e CONDITION MEASUREMENT1 COMPARE float MEASUREMENT2 detect f COMPARE gt lt s gt 2
165. er Werkzeugkette unterst tzt Ferner besteht ein zentraler Ordner f r jedes erstellte drahtlose Sensornetz in dem s mtliche Konfigurationsdateien abgelegt werden Dies wird von einem speziellen Wizard realisiert das vom Root Plugin des Rahmenwerks ScatterPlug zur Verf gung gestellt wird Editor Sowohl ein textueller als auch ein grafischer Editor sind vorhanden Der textuelle Editor welcher vom Entwicklungs Plugin des ScatterEditor Rahmenwerks angeboten wird ist f r die Codierung der Anwendungen zust ndig Da der Editor auf Basis des Eclipse Projektes CDT realisiert wurde werden zahlreiche der in Tabelle 6 aufgelisteten Merkmale standardm ig unterst tzt Ferner werden die Merkmale von CDT von der Eclipse Gemeinschaft st ndig erweitert und optimiert Der grafische Editor in ScatterClipse ist f r die Modellierung zust ndig und wird daher von der architekturzentrierten Infrastruktur angeboten Beim grafischen Editor handelt es sich um einen GMF generativen Editor der sich automatisiert aus dem EMF Metamodell generieren l sst Ferner liefert er einen Adapter zur dynamischen Einbindung der benutzerdefinierten Randbedingungen um die Live Validierung der Modelle zu bewerkstelligen Simulator Diese Funktionalit t wird lediglich von der Entwicklungsumgebung Viptos unterst tzt In der ScatterClipse Werkzeugkette wird diese Funktionalit t durch den Simulationsdienst von ScatterUnit bewerkstelligt wie z B Simulation der Topologie nderun
166. erWeb Sensorknoten 117 Speichers Daher bleiben ca 37 f r die zu testende Anwendung und den zugeh rigen Testfallcode Sicherlich variiert die Gr e des Testfallcodes in Abh ngigkeit des Testobjektes jedoch wurde in Tabelle 4 von einer festen Gr e ausgegangen 490 Bytes die als obere Schranke f r einen Testfallcode angesehen werden kann ScatterWeb Firmware EMPTY ScatterWeb Anwendung Firmware ScatterWeb ScatterWeb Testing Layer Testing Layer ROM Speicher 60 KB RAM Speicher 2 KB Abbildung 71 Speicherplatzbedarf der Testautomatisierung Kame07 Denn beim Testfallcode handelt es sich berwiegend um eine Sequenz von Methodenaufrufen der Dienste der Testautomatisierungsschicht oder der Prozeduren des Testobjekts die die Ausf hrung des modellierten Testszenarios veranlasst Somit stellt der brig bleibende Speicherplatz gen gend Kapazit t f r die zu testende Anwendung zur Verf gung Dies belegen die drei repr sentativ gew hlten Anwendungen Betrachtet man beispielsweise die gr te der drei Anwendungen n mlich das Directed Diffusion Routingprotokoll so werden maximal 21426 Bytes beansprucht was ca 30 der Gesamtkapazit t ausmacht Anders sieht es beim wesentlich kleineren RAM Speicher aus Hier ben tigt die Firmware bereits ca 68 der gesamten Speicherkapazit t und weitere 7 kommen hinzu die von der Testautomatisierungsschicht ben tigt werden Dadurch bleiben ca 25 frei verf gbar was einen kna
167. erierungsprozess und dessen Realisierung er l utert Hier lag u a ein Augenmerk auf der Zusammenf gung von automatisiert generiertem und manuell erstelltem Code Dabei wurde der Gebrauch der Technik der gesch tzten Bereiche bei der Codegenerierung erl utert In den bisherigen Ab schnitten werden die Phasen des modellgetriebenen Prozesses deutlich angefangen von der Metamodellierung bis hin zur Generierung der Codeartefakte der Dienste zur koordinierten Durchf hrung des verteilten Testes auf den verschiedenen Sen sorknoten Die vielf ltigen Funktionalit ten dieser Dienste wurden im darauffolgenden und letzten Abschnitt beschrieben ScatterUnit bietet viele Dienste die f r den Test ver schiedener Anwendungen wiederholt in Anspruch genommen werden So kann z B die Messung von Sensordaten oder die Topologie eines Sensornetzwerks simuliert werden Auf diese Weise k nnen sich oft wiederholende Testdurchl ufe von Scat terWeb Anwendungen unabh ngig von der aktuellen Umgebung des Sensor Netz werks ausgef hrt werden Ferner wurde geschildert auf welche Weise es die Archi tektur ScatterUnits erm glicht dass das Verhalten der getesteten Anwendung von der Erweiterung durch ScatterUnit unbeeinflusst bleibt 70 5 ScatterFactory Der Pfad zur Anwendungsentwick lung ScatterFactory Hent06 stellt den zweiten Teil der generativen Infrastruktur der ScatterClipse Werkzeugkette dar Analog zu Visual ScatterUnit ist ScatterFactory ein model
168. erk mit dessen Hilfe die Daten drahtloser Sensornetze sowie der auf ihnen laufenden Anwendungen visuali siert und statistisch analysiert werden k nnen Die Konfiguration berwachung und Softwareupdates des Sensornetzes bzw der darauf laufenden Anwendungen wird mit Hilfe des ScatterEditors bewerkstelligt welches im siebten Kapitel vorge stellt wird Dabei wird erl utert wie die Hauptmerkmale von ScatterEditor eben falls internetbasiert in Anspruch genommen werden k nnen Im letzten Teil der Arbeit Bewertung und Positionierung von ScatterClipse wird in Kapitel 8 die Werkzeugkette ScatterClipse sowie deren Nutzen evaluiert bevor in Kapitel 9 verwandte Arbeiten diskutiert werden Abschlie end wird in Kapitel 10 ein Fazit gezogen wobei der integrierte Einsatz der Werkzeugkomponenten von ScatterClipse der einen koh renten Betrieb der Werkzeugkette bewirkt anhand der ScatterClipse AssemblyLine geschildert wird Vielf ltige Beispiele zum Einsatz der Werkzeugkette finden sich im Benutzerhandbuch sowie in den Video Demos auf der Webseite von ScatterClipse welche unter WebAlsa zu finden ist 4 Auf die technische Realisierung von ScatterFactory wird nicht gesondert in einem eigen st ndigen Kapitel eingegangen da diese analog zu Visual ScatterUnit vonstatten geht Je doch werden bestimmte technische Besonderheiten und Herausforderung innerhalb des Ka pitels hervorgehoben und genauer untersucht 2 Verwendete Technologien und Werkzeuge
169. erleichtert wird So kann beispielsweise auf den Status eines Knotens durch Instanzattribute zugegriffen werden wobei seine Funktionalit ten dann mittels entsprechender Methodenaufrufe in Anspruch genommen werden k nnen Zum Zweck der Realisierung der angestrebten Emulation des WSNs wurde das Paket ScatterWeb for Java entwickelt durch das die Einheiten eines WSNs durch ihre jeweils auf dem Rechner laufenden Java Objekte repr sentiert werden Nun k nnen netzbezogene Abl ufe anhand entsprechender Java Anwendungen gem dem objektorientierten Paradigma realisiert werden Diese Vorgehensweise erm glicht die Abstraktion von l stigen technischen hardwarenahen Aspekten Das Datenmodell des Pakets ScatterWeb for Java verf gt ber einen baumartigen Aufbau der sich aus den folgenden grundlegenden Klassen zusammensetzt vgl Abbildung 49 e Network fungiert als Beh lter der die unten aufgelisteten Instanzen beinhaltet aus denen das WSN besteht Desweiteren werden Konfigurationsdaten zum WSN in dieser Klasse abgelegt Diese Klasse stellt die Wurzel des Datenmodells dar 88 e eGate repr sentiert die Senke Einer Network Instanz ist genau eine Senke bzw eGate Instanz zugewiesen e Node repr sentiert einen Sensorknoten Eine Network Instanz kann beliebig viele Node Instanzen enthalten e AbstractModule repr sentiert ein auf dem Sensorknoten laufendes Softwaremodul Ein Knoten besteht aus einer beliebigen Anzahl solcher Module die geme
170. ersetzt w rde beliebig zwischen den unterschiedlichen generierten Codeartefakten zu navigieren und diese auf ausgew hlte Sensorknoten auszubringen Darin besteht das Hauptmerkmal des Entwurfs des OTA Flashing Reiters Die Softwareaktualisierung ber Funk via eGate ist im Vergleich zum seriellen Flashing etwas komplexer Zuerst wird eine serielle Verbindung zum eGate ber den Java COM Port hergestellt F r diese Aufgabe wird das Javax com verwendet Dadurch wird das kompilierte Softwareartefakt Hex file Zeile f r Zeile in das EEPROM des eGates geladen Als n chstes wird das Hex File zu den Zielknoten per Funk gesendet und gleichzeitig auf der seriellen Verbindung zum eGate auf alle auftretenden Fehler gelauscht Falls n tig wird dies in einer entsprechenden Dialogbox angezeigt Eine andere Herausforderung liegt darin dem Benutzer eine klare und einfache Interaktionsm glichkeit mit diesem Prozess zur Verf gung zu stellen der die 106 Handhabung der OTA Flashing Komponente in ScatterEditor erm glicht Mehr zu den einzelnen Funktionalit ten der OTA Flashing Komponente im Anhang 11 3 3 7 2 5 Die WSN berwachung Alarm Drahtlose Sensornetze werden zumeist zum Zweck der Beobachtung ihrer Umgebung eingesetzt Die Sensorknoten nehmen Messwerte aus ihrer Umgebung bearbeiten und evaluieren diese um R ckschl sse auf ihre Umgebung ziehen zu k nnen Typisch f r eine solche Messung z B zum Zweck der Geb udeautomatisierung ist die d
171. erungsdiagramm der Aktivitat AwaitSecondPaket 42 Die Testinformationen werden nach der Beendigung des Testfalls anhand des w hrend der Testausf hrung akkumulierten Logs bei der zust ndigen Pr froutine bzw dem zust ndigen Dienst von ScatterUnit analysiert Wie man unschwer erken nen kann sind solche Pr froutinen sehr anwendungsspezifisch daher werden sie ebenfalls vom Entwickler manuell implementiert So handelt es sich beispielsweise hier um die berpr fung der Integrit t des Pakets durch welche festgestellt wird ob dessen Nutzlast w hrend der bertragung erhalten geblieben ist oder besch digt wurde Bei der automatisierten Generierung der Testskripte eines Testfalls zerlegt der Codegenerator dieses in die darin enthaltenen Aktionen und weist diese dem Test skript des jeweiligen Sensorknotens zu auf dem das Skript mitsamt seiner Aktionen ausgef hrt wird Um die Reihenfolge der Ausf hrung der Aktionen beizubehalten werden wie zuvor erl utert die entsprechenden Signalisierungsbefehle des Testpro tokollierungsprozesses von ScatterUnit eingesetzt Da mit Hilfe der modellgetriebe nen Visual ScatterUnit die Ausf hrungsreihenfolge der Aktionen anhand der Rich tungspfeile des Aktivit tsdiagramms modellierbar ist wird auf dieser Basis der Co degenerator in die Lage versetzt zu unterscheiden ob zur Generierung der betroffe nen Aktionen entsprechende Signalisierungsbefehle erstellt werden m ssen oder nicht Dies ist m gli
172. es a sync node is linked to must be executed on distinct sensor nodes AwaitFirstPacket Chanae Topoloay Abbildung 37 Live Validierung entdeckt eine unzul ssige parallele Ausf hrung SendFirstPacket s ca context testcase SyncNode ERROR The control pathes a sync node is linked to must be executed on distinct sensor nodes List testcase ControlPath this outgoing target select e e metaType testcase ControlPath getDeploymentIdForFirstAction size List testcase ControlPath this outgoing target select e e metaType testcase ControlPath getDeploymentIdForFirstAction toSet size Programmauszug 7 Checks Ausdruck zu Abbildung 37 Kame08 Der durch die Live Validierung bereits auf Modellierungsebene bewirkte Ausschluss des Vorkommens von Zyklen im Testverlaufsmodell f hrt zu einer Reduzierung der Komplexit t des darauf folgenden Codegenerierungsprozesses Dies wird dadurch erreicht dass w hrend der Einbindung der notwendigen Templates nicht laufend berpr ft werden muss ob die f r die betroffenen Modellentit ten geltenden Rand bedingungen verletzt wurden oder nicht So kann die Einbindung der n tigen Temp 43 Das sind diejenigen Aktivit ten die im Diagramm zwischen zwei aufeinander folgenden Synchronisationsbalken modelliert werden 61 lates unmittelbar an den Ansto des Generierungsprozesses anschlie en ohne dass die Gefahr besteht durch im Modell
173. etet Regeln durch die ein Schema f r jedes g ltige XMI tibertragbare MOF basierte Metamodell generiert werden kann WebXML 154 11 3 Benutzerinteraktion Im Folgenden wird die Benutzerinteraktion mit ausgew hlten Komponenten der ScatterClipse Werkzeugkette demonstriert um den Aspekt Human Computer Interfaces f r WSN in der Werkzeugkette zu illustrieren 11 3 1 Der Wizard zur Einrichtung des WSN Step 3 Select outline graphics Select outline file X size I Y size Look in Diplomarbeit s O metadata r develop Recent Ecate eGatermi kasuj E plotter Desktop plugin DO startCOMPortServer OtestPlugin O9 MLParser N big_picture bmp N big_picture_270 bmp i figure _03 gif grundriss jpg N screenshots bmp My Documents My Computer a File name grundriss ipg Console 3 2 n n My Network Files of type peg gif bmp ipg v Cancel Abbildung 83 Der Wizard von ScatterPlug zur Einrichtung des WSN Lesz06 Im ersten Schritt Abbildung 84 oben links wird das Projekt des zu errichtenden WSNs angelegt Im folgenden Schritt oben rechts wird die Konfiguration der Datenbank vorgenommen und im letzten Schritt Mitte kann abschlie end die Grafik des WSN Grundrisses und die dazu n tige Skalierung gem der realen Entfernungen angegeben werden 155 11 3 2 Das ScatterFlash Plugin Kompilierung und Initialisierung
174. formation Language ATL http www eclipse org m2m atl WebBart Bartlett J The art of metaprogramming IBM 2005 http www ibm com developerworks linux library l metaprog1 html WebCart McCartney B Sridhar N TOSDev 0 J http selab csuohio edu dsnrg tosdev Link seit dem 2 8 09 nicht mehr aufrufbar 180 WebCastor Webseite des Castor Rahmenwerks http www castor org WebCDT Eclipse C C Development Tooling CDT http www eclipse org cdt WebCheck Check Language Reference http apps eclipse org gmt oaw doc 4 1 r30_checkReference pdf WebComp Wikipedia Art Komponentenbasierte Entwicklung http de wikipedia org wiki Komponentenbasierte_Entwicklung WebCSMA CA Computerlexikon CSMA CA http www computerlexikon com begriff csma ca highlight Netzwerk Webe98 Weber M Verteilte Systeme Spektrum Akademischer Verlag Heidelberg Berlin 1998 WebEcli Eclipse SDK http www eclipse org WebEcore Meta Model Ecore for Describing Models http download eclipse org modeling emf emf javadoc 2 5 0 org eclipse emf ecore package summary html details WebEMF Eclipse Modeling EMF http www eclipse org modeling emf WebFAT Wikipedia Art File Allocation Table http de wikipedia org wiki File_Allocation_Table WebGME Graphical Modeling Environment GME http www isis vanderbilt edu projects gme WebGMF Graphical Modeling GMF http www eclipse org modeling gmf WebGRATIS
175. g 138 Compiler Wird durch das Entwicklungs Plugin von ScatterEditor angeboten und ist auf Basis des standardm ig in Eclipse integrierten ANT Projektes realisiert Burner Ein Burner existiert als serielle Variante und ber Funk OTAP Die serielle Variante wird analog zum zuvor erw hnten Compiler realisiert Die funkgest tzte Softwareausbringung wird durch das in Reitern organisierte Verwaltungs Plugin unterst tzt und wurde dort als eigenst ndiger Reiter realisiert Keines der in der Studie untersuchten Werkzeuge unterst tzt diese Funktionalit t berwachung Diese Funktionalit t wird ebenfalls von keiner Entwicklungsumgebung unterst tzt In ScatterClipse sind unterschiedliche Techniken vorhanden die je nach Zweck die entsprechende berwachungsfunktionalit t realisieren So kann der Sensorstatus durch das Visualisierungs Plugin in ScatterPlug visualisiert und berwacht werden Ferner gew hrt das Statistik Plugin von ScatterPlug eine statistische Analyse der gesammelten Sensordaten um R ckschl sse auf die Sensorik sowie die Sensorumgebung zu ziehen Debugging Ein visueller automatisierter Test und Debuggingprozess wurde in ScatterClipse mittels Visual ScatterUnit realisiert Diese Funktionalit t wird ebenfalls von keiner der ber cksichtigten Entwicklungsumgebungen angeboten Die ScatterClipse Werkzeugkette erf llt damit alle Anspr che die in dieser Studie an WSN Entwicklungswerkzeuge gestellt werden Wie bereit
176. g 1 Der MDA Prozess Abbildung 2 Der AC MDSD Prozess Abbildung 3 Die Eclipse Plattform als OSGi Server Abbildung 4 Die Elemente von Ecore als Klassenhierarchie Abbildung 5 Die generative Schicht von EMF Abbildung 6 Modell Validierung im GMF Editor Abbildung 7 Die automatisierte Erstellung des Editors im GMF Abbildung 8 Die Architektur und Technologien von oAW Abbildung 9 Ein einfaches mittels Checks zu validierendes Modell Abbildung 10 Die Architektur der Live Validierung Abbildung 11 Die Template Sprache Xpand von oAW Abbildung 12 Die Workflow Konfiguration von ScatterFactory Abbildung 13 Die in ScatterClipse eingesetzen Werkzeuge und Technologien im Kontext des MDD Prozesses 14 Abbildung 14 Zusammenarbeit zwischen ScatterUnit und Visual ScatterUnit 15 Abbildung 15 Aktivit ten beim Einsatz von Visual ScatterUnit 16 Abbildung 16 Der generative Editor von Visual ScatterUnit 17 Abbildung 17 Modellierung des Testverlaufs mit Hilfe von Aktivit tsdiagrammen 18 Abbildung 18 Die beteiligten Komponenten einer typischen ScatterWeb Anwendung 19 Abbildung 19 nderung der Topologie w hrend der Testdurchf hrung 20 Abbildung 20 Aktivit tsdiagramm zur Modellierung des Verlaufs des Testszenarios 21 Abbildung 21 Das verfeinerte Diagramm der Aktivit t Change Topology aus Abbildung 20 22 Abbildung 22 Verfeinertes Diagramm der Aktivit t SendSecondPaket 23 Abbildung 23 Verfeinerungsdiagramm der Aktivit t AwaitSecondPaket 24 Abbildun
177. g 24 Visualisierung der Fehlermeldung im Modell durch den Einbau von entsprechenden Icons Links der Aktionen 25 Abbildung 25 Iterative Vorgehensweise bis der Fehler im Code aufgefunden wurde 26 Abbildung 26 Der Prozess zur Isolierung von Codefehlern innerhalb der zu testenden Anwendung 27 Abbildung 27 Das verfeinerte Diagramm des Testfalls 28 Abbildung 28 Der relevante Ausschnitt des Metamodells links das die Entit ten des Aktivit tsdiagramms rechts sowie deren Zusammenh nge veranschaulicht Eu En Heka Wna 7 9 10 12 13 15 16 17 18 19 21 22 24 29 31 32 33 34 37 40 40 Al 42 45 46 47 48 51 29 Abbildung 29 Assoziationen zwischen den Diagrammentit ten Ausschnitt aus dem Metamodell UML Notation 30 Abbildung 30 Verbindungen d rfen bei keinem Startknoten enden links Verbindungen d rfen ihren Ausgangspunkt nicht in einem Endzustand haben rechts 31 Abbildung 31 Der relevante Ausschnitt des Metamodells in UML Notation links der Entit ten des Detaillierungsdiagramms rechts 32 Abbildung 32 Die Markierungen hier Nutzlast fungieren als Bindungsmecha nismus zwischen den Protokolleintr gen und deren Pr froutinen Die Meldungen 171 52 53 54 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 der Uberpriifungen werden anschlieBen
178. g 73 Diagramme des entwickelten Testfalls Fortsetzung 74 Abbildung 74 Protokollierung und Analyse der Routingtabelle zum Zeitpunkt der Versendung des Paketes 75 Abbildung 75 Erg nzung des Detaildiagramms ErstesPaketSenden um eine Pr froutine zur berpr fung der Next Hop Information f r Schritt 3 76 Abbildung 76 Erg nzung zum Detaildiagramm Init1UndWarten Warten auf den Empfang der Routing Information ber den Empf nger des Datenpakets f r Schritt 4 77 Abbildung 77 Austausch der Routinginformationen ber den Zielknoten Knoten 4 78 Abbildung 78 Das erweiterte Detaildiagramm Init1UndWarten f r die Protokollierung des Eintrags der Routingtabelle vor und nach dem Empfang der betroffenen Routinginformation 79 Abbildung 79 Ben tigte Codegr e in Codezeilen f r die Testfallentwicklung 80 Abbildung 80 Ben tigte Codezeilen f r die automatisierte Fehlersuche 112 115 117 119 120 123 124 125 127 128 130 131 133 134 81 Abbildung 81 Anstieg des ben tigten Codes in Codezeilen zur Fehlersuche vor und nach der Fehlerlokalisierung und der mehrfachen Verfeinerung des Testfallmodells 82 Abbildung 82 Die ScatterClipse Assembly Line 83 Abbildung 83 Der Wizard von ScatterPlug zur Einrichtung des WSN 84 Abbildung 84 Das ScatterFlash Plugin zur Kompilierung und Initialisierung der generierten Softwareartefakte 85 Abbildung 85 Der OTA Flashing Reiter 86 Abbildung 86 Der Alarm Reit
179. g into any particular component all the way to the lowest level Opening any component to go to a lower level results either in a wiring diagram or a source file depending on the component Such hierarchical views provide a nice cognitive advantage the views are presented in mind sized chunks allowing developers the ease of use of small and manageable diagrams while at the same time carrying all the semantic information that is inherent in the wiring diagrams Cart06 Ferner bietet das Rahmenwerk weitere unterst tzende Funktionalit ten wie einen integrierten Compiler der nesC Sprache sowie einen Burner zur Vorbereitung der kompilierten Codeartefakte In dem im Jahr 2006 ver ffentlichten Beitrag zu TOSDev wird angek ndigt das Rahmenwerk weiter entwickeln zu wollen We are currently working on extending TOSDev to support TinyOS 2 0 and nesC 1 2 TOSDev will provide different visual cues for generic objects Cart06 Ruft man jedoch die offizielle Seite des Projekts auf WebCart stellt man fest dass die letzte Aktualisierung ebenfalls im Jahr 2006 vorgenommen und das Projekt anscheinend eingefroren wurde Vom Codegenerierungsprozess wird im Paper kaum etwas gesagt Ferner findet die Modellierung nicht gem dem modellgetriebenen Paradigma systematisch auf Basis eines zuvor festgelegten Metamodells zur Komponentenmodellierung statt Daher kann hinsichtlich der formalen Modellierung nicht von einer Dom nensprache ges
180. gen die Erf llung von zentral gehaltenen Rand bedingungen berpr ft wird Ferner wurde illustriert wie solche Randbedingungen mit Hilfe der ebenfalls von oAW mitgelieferten Sprache Checks formuliert werden k nnen Die f r die Konstruktion der Werkzeugkette verwendeten Rahmenwerke sind ausschlie lich Eclipse Projekte Dies erm glicht eine optimale Integration der Werkzeuge wodurch eine einwandfreie Zusammenarbeit gem dem modellgetrie benen Paradigma erzielt wird Alle verwendeten Rahmenwerke sind Open Source Projekte 25 3 Der Pfad des Anwendungstests Visual ScatterUnit Angenommen es soll ein System zur Steuerung einer sich selbst konfigurierenden HiFi Anlage getestet werden wobei das System die gesamten R umlichkeiten des Hauses abdecken soll Hierzu wird jeder Raum des Hauses mit einem Radioempfan ger sowie einem Lautsprecher ausgestattet Die Hauptaufgabe des HiFi Steuerungssystems ist es zu gew hrleisten dass genau diejenigen Komponenten des Systems eingeschaltet sind die sich in dem Raum befinden den eine Person ge rade betritt bzw in dem sie sich momentan aufh lt Dazu muss im zuletzt betrete nen Raum derjenige Sender automatisch ermittelt werden den die Person im zuvor verlassenen Raum geh rt hat Ein solches System besteht aus einer Vielzahl von an verschiedenen Stellen platzierten drahtlosen Sensorknoten wobei die Sensorknoten eines Raumes mit dem Radioempf nger des benachbarten verbunden sind Die Sen so
181. geschilderten Testverlauf zu steuern ist es unerl sslich die verteilte Ausf hrung des Testfalls test case zu koordinie ren Daf r muss ein entsprechender Synchronisationscode geschrieben werden was ein schwieriges Unterfangen ist da die manuelle Erstellung eines solchen Codes oft komplex und daher zeitaufwendig ist Wird nun diese Aufgabe automatisiert erledigt und dem Entwickler durch einen Codegenerator abgenommen tr gt dies erheblich zur Steigerung der Effizienz des Testprozesses bei Dies ist die Schl sselidee des im Rahmenwerk verfolgten modell getriebenen Ansatzes Daher werden Testszenarios durch ihre korrespondierenden formalen Modelle repr sentiert und anschlie end nach deren Validierung in den Codegenerator eingegeben um den Code des Testfalls zu generieren und auf den Sensorknoten auszubringen Der Anwendungstester bzw Entwickler muss sich le diglich auf den Entwurf des Testszenarios konzentrieren und ist daher weniger mit technischen Belangen besch ftigt Nach der Ausf hrung des Testfalls werden die Testergebnisse gesammelt um an schlie end in den zuvor erstellten Modellen visualisiert zu werden Die formalen Modelle vereinfachen ebenso die Aufgabe der Lokalisierung entstehender Fehler in der zu testenden Anwendung An dieser Stelle kommt die zweite Schl sselidee zum Tragen der visuelle kognitive Debuggingprozess der iterativ vom Entwickler in Ab h ngigkeit vom Testverlauf betrieben werden kann Bei jeder Iterat
182. gewonnen wird Dies wird in einem Unterkapitel erl utert wobei sich die Darstellung auf eine theoretische Grundlage beschr nkt und mehr die 142 Konzeption der M2M Transformation geschildert wird Ebenso wenig wird darauf eingegangen wie die Realisierung des Transformationskonzepts vonstatten geht Alles in allem handelt es sich hier eher um einen Vorschlag in dem Eigenschaften und Entwurf einer zu entwickelnden Modellierungssprache entworfen werden Nachfolgende Arbeiten zu dem vorgestellten Beitrag existieren bislang anscheinend nicht was die Realisierbarkeit des Ansatzes berhaupt in Frage stellt Ferner existieren modellgetriebene Werkzeuge zur Generierung von Softwareartefakten zur automatisierten Erstellung von Anwendungen drahtloser Sensornetze So wird in Losi07 ein modellgetriebenes Rahmenwerk zur automatisierten Generierung von Softwareartefakten f r eine plattformunabh ngige Erstellung von Anwendungen drahtloser Sensorknoten vorgestellt Dies soll mittels einer universellen Modellierungssprache bewerkstelligt werden in der allgemein gebr uchliche Aspekte der WSN Dom ne dargestellt werden F r die Modellierungssprache wird UML verwendet Damit wird in der Arbeit eindeutig ein MDA Ansatz verfolgt F r die Definition der Modellierungssprache wurde hnlich wie bei ScatterClipse ein EMOF Metamodell mit Hilfe des EMF Rahmenwerks entwickelt Allerdings werden Verhaltensdiagramme wie z B Aktivit tsdiagramme bislang nicht
183. gkette 112 8 1 Die Codegr e der in ScatterFactory erstellten Anwendungen 112 8 2 Bewertung der Testautomatisierungsschicht 114 8 3 Bewertung des modellgetriebenen Anwendungstests Fallstudie 119 8 3 1 Analyse und Evaluierung der Fallstudie 129 8 3 2 Schlussbemerkung zur Fallstudie 135 9 Verwandte Arbeiten 134 9 1 Zusammenfassung 145 10 Fazit und Zusammenf hrung 147 11 Anhang 152 11 1 Abk rzungsverzeichnis 152 11 2 Glossar 153 11 3 Benutzerinteraktion 155 11 3 1 Der Wizard zur Einrichtung des WSN 155 11 3 2 Das ScatterFlash Plugin Kompilierung und Initialisierung der Software 156 11 3 3 OTA Flashing 157 11 3 4 Der Alarm Reiter 158 11 3 5 11 4 11 5 11 5 1 11 5 2 11 6 11 7 11 7 1 11 7 2 11 7 3 11 8 11 9 Benutzerinteraktion im entfernten Modus Das Metamodell der Dom nensprache Die in Checks formulierten Randbedingungen Randbedingungen in Visual ScatterUnit Randbedingungen in ScatterFactory2 ScatterClipse im Einsatz Verzeichnisse Abbildungsverzeichnis Programmauszugverzeichnis Tabellenverzeichnis Literaturverzeichnis Aus der Arbeit entstandene Publikationen 159 160 162 162 167 170 171 171 174 175 176 184 1 Einleitung Drahtlose Sensornetze Wireless Sensor Networks WSN sind in den letzten Jahren Gegenstand erheblicher Forschungst tigkeit gewesen Sie bestehen aus einer gro en Anzahl von Sensoren die mit Mikro Kontroller Datenspeicher Sensorik und Funkmodulen
184. gung der Syntax und der Semantik basiert auf ei nem Ecore Meta Modell das gem dem EMF Meta Meta Modell definiert wurde Die Modellierung des Testverlaufs in der Dom nensprache orientiert sich stark an der Notation der Aktivit tsdiagramme in der UML Rupp07 S 235 365 Aktivi t tsdiagramme eignen sich gut f r diesen Zweck da es sich haupts chlich um die Steuerung des Testverlaufs handelt 30 Graphical Modeling Framework 1 Testfall modellierung Graphischer Editor basiert auf eingesetztes erstellt mit Werkzeug produziert C Testfallmodell nutzt f r die Live Validierung oAW Modell pr fung Metamodell der Modellierungssprache L Pr fausdr cke wird verarbeitet von 2 Modell validierung eingesetztes evaluiert Werkzeug produziert validiertes Testfallmodell wird verarbeitet von LI Templates 3 Code generierung bearbeitet Anweisungen von eingesetztes Werkzeug oAW Code generator produziert generierbarer Teil des Testfalls wird erg nzt von 4 Manuelle Code implementierung Eclipse JDT und CDT kompiliert und auf den Sensor knoten installiert mit Hilfe von ScatterUnit eingesetzte Werkzeuge produziert vollst ndiger Testfall wird ausgef hrt von Ant Skript innerhalb von Eclipse ausf hrbar
185. guration der Anwendung mit s mtlichen ben tigten Artefakten Trei bern und Bibliotheken automatisiert bewerkstelligt werden kann Dies wird mit ScatterFactory2 erreicht Abbildung 46 zeigt ein Modell in ScatterFactory2 in dem die Laufzeitumgebung zweier MSB Anwendungen in einem einzigen Diagramm mitsamt ihrer Konfigurati on repr sentiert wird ri NodeA MSB fa NodeB MSB iy MyApp Application If MyAppUsingFAT Application L scatterweb Library L CC1020 Library L SD Library L FAT Library SD_CACHE 1 FAT_FIND_SIMPLE 1 Abbildung 46 Das Modell einer Laufzeitumgebung zweier MSB Anwendungen Kame08 Im obigen Modell werden die Anwendungen MyApp und MyAppUsingFAT repr sen tiert Gem der Laufzeitkonfiguration des Modelldiagramms verwenden beide An wendungen die Standardsystembibliotheken scatterweb und CC1020 Des Weiteren benutzen beide zus tzlich die SD Bibliothek durch die ein Treiber zur Verf gung gestellt wird um einen Zugriff auf die SD Speicherkarte des MSBs zu erm glichen Das SD_CACHE Attribut der SD Bibliothek wird dabei auf 1 gesetzt Dies bewirkt die Aktivierung des Caching Dienstes w hrend der Inanspruchnahme des Moduls der Speicherkarte Hinter der Aktivierung der Dienste durch ihre zugeh rigen Attribute im Modell verbirgt sich die Idee dass die Initialisierungsroutine solcher Dienste auf Imple mentierungsebene als define in der C Sprache realisiert ist Ist die Belegung des Attributs im Modell 1 bz
186. he Dabei handelt es sich um dom nenspezifischen Infrastrukturcode der an den Codegenerator delegiert und somit dem Benutzer abgenommen wird Auf diese Weise konnte der architekturzentrierte Ansatz optimal eingesetzt werden Der vorliegende Problemraum stellt eine Dom ne mit sich oft wiederholendem Infrastrukturcode dar die sich zweckm ig architekturzentriert automatisieren l sst Dies best tigt auch der ben tigte Code der manuellen Testdurchf hrung in seiner Gesamtheit Denn hier handelt es sich vor allem um den f r die Koordinierung des dezentralen Testverlaufs zust ndigen Infrastruktur Code welcher vollkommen aus seinem zugeh rigen visuellen Modell im modellgetriebenen Visual ScatterUnit generiert werden kann 130 600 manuell erstellter Code u generierter Code 450 300 150 modeligetrieben manuell Abbildung 80 Ben tigte Codezeilen fiir die automatisierte Fehlersuche Kame08 Es bleibt zu untersuchen wie sich die Automatisierbarkeit des ben tigten Codes w hrend des Voranschreitens der Testdurchf hrung nach der Fehlersuche verh lt Ausschlaggebend ist dabei wie sich die Fehlerlokalisierung bei der Fehlersuche auf das Verhalten der Codegenerierbarkeit im Laufe des Testverlaufs auswirkt Insofern ist es sinnvoll den Automatisierungsgrad hinsichtlich der schrittweisen Verfeinerung des Testfallmodells zu betrachten Demzufolge ist das Verh ltnis zwischen manuellem und generiertem Codeanteil in Bezug auf die e
187. hlers zur Verf gung 99 9 234 103 3 bytes data DE CA 00 FAILURE The payload of the packet received on node 99 is corrupted Programmauszug 12 Ausschnitt eines um ad quate Fehlermeldungen erg nzten Protokolls Kame08 Die Daten der Protokolleintr ge werden in dem EEPROM des Sensorknotens abge legt um bei der anschlie enden Testanalyse effizient ausgelesen und bearbeitet werden zu k nnen Ein festgelegter Speicherbereich innerhalb des EEPROM wird ausschlie lich zum Zweck der Protokollierung in Anspruch genommen da gleichzei tig andere Segmente des EEPROM von weiteren simultan laufenden Anwendungen benutzt werden So wird der mit einer Speicherkapazit t von 64 KB ausgestattete EEPROM neben der zu testenden Anwendung von verschiedenen Firmwaremodulen der ScatterWeb Plattform verwendet Freilich f hrt dies dazu dass der Speicherbe reich nicht grenzenlos f r die Protokollierung in Anspruch genommen werden kann Jedoch ist bei der Durchf hrung der Testf lle in ScatterUnit nicht von einem Lang zeitbetrieb auszugehen Normalerweise handelt es sich bei den Testf llen um An wendungen die f r wenige Minuten ausgef hrt werden und bei denen sich der be n tigte Speicher kaum durch Log Eintr ge aufbl ht Dank der kurzen Ausf hrungs zeit h lt sich auch der f r die zu testende Anwendung ben tigte Speicherbedarf zur Speicherung der Messdaten in Grenzen Ferner spielt die Gr e bzw Anzahl der Log eintr ge f r die Aus
188. hmenwerks erfolgt und der visuelle Editor mit Hilfe des Graphi cal Modelling Rahmenwerks erstellt wurde werden die Komponenten mit Hilfe des GMF2 Adapters kombiniert um die Live Validierung zu erm glichen Zu diesem Zweck enth lt der visuelle Editor den GMF2 Adapter der den Zugriff auf die model checking engine von openArchitectureWare erm glicht Diese wird wiederholt aufge rufen um das Testfall Modell das gerade editiert wird auf der Basis von Bedingun gen zu validieren Eine gro e Anzahl von syntaktischen Regeln kann kompiliert werden der wahre Nutzen der Modellvalidierung in Visual ScatterUnit entfaltet sich jedoch bei der Pr fung semantischer Regeln Im Kapitel wurden repr sentative semantische Randbedingungen erl utert und diskutiert wobei gezeigt wurde wie stark sich dadurch die Robustheit des verteilten Tests steigert Insgesamt sichert die Modell Validierung die Qualit t des auszuf hrenden Testfalls und erh ht damit die Robustheit der Testfallentwicklung Weiterhin zeigt die Live Validierung Fehler w hrend der Testfallmodellierung an so dass der Benutzer diese zeitnah korrigie ren kann 50 Es handelt sich um den von ScatterUnit standardm ig unterst tzten Protokollierungs dienst f r die empfangenen Pakete bei dem der Detaillierungsgrad der Protokollierung Pa ketkopf usw vom Benutzer auf Modellebene beliebig konfiguriert werden kann Siehe hier zu Abbildung 33 in 4 1 69 Als n chstes wurden der Codegen
189. hnet einsetzen l sst um diesen kognitiven iterativen Debuggingprozess effizient und robust auszu f hren 49 4 Technische Realisierung des Testrahmenwerks Wie im letzten Kapitel ersichtlich wurde bedingt ein optimierter Einsatz des Tests eine robuste Zusammenarbeit seiner verschiedenen Komponenten entlang der Ar chitekturhierarchie angefangen von der auf den Sensorknoten laufenden Testinfra struktur ScatterUnit bis hin zur Dom nensprache die auf Basis des dazu geh rigen Metamodells definiert ist Daher ist es an dieser Stelle angebracht einen genaueren Blick auf die im Hintergrund laufenden Prozesse zu werfen auf denen die koh ren te zielgerichtete Gesamtfunktionalit t des Rahmenwerks beruht Dabei folgt die Behandlung der Komponenten der Werkzeugkette einer top down Betrachtung Zu n chst werden die Eigenschaften der Dom nensprache DSL beschrieben vgl Ka me 08 dann wird er rtert wie anhand des Metamodells die Modellierungssprach eigenschaften in Visual ScatterUnit entworfen und realisiert wurden Dies f hrt zur Validierung vgl Kame 08 der DSL welche auf den Eigenschaften des Metamodells fu t und der Frage inwiefern die Validierung den darauf folgenden Codegenerie rungsprozess vgl Kame 08 steuert Die wichtigsten Techniken der Generierung von Code Artefakten zur Testautomatisierung in Visual ScatterUnit werden disku tiert Abschlie end werden die Dienste vgl Kame 07 der Testautomatisierungs schicht Sca
190. hrerseits festlegen wie weiter vorgegangen wird Das Modell des Testfalls wird entsprechend verfeinert und der Testfall erneut ausgef hrt Auf diese Weise wird sukzessiv verfahren bis das Modell vollst ndig von Fehlern bereinigt und somit die Versagensursache endlich gefunden wurde Um dies zu veranschaulichen kehren wir zum Testfall des DSDV Routingprotokolls zur ck und versuchen das eben Gesagte an diesem Beispiel zu demonstrieren Die berpr fung der Testresultate nach der Ausf hrung des Testfalls bei der ers ten Iteration zeigt dass das zweite Datenpaket von Sensorknoten 4 nicht empfangen wurde Wir stellen daher die Hypothese auf dass das Routingprotokoll das Paket ber eine falsche Route weitergeleitet hat Nun m ssen wir bestimmen ber welche Route das Paket f lschlicherweise weitergeleitet wurde Das Testfalldiagramm wird verfeinert vgl Abbildung 27 indem es um weitere Aktivit ten erweitert wird durch die der unmittelbar benachbarte Knoten zu dem das betroffene Paket weiter geleitet wurde festgestellt werden soll Im Fall dass das Paket ber die restlichen Sensorknoten 2 bzw 3 1 ist der Sen der und 4 ist der Empf nger weitergeleitet wird warten die Aktivit ten Assert Forwarding und AssertNoForwarding auf das Datenpaket Eine Pr froutine wird dem Sensorknoten 2 zugewiesen um einen Fehler zu registrieren falls das Da tenpaket nicht zu diesem Sensor weitergeleitet wird Dieses Vorgehen ist dadurch begr ndet
191. hrung des zum Test gew hlten Testszenarios Somit setzt sich ein Testszena rio in ScatterUnit aus einer Menge von Aktionen zusammen z B das Versenden ei nes Pakets sowie aus Ereignissen deren Vorkommen man f r den Fall erwartet dass die Ausf hrung der Anwendung fehlerfrei vonstatten geht z B der erfolgreiche Empfang eines Pakets durch den richtigen Zielknoten Daher besteht die Grundlage f r die Evaluierung der Testfallausf hrung in der Erstellung einer Sequenz von Aktionen bzw Ereignissen die aus der Protokollie rung des nebenl ufigen Testverlaufs konstruiert werden Aufgrund der nebenl ufi gen Ausf hrung muss weiterhin die Reihenfolge spezifiziert werden in der die Akti onen ausgef hrt werden sollen Diese Ordnung ist dem Testszenario zu entnehmen das wie eingangs erw hnt als Leitfaden des Testfalls fungiert Das Schreiben des dazu n tigen Codes mit der Einhaltung der richtigen Reihenfolge der nebenl ufig ablaufenden Aktionen ist jedoch ein schwieriges Unterfangen Dies wird im kom menden Abschnitt anhand eines konkreten Anwendungsbeispiels demonstriert 3 3 Die Implementierung des Testfalls in ScatterUnit ScatterUnit ben tigt f r die Implementierung eines Testfalls wie bereits erw hnt sogenannte Testskripte welche die f r den Test n tigen Steuerbefehle implementie ren Daher muss der Entwickler bzw Testfalldesigner sich mit den folgenden beiden Fragen befassen e Welche Steuerbefehle werden auf welchem Sens
192. ich angekommen war 123 O E Ve FY Empfaenger Log Action Log Label FY Routingtabelle Log Action Log Label Routingtabelle EmpfaengerNichtBekannt Assertion Log Labels Routingtabelle V NextHopFalsch Assertion Log Labels Routingtabelle E Senden Control Action Abbildung 75 Erg nzung des Detaildiagramm ErstesPaketSenden um eine Pr froutine zur berpr fung der Next Hop Information f r Schritt 3 Kame08 124 WN WarteAufRoutingInfo Await Radio Packet Action Sending Node 3 Addressed Node 255 Packet Type 6 Timeout 0 Additional Checking true Processing Time BEFORE laa D H RoutingInfoEmpfangen Radio Packet Received Event m e a eel Fr RoutingInfo Radio Packet Log Action Log Label RoutingInfo Detail DATA_ONLY NextHopFalsch Assertion Log Labels RoutingInfo 5SekundenWarten Control Action 7 ssekundenabgelaufen Event ee a ee ea Abbildung 76 Erg nzung zum Detaildiagramm Init1UndWarten Warten auf den Empfang der Routing Information ber den Empf nger des Datenpakets f r Schritt 4 Kame08 Schritt 5 ben tigte Zeit ca 60 Minuten Der Testfall wurde aus Gr nden der Robustheit mehrfach durchgef hrt und leider wurde paradoxerweise festgestellt dass das Versenden stets klappte das versendete 125 Datenpaket den Empf nger jedoch nicht immer erreichte da die Routingtabelle nur zeitweise die korrekten Eintr ge beinhaltete U
193. ie Realisierbarkeit einer universellen Modellierungssprache kaum nachweist Es handelt sich bei der Arbeit eher um eine Anregung bzw einen Ansatz der von seiner Realisierung noch weit entfernt ist Des Weiteren werden im vorgestellten Ansatz zwei Kernaspekte nicht unterst tzt Verhaltensdiagramme in der vorgeschlagenen universellen Modellierungssprache werden nicht in Betracht gezogen wodurch sich die Modellierung auf statische Aspekte der Anwendung beschr nkt Das Verhalten der modellierten Anwendungen wird somit au er acht gelassen Ein Testprozess ist damit nicht im Blickfeld Andererseits wird in der gesamten Arbeit keine Modellvalidierung erw hnt was jedoch f r eine robuste modellgetriebene Anwendungsentwicklung unerl sslich ist Nachfolgende Entwicklungen dieser Arbeit sind bislang nicht zu finden Von Sadilek et al wird ein Forschungsvorhaben vorgestellt in dem die Eigenschaften einer dom nenspezifischen Sprache f r die modellgetriebene Entwicklung von WSN Anwendungen im Mittelpunkt steht Sadi07 Sadi08 Zwar ist inzwischen die Zielsetzung des Vorhabens vollst ndig neu definiert worden was m glicherweise 18 Das Forschungsprojekt besch ftigt sich inzwischen mit der strukturierten Entwicklung und Wartung von Metamodellen und deren Dom nensprachen im Hinblick der in den Modellen ben tigten operationalen Semantik Mehr dazu in WebSadilek 143 darauf hinweist dass der vorgestellte Ansatz keine entsprechende Umsetzung gefu
194. ie Senke angeschlossen ist und sorgt f r die automatische Initialisierung bzw Konfiguration notwendiger Soft waremodule der Sensorknoten um den Testablauf anzusto en Wurde die Ausf h rung des Testfalls gestartet schreitet der Prozess wie folgt voran Jeder am Testszenario beteiligte Sensorknoten empf ngt zum Zeitpunkt der Initi alisierung von ScatterUnit Testautomation die folgenden Softwareartefakte die dann der Reihenfolge nach auf dem jeweiligen Knoten initialisiert werden 1 die zu testende Anwendung 2 die libScatterUnit Bibliothek 3 der f r jeden Sensorknoten abh ngig von seiner Rolle im Test ma geschnei derte Testcode z B Testskript etc Unmittelbar zu Beginn aktiviert ScatterUnit Testautomation jeweils die libScat terUnit Bibliothek auf jedem Sensorknoten mit deren Hilfe der Testverlauf dezen tral gesteuert wird und beginnt dann auf die vom Sensornetz eingehenden Nach richten zu lauschen Nun f ngt die nebenl ufige auf den Sensorknoten verteilte Ausf hrung des Testcodes an was nun unabh ngig vom auf dem Rechner laufenden Rahmenwerk ScatterUnit Testautomation durchgef hrt wird Dies wird dadurch m glich dass der Testcode jegliche ben tigte Funktionalit t lediglich durch die sich auf demselben Knoten befindenden Dienste der libScatterUnit Bibliothek findet und in Anspruch nimmt Dadurch wird eine infrastrukturlose Steuerung und Koordina tion des verteilten Tests erreicht um den Funkkanal so wenig wi
195. iert der sich auf die Schnittstellen der TinyOS Komponenten beschr nkt Dies ist wahrscheinlich auf die eben erw hnte Einschr nkung des Codegenerierungsprozesses zur ckzuf hren Generierung von Infrastrukturcode wie bei ScatterClipse wird nicht gew hrleistet Ferner bleibt der Test der zu entwickelnden Anwendungen insgesamt ausgeblendet und es werden auch keine Simulations und Verwaltungsfunktionalit ten in den Entwicklungsprozess integriert Eine grafische Entwicklungsumgebung die ebenfalls die komponentenbasierte Entwicklung f r TinyOS unterst tzt ist das von der Cleveland State University entwickelte TOSDev Rahmenwerk Cart06 Die komponentenbasierte Modellierung ist im Vergleich zu GRATIS anspruchvoller So k nnen zwischen den Komponenten vorhandenen Assoziationen semantische Eigenschaften zugewiesen werden wodurch die Abh ngigkeiten der verkn pften Komponenten feink rniger ausgedr ckt werden k nnen Dies f hrt dazu dass der daraus generierte Codeanteil deutlich steigt Ferner bietet die Modellierung flexible Konfigurationsm glichkeiten der einzelnen Komponenten indem beispielsweise beliebig neu definierte Schnittstellen zum Komponentenmodell hinzugef gt werden k nnen Dies ist u a deshalb m glich weil jedes einzelne Komponentendiagramm intern bearbeitet werden kann was den Detaildiagrammen der Firmwaremodule bzw der Testfalldiagramme in ScatterClipse vergleichbar ist The wiring editor also allows the developer to di
196. iert die zur Realisierung der jeweiligen Funktionalit t des Ablaufstrangs bzw der jeweiligen Aktivit t der Testdurchf hrung notwendig sind Solche im Detaillierungsdiagramm modellierten technischen Belange fungie ren dann als Eingabeparameter f r den Testgenerator um daraus den zugeh rigen Infrastrukturcode automatisiert zu generieren Das Ablaufstrangdiagramm liefert somit einen tieferen Einblick ins Innere eines bestimmten Sensorknotens hinsicht lich des Verhaltens der darauf laufenden zu testenden Anwendungen Zudem wird die Reihenfolge der Ausf hrung der einzelnen Aktionen als lineare Sequenz festge legt die auf dem jeweiligen Knoten l uft Der Modellierer muss festlegen welche Aktionen zu einem Ablaufstrang zusammengestellt werden er muss jedoch nicht f r die Parallelit t der Ausf hrung Sorge tragen da diese wie bereits erw hnt aus schlie lich durch die Synchronisationsbalken des Aktivit ts bersichtsdiagramm ko ordiniert wird Abbildung 31 zeigt den relevanten Ausschnitt des Metamodells zur Definition des detaillierten Diagramms In diesem Ausschnitt finden sich die im letzten Kapitel bez glich des Routingprotokolls behandelten Modellentit ten wieder 40 Beim Infrastrukturcode beim Einsatz Visual ScatterUnit handelt es sich beispielsweise um den Code zur Erstellung und Bearbeitung der Log Eintr ge zur Analyse der Testergebnisse Dienste von ScatterUnit Steuerung und Koordination des Testverlaufs und Visualisieru
197. ierung der zu testenden Anwendung nicht beeintr chtigt Daher bezieht sich die weitere Diskussion hinsichtlich des EEPROMS Speicherverbrauchs ebenfalls auf die ESBs obwohl bei den MSBs eine vier GB gro e SD MM Karte zur Verf gung steht Das 64 KB gro e EEPROM wird meist zur Ablegung von Me daten verwendet die von der Anwendung gesammelt werden Daher beansprucht die Firmware einen vergleichsweise minimalen Anteil des EEPROMs In erster Linie kommt f r die Inanspruchnahme des 118 EEPROMs die Speicherung der erstellten Log Eintr ge zur Realisierung des local logging zum Tragen F r diesen Zweck wurde der Testfall f r das DSR Routingprotokoll 60 Sekunden lang ausgef hrt wobei in dieser Zeit der Protokollierungsdienst der Datenpakete voll aktiviert war Am Ende betrug das Datenvolumen der gesamten Log Eintr ge ca vier KB was f r den 64 KB gro en EEPROM Speicher keine Herausforderung darstellt Ferner ist zu betonen dass es sich bei den durchgef hrten Testf llen keineswegs um einen Langzeitbetrieb handelt Die Testf lle werden vielmehr gezielt hinsichtlich ausgew hlter zu pr fender Fragestellungen bzw Aspekte des Testobjektes ausgef hrt Eine Aufbl hung der Log Eintr ge bis zur berschreitung der maximalen Kapazit t des 64 KB gro en EEPROM Speichers ist somit so gut wie ausgeschlossen Kame07 8 3 Bewertung des modellgetriebenen Anwendungstests Fallstudie Zur Beurteilung der erzielten Produktivit t der modellgetriebe
198. iesen Gegebenheiten bzw Anforderungen m ssen die Entwicklungswerkzeuge und verwendeten Ans tze und Technologien Rechnung tragen Daher verwundert es nicht dass Softwarehersteller ebenfalls diese Bed rfnisse erkannt haben und be strebt sind die WSN Technologie und deren Softwareentwicklungsprozess in ihre Entwicklungsumgebungen nahtlos zu integrieren Dies wird z B bei Forschungsar beiten von Microsoft Research deutlich Up until now research in the area of WSNs has mostly focused on hardware design self organisation a plethora of routing algo rithms or energy saving patterns The upcoming challenge is the design of efficient interfaces to the WSNs and their tight integration into development environments such as Visual Studio Naum07 Der steigenden Komplexit t sollten Werkzeuge mit entsprechender Abstraktion w hrend der Anwendungsentwicklung entgegenwirken wodurch die Fachlichkeit in den Mittelpunkt r ckt und von den technischen Belangen abstrahiert werden kann Dies ist auch der erste Aspekt der im bereits erw hnten Beitrag von Wada et al bei den meisten vorhandenen Entwicklungswerkzeugen f r WSN Anwendungen be m ngelt wird The first issue is a lack of adequate abstractions that application de velopers can leverage for the rapid implementation of WSN applications The level of abstraction remains very low in the current practice of WSN application develop ment Wada07 Die Notwendigkeit zur Abstraktion von te
199. igenschaften in die Programmstruktur F r nesC wird daher ein spezieller Compiler ben tigt Mehr dazu in Gay03 134 zweckm ige Erweiterung der Entwicklungsumgebung Der Test der zu entwickelnden Anwendung wird ebenfalls nicht unterst tzt Ferner fehlen Verwaltungsfunktionalit ten wie die Konfiguration und Visualisierung des Sensorstatus sowie die funkgest tzte Ausbringung der Softwaremodule Eine Internetintegration in die Eclipse Plattform zur entfernten Bet tigung der Umgebungsmerkmale wird ebenfalls nicht unterst tzt Eine weitere Eclipse basierte Entwicklungsumgebung ist TinyDT WebSall die an der Vanderbilt Universitat entwickelt wurde TinyDT wurde ebenfalls fiir die Unterstiitzung des TinyOS Betriebssystems entwickelt The most important feature that distinguishes TinyDT from the existing TinyOS IDE attempts is that TinyDT s internal parser builds an in memory representation of the actual nesC application which includes component hierarchy wirings interfaces and the JavaDoc style nesC documentation WebSall Insofern hnelt sie sehr dem zuvor besprochenen YETI Rahmenwerk Allerdings bietet TinyDT im Gegensatz zu YETI keine grafische Darstellung der TinyOS Komponenten der jeweils zu entwickelnden Anwendung GRATIS Graphical Development Environment for TinyOS WebGRATIS ist ein ebenfalls an der Vanderbild Universit t entwickeltes Rahmenwerk f r die modellgetriebene Entwicklung von Anwendungen drahtloser Sensorknoten
200. im Verfahren entsteht nach der der Code weiter zerlegt und somit der Problem bereich kleiner wird Im obigen Beispiel w re es m glich die Annahme zu treffen dass der Fehler auf die Speicherungsfunktionalit t der gesammelten Daten zur ck zuf hren ist Um diese Annahme zu verifizieren m ssen die relevanten vom Sen sorknoten gesammelten Daten in Betracht gezogen werden Dieser Schritt ist f r die 38 Um die Sensorik des Knotens zu berpr fen kann parallel die statistische Analyse von ScatterPlug eingesetzt werden mehr dazu in 6 4 Dies ist ein Beispiel f r die erg nzende Zusammenarbeit der verschiedenen Features bzw Komponenten der ScatterClipse Platt form 46 Durchf hrung des oben beschriebenen Prozesses unerl sslich An dieser Stelle stellt sich die Frage wie das Gesamtbild des Prozesses zur Isolierung der Fehler inner halb des Codes genau aussieht Beim Einsatz der modellgetriebenen Visual Scatter Unit geschieht dies wie in Abbildung 26 dargestellt Defekt lokalisieren Testergebnisse Testfall analysieren ausf hren Defekt nicht lokalisiert Testfall verfeinern Defekt lokalisiert Abbildung 26 Der Prozess zur Isolierung von Codefehlern innerhalb der zu testenden Anwendung Kame08 Zuerst werden wie erw hnt die in das Modell inkorporierten Testresultate analy siert Auf Basis der daraus erhaltenen R ckschl sse auf das Verhalten der Anwen dungen werden neue Hypothesen aufgestellt die i
201. inden werden manuell nach der Codegenerierung an wendungsspezifisch vervollst ndigt 1 ControlAction InitNodel 2 bool bAbortTestCaseExecution False PROTECTED REGION ID MovingReceiverTestCase Init InitNodel ENABLED START DSDV init 5 PROTECTED REGION END is if bAbortTestCaseExecution 11 Test abort 0 12 return 13 Programmauszug 10 Einsatz von geschiitzten Bereichen fiir den manuellen Code Kame08 lt lt PROTECT CSTART CEND ID this protectedRegionld testCaseName gt gt TODO Implement ControlAction this name here TODO Set bAbortTestCaseExecution to True if a failure occured lt lt ENDPROTECT gt gt Programmauszug 11 Definition von geschiitzten Bereichen innerhalb des Templates Kame08 64 4 4 Die Dienste der Testschicht ScatterUnit ScatterUnit Kame07 stellt die notwendigen Dienste zur Verf gung die die Auto matisierung des Testablaufs von ScatterWeb Anwendungen auf Sensorknotenebene erm glichen Hierf r ist es unerl sslich die Funktionalit ten der Testschicht so wohl direkt auf den Sensorknoten als auch auf der Basisstation PC laufen zu las sen Zu diesem Zweck wurde einerseits die Laufzeitumgebung der Sensorknoten mit Hilfe der Bibliothek libScatterUnit best ckt Anderseits wurde ein Rahmenwerk namens ScatterUnit Testautomation realisiert Dieses Java basierte Rahmenwerk l uft auf dem Rechner der Basisstation an den d
202. inen Fehler in der Anwendung auf so wird wie zuvor erw hnt der betrof fene Eintrag im Protokoll um eine entsprechende f r den Benutzer aussagekr ftige Fehlermeldung erg nzt Programmauszug 12 zeigt einen Ausschnitt aus einem er 67 weiterten Protokoll in das eine Fehlermeldung bez glich der berpr fung der Nutzlast eines vom Sensorknoten mit der ID 99 empfangenen Pakets eingef gt wurde Die textuelle Fehlermeldung The payload ist durch das Blitz Symbol im Modell einsehbar und gleiches gilt f r die protokollierte Nutzlast anhand des i Symbols Das durch die Fehlermeldungen erweiterte Protokoll kann zus tzlich dem Benutzer textuell ausgegeben werden Diese Variante zur Fehlernachvollziehung steht dem Benutzer zwar zur Verf gung das Hauptanliegen des Rahmenwerks ist es jedoch die Fehlermeldungen innerhalb der formalen Modellkonstrukte welche die Fehler verursachen im Editor zu visualisieren Gem den protokollierten Eintr gen des Protokollausschnitts besteht die Nutz last des Datenpakets aus den drei Bytes DE CA 00 die jedoch nicht mit der erwarte ten Anzahl bereinstimmen Aufgrund seiner Kenntnis ber die zu testende An wendung und das Testszenario kann der Benutzer in Erfahrung bringen dass die korrekte Nutzlast des Pakets lediglich aus den zwei Bytes DE CA besteht Daher stellen die protokollierten Daten mit ihrer zugeh rigen Fehlermeldung ausreichend Informationen zum genauen Verst ndnis des gemeldeten Fe
203. ing addind and modification of timers portName matches Events amp portConnections exists e e toPort portName matches AddTimers e toPort portName matches ModifyTimers Programmauszug 13 Einige Checks Ausdriicke in ScatterFactory syntaktische Randbedingungen oben und semantische dom nenspezifischen Randbedingungen unten Hent06 TT Im Folgenden wird aus jeder Klasse jeweils ein Ausdruck n her betrachtet um ein genaueres Bild des Einsatzes der Checks Sprache f r ScatterFactory zu gewin nen Betrachtet man den zuerst spezifizierten Ausdruck so sieht man dass der Ausdruck der berpr fung dient ob jede Sensorinstanz ber einen eindeutigen Namen verf gt und der Name kein leeres String ist Hier ist leicht erkennbar dass der Ausdruck sich mit einer syntaktischen Fragestellung der Dom nensprache be fasst Beim ersten recht komplexen Ausdruck der unteren Kategorie handelt es sich im Gegensatz dazu um einen dom nenspezifischen Ausdruck Dieser zeigt einen Modellierungsfehler an im Falle dass der f r eine passive Komponente definierte Port Actor mit einem weiteren Port verkn pft wird welcher einen Dienst des ereig nisgesteuerten Timermoduls zur Verf gung stellt Durch diesen Ausschluss wird bewirkt dass kein unn tiger Code f r eine solche passive Komponente generiert wird was zu einer Optimierung des Speicherbedarfs f hrt Eine bestm gliche Ver kn pfung der Komponenten richtet sich dank entsprechender M
204. ins WSN SensorNode amp amp e name this name size 1 context WSN FilterRule ERROR The definition of a filter rule must not be empty this definition null amp amp this definition length gt 0 context WSN TestCase ERROR A test case must be assigned to at least one sensor node this linkedNodes select e e metaType superTypes contains WSN SensorNode size 167 gt 0 context WSN TestCase ERROR Some sensor node ids are assigned to more than one sensor node this outgoing size this incoming size 0 true Set WSN LabeledLink this outgoing union this incoming label hasDuplicateIds false context WSN Library ERROR A library must be linked to at least one application this linkedNodes select e e metaType WSN Application size gt 0 context WSN Application ERROR An application must be linked to at least one sensor node this linkedNodes select e e metaType superTypes contains WSN SensorNode size gt 0 context WSN Application ERROR The name of an application must be unique this name null this name length 0 true this diagram diagramNodes select e e metaType WSN Application amp amp e this name contains this name false context WSN Application WARNING An application should be linked to the library scatterweb this linkedNodes
205. insam die Sensormaske bilden Network Schicht Network EX J l Xe Node amp eGate Schicht Node ve Node eGate vA x yA Module Schicht Module u Module Abbildung 49 Das Datenmodell in ScatterWeb for Java Mysl06 Abbildung 50 veranschaulicht die Ablaufschritte beim Nachrichtenaustausch und die daran beteiligten Klassen bzw Methoden des ScatterWeb for Java Pakets Ausschlaggebend f r den Nachrichtenaustausch in ScatterWeb for Java ist dass die Zustellung der aus dem WSN kommenden Nachrichten einem ereignisbasierten Ansatz unterliegt der auf der Java Listener Technik basiert Dies ist ein weiteres Beispiel f r den Einsatz objektorientierter Technologien 89 DJ Nachrichtenaustausch Network P wa 2 WSN implementiert eGate gt gt Event Listener serialEvent E Node 1 Noden received received P Yy 4 BR st aus Module 1 Module et Bisa received received oderven Abbildung 50 Nachrichtenaustausch in ScatterWeb for Java Die eGate Klasse implementiert die von der COM Port API angebotene Schnittstelle javax comm SerialPortEvent Listener Dementsprechend wird die lauschende eGate Methode serialEvent aufgerufen sobald eine Nachricht aus dem WSN vorliegt Die Methode bewirkt die Zustellung der Nachricht an denjenigen Knoten an den die Nachricht adressiert ist Der
206. insatzgegebenheiten an das Rahmenwerk in Bezug auf die ScatterWeb Sensorknoten eine entscheidende Rolle Hierbei ist das Spektrum der mit dem Rah menwerk potentiell zu testenden Anwendungen von zentraler Bedeutung Akyi02 Eine typische WSN Anwendung wie es auch in ScatterWeb der Fall ist besteht haupts chlich in der Erfassung der Umgebungsdaten ber eine bestimmte Zeitperi ode und anschlie end der Evaluierung der gesammelten Daten auf dem Rechner bzw einem designierten Knoten vgl Abbildung 18 i wireless 2 em a ESB Abbildung 18 Die beteiligten Komponenten einer typischen ScatterWeb Anwendung Ding07 31 Mehr zur technischen Realisierung in 6 1 bei der Behandlung der Bibliothek ScatterWeb for Java 32 Zu diesem Zweck werden die entsprechenden Komponenten des WSN VerwaltungsPfades von ScatterClipse eingesetzt Mehr dazu in Kapitel 7 An dieser Stelle zeigt sich noch einmal die erg nzende Zusammenarbeit der verschiedenen Komponenten der ScatterClipse Werk zeugkette 34 Um einen Testfall f r das obige Szenario zu realisieren muss die Testinfrastruk tur in der Lage sein die von den Sensorknoten w hrend der Ausf hrung der zu tes tenden Anwendung bermittelten Daten zu analysieren um feststellen zu k nnen ob der Test fehlerfrei verlaufen ist oder nicht Dadurch lassen sich R ckschl sse auf die Korrektheit der Funktionalit t der Anwendung gewinnen Daher muss die Test infrastruktur die zu testende Anwendung m
207. inzelnen Schritte der Fallstudie n her zu untersuchen Dies zeigt Abbildung 81 welche veranschaulicht inwiefern die iterative Verfeinerung des Testfallmodells zur Hypothesenbildung einen Anstieg an Codezeilen mit sich bringt Dabei wird das Verh ltnis zwischen manuellem und generiertem Code angegeben Ferner zeigt die Abbildung wie sich dieser Codeanstieg auf die jeweiligen in der Fallstudie durchgef hrten Schritte verteilt Wie man sieht wird der Anteil an nicht automatisierbarem Code klein gehalten Der gesamte Codezuwachs ist zwar durchaus beachtlich jedoch wird der zus tzlich entstandene Code berwiegend automatisiert generiert Der manuelle Codeanteil ist vor allem auf die Realisierung der Programmlogik der im jeweils verfeinerten Modell definierten Log Aktionen und Pr froutinen zur ckzuf hren Bemerkenswert ist dass bei den Schritten zwei f nf und sechs vgl Abbildung 81 keinerlei manueller Code ben tigt wurde da bei allen drei Schritten das Modell derart verfeinert wurde dass lediglich Standarddienste von ScatterUnit in Anspruch genommen werden mussten welche vollst ndig automatisiert generiert werden k nnen Hingegen wurde insbesondere in Schritt drei verh ltnism ig viel manueller Code ben tigt da in diesem Schritt die Verfeinerung des Modells daraus bestand das bisherige Diagramm um neue recht gro e Log Aktionen und Pr froutinen zu erg nzen welche anwendungsspezifisch sind Dennoch bleibt der Anteil an nicht auto
208. ion des Testver laufs werden die Modelle verfeinert und anschlie end zur Automatisierung in den Codegenerator eingegeben Nach Beendigung jeder Iteration bzw Testfallausf h rung werden genauere Informationen zum Verhalten der Anwendung gesammelt und anschlie end in den verfeinerten Modellen visualisiert Demzufolge k nnen aussagenm chtigere Hypothesen vom Softwaretester hinsichtlich der Versagensur sache im Code der Anwendung getroffen werden Der zweigleisige Einsatz der Mo delle bestehend aus der Kombination der Visualisierung einerseits und dem Zweck der Automatisierung andererseits stellt die Innovation des Test Rahmenwerks dar An dieser Stelle stellt sich die Frage wie sich das eben Gesagte mit dem eingangs erw hnten Szenario der Navigation durch verschiedene R ume vereinbaren l sst Mit anderen Worten wie sieht der Ablauf eines m glichen Testszenarios beim Ein satz von Visual ScatterUnit aus Jedes Testszenario ist durch einen entsprechenden Testfall zu realisieren Somit geht der Realisierung des Testfalls stets der Entwurf eines Testszenarios voran das vom Testfall im Kontext der Testinfrastruktur bewerkstelligt werden soll Im Ent wurf des Testszenarios m ssen daher die Aktionen und Ereignisse zur Durchf h rung des Tests zum Ausdruck gebracht werden Des Weiteren muss durch das Test szenario vorgegeben werden auf welchem Sensorknoten und zu welchem Zeitpunkt eine Aktion w hrend des Tests ausgef hrt werden muss
209. ions werden oft als Steuerungselemente in ein Haupt Plugin eingebettet und dann vom Benutzer ab und an bet tigt Sie bieten unterst tzende Funktionali t ten die oft vom Benutzer nicht unbedingt l ngerfristig in Anspruch En Plug J Plug in Plug in a N UI Generic Workbench l Plug in N 7 N b 4 JFace Plug in Plug in XY J J f N gt SWT Pigi hs he N DE a N OSGi Plattform Eclipse Runtime Ne ff Abbildung 3 Die Eclipse Plattform als OSGi Server Hent06 10 Die aktuelle geschtitzte Bezeichnung lautet OSGi Alliance 10 genommen werden Daher wurden beispielsweise in ScatterPlug vgl Kapitel 6 be stimmte Funktionalit ten wie der Verbindungsaufbau und abbruch zum Sensor netz sowie das Scannen des Netzes zur Pr fung der platzierten Sensoren als Actions realisiert Views sind Fenster die spezifische Funktionen zur Verf gung stellen Der Benut zer kann diese je nach Bedarf aktivieren und individuell in der Umgebung platzie ren Damit bietet das Konzept der Views in Eclipse ein bemerkenswertes Merkmal um eine optimale ergonomische Interaktion mit dem Benutzer zur erzielen Von die sem Konzept haben wir insbesondere im Entwurf des Verwaltungs und berwa chungspfads der Sensorknoten ausgiebig Gebrauch gemacht Hier wurden verschie dene mit dem Benutzer interagierende und illustrative Funktionalit ten als Views realisiert wie die Visualisierung die Stati
210. ionsdateien wie Make Dateien und XML Dateien f r das Ant Build um die anschlie ende Kompi lierung und Ausbringung Deployment der Software auf die Sensorknoten zu be werkstelligen Im Codegenerierungsprozess werden zwei f r die Optimierung der Codegr e ent scheidende Techniken verfolgt Die erste ist die Verwendung von Dummy Templates Dabei werden bei der Generierung der im Modell nicht vorkommenden und somit nicht ben tigten Firmwaremodule Dummy Templates eingebunden Ein Dummy Template beinhaltet lediglich die Signaturen der Prozeduren dieses Firm waremoduls wobei der Rumpf jeder Prozedur leer bleibt daher die Bezeichnung Dummy Somit wird gew hrleistet dass am Ende des Generierungsprozesses ein 55 Mehr zu den Aktivit ten der Deployment Phase im folgenden Abschnitt ber das Ent wicklungs Plugin 78 38 tutorial 8 amp src a metamodel w projectresources w templates w templates ESB S templates ESB Applications EMPTY w templates ESB Applications LED templates ESB Applications YellowSwitcher 8 templates ESB Dummy D model scatterweb A model scatterweb_diagram E A JRE System Librar New 4 a m Plug in Dependen Open F3 amp META INF Open with R amp src gen im build properties 2 copy Ctrl C 5 Paste Ctri W Delete Delete Build Path E Refactor Alt Shift T s Import r Export amp Refresh FS adoc Declaration Console amp Properties 33 Debug As 2 Ru
211. ipse basierten ScatterPlug Rahmenwerk einerseits und dem mittels des Rahmenwerks errichteten WSN andererseits ist unerl sslich um von den Diensten des Rahmenwerks nach der Inbetriebnahme des WSNs problemlos Gebrauch machen zu k nnen Die Herausforderung vor allem in Hinsicht auf den erforderlichen Datenaustausch liegt darin dass die auf den Sensorknoten laufende Software vollst ndig in C implementiert ist w hrend die Sprache des Eclipse basierten Rahmenwerks Java ist Hierf r wird die in 3 1 besprochene COM PORT Bibliothek von Sun verwendet auf der die Realisierung der Kommunikationsbr cke fu t Dabei wird die serielle Hardwareschnittstelle zur Kommunikation zwischen dem eGate und dem Rahmenwerk als Java Objekt dargestellt dessen Funktionalit t mittels entsprechender Methodenaufrufe der Bibliotheks API gem dem objektorientierten Paradigma in Anspruch genommen werden kann Da die Kommunikationsschnittstelle zum WSN der objektorientierten Methode folgt liegt es nahe das mittels des Rahmenwerks errichtete WSN in der Form korrespondierender Objekte zu emulieren um von den Vorteilen der objektorientierten Methode sowie den diversen zur Verf gung stehenden objektorientierten Technologien wie Logging der Nachrichten etc Gebrauch machen zu k nnen Demzufolge wird in der Darstellung des errichteten WSNs ein h heres Abstraktionsniveau erreicht wodurch die Handhabung sowie Erfassung der Knoten und ihrer Abl ufe im Betrieb deutlich
212. ird nun ber das Auftre ten des Fehlers berichten indem die betroffene Aktion indiziert wird F r den Ab bruch der Ausf hrung wird kein manuell geschriebener Code ben tigt lediglich ein einziger Systemaufruf der diesen veranlasst Fehler deren Vorkommen auf diesem Weg berichtet wird reduzieren die Implementierungszeit f r die Fehlerbenachrich tigung weil auf sie prompt mit Abbruch reagiert wird Alles in allem werden die folgenden Testresultate analysiert Fehler aus benut zerdefinierten Log Aktionen die durch deren korrespondierende Pr froutinen ber pr ft werden Fehler die durch den Abbruch der Ausf hrung des Testfalls verur sacht werden und die Daten die durch die Protokollierung des Testverlaufs als Ak tionen geloggt werden Um diese Resultate auf einfache Art hinsichtlich des Anwen dungsverhaltens auslesen bzw interpretieren zu k nnen flie en sie in das Dia grammmodell des Testfalls ein Abbildung 24 zeigt die Visualisierung der Fehler meldung die durch die Pr froutine CheckPacketIntegrity aus Abbildung 23 verursacht wurde Der Fehler wird durch das entsprechende Blitz Icon im Dia gramm angezeigt Der Tooltip des Icons blendet dann die folgende Meldung ein The payload of the data Paket was corrupted Au erdem gelangt man durch das i Icon der Aktion LogRadioPacket im Diagramm zu den Daten des betroffenen Pa kets 44 PR LogRadioPacket Radio Packet Log Action Log Label SecondRadioPacket Detail A
213. it Mechanismen erweitern die im All gemeinen den Testfall in die Lage versetzen die w hrend der Anwendungsausf h rung ablaufenden Aktionen bzw auftretenden Ereignisse zu protokollieren um auf dieser Basis das Verhalten der Anwendung nachvollziehen zu k nnen F r die Integration solcher Mechanismen in die Laufzeitumgebung der Sensor knoten m ssen die entsprechenden Ressourcen vor allem Rechenzeit auf Sensorar chitekturebene in Anspruch genommen werden Dies darf jedoch das initiale Verhal ten der zu testenden Anwendung in keiner Weise beeintr chtigen bzw manipulie ren Unerw nschte Folgen dieses Eingriffs m ssen daher in Betracht gezogen wer den Cunh01 Dies ist eine essentielle Entwurfsanforderung da es sogar dazu kommen kann dass durch einen solchen Effekt die Ausf hrung der Anwendung fehlschl gt Dies ist insbesondere der Fall wenn die Anwendung zeitkritisch z B bei sehr ge ringer Reaktionszeit auf auftretende Ereignisse ausgef hrt werden muss Des Wei teren soll keine Beeintr chtigung verursacht werden wenn ein Dienst getestet wird der auf verschiedenen Sensorknoten gleichzeitig l uft Dies ist z B der Fall wenn es sich beim Testobjekt um ein Routingprotokoll handelt was ein typisches und weit verbreitetes Szenario im Kontext drahtloser Sensornetze ist Folglich wird ein dezentralisierter Steuerungsmechanismus zur Ausf hrung des Testverlaufs in der Testschicht ScatterUnit verfolgt Ulri99 um diesen Anforde
214. itektur MDA WebMDA entwickelt Abbil dung 1 veranschaulicht die Abl ufe des MDA Prozesses sowie die zwischen ihnen bestehenden Abh ngigkeiten Das Platform Independent Model PIM stellt die fachliche Spezifikation der darun terliegenden abzudeckenden Plattformen dar Das Ziel ist dabei eine universelle formale Modellierungssprache zur Verf gung zu stellen die eine umfassende Abs traktion bewirkt und zwar von m glichst allen Schl sselkonzepten der unterschied lichen zu modellierenden Plattformen Daher werden solche PIMs in einem ersten Transformationsschritt zu einem an die jeweilige Plattform angepassten Modell Platform Specific Model PSM transformiert woraus in einem weiteren Schritt die dieser Dom ne korrespondierenden Codeartefakte generiert werden Demzufolge wird dieser Vorgang als Model to Model to Code Transformation bezeichnet Wie bereits erw hnt wird f r die Realisierung der generativen Infrastruktur ScatterFactory und Visual ScatterUnit in ScatterClipse die architekturzentrierte Methode verfolgt die eine Instanz bzw Auspr gung des modellgetriebenen Para digmas darstellt W hrend die Zielvorgabe der OMG bez glich der MDA die Steige rung der Portabilit t und Interoperabilit t der Software durch eine einheitliche und umfassende Modellierungstechnik ist liegt der Fokus des modellgetriebenen archi tekturzentrierten Ansatzes in der Erh hung der Effizienz und Robustheit des Soft wareentwicklungsprozesses durch
215. iter sichtbar Die brigen Reiter werden erst angezeigt wenn die Verbindung mit einem Port erfolgreich war und nachdem das WSN gescannt wurde Dies tr gt zur bersichtlichkeit bei und erleichtert die Interaktion mit dem Benutzer Nach einer erfolgreichen Verbindung zum WSN werden die Reiter der Dienste ScatterUnits angezeigt 1 vgl unterer Bildschirmabzug in Abbildung 61 ber die dem Benutzer der Zugriff auf die entsprechenden Funktionalit ten erm glicht wird Somit wird der Benutzer erst nach der erfolgreichen Verbindung zum WSN in die Lage versetzt die Reiter zu bet tigen Dies gew hrleistet dass nur die im WSN erreichbaren bzw aktiven Sensorknoten angesprochen werden k nnen wodurch unn tiger Datenaustausch vermieden wird Im Folgenden werden die Funktionalit ten der einzelnen Reiter erl utert 7 2 2 Visualisierung durch den Property Reiter Nachdem die Verbindung zum WSN erfolgreich aufgebaut wurde wird der Benutzer mittels des Property Reiters in die Lage versetzt die Eigenschaften der im WSN aktiven Sensorknoten sowie die des eGates fortlaufend zu beobachten Hierzu erm glicht die Property Funktionalit t die grafische Darstellung des Sensorstatus sowie der durch den Sensorknoten von seiner Umgebung erfassten Daten Dabei wird jegliches Attribut bzw Feld der Sensormaske on the fly illustriert w hrend durch eine transparente Benutzerinteraktion die Sensormaske beliebig konfiguriert werden kann Abh ngig von den Sens
216. ivierung der gew nschten Funktionalit ten beruht auf der Verwendung der Makefiles Technik Die zu diesem Zweck bereitge stellten ebenfalls automatisiert generierten Makefiles sind in der Lage durch die Definition entsprechender Aktionen die relevanten Funktionalit ten der mspgec Software aufzurufen Um nun den Kompilierungsprozess sowie das serielle Flashing innerhalb von Eclipse zu veranlassen wird das XML basierte Ant Plugin eingesetzt Demzufolge besteht die Herausforderung bei der Integration des Ant Plugins in der F higkeit auf die Aktionen der Makefiles zuzugreifen und diese aufzurufen wo durch die mspec Software innerhalb des Eclipse Rahmenwerks gesteuert werden kann 5 6 ScatterFactory2 Wie bereits geschildert ist ScatterFactory f r die erste Generation der ScatterWeb WSN Plattform entwickelt worden und somit auf die ESBs Embedded Sensor Boards optimiert Damit die Vorteile von ScatterFactory f r die zweite Sensorkno tengeneration MSBs58 von ScatterWeb erhalten bleiben wurde ScatterFactory2 Kame08 angelehnt an ScatterFactory entworfen und den Anforderungen der MSBs angepasst 5 Die MSBs unterscheiden sich vom eher monolithischen Vorl ufer ESB im Wesentlichen durch ihren modularen Entwurf und zwar sowohl softwareseitig als auch hardwareseitig So verf gt die Softwarearchitektur der MSBs ber einen modularen Aufbau der Firmware bestehend aus diversen Bibliotheken und Trei 58 Die Modular Sensor Boards MSBs
217. ivit tsdiagramms zur Modellierung eines Testverlaufs mit einer Meldung der Live Validierung im grafischen Editor sowie die entsprechende detaillierte Mel dung in der Eclipse Problem View im unteren Bereich des Editors 32 eae Java Test Case Models DSDV ChangedTopology testcase_diagram Eclipse SDK oa Jes 0 887 xaje i E Qr T Java J J J J Tahoma HO rI Qi Bir od Bee 140 18 Package Explorer 5 z Off ChangedTopology testcase_diagram 5 T Fee j Palette sb Y Test Case Models IR Select v DSDV gt Zoom ChangedTopology testcase Note x 4l ChangedTopology testcase_ Control Path endFirstPacket aN AwaitFirstPacke gy Bs un B a LEF Cune Mada 1 4 The name must only contain alphabetic and numeric letters hange Topology lt i gt E Problems X lerror 2 warnings 0 infos Description 4 Resource Path Location v tz Errors 1 item The name must only contain alphabetic and numeric letters ChangedTopology testcase_di Test Case Models DSDV lt TestCaseDiagram gt AAwaitFirstPacket y t Warnings 2 items amp The control path has no successor ChangedTopology testcase_di Test Case Models DSDV lt TestCaseDiagram gt SendFirstPacket amp The control path has no successor ChangedTopology testcase_di Test Case Models DSDV lt TestCaseDiagram gt Se
218. kt dass Log Pakete nur in dem Fall ben tigt werden dass Log Marken im Modell zur Verfeinerung der aufgestellten Hypothesen angegeben werden m ssen Von gro er Bedeutung ist es allerdings den bei der Protokollierung aber auch im Allgemeinen verursachten Verbrauch im knappen Speicherplatz der Sensorknoten zu untersuchen was im Folgenden geschieht Die Beanspruchung des Speichers ist gerade im Kontext der ressourcenschwachen drahtlosen Sensorknoten ein essentieller Aspekt F r die Integration und Durchf hrung der Testautomatisierung innerhalb der Laufzeitumgebung vgl Abbildung 70 des Sensorknotens werden alle drei Speicherarten in Anspruch genommen n mlich ROM RAM und EEPROM Daher befasst sich die folgende Untersuchung mit dem Verbrauch 116 aller dieser drei Speicherarten Die drei Speicher werden von Komponenten der erweiterten Laufzeitumgebung verwendet die Firmware die zu testende Anwendung der Testfallcode und die Testautomatisierungsschicht bzw die libScatterUnit Bibliothek Tabelle 4 veranschaulicht den Speicherverbrauch der ROM und RAM Speicher von unterschiedlich relevanten Codeartefakten die in der erweiterten Laufzeitumgebung zur Bewerkstelligung der Testautomatisierung in Frage kommen Anwendung Testfall Testobjekt code ScatterWeb Testing Layer ScatterWeb Firmware Abbildung 70 Erweiterte Laufzeitumgebung des Sensorknotens zur Testautomatisierung Kame07 Softwaremodul R
219. l abstrakte Syntax des Modells definiert auf dessen Basis das eingegebene formale Modell gebildet wurde Daher muss das Metamodell ebenfalls als Java Repr sentation vorliegen um vom oAW Rahmenwerk zwecks Validierung des eingegebenen formalen Modells bearbeitbar und interpretierbar zu sein Welches Metamodell das Rahmenwerk dabei verwendet ist vom Benutzer frei konfigurierbar Hierzu unterst tzt oAW standardm ig Ecore konforme Metamodel le sowie das Metamodell f r UML 2 Da leider das XMI der verschiedenen UML Werkzeuge noch nicht einheitlich ist stellt oAW eine Reihe von entsprechenden Adapterklassen f r die jeweiligen Werkzeuge zur Verf gung Efft08 Dadurch wird eine breite Palette von UML Werkzeugen unterst tzt Um nun aus dem eingegebe nen Metamodell die quivalente Java Repr sentation zu erzeugen stellt oAW einen 16 Da m glicherweise andere Austauschformate existieren werden von oAW daf r zust ndi ge benutzerdefinierte XML basierte Mapping Dateien zur Verf gung gestellt 17 speziellen Generator zur Verf gung Handelt es sich dabei wie es oft der Fall ist um ein Ecore Metamodell so ist keine Metamodelltransformation mittels des Gene rators in das quivalente Java Objektgeflecht vonn ten da auf die bereits in EMF generierte Java Repr sentation des Metamodells zugegriffen werden kann Hier sieht man ein weiteres Beispiel f r die enge und sich erg nzende Zusammenarbeit der verwendeten Rahmenwerke in
220. lastung eine wesentliche Rolle Im Fall von ScatterUnit berschreitet die maximale Gr e eines Log Eintrages in der Regel kaum 40 Bytes wie man im letzten Programmauszug 12 sehen kann So wurde beispielsweise das 48 Das zugeh rige Modellkonstrukt n mlich das Pr froutine Log Aktion Paar das durch die Markierung Nutzlast gekoppelt wird wurde in Abbildung 24 in Abschnitt 3 5 dieses Kapitels bereits gezeigt 49 blicherweise wird der EEPROM von der auf dem Sensorknoten laufenden Anwendung Testobjekt zur Beobachtung der Sensorumgebung ber einen langen Zeitraum berwiegend zum Zweck der Speicherung der von der Umgebung erfassten Messdaten in Anspruch ge nommen Dies ist allerdings bei der Testfalldurchf hrung dieser Anwendungen nicht gege ben da die Testf lle lediglich f r wenige Sekunden ausgef hrt werden m ssen 68 DSR Routingprotokoll Davi01 S 139 172 f r genau eine Minute als Testobjekt ausgef hrt und w hrenddessen s mtliche w hrend der Ausf hrungszeit bei jedem Sensorknoten eingehenden Pakete durch den entsprechenden Dienst von ScatterU nit vollst ndig protokolliert 5 Nach der Beendigung der Ausf hrung des Testfalls betrug der beanspruchte Speicheranteil des Log Protokolls nahezu 4 Kilobytes Eine solche Gr enordnung stellt keine Einschr nkung f r die Testdurchf hrung dar Dies belegen ebenfalls die gemessenen Daten zur Untersuchung der Speicherauslas tung in 8 2 zur Evaluierung des Rahmenwerks 4
221. lgetriebenes Rahmenwerk das mit denselben Werkzeugen und Technolo gien wie Visual Scatter Unit realisiert wurde Dies erm glicht auch ihre problemlose Zusammenarbeit die sp ter behandelt wird Mit Hilfe von ScatterFactory werden Software Familien f r die auf den Embedded Sensor Boards ESBs laufenden An wendungen automatisiert erstellt Abbildung 40 zeigt die Architektur des Scatter Factory Rahmenwerks die veranschaulicht welche Werkzeuge und Technologien zur Realisierung eingesetzt wurden und wie diese zusammen arbeiten Ferner wer den auf der rechten Seite der Abbildung die in jeder Stufe des Entwicklungsprozes ses entstehenden bzw ben tigten Dateien aufgef hrt Im linken Balken werden zu jeder Prozessphase die involvierten Werkzeuge bzw Plugins angegeben Werkzeuge Modelle Dateien Eclipse EMOF Meta Metamodell iat Syntax fiir i Metamodelle nn ScatterWeb Metamodell ecore a EAA EE Transformationsvor Eclipse EMF i schrift genmodel i Eclipse GMF graphisches Modell gmfpraph i Toolmodell gmftool Modellmapping gmfmap 1s Pie dea reese G Generatormodell gmfgen h Eclipse GEF i Dom nen Modell ScatterWeb Constraints chk ScatterModeller i ScatterValidator liigi konkrete Syntax oAW GMF Adapter ie PSM o oAW Code Generierung Templates xpt i Xpand Xtend Expressions i Generator Helper ext Checks k Abstrakte Syntax Scatte
222. lichen Sensorknoten An dieser Stelle mangelt es an entsprechenden Werkzeugen was die Notwendigkeit von Visual ScatterUnit un terstreicht Insbesondere im Bereich drahtloser Sensornetze m ssen Routingprotokolle auf Topologie nderungen eingestellt sein um diese robust zu bew ltigen Ein einfaches und zugleich repr sentatives Testszenario f r ein solches Routingprotokoll ist der Aufbau eines kleinen multi hop Netzwerkes in dem anhand des Routingprotokolls die Datenpakete von einem Knoten an einen oder mehrere benachbarte Knoten wei tergereicht werden Wie zuvor dargestellt besteht die Hauptaufgabe des Testfalls im Versenden eines designierten Pakets auf Basis des zu testenden Routingproto kolls und die gleichzeitige Beobachtung ob das Paket den Zielknoten ordnungsge m erreicht oder nicht Bei der Ausf hrung des Testfalls kann ein Fehler auftau chen wenn das Routingprotokoll bei der Zustellung der Datenpakete versagt weil die Pakete unterwegs nicht korrekt weitergeleitet wurden Um nun nachvollziehen zu k nnen an welcher Stelle Softwaremodul bzw Funk tionalit t das Versagen aufgetreten ist muss der Testprozess in der Lage sein die Route des betreffenden Pakets zu rekonstruieren Dazu werden die Aktionen die zur Weiterleitung des Pakets von den benachbarten Knoten stattgefunden haben in der korrekten Reihenfolge ben tigt Man sieht dass sich das Testobjekt auf mehrere miteinander agierende Knoten erstreckt ScatterUnit verf
223. liegend diesen Prozess zu automatisieren Diese Aufgabe erledigt GMF und zwar modellgetrieben Dabei werden aus dem aus EMF importierten Me tamodell verschiedene Modelle automatisiert generiert die dann als Eingabe f r weitere Wizards und Werkzeuge fungieren Dabei ist jedes Modell f r die Realisie rung einer bestimmten Aufgabe zust ndig Somit findet eine Teilung von Belangen statt was die Steuerung der automatisierten Generierung des Editors strukturiert und ihre Komplexit t deutlich verringert Abbildung 7 veranschaulicht die verschiedenen generierten Modelle sowie deren Abh ngigkeiten und den Ablauf ihrer Zusammenarbeit bis hin zur Editorerzeugung Im Folgenden sind die verschiedenen Modelle sowie deren Zust ndigkeiten aufgelis tet Hent06 e Das Graphical Definition Model gmfgraph Hier wird festgelegt wie die einzelnen Elemente des Metamodells visuell im Editor durch ihre entspre chenden Figuren erscheinen Dieses Vorgehen wird vom Benutzer durch die entsprechenden Wizards bestimmt e Das Tooling Definition Model gmftool Die Vorgehensweise ist analog zum obigen Modell allerdings werden hier die einzelnen Elemente der Palette vgl Abbildung 6 rechts vom Editor bearbeitet Neben der Konfiguration der visuellen Erscheinung k nnen die Elemente der Palette gem dem Design der DSL zu einer Kategorie zusammengef gt werden Ein Beispiel ist die Er stellung der Kategorie der Modellinstanzen Connections und die Einordnung
224. llen erfordern um festzustellen ob ein Programm oder System korrekt funktioniert Testf lle werden oft als Testskripts bezeichnet insbesondere wenn sie codiert werden Codierte Testf lle werden blicherweise als Test Suite gesammelt WebTestfall UML Profiles Der Profile Mechanismus wurde mit dem Zweck definiert einen leichtgewichtigen Erweiterungsmechanismus f r den UML Standard zur Verf gung zu stellen In UML 1 1 wurden Stereotype und tagged values Attribute als Erweiterungen verwendet die an die UML Modelle flexibel angebunden werden k nnen In nachfolgenden Verbesserungen von UML wurde das Konzept des Profils definiert um mehr Struktur und Pr zision f r die Definierung von Stereotypen und tagged values zu erreichen Die UML 2 0 Spezifikation hat die Technik der Profiles weitergetrieben indem diese als eine spezifische Metamodellierungstechnik definiert wurde WebProfiles Unified Modeling Language UML UML ist die meist verwendete Spezifikation der OMG OMG Struktur Verhalten und Architektur von Anwendungen lassen sich damit ebenso modellieren wie Gesch ftsprozesse und Datenstrukturen UML stellt die Grundlage f r die Modellgetriebene Architektur gt MDA dar UML hat sich als Standardtechnik f r Objektorientierte Programmierung durchgesetzt WebUML XML Metadata Interchange XMI XMI ist ein XML basiertes Austauschformat durch das sich Meta Modelle verschiedener Technologien serialisieren lassen XMI bi
225. llt einen Meilenstein f r die Konstrukti on von f r den MDSD Prozess tauglichen Werkzeugketten dar Abbildung 5 zeigt die Komponenten der generativen Ebene von EMF sowie deren Zusammenarbeit Das Generatormodell ist die Ausgabe der Transformation eines Wizards dessen Eingabe ein Ecore konformes Modell ist Zusammen mit den Java Emitter Templates fungiert das nun bearbeitbare Generatormodell als Eingabe f r die EMF Generatorkomponente Die Templates steuern die Codegenerierung und bieten die M glichkeit die Artefakte des Generatormodells mit Templates zu ver kn pfen Hent06 Plattform Independent Generator Model Model ecore Java Emitter Templates EMF model EMF editor EMF test Abbildung 5 Die generative Schicht von EMF Hent06 Das Resultat dieses Generierungsprozesses sind die f r die weiteren Schritte n ti gen Artefakte Das EMF model liefert eine programmierbare Javacodierung des ur spr nglichen Ecore Models F r die Erstellung des generativen aus dem Metamo dell gewonnen Editors sind EMF edit und EMF editor zust ndig An dieser Stelle ist anzumerken dass die Eclipse Community bestrebt ist sowohl den gerade erw hn ten generativen Editor als auch die Java Emitter Templates standardm ig durch andere umfangreichere Technologien bzw Werkzeuge zu ersetzen So werden die 13 Diese erfolgreiche Interoperabilit t wird durch die Werkzeugkette von ScatterClipse an schaulich illustriert 13 J
226. m eingebettet muss die Ordnung aller im Diagramm vorhandenen Aktionen entsprechend umgestaltet werden Dies leistet der entsprechende Code zur Koordination der erneuten Ausf hrung der Testskripte auf den Sensorknoten Da dieser Code mit Hilfe von Visual ScatterUnit automatisiert generiert wird muss der Softwaretester die technische Umsetzung der Modellverfeinerung nicht selbst bew ltigen Die erzielten Vorteile machen sich insbesondere bemerkbar wenn man die Herausforderung betrachtet suspekte Codesegmente bis zur Lokalisierung der Fehlerursache iterativ zu isolieren Bei der iterativen Verfeinerung des Modells f r die erneute Testdurchf hrung m sste der Benutzer jedes Mal den dazu n tigen Infrastrukturcode neu schreiben Da dies jedoch mit Hilfe des Codegenerators automatisiert vonstatten geht reduziert sich der Zeitaufwand f r den Implementierungsprozess des Testfalls signifikant Insgesamt wurde es mit Hilfe von Visual ScatterUnit m glich verschiedene f r die Implementierung des Testfalls essentielle Aktivit ten zu automatisieren und sie somit dem Benutzer zu ersparen Dies ist von gro em Nutzen da gerade solche Aktivit ten komplex und zeitaufw ndig sind Statt diese Aufgaben selbst und von Hand zu bew ltigen kann der Tester der WSN Anwendung seinen Fokus auf andere f r den Test entscheidende Belange legen Bei der Implementierung des Testfalls ist dies der Entwurf des Testszenarios und bei der Fehlerisolierung die ad quate Ve
227. m nun die Gewissheit zu erreichen dass tats chlich falsche Routinginformationen vorlagen wurde eine weitere Wartefunktion neben der ersten definiert Die zweite Wartefunktion bewirkt das Anhalten des Testverlaufs auf dem betroffenen Knoten 1 zu einem sp teren Zeitpunkt im Testverlauf Auch in diesem Fall wurden nach wie vor manchmal falsche Routinginformationen festgestellt Der Schritt war nicht unbedingt notwendig jedoch konnte damit mehr Gewissheit erzielt erden bevor im Testverlauf weiter verfahren wurde Schritt 6 ben tigte Zeit ca 90 Minuten Der aus den bisherigen Schritten resultierende Stand der Kenntnis ber die Routinginformationen ist dass obwohl die korrekten Routinginformationen ausgetauscht wurden trotzdem manchmal nicht bereinstimmende Eintr ge in der Routingtabelle vorliegen Die Ursache des Versagens muss daher in der Verbindung zwischen dem Informationsaustausch und der entsprechenden Aktualisierung der Routingtabellen gesucht werden Ausschlaggebend f r die Aufstellung dieser Hypothese ist der geschilderte Umstand dass die Routinginformationen zeitweise korrekt in der Tabelle vorliegen sich dann ihr Wert aber unerwartet zu einem falschen ndert was zum Versagen f hrt Dies ist ein deutlicher Hinweis darauf dass der korrekte Wert spontan falsch berschrieben wird Daher m sste die Routinginformation zus tzlich zu einem weiteren Zeitpunkt des voranschreitenden Routingvorgangs auf ihre Korrektheit gepr ft we
228. matisierbarem jedoch visuell modellierbarem Code nach mehrfacher Modellverfeinerung im modellgetriebenen Visual ScatterUnit insgesamt wesentlich geringer als der von Hand zu implementierende Code wenn der Test manuell und ohne jegliche visuelle Modellierung durchgef hrt wird 131 160 manuell erstellter Code E generierter Code 120 80 40 O N Y A Ss amp amp F I amp LW a3 of a3 a3 ay a3 of Abbildung 81 Anstieg des ben tigten Codes hinzugef gte Codezeilen zur Fehlersuche vor und nach der Fehlerlokalisierung und der mehrfachen Verfeinerung des Testfallmodells Kame08 8 3 2 Schlussbemerkung zur Fallstudie Wie die Fallstudie zeigt nimmt die Gr e des Testfalls w hrend der Fehlerlokalisierung signifikant zu Zeit und Aufwand die daf r ben tigt werden k nnen durch den hohen Anteil an generiertem Code eingespart werden Der gro e Anteil des generierten Codes der vor allem f r die Ausf hrung des Testfalls verwendet wird bedeutet einen weiteren Vorteil Er stellt sicher dass die Aktionen in der korrekten Reihenfolge ausgef hrt werden Im Testfallmodell kann diese Sequenz auf klare und verst ndliche Art und Weise modelliert werden wodurch Fehler in dieser Sequenz sehr viel weniger wahrscheinlich sind als in einer manuell modellierten Sequenz Folgende Aufgaben wurden abgesehen von der Erweiterung des Testfalls durchgef hrt um die Fehler zu lokalisieren Die Ausf hrung des Testfalls die wenig Z
229. mit verz gerter Kommunikation lediglich die essentiellen aus dem WSN ankommenden Daten selektiert und angezeigt und nicht jegliche aus einem Sensor auf Grund eines beliebigen Ereignisses erzeugte Nachricht Java Eclipse SDK Dear File Edit Navigate Search Project Run Window Help mil a0 O Qa 8 C6 8V ic E amp Java Problems Javadoc Declaration B REN ae tera ScatterServer Connection Property Terminal Alarm Log OTA Flashing 1 Type of Communication Communication via Terminal Priority Local eGate Er Local Terminal Super Node O Remote Terminal Information of WSN ID Connection Time 1 28 Jan 2007 00 25 48 3 28 Jan 2007 00 25 48 Status Connection successful Abbildung 61 Connection Reiter vor oben und nach unten dem Verbindungsaufbau Ding07 N tzliche Informationen bez glich der Sensorknoten wie die Sensor ID Typ des Sensorknotens Verbindungszeitpunkt etc werden in der Tabelle aufgelistet 5 Die Tabelle kann zu jedem Zeitpunkt vom Benutzer durch die Refresh Funktionalit t 7 aktualisiert werden durch die alle Sensoren des WSNs neu erfasst werden Neu dazu kommende Sensorknoten sowie nicht mehr existierende k nnen somit flexibel ermittelt 102 und dem Benutzter aufgelistet werden siehe 2 im unteren Bildschirmabzug der Abbildung 61 Der Status der Verbindung zum WSN wird mittels Status 6 angezeigt Beim Start des Plugins ist nur der Connection Re
230. mitgeteilt Um nun das instanziierte Modell f r die brigen Komponen ten von oAW w hrend des Generierungsprozesses handhabbarer zu machen wird es mit Hilfe von outputSlot durch eine Referenz namens model repr sentiert ber die dann auf das instanziierte Modell zugegriffen werden kann 3 Bevor die Codegenerierung auf Basis der definierten Templates angesto en wird muss die Modellintegrit t gew hrleistet sein Daf r m ssen die mit Checks spezifizierten Randbedingungen in Betracht gezogen werden Hierzu muss der Zielort der Datei in der die Checks Bedingungen enthalten sind angegeben werden Nun m ssen die Checks Bedingungen auf Basis der Mo dellkonstrukte validiert werden d h jedes Objekt im instanziierten Modell muss bez glich seiner Checks Bedingungen gepr ft werden Hier kommt die in Schritt 1 definierte Modell Referenz model zum Zuge Denn durch mo del eAllContents werden s mtliche Objekte des instanziierten Modells aufbe reitet und zur Verf gung gestellt 4 Nun kann der Code der einzelnen Objekte des instanziierten Modells aus den korrespondierenden Templates emitiert werden Zu diesem Zweck muss das Wurzeltemplate angegeben werden mit dem der Generierungsprozess star tet Hierzu dient das expand Attribut Um Add ons neben den Software Arte fakten zu generieren kann die GeneratorAdvice oAW Komponente aktiviert werden die zur Aufgabe hat gesonderte Templates z B modellunabh ngige Templates in die Modell zu Code
231. more J Kindberg Tim Distributed Systems Concepts and Design Addison Wesley Longman Amsterdam 2000 Cunh01 Cunha J C Loureno J Duarte V Debugging of parallel and distributed programs In Cunha J C Kacsuk P Winter S eds Parallel program development for cluster computing methodology tools and integrated environments Advances in Computation Theory and Practice Vol 5 pp 97 129 Nova Hauppauge 2001 Czar00 Czarnecki K Eisenecker U Generative Programming Methods Tools and Applications Addison Wesley Longman Amsterdam 2000 Daum06a Daum B Java Entwicklung mit Eclipse 3 2 Anwendungen Plugins und Rich Clients Dpunkt Verlag Heidelberg 2006 Daum06b Daum B Das Eclipse Codebuch 182 Tipps Tricks und L sungen fiir Eclipse spezifische Probleme Dpunkt Verlag Heidelberg 2006 Davi01 Johnson D B Maltz D A Broch J DSR The Dynamic Source Routing Protocol for Multi Hop Wireless Ad Hoc Networks In Perkins C E ed Ad Hoc Networking pp 139 172 Addison Wesley Longman Amsterdam 2001 Ding07 Ding J Entwicklung einer Eclipse Konsole fiir ScatterWeb Unpublizierte Diplomarbeit Betreuer Mohammad Al Saad Freie Universit t Berlin 2007 Efft06 Efftinge S Checks Validation Language 2006 http www eclipse org gmt oaw doc 4 1 r30_checkReference pdf Efft08 Efftinge S Friese P Haase A H bner D Kadura C Kolb B K hnlein J Moroff D
232. n Pr froutinen zugewiesenen Logmarkierungen Log labels in das Testfalldiagramm erm glicht die ma geschneiderte Generierung der Codesegmente der zugeh rigen Pr froutinen zur Filterung der korrespondierenden Eintr ge im textuellen Log Die ses wird durch local logging zur verteilten Protokollierung der Testfallausf hrung von ScatterUnit zusammengestellt Wie man sieht wird das Schreiben und bei sich wiederholender Verfeinerung des Modells nochmalige Schreiben des von ScatterUnit ben tigten Infrastrukturcodes vollst ndig an den Codegenerator delegiert und geht automatisiert vonstatten So wird der angestrebte Nutzen des modellgetriebenen architekturzentrierten Ansatzes beim Testen von Anwendungen drahtloser Sensor netze optimal erreicht 3 6 Zusammenfassung Um Anwendungen drahtloser Sensornetze ad quat testen zu k nnen sind entspre chende Dienste erforderlich die beispielsweise die n tige Koordination des verteil ten Testverlaufs sowie Simulationsfunktionalit ten bereitstellen Solche Dienste werden auf automatisierte Art von der Testautomatisierungsschicht ScatterUnit angeboten Die Dienste von ScatterUnit und deren Funktionsweise sowie die Erstel lung eines Testfalls mit Hilfe von ScatterUnit wurden zu Beginn des Kapitels an hand eines konkreten Anwendungsszenarios dem DSDV Routingprotokoll ausf hr lich geschildert und diskutiert Dennoch blieb die entsprechende Codierung eines Testfalls f r eine auf den verschiedenen Knoten
233. n Local C C Application Team I 3 OAW Workflow ji gt Compare Run imber 2006 01 17 28 Replace With Qu External Tools a runtime New_configural Properties Alt Enter t Tame start_generator oaw path Tutorial src start_generator oaw size 1303 bytes Abbildung 44 Gleichzeitiger Ablauf des Modellierungs und des Generierungsprozesses innerhalb von Eclipse Hent06 korrekt kompilierter Code steht wobei unn tiger Code gr tenteils vermieden wird 5 Um die Funktionalit t von Dummy Templates bei der Modellierung zu akti vieren muss die Anweisung USE_DUMMIES vgl Abbildung 43 bei der Sensorin stanz angegeben werden Die zweite Technik besteht im Einsatz von Filterregeln mit deren Hilfe w hrend der Codegenerierung gem der jeweiligen im Modell spezifizierten Filterregeln be stimmte Codeartefakte bei der Emittierung des betroffenen Templates herausgefil tert werden Dies sind insbesondere berfl ssige Codesegmente der im Quellcode der Firmwaremodule verstreut eingeflochtenen Macros und Konsolekommandos Es wird zwischen drei Arten von Filterregeln unterschieden wobei jede die Filterung spezifischer Codeartefakte bewirkt 56 In 8 1 wird die erzielte Effizienz des Einsatzes von Dummy Templates anhand der erspar ten Codegr e bez glich repr sentativer Anwendungsszenarien ausf hrlich diskutiert 79 amp src gen 3 amp ESB_TEST Application_EMPTY amp bin 3 out a3 sre ScatterWeb Event c
234. n SecondRadi oPacket im Testfallmodell die Logmarkierung LogRadioPacket an wobei diese Logmarkierung gleichzeitig auf die f r die berpr fung der Aktion SecondRadio Packet zust ndige Pr froutine CheckPacketIntegrity verweist Der Pr froutine stehen somit s mtliche Daten zur Verf gung so dass die technische Realisierung der gerade beschriebenen Abl ufe ebenfalls voll automatisiert durch den Codegene rator vonstatten gehen kann Obwohl der Code f r die Selektierung der Logeintr ge automatisiert generiert werden k nnte muss er dennoch der Anwendungslogik einer Pr froutine entspre chend manuell implementiert werden Der Grund hierf r liegt vor allem darin dass die Routine zur berpr fung eines Fehlers ebenfalls anwendungsspezifisch ist Es gibt jedoch einen typischen Fehler dessen Code automatisiert generiert werden kann Dieser Fehlertyp geht von der folgenden Annahme bez glich des Testfallmo dells aus Die modellierte Sequenz der Aktionen im Diagramm richtet sich danach ob der Testverlauf am Ende eine fehlerfreie Anwendungsausf hrung aufweist Wird die Ausf hrung unterbrochen so impliziert dies eindeutig dass ein Fehler w hrend der Anwendungsausf hrung aufgetreten ist Es w re beispielsweise m glich dass die Aktion SendSecondPacket die Ausf hrung des Testfalls abbricht um darauf hinzuweisen dass das Versenden des Pakets mittels des zu testenden Routingproto kolls fehlgeschlagen ist Eine dazu generierte Pr froutine w
235. n Steigerung der An zahl von Knoten die ein solches Netz bilden Dies erh ht die Komplexit t der Rand bedingungen unter denen die Sensorknoten betrieben werden was dazu f hrt dass die technischen Belange zur Entwicklung der auf den Sensorknoten laufenden Soft ware entsprechend vielschichtiger werden Ferner bedarf eine robuste Anwendungs entwicklung einer ad quaten Betriebsn he hinsichtlich der vielf ltigen von den Sensorknoten zu bew ltigenden Aufgaben Gegenw rtige Techniken zur Implementierung dieser Art von Systemen beruhen meist auf simulativen Einsatzszenarien Daher ist die Entwicklung solcher Simula tionswerkzeuge ein Bereich in dem entsprechend viel geforscht wird Dabei steht jedoch zumeist das Verhalten des Sensornetzes selbst im Mittelpunkt und weniger jene Entit t welche dieses Verhalten bewirkt n mlich die auf den Sensorknoten des Funknetzes laufende Software Statt sich auf Simulationsumgebungen zu be schr nken muss die Anwendungsentwicklung realit tsn her vonstatten gehen Geht man noch einen Schritt zur ck so muss zun chst gew hrleistet werden dass die Sensorsoftware bereits bei ihrer Implementierung leistungsf hig und robust er stellt und getestet werden kann und zwar auf den sich bereits im Betrieb befinden den Sensorknoten Hier mangelt es an entsprechenden L sungsans tzen und Werk zeugen was die Notwendigkeit der vorliegenden Arbeit unterstreicht deren Ergeb nis die modellgetriebene ScatterClips
236. n Testverlauf zu kontrollieren und dem Ablauf des Tests zu folgen um zu entscheiden ob eine Anwendung versagt hat oder nicht Um den besonderen Anforderungen der Dom ne drahtloser Sensornetze gerecht zu werden m ssen bestimmte Entwurfsentscheidungen auf der Architekturebene getroffen werden Man denke etwa an die schwachen Ressourcen oder den h heren Parallelit tsgrad der Anwendungen in einer solchen Dom ne Daher stellt Scatter Unit mehrere Dienste zur Verf gung die f r den Testzweck vielf ltiger WSN Anwendungen oft mehrfach in Anspruch genommen werden beispielsweise f r die Erfassung der gesammelten Sensordaten und deren Protokollierung oder die Ermitt lung der Topologie des Netzes um den Aspekt der Mobilit t zu unterst tzen Dar ber hinaus werden vielf ltige Dienste unterst tzt die in 4 4 ausf hrlicher behan delt werden Wichtig ist an dieser Stelle dass durch die von ScatterUnit angebote nen Dienste der extensive Test der auf den Sensorknoten laufenden Anwendungen unbeeintr chtigt bleibt Obwohl ScatterUnit die angestrebte Automatisierung erm glicht bleibt die Imp lementierung eines Testfalls eine f r den Anwender zeitaufwendige und komplexe 28 T tigkeit Dies liegt vor allem an der vorhin erw hnten Eigenschaft der WSN Dom ne n mlich dem h heren Verteilungsgrad der Anwendungen Denn nur in diesem Kontext k nnen Testf lle f r die auf den Sensorknoten laufenden Anwen dungen erstellt werden Hierf r m
237. n average the network topology changed every 4 seconds Malt00 Die Experimente wurden mehrfach wiederholt wobei jedes Experiment zwischen 30 und 120 Minuten dauerte Ein solches Szenario bietet zwar vorz gliche realit tsnahe Testbedingungen f r das zu testende Protokoll insbesondere hinsichtlich der Mobilit t der Sensorknoten im Netz die eine besondere Herausforderung an solche Routing Protokolle darstellt jedoch scheitert ein solcher Ansatz schnell an der Anforderung der Skalierbarkeit Mit anderen Worten ein solcher Ansatz st t an seine Grenze wenn es um die Frage geht wie ein Protokoll f r ein Netz mit einer gro en Anzahl von agierenden Sensorknoten zu testen ist Hier sind simulative Eingriffe zur automatisierten Testdurchf hrung unerl sslich Die Integration simulativer Funktionalit ten tr gt zu einer deutlichen Erh hung des Automatisierungsgrads vom real auf den Sensorknoten auszuf hrenden Testfall bei Daher pr gt dieser hybride Ansatz den Entwurf von ScatterUnit der Testautomatisierungsschicht der Werkzeugkette Dies sieht man z B im Einsatz des Simulationsdienstes in ScatterUnit zur dynamischen Konfiguration der Netztopologie w hrend der Testdurchf hrung Ein Testwerkzeug das ebenfalls diesen Ansatz verfolgt ist SeNeTs Blum04 welches an der Universit t Rostock entwickelt wurde Eine Basisstation sendet f r die Steuerung des Testverlaufs entsprechende Kontrollbefehle zu den Knoten im Netzwerk z B um
238. n und zwar jeweils mit und ohne die Verwendung von Filterregeln vgl Kapitel 5 4 Szenario Ohne NO_SERIAL MIN_COOMANDS MIN_COMMANDS Filter EMPTY 34050 32222 32215 31990 YellowSwitcher 24980 24230 24226 23950 LED 19846 19048 18944 18944 Tabelle 2 Gr e des generierten Codes nach dem Kompilierungsprozess mit und ohne Filterregeln Hent06 Wie der Tabelle zu entnehmen ist kommt es bereits ohne die Aktivierung der Filterregeln zu einer erheblichen Ersparnis an generiertem Code So ist der f r die Yelow_Switcher Anwendung generierte Code ohne die Benutzung von Filterregeln um ca 27 niedriger als die Referenz n mlich die Empty Anwendung ohne Filterregeln Mit anderen Worten wird f r eine typische Anwendung eines Knotens die daraus besteht auf Ereignisse im WSN zu reagieren sowie empfangene Pakete zu verarbeiten alleine durch die entsprechende strukturierte Repr sentation im formalen Modell ein beachtlicher Codeanteil eingespart Dasselbe gilt f r die zweite repr sentative Anwendung die LED Anwendung bei der der Knoten die Rolle eines Akteurs im WSN einnimmt Hier wird sogar eine Codeersparnis von ca 42 erreicht Werden nun zus tzlich die Filterregeln aktiviert so steigert sich die Codeersparnis bei der Yellow_Switcher Anwendung auf 30 und bei der LED Anwendung auf ca 45 Was die Beurteilung der Produktivit t von ScatterFactory2 anbelangt so l sst sich sagen dass dank des modularen Hardwaree
239. nd Um einen koordinierten Ablauf der verschiedenen Schritte zu gew hrleisten bie tet oAW eine robuste und bersichtliche L sung die den Benutzer in die Lage ver setzt auf einfache Weise seine individuelle Konfiguration des Generierungsprozes ses zu bestimmen Hierzu liefert oAW standardm ig eine XML basierte Workflow Engine Dabei kann der Benutzer mit Hilfe von diversen Wizards eine zentrale XML Datei erstellen mit der die Reihenfolge der Arbeitsschritte des Generierungs prozesses sowie die daran beteiligten Werkzeuge festgelegt werden Nun kann der Generierungsprozess vom Benutzer kontrolliert angesto en werden indem die Workflow Engine die Datei sequenziell abarbeitet In Abbildung 12 wird ein Bei spiel einer solchen Workflow Datei gezeigt Hent06 21 lt work low gt lt property name model ile value model scatterweb gt lt property name sre gen value sre gen gt lt component class org openarchitectureware emf XmiReader gt D lt metallodelPackage value scatterweb impl ScatterwehPackagelmpl gt lt modelFile value modelfile gt lt outputSlot value model gt lt component gt lt component class org openarchitectureware check CheckComponent gt lt metallodel class org openarchitectureware type emf Em Netallodel gt lt metallodelPackage value scatterveb impl ScatterwebPackagelmpl gt lt metallodel gt lt checkFile value model scatterweb constraints
240. ndSecondPacket 4 Im Abbildung 17 Modellierung des Testverlaufs mit Hilfe von Aktivit tsdiagrammen Kame08 Nach der Modellvalidierung kann nun der Codegenerierungsprozess angesto en werden Allerdings bleibt der generierte Code des Testfalls immer noch unvollst n dig da bestimmte anwendungsspezifische Codesegmente berwiegend manuell vom Entwickler implementiert werden m ssen Da bestimmte Codeartefakte direkt auf den Sensorknoten ausgef hrt werden sind diese in der Programmiersprache C zu implementieren Anders verh lt es sich was Visual ScatterUnit anbelangt Weil das Rahmenwerk Eclipse basiert ist erfolgt seine Implementierung voll st ndig in der Programmiersprache Java Um nun den Datenaustausch zwischen den C basierten ScatterWeb Sensorknoten und der Java basierten Visual Scatter Unit zu erm glichen wird die f r eingebettete Systeme entwickelte COM PORT WebJavaCom Bibliothek verwendet Dadurch wird die USB Schnittstelle des Rechners auf dem das Rahmenwerk l uft und an dem somit die Sinke z B eGate 30 The Java Communications 3 0 API is a Java extension that facilitates developing plat form independent communications applications for technologies such as Smart Cards em bedded systems and point of sale devices financial services devices fax modems display terminals and robotic equipment The Java Communications API also known as javax comm provides applications access to
241. nden hat Nichts desto trotz soll hier auf dessen Konzept im Vergleich zu ScatterClipse eingegangen werden Die Schl sselidee liegt in einer Dom nensprache f r drahtlose Sensornetze die nicht nur auf der Basis von Metamodellen eingesetzt wird sondern auch die Technik der Metaprogrammierung verwendet Bei Metaprogrammiersprachen handelt es sich im Allgemeinen um Sprachen die das Verhalten fremder Programme welche in der Regel in anderen Programmierparadigmen geschrieben sind steuern und manipulieren k nnen Dies ist m glich weil Metaprogramme in der Lage sind die zu steuernden Fremdprogramme auch Fremdobjekte genannt als eigene Datenstrukturen zu handhaben WebMetaprogrammierung Die Autoren begr nden ihren Ansatz der Verwendung von Metaprogrammierung neben Metamodellen indem sie anmerken dass letzteren eine Beschreibung der operationalen Semantik hinsichtlich des Verhaltens der zu modellierenden Dom ne fehlt Metamodels miss inherent operational semantics They only contain a description of the language s abstract syntax i e which language concepts are available and how they can be combined They miss a description of the language s operational semantics i e how the language concepts should behave when executed We can conclude that metamodels make the language prototyping cycle as we expect it for WSNs expensive because they miss inherent operational semantics Dieser Argumentation steht bei ScatterClipse entgegen dass
242. ndere auf der Ebene der Metamodellierung und der grafischen Editoren der Dom nensprachen Ferner findet eine Validierung der formalen Modelle statt bevor die Codegenerierung angesto en wird Dies ist dem Constraint Manager zu verdanken mit dessen Hilfe OCL basierte Randbedingungen vom Benutzer definiert werden k nnen Es fehlt jedoch eine Integration m chtiger Codegeneratoren was dazu f hrt dass der Codegenerierungsprozess eingeschr nkt bleibt Ferner ist eine Integration in die Standardentwicklungsumgebung nicht ausreichend vorhanden Aus diesem Grund musste f r GRATIS ein gesondertes Eclipse Plugin entwickelt werden um von den Merkmalen der Eclipse Plattform Gebrauch machen zu k nnen Zwar schneidet GRATIS bei der Studie wie Tabelle 6 zeigt nicht gut ab dennoch ist GRATIS eins der ersten 13 Jedenfalls nicht bis zum Zeitpunkt der Implementierung von ScatterClipse 14 Das entwickelte Eclipse Plugin fungiert laut den Entwicklern u a als Br cke zu der davor besprochenen Eclipse basierten TinyDT Umgebung die ebenfalls an der Vanderbilt Universit t entwickelt wurde Insofern sollten in der unteren Bewertungstabelle der Studie die Merkmale beider Rahmenwerkzeuge eher gemeinsam in Betracht gezogen werden Denn durch die Eclipse 135 generativen modellgetriebenen Werkzeuge zur automatisierten Anwendungsentwicklung f r drahtlose Sensorknoten Mit Hilfe von GRATIS wird wie die Entwickler beschreiben lediglich Glue Code gener
243. ne incoming link this incoming size 1 context testcase ControlPath ERROR A control path must have at maximum one outgoing link this outgoing size lt 1 context testcase ControlPath ERROR A control path must have a name this name length gt 0 context testcase ControlPath ERROR The name of a control path must be unique this diagram controlPathes select e le this name contains this name false context testcase ControlPath ERROR The name must only contain alphabetic and numeric letters this name matches p Alpha p Digit context testcase ControlPath ERROR A control path and its branching points must be linked to distinct nodes this allOutgoing target size this allOutgoing target toSet size context testcase ControlPath WARNING The control path has no successor this allOutgoing size gt 0 context testcase TopologyChangeAction ERROR The id of the opposite node must be greater than zero this oppositeNode gt 0 context testcase TopologyChangeAction ERROR The id of the opposite node must be less than 255 this oppositeNode lt 255 context testcase TopologyChangeAction ERROR The id of the opposite node must be different from the local node id this oppositeNode this sensorNode deploymentld context testcase RadioPacketReceivedEvent ERROR A preceding await radio packet action must
244. nen automatisierten Erstellung der Testf lle wurde eine Fallstudie Kame08 durchgef hrt bei der eine Anwendung mit Hilfe von Visual ScatterUnit getestet wurde Bei der Anwendung handelt es sich um das DSDV Routingprotokoll vgl Kapitel 3 4 Wie im Folgenden gezeigt wird war es beim modellgetriebenen Test des Routingprotokolls m glich anhand der zahlreichen Funktionalit ten der Werkzeuge Fehler unterschiedlicher Art in der Implementierung des zu testenden Routingprotokolls ausfindig zu machen Des Weiteren wurde die Versagensursache f r jeden Fehler im Code lokalisiert und behoben indem das Testfallmodell hinsichtlich der ber die Versagensursache aufgestellten Hypothesen schrittweise verfeinert wurde bis die betroffene Stelle im Code lokalisiert werden konnte Die Version des in der Fallstudie getesteten Routingprotokolls wurde urspr nglich f r die ESB Knoten entwickelt Da aber das Testwerkzeug f r die zweite Knotengeneration MSB entwickelt wurde war es notwendig die vorliegende Implementierung auf die MSB Knoten zu portieren Allerdings ging die Portierung auf Grund vorhandener Inkonsistenzen bestimmter Komponenten der beiden Plattformen nicht fehlerfrei vonstatten was zur Folge hatte dass die auf die MSB Knoten angepasste Implementierung Fehler beinhaltete Ferner wurden weitere Fehler entdeckt die auf die initiale Implementierung zur ckzuf hren sind und bislang unentdeckt geblieben waren Insofern unterliegen die Durchf hrung
245. nerierten Softwareartefakte kompiliert um ein Code Image zu erzeugen Es ist daher nicht verwunderlich dass die f r die Konstruktion der Werkzeugket te verwendeten Rahmenwerke ausschlie lich Eclipse Projekte sind Dies erm glicht eine optimale Integration der Werkzeuge wodurch eine einwandfreie Zusammenar beit gem dem modellgetriebenen Paradigma erzielt wird Alle verwendeten Rah menwerke sind Opensource Projekte 2 2 Die Eclipse Plattform Was ist Eclipse Antwortet man auf diese Frage dass Eclipse lediglich eine Ent wicklungsumgebung f r Java ist so hat man sp testens nach der Entwicklung von Eclipse 3 0 eine falsche Antwort gegeben Es muss an dieser Stelle betont werden dass Eclipse trotz eines hohen Marktanteils f r die Entwicklung mit Java eine allgemeine umfassende und betriebssystemunabh ngige Plattform darstellt die nicht auf ein spezielles Gebiet beschr nkt ist alles m gliche und nichts im beson deren Daum06a Dass Eclipse nicht auf Java beschr nkt ist wird sich auch in dieser Arbeit deutlich zeigen da berwiegend C Code Makefiles und andere Temp lates bzw Spezifikationssprachen f r die Codegenerierung bzw Live Modellvalidierung unter Eclipse mit Hilfe von diversen speziellen Wizards und Plug ins bearbeitet bzw erstellt werden Eclipse bildet einen Kern an den f r unterschiedliche Zwecke und unabh ngig voneinander entwickelte Plugins angeschlossen und integriert werden Die
246. nes auf Basis von ScatterUnit erstellten Testfalls wesentlich effizienter Dies ist auf den Entwurf der Architektur von ScatterUnit zur ckzuf hren welcher zwei pr gnante Charakteristika aufweist Erstens l uft ein Teil des Testcodes direkt auf den Sensorknoten um die verteilte Testausf hrung zu koordinieren zweitens findet die Fehler berpr fung mittels der Pr froutinen erst nach Beendigung des Testdurchlaufs statt so dass die relevanten Aktionen bzw Ereignisse des Tests nicht w hrend der Testausf hrung sondern erst danach von den auf dem Rechner laufenden Pr froutinen analysiert werden Diese erw hnten Charakteristika sind unentbehrlich f r eine schonende Beanspruchung von Ressourcen im Sensornetz Damit wird eine Testdurchf hrung m glich welche die zu testende Anwendung u erst geringf gig ber hrt so dass das tats chliche Verhalten der Anwendung unbeeinflusst bleibt Andernfalls w rden die Testergebnisse das Verhalten der getesteten Anwendung unter realen Bedingungen nicht reflektieren Auf diese Weise k nnen pr zisere Hypothesen hinsichtlich der Fehlerursache getroffen werden Allerdings bleibt die eigentliche Codierung der Testskripte zur Koordination der verteilten Testdurchf hrung ein schwieriges Unterfangen Auf der Ebene von ScatterUnit ist die Implementierung dieses Codes eine komplexe und zeitaufw ndige Aktivit t Die Befehle des Testfalls m ssen von diversen Testskripten implementiert werden die dann verteilt auf
247. ng matches NO_SERIAL gt gt Packet_t packet Packet to String_parselnt amp str Null packet type PING_PACKET Programmauszug 14 Einsatz von Filterregeln bei der Codegenerierung Hent06 80 Die Korrespondenz zwischen der Modellierung einerseits und dem damit verbun denen Generierungsprozess auf der anderen Seite erfolgt bei der Anwendungsent wicklung in ScatterFactory reibungslos Dies zeigt das folgende Szenario das illust riert wie jede beliebige nderung des Modells von dem darauf folgenden Codegene rierungsprozess mittels entsprechender Anpassung der Templates ohne weiteres un terst tzt werden kann Im Programmauszug 15 wird anhand eines Xpand Templates veranschaulicht wie eine zur Standardkomponente des Firmwaremoduls Net alternative Implemen tierung derselben Komponente bei der Codegenerierung verwendet wird Bei der al ternativen Implementierung handelt es sich um die auf CSMA CA basierende Rea lisierung des Net Firmwaremoduls Auf Modellebene wird das Attribut Component Version der Komponenteninstanz siehe dazu Abbildung 41 des Metamodells auf CSMA CA vom Benutzer initialisiert was ber das Properties View von Eclipse be werkstelligt werden kann vgl Abbildung 42 Teil 3 Dadurch wird bekanntgegeben dass es sich bei der Komponente um die alternative CSMA CA Implementierung des Net Firmwaremoduls handelt Der obere Ausschnitt des f r das Net Firmwaremodul stehenden Templates Component xp
248. ng der Testergebnisse im zugeh rigen Modell 53 Ablaufstrang Diagramm Startknoten Steuerbefehl 7 ZweitesPaketErwarten Await Radio Packet Action Sending Node 1 Addressed Node 4 Packet Type 100 Timeout 1 000 Additional Checking false Processing Time AFTER Protokolleintrag ke NutzlastProtokollieren Radio Packet Log Action Log Label Nutzlast Detail DATA_LONLY NutzlastVerfaelscht Assertion Log Labels Nutzlast Abbildung 31 Der relevante Ausschnitt des Metamodells in UML Notation links der Entit ten des Detaillierungsdiagramms rechts Kame08 1 Steuerbefehle die bestimmte Aktionen des Testfalls bewirken Es handelt sich dabei um Aufrufe der zu testenden Anwendung zur Durchfiihrung des Testfalls wie z B das Versenden eines Pakets mittels der dazugeh rigen Me thode des Routingprotokolls Testobjekt bzw Aufrufe von Diensten der Testschicht ScatterUnit wie der Dienst zur Topologie nderung um den Sen debereich zu simulieren Dabei werden Pakete beim Empfang einfach gefil tert 41 Bei den gefilterten Paketen handelt es sich um diejenigen die aus den Sensorknoten stammen die au erhalb des Sendebereichs liegen sollen 54 2 Ereignisse die als Benachrichtigung auf die korrekte Ausf hrung eines er warteten Steuerbefehls bzw einer erwarteten Aktion fungieren wie z B der erfolgreiche Empfang eines erwarteten Paketes 3 Protokolleintr ge
249. ng und der Test der Sensorsoftware kostspielig seien trifft auf ScatterClipse nicht zu Denn mit Hilfe von Visual ScatterUnit und den Verwaltungsfunktionalit ten der Werkzeugkette k nnen Testf lle auf die jeweiligen Sensorknoten nahtlos ausgebracht und dort ausgef hrt werden Von Wada et al wird ein modellgetriebenes Rahmenwerk zur Entwicklung von WSN Anwendungen vorgestellt Wada07 Die Modellierung der Anwendungen fu t hnlich wie in Lenz07 auf der UML Profiles Technik Um die formalen UML Modelle validieren und ausf hren zu k nnen wurde speziell f r diesen Zweck eine virtuelle Maschine Matilda als wichtige Komponente des Rahmenwerkes entwickelt Die Modellierungssprache verwendet verschiedene Arten von UML Diagrammen Klassen Aktivit ts und Instanzdiagramme The proposed UML profile specifies the conventions to build UML models for event detection WSN applications and defines stereotypes and tagged values to precisely describe computationally complete input models In the 144 proposed UML profile an input model is defined as a set of UML 2 0 class diagrams sequence diagrams and an instance diagram Wada07 Auch hier gelten die beztiglich Lenz07 angesprochenen Nachteile der Modellierung mit UML Profiles insbesondere was die Komplexit t bzw Skalierbarkeit der Modellierungssprache betrifft So sieht die im Rahmenwerk vorgestellte Modellierungssprache vor alle im WSN vorkommenden Sensorknoten als eigenst ndige
250. ngstechniken zur ck zu f hren Die Integration modellgetriebener Elemente in den Testprozess wie sie in ScatterClipse vorhanden sind w re hier eine sehr interessante Herausforderung Ans tze in diese Richtung existieren bereits Zand05 Ferner w rde die Unterst tzung eines kognitiven Testprozesses bei dem die Testf lle iterativ auf Basis der Hypothesen der Tester verfeinert werden wie bei Visual ScatterUnit die Beherrschbarkeit sowie Pr zision der Erstellung der Testfallmodelle deutlich erh hen Ein kognitiver modellgetriebener Testprozess findet anscheinend bislang in TTC 3 keine Unterst tzung Alles in allem bietet die Modellierungssprache m chtige Eigenschaften zur Unterst tzung des Testprozesses jedoch stehen dabei Feldbussysteme und verteilte Infrastrukturen und nicht Ad hoc Netze als Testdom nen im Fokus Ein weiteres modellgetriebenes Werkzeug das auf einer Aktivit tsdiagramm hnlichen Modellierungssprache beruht wird von Ulbrich et al vorgestellt Ulbr05a Ulbr05b wobei die Autoren jedoch nicht erl utern warum eine eigene Notation in der Modellierungssprache verwendet wird Jedenfalls wird im Beitrag eine modellgetriebene visuelle Sprache nach dem MDA Ansatz f r Sensornetze vorgestellt Das Hauptziel der Sprache ist die Abstraktion von spezifischen Endger ten sowie die Verdeckung der Verteilung beim Einsatz dieser Ger te Dementsprechend besteht eine nach der Modellierungssprache repr sentierte Anwendung aus einer
251. nhand ihrer IDs 1 2 und 3 zugewiesen Dabei han delt es sich um diejenigen Sensorknoten die im modellierten Testfall TestCollecti onProcess vorkommen Somit k nnen mit Hilfe des obigen Modells s mtliche Code artefakte automatisiert generiert werden die f r die auf den drei Knoten laufenden Skripte des Testfalls ben tigt werden sowie f r die auf den Knoten laufenden An wendung mitsamt ihrer Treiber und Bibliotheken Gem dem obigen Modell wird die Anwendung DataSource f r die Knoten 1 und 2 generiert und die Anwendung DataSink f r den Sensorknoten 3 Hierbei fungieren NodeA und NodeB als Typen die eine bestimmte Konfiguration einer Anwendungslaufzeitumgebung repr sentie ren denen dann konkrete Sensorknoten zugewiesen werden f r die der Code der Laufzeitumgebung vollst ndig und automatisiert generiert wird Das Diagrammmo dell des Testfalls TestCollectionProcess f r die drei Sensorknoten k nnte beispiels weise mit Hilfe von Visual ScatterUnit wie in Abbildung 48 dargestellt modelliert werden vgl Abbildung 48 Werden die Skripte des obigen Testfalls f r die drei Sensorknoten aus dem Gesamtmodell vgl Abbildung 47 generiert so wird f r je den Sensorknoten das zugeh rige Makefile mit generiert um den Compiler entspre chend zu steuern Dadurch wird gew hrleistet dass die Testskripte eines Sensor knotens mit den Codeartefakten der Anwendungslaufzeitumgebung dieses Sensor knotens zu einem gemeinsamen Code Image durch d
252. nicht lokalisiert worden Nun muss die Verteilung der Eintr ge der Routingtabelle bzw ihre Aktua lit t angesichts der Topologie nderung berpr ft werden weshalb eine weitere Ver feinerung mit neu hinzugef gten Aktionen zum Einsatz kommt usw Dieses Beispiel zeigt wie durch das kognitive Vorgehen bei der Fehlerlokalisie rung mithilfe der iterativen Verfeinerung des Testfallmodells die Fehlerursache f r das Versagen der zu testenden Anwendung lokalisiert werden kann Die modellge triebene Visual ScatterUnit vereinfacht diese Vorgehensweise indem sie erm glicht die Testdiagramme zielgerichtet zu verfeinern um die vom Softwaretester aufge stellten Hypothesen hinsichtlich der Fehlerlokalisierung zu verifizieren Dabei liegt der gro e Nutzen des modellgetriebenen Paradigmas darin dass es m glich ist den in hohem Ma e iterativen Verfeinerungsprozess des Modells zu automatisieren Werden bei weiterer Verfeinerung neue Aktionen ins Testfalldiagramm eingebettet 48 muss die Ordnung aller im Diagramm vorhandenen Aktionen entsprechend um gestaltet werden Dies muss der entsprechende Code zur Koordination der Ausf h rung der Testskripte leisten Da dieser Code mit Hilfe von Visual ScatterUnit auto matisiert generiert wird muss der Softwaretester die technische Umsetzung der Modellverfeinerung nicht selbst bew ltigen Das gleiche trifft auf den zur Evaluie rung der Testresultate ben tigten Infrastrukturcode zu Die Integration der de
253. nik hinsichtlich neu auftretender Fragestellungen in der dynamischen Dom ne der drahtlosen Sensornetze Gleiches gilt f r die Modellvalidierung um die Robustheit des Entwicklungsprozesses zu steigern Benutzerdefinierte semantische Randbedingungen im Hinblick auf die Plattformeigenschaften werden im Rahmenwerk nicht unterst tzt Ferner bleibt die Codeerzeugung in ihrer Funktionalit t beschr nkt Daher sprechen die Autoren auch von einer Transformation der grafischen Diagramme in Codeartefakte Viptos allows developers to create block and arrow diagrams to construct TinyOS programs from any standard library of nesC TinyOS components The tool automatically transforms the diagram into a nesC program that can be compiled and downloaded from within the graphical environment onto any TinyOS supported target hardware Cheo05 Eine Weiterentwicklung des Viptos Rahmenwerks hinsichtlich der Unterstiitzung eines umfassenden Softwareentwicklungsprozesses der Anwendungen der Sensorknoten scheint zum jetzigen Zeitpunkt nicht in Sicht zu sein da auf der offiziellen Seite des Projektes Webviptos die letzte Versionsausgabe und somit Aktualisierung am 9 Februar 2007 vorgenommen wurde Tabelle 6 zeigt die vorgestellte Vergleichstabelle der Studie Teng08 in der auch die Ubersicht des Studienresultats vorgestellt wird Die tabellarische Gegeniiberstellung der betrachteten Werkzeuge findet auf Basis der eingangs geschilderten Anforderungen statt die die A
254. nmittelbar vor dem Versenden des Pakets ber die korrekten Routingeintr ge verf gt Wie das Diagramm in Abbildung 75 veranschaulicht bezieht sich die Pr froutine auf die Next Hop Informationen bez glich des Empf ngers Knoten 4 Daher wird auf die ankommenden Routinginformationen von Knoten 3 dem erwarteten Next Hop nach der Topologie nderung gewartet Bei einer mehrfachen Durchf hrung des erg nzten Testfalls wurde jedes Mal festgestellt dass die Ausf hrung des Testfalls nicht terminiert Das Voranschreiten des Testverlaufs wurde stets dort blockiert wo die Wartefunktionalit t eintritt Schlie lich wurde nach mehrfacher Begutachtung der betroffenen Stelle die zur Blockierung der Ausf hrung f hrte festgestellt dass Informationen vom Knoten 3 nicht an den Knoten 1 adressiert wurden Dies verursachte das endlose Warten auf die nicht ankommenden Pakete Dies f hrte unmittelbar zur Ursache n mlich dass die vorliegende Implementierung des Routingprotokolls zum Datenaustausch die Broadcast Addressierung verwendet Demzufolge wurde der Wert des Parameters Adressed Node des Wartevorgangs von 1 Empf nger Adresse auf die Broadcast Adresse 255 gesetzt Nun terminierte die Ausf hrung des Testfalls nach erneuter Durchf hrung und mittels der Pr froutine wurde festgestellt dass der sendende Knoten 1 die korrekten Next Hop Informationen erhalten hatte Ferner wurde beobachtet dass das versendete Paket beim Empf nger Knoten 4 erfolgre
255. noten laufenden Testskripte manuell koordiniert werden muss Die Aufgabe der Verteilung der Aktionen eines Testszenarios auf die verschiedenen Sensorknoten sowie die Koordination ihrer Ausf hrung kann gem dem AC MDSD an den Codegenerator delegiert werden wodurch eine Automatisierung dieser Aktivit t erzielt wird Dies ist m glich weil die notwendigen Informationen im formalen Modell festgehalten werden Des Weiteren werden f r den Test relevante Informationen in den formalen Modellen dargestellt So werden die von 148 ScatterUnit protokollierten Testergebnisse nach der Testdurchf hrung in demselben formalen Modelldiagramm welches die Testdurchf hrung repr sentiert visualisiert Auf diese Weise kann das Verhalten der zu testenden Anwendung dem Benutzer visuell dargestellt werden Visual ScatterUnit macht es m glich durch das kognitive visuelle Vorgehen mithilfe der iterativen Verfeinerung des Testfallmodells die Ursache f r das Versagen der zu testenden Anwendung zu lokalisieren Indem Visual ScatterUnit die zielgerichtete Verfeinerung der Testdiagramme erm glicht um die vom Softwaretester aufgestellten Hypothesen zur Fehlerlokalisierung zu verifizieren wird diese Vorgehensweise vereinfacht Dabei liegt der gro e Nutzen des modellgetriebenen Paradigmas von Visual ScatterUnit in der Automatisierung des in hohem Ma e _iterativen Verfeinerungsprozesses des Modells Werden bei weiterer Verfeinerung neue Entit ten ins Testfalldiagram
256. nt Assertion Log Labels Routingtabelle Abbildung 74 Protokollierung und Analyse der Routingtabelle zum Zeitpunkt der Versendung des Paketes Kame08 Schritt 2 ben tigte Zeit ca 10 Minuten Weiterhin war es nicht m glich das Datenpaket erfolgreich zu versenden obwohl die ben tigten Eintr ge in der Routingtabelle zum Zeitpunkt der Versendung des Pakets korrekt vorlagen Um sicher zu stellen dass die Eintr ge auch fehlerfrei von der betroffenen Methode bearbeitet werden wurde der 17 zeilige Code der Methode genauer untersucht Dabei wurde die Versagensursache f r den gescheiterten Versand des Pakets bestimmt Der Typ der Empf ngeradresse die der Methode als formaler Parameter bergeben wird stimmte nicht mit dem der Adressen der Routingtabelle 122 berein Die Typunvertr glichkeit ist auf einen Fehler bei der Portierung des zu testenden DSDV Routingprotokoll von der ESB zur MSB Plattform zur ckzuf hren Bei den ESBs werden zwei Bytes Adressen verwendet f r die Adressierung bei den MSBs hingegen nur ein Byte Schritt 3 ben tigte Zeit ca 75 Minuten Nun gelang das Versenden des Pakets vom Sender aus es wurde jedoch festgestellt dass der Zielknoten das Paket trotzdem nicht empfing Aus diesem Grund wurde der erste Schritt erneut in Betracht gezogen wobei der Fokus auf den Next Hop Informationen der Routingtabelle lag Diese berlegung wurde dadurch motiviert dass der Sendevorgang des Datenpakets erfolgrei
257. nted approach is the lack of a standard and unified toolset for building WSN applications and the entire software development process is ad hoc Thus WSN development tools should provide an integrated efficient and convenient development toolchain for end users Teng08 Der Aufbau der Werkzeugkette soll jedoch auch bei einer hohen Integrit t eine offene Architektur aufweisen um zuk nftige Erweiterungen nahtlos bewerkstelligen zu k nnen WSN development tools should provide a po werful mechanism allowing nearly unlimited extensions and enhancements of its inbuilt functionality for end users Teng08 Diverse Forschungsbeitr ge best tigen demnach die Notwendigkeit von innovati veren leistungsf higeren Ans tzen zur Softwareentwicklung f r sensitive Sensor knotenanwendungen Betrachtet man jedoch die bisherigen Beitr ge der Forschung so stellt man fest dass bis zum jetzigen Zeitpunkt kein Ansatz vorhanden ist der den Softwareentwicklungsprozess drahtloser Sensornetze in seiner Gesamtheit be trachtet Anwendungsprogrammierung Verwaltung aber auch Test sollten nicht iso liert von einander sondern gemeinsam in einem Gef ge behandelt werden Dies ist das Ziel dieser Arbeit und der Aspekt in dem sie sich von anderen Ans tzen unter scheidet 2 Siehe Glossar 3 Die Ergebnisse der Studie wurden auf der ICSNC 08 Konferenz vorgestellt auf der ein gro Ber Teil der Endergebnisse der vorliegenden Arbeit ebenfalls vorgestell
258. ntwurfs der MSBs und dessen kongruentem Abbild auf Metamodellebene in ScatterFactory2 nur der f r die Anwendung ben tigte Code mit s mtlichen dazu notwendigen Treibern generiert wird Jegliche Bibliotheken Treiber sowie Softwarefragmente f r im Modell nicht vorkommende Sensormodule werden bei der Generierung nicht miteinbezogen Daher wird wie in 5 6 geschildert bei ScatterFactory2 bei der Erzeugung der Softwarefamilien von einer automatisierten modellgetriebenen Konfiguration der Laufzeitumgebung der Anwendungen gesprochen Alles in allem hat sich die hier verfolgte automatisierte Codegenerierung hinsichtlich der Produktivit t des zugrunde liegenden modellgetriebenen Entwicklungsprozesses der Sensorknotenanwendungen sowohl f r die modulare als auch f r die monolithische Infrastruktur als Optimierungstechnik zur Ressourcenausnutzung hervorragend bew hrt 8 2 Bewertung der Testautomatisierungsschicht Wie er rtert besteht die Testautomatisierung mit Hilfe von ScatterUnit hinsichtlich der Bearbeitung der Daten die von der zu testenden Anwendung empfangen werden vgl Abbildung 69 aus folgenden T tigkeiten Empfang und Weiter leitung der Datenpakete ScatterWeb Firmware Anwendung Testobjekt a Regul rer Betrieb der Laufzeitumgebung 114 ScatterWeb Testinfrastruktur b Die Verarbeitungsschritte der Zwischenschicht zur Durchf hrung der Testautomatisierung Abbildung 69 Die Laufzeitumgebung
259. null context testcase Testverlauf Uebersichtsdiagramm ERROR Es muss genau ein Endknoten existieren this endknoten null context testcase Testverlauf Uebersichtsdiagramm ERROR Es muss mindestens ein Ablaufstrang existieren this ablaufstraenge size gt 0 Programmauszug 2 Ausdr cke der Sprache Checks zur berpr fung der semantischen Regel des Vorhandenseins eines Start und Endknotens im Aktivit tsdiagramm zur Modellierungszeit Kame08 1 Vorg nger ausgehend DT Verbindung 1 Nachfolger Ablaufstrang Startknoten Endknoten Abbildung 29 Assoziationen zwischen den Diagrammentit ten Ausschnitt aus dem Metamodell UML Notation Kame08 Diagramm entit t eingehend Synchronisations balken not self oclIsTypeOf Startknoten not self oclIsTypeOf Endknoten Programmauszug 3 OCL Ausdruck zum Start und Endknoten des Aktivit tsdiagramms Kame08 Hier wurden die semantischen Regeln nicht durch die Livevalidierung anhand von Checks Ausdr cken definiert was auch m glich w re sondern bereits auf Meta modellebene mit Hilfe von an die Metamodellelemente gebundenen OCL Ausdr cken angegeben Bei den semantischen Regeln handelt es um solche die sich stark an der Notation der Modellentit ten wie z B deren Verkn pfung im Editor orientieren und weniger an modellierten Aspekten der zugrunde liegenden Dom ne Daher werden solche Randbe
260. o muss in 3 statt der Eingabe der Sensor IDs eGate eingetippt werden 157 11 3 4 Der Alarm Reiter Abbildung 87 zeigt einen Bildschirmabzug des Alarm Reiters Java Eclipse SDK Mile Eck Navigate Search Project Run Window Help 37 m 0 8586 Problems Javadoc Declaration keit TR Connection Property Terminal Alem Log OTArFlashing Choose Sensor Alarm Status Control Buttons Sensor 6 kabus v 1 Microphone Siek Vibration Detect IP Movement Detect Alamo e Temperature 26 5 Battery 3 57 Sencor Alarm Editor Tineperiod Operation Edt Mesaremerk Categories Comparison Operators Value From To 4 AND gt RESET Undo temp v 2 By 3 20 x 12 00 23 00 ee am Bu 7 Constraint alam 3 if temp gt 20 from 12 00 to 23 00 amp batt lt 2 5 or vite detect or kmo detect Al defined Constraints Constrant Ar 0 alarm 8 amp temp gt 20 from 12 00 to 23 00 batt lt 2 5 or vibr detect or rmo detect 8 G Delete Cor straint 9 Abbildung 86 Der Alarm Reiter Ding07 Im Alarm Reiter kann der Benutzer das Alarmsystem konfigurieren und wird illustrativ ber erf llte Bedingungen im WSN informiert Die Interaktion des Benutzers mit dem Reiter ist ein weiteres Beispiel f r die Implementierung der Schnittstelle zwischen Mensch und Maschine in ScatterWeb Zuerst w hlt der Benutzer die IDs derjenigen Sensorknoten aus die von der Alarmbedingung erfasst werden sollen siehe 1 im obigen Bildschirmabzug Zun
261. odell berpr fung nach den Eigenschaften der Sensorknoten und den darauf laufenden Softwaremodu len 5 4 Die Codegenerierung Durch die Integration des oAW Codegenerators wie auch des GMF Editors als Plu gins in das Eclipse Rahmenwerk kann nach der Erstellung und Validierung des formalen Modells der Codegenerierungsprozess innerhalb der Eclipse Umgebung angesto en werden Hierzu muss wie Abbildung 44 veranschaulicht durch den Be fehl start_generator oaw und dann Run As im Projektexplorer von Eclipse der Gene rator mittels oAW Workflow aktiviert werden Gem der Konfiguration der Workflow Datei des oAW Generatorrahmenwerks wird das formale Modell aus dem Editor vom Codegenerator erkannt und anschlie end serialisiert um dann zwecks Codegenerierung die den serialisierten Modellinstanzen korrespondierenden Temp lates einzubinden S mtliche aus dem Generierungsprozess entstandenen Benachrichtigungen wer den in der Console View von Eclipse dem Benutzer mitgeteilt wodurch er das Vo ranschreiten bzw den Ausgang des Generierungsprozesses nachvollziehen kann Die generierten Artefakte werden in einem speziellen Zielordner namens src gen ab gelegt vgl Abbildung 45 Dieser Zielordner kann beliebig vom Benutzer innerhalb der Workflow Datei des Codegenerators bestimmt werden Bei den generierten Arte fakten handelt es sich um Quellcodedateien wie die C Dateien und deren Kopfzeilen f r die Firmwaremodule und die Anwendung sowie Konfigurat
262. on UML Unified Modeling Language WSN Wireless Sensor Network XMI XML Metadata Interchange 152 11 2 Glossar Domain Specific Language Dom nensprache DSL DSL ist eine Modellierungssprache oder Spezifikationssprache die f r eine Dom ne mit einer spezifischen Problemstellung bestimmt ist eine bestimmte Technik der Repr sentation eines Problems und oder eine spezielle L sungstechnik Der Ausdruck wurde jedoch g ngig aufgrund des Aufstiegs von dom nenspezifischer Modellierung WebDSL Meta Object Facility MOF MOF ist die Grundlage der Industriestandard Umgebung von OMG OMG Modelle k nnen darin von einer Anwendung in eine andere importiert in ein Netzwerk transportiert und in einem Repository abgelegt und von dort wieder abgefragt werden wobei sie in verschiedene Formate darunter XMI XMI serialisiert werden k nnen Diese Funktionen stehen nicht nur f r strukturierte Modelle oder nur f r UML Modelle zur Verf gung sondern auch f r Verhaltensmodelle und Datenmodelle ebenso f r nicht UML Modellierungssprachen die MOF basiert sind WebMOF Model Driven Architecture Modellgetriebene Architektur MDA MDA stellt einen offenen anbieterunabh ngigen Ansatz zur Verf gung Gesch fts und Anwendungslogik werden von der unterliegenden Plattformtechnologie getrennt Plattformunabh ngige Modelle einer Anwendung oder Gesch ftsfunktionalit ten bzw verhalten integrierter Systeme die mit UML UML und
263. on Log Label WR NachverarbeitungralscherRoutingInfo Await Radio Packet Action Sending Node 0 Addressed Node 0 Packet Type 6 Timeout 0 Additional Checking false Processing Time AFTER RoutingInfoWurdeVerarbeitet Radio Packet Received Event CETERE S Abbildung 78 Das erweiterte Detaildiagramm Init Und Warten f r die Protokollierung des Eintrags der Routingtabelle vor und nach dem Empfang der betroffenen Routinginformation Kame08 Schritt 8 ben tigte Zeit ca 45 Minuten Nun wurde der Typus der verf lschten Informationen bestimmt was einen wichtigen Schritt f r die Lokalisierung des Fehlers bedeutet Dabei lag der Fokus auf dem relevanten Codefragment das f r das Beschreiben der Next Hop Information in der 128 Tabelle zust ndig ist Nach intensiver Analyse der Codezeilen wurden die Fehler gefunden Die zwei Fehler auf die das Versagen zur ckzuf hren war bestanden darin dass die von einem Knoten empfangenen Routinginformationen in Bezug auf Knoten 3 und 4 zwar wie vorgesehen vom Empf ngerknoten zuerst bearbeitet wurden um diese dann per Broadcast weiterzuleiten Jedoch wurden der Broadcast Methode jeweils die Eintr ge der Tabelle selbst bergeben und nicht die bereits bearbeiteten Kopien der Datenstruktur der empfangenen Routinginformation Das Auffinden von Fehlern dieser Art in einem fremden Code mit Hilfe von Visual ScatterUnit ist eine weitere Demonstration des effektiven Einsatzes der hier v
264. on der f r die Verwaltung von Funksensornetzen essentiellen Funktionalit ten in den modellgetriebenen au tomatisierten Entwicklungsprozess Dieser soll nicht isoliert gestaltet werden son dern reibungslos mit Eigenschaften wie Konfiguration Fehlerbehebung berwa chung Nutzerinteraktion sowie der Visualisierung des Sensorstatus ScatterEditor und ScatterPlug kombiniert werden Diese Kombinationsm glichkeiten sind ein wichtiges Kennzeichen der Plattform das durch eine Plugin orientierte Architektur gem der Eclipse Plattform realisiert wird Der Benutzer kann sich einerseits be stimmter Plugins Funktionalit ten unabh ngig von den anderen bedienen wo durch ein separation of concerns erreicht wird andererseits kann er zwischen den verschiedenen Plugins kollaborativ navigieren was die Koh renz erh ht Um die Produktivit t der Plattform zu verbessern sollen ihre Hauptmerkmale sowohl im lokalen Modus als auch im entfernten Modus bzw internetbasiert in An spruch genommen werden k nnen Damit kann beispielsweise die Verwaltung und Konfiguration auf einem Rechner an einem Ort Entwicklungs und Testlabor erle digt werden w hrend die Sensoren entfernt an einem anderen Ort Experimentfeld unter realen Bedingungen platziert sind Dies wurde durch eine herk mmliche IP basierte Client Server Architektur realisiert 1 3 Aufbau der Arbeit Die Kapitel dieser Arbeit sind in vier thematischen Teilen gruppiert Der erste Teil der A
265. or besonderer Wert auf den Aspekt der Human Computer Interfaces f r WSN gelegt Im Folgenden wird die Architektur von ScatterEditor und dessen Komponenten dargestellt Danach werden die einzelnen Funktionalit ten des Rahmenwerks behandelt sowie deren Internet Integration 7 1 Architektur und Design von ScatterEditor Mit Hilfe des ScatterEditor Plugins k nnen die Sensorknoten sowie die Senke eGate der ScatterWeb Plattform kontrolliert konfiguriert und berwacht werden Wie eingangs erw hnt kann ScatterEditor dank der Internetintegration sowohl im lokalen als auch im entfernten remote Modus benutzt werden Im ersten Fall fungiert das Programm als Server an dem das eGate direkt angeschlossen wird Im zweiten l uft das Programm lediglich als Klient und verbindet sich mit dem WSN durch einen designierten Server ber das Internet Dieser Aufbau macht es m glich dass ScatterEditor je nach Wahl des Benutzers als Klient oder als Server fungieren kann und hat den Vorteil dass der Benutzer sich nur mit einem Programm vertraut machen muss was die Flexibilit t erh ht Dies erleichtert den Einstieg und die Akzeptanz von ScatterEditor Die zahlreichen Dienste von ScatterEditor wurden durch einzelne Reiter realisiert zwischen denen der Benutzer leicht navigieren kann Alternativ zum eGate als Verbindungsglied zum drahtlosen Netz ist es ebenfalls m glich einen gesonderten Knoten genannt SuperNode einzusetzen Dieser SuperNode ist ein S
266. oreigenschaften k nnen die entsprechenden Funktionalit ten vom Benutzer beliebig aktiviert bzw deaktiviert werden Abbildung 62 zeigt einen Bildschirmabzug des Property Reiters Um die aktuell im WSN aktiven bzw erreichbaren Knoten zu ermitteln steht dem Benutzer die Refresh Funktionalit t 2 zur Verf gung die eine Liste der IDs aller im WSN vorhandenen aktiven Konten liefert Aus dieser Liste pull down Men kann der Benutzer einen bestimmten Knoten w hlen mit dessen Maske die weitere Interaktion stattfindet Wird die ID des eGates vom Benutzer gew hlt so k nnen zus tzliche eGate spezifische Informationen in 3 erscheinen In der obigen Abbildung wird beispielsweise der Sensorknoten mit der ID 8 aus der Liste selektiert und dementsprechend werden die Daten seiner Maske in der grafischen Schnittstelle visuell angezeigt bzw seine Funktionen ausgef hrt So k nnen in 4 und 6 der Reihe nach die LEDs sowie der Pieper des Knotens bet tigt werden In 5 ist es m glich die Konfiguration des Knoten zur ck zu setzen Die verschiedenen Firmwareattribute k nnen in 7 und 8 vom Benutzter konfiguriert werden Weitere technische Daten ber den Sensor wie dessen Sendest rke externe und interne Stromversorgung werden in 10 und 11 angezeigt Daten ber die Sensorik des Knotens wie die Temperatur Bewegungssensor etc werden in 9 angezeigt Die visuell orientierte Gestaltung des Property Reiters ist ein Beispiel daf r wie di
267. orgestellten visuellen kognitiven Testautomatisierung 8 3 1 Analyse und Evaluierung der Fallstudie Zun chst muss eine ad quate Skala bestimmt werden anhand der die aus der Anwendung des modellgetriebenen Paradigmas gewonnene Produktivit t hinsichtlich des Testprozesses bemessen werden kann Zu diesem Zweck wurde die in der Fallstudie getestete Anwendung separat manuell mit Hilfe der Dienste von ScatterUnit getestet Demzufolge wurden keine Testfallmodelle eingesetzt aus denen Codeartefakte jeglicher Art generiert werden S mtliche Dienste von ScatterUnit mussten manuell aufgerufen werden Des Weiteren musste der gesamte Code zur Koordinierung des dezentralen Testverlaufs von Hand implementiert werden Ferner wurden s mtliche Log Eintr ge des Testverlaufs ebenfalls manuell vom Benutzer analysiert Es findet keinerlei Visualisierung des Testverlaufs bzw des Verhaltens des Testobjekts statt Die unautomatisierte herk mmliche Testdurchf hrung fungiert somit als Referenz gegen welche die aus der Automatisierung resultierende Leistungssteigerung gemessen wird Schon bei der Konzeption des Testszenarios wurde klar dass ohne den Einsatz formaler Modelle gro e Hindernisse bei der Umsetzung des Testentwurfs in einen Testfall entstehen der den Anforderungen des Testszenarios Rechnung tr gt Die Testbarkeit der Anwendung wird generell erschwert da man ohne die durch die Modelle erzielte Abstraktion zwangsl ufig mit den technischen Belangen der
268. orknoten ausgef hrt f r die das Testskript implementiert werden muss e Nach welchem Steuerbefehl wird ein weiterer Steuerbefehl ausgef hrt 5 Um den Einsatz von ScatterUnit ausf hrlicher zu er rtern wird im Folgenden die Implementierung eines konkreten Testfalls zum Testen des DSDV Routingprotokolls Perk94 mit Hilfe von ScatterUnit demonstriert Die Auswahl eines Routingprotokolls als Testobjekt f r die Demonstration der Funktionalit t von 34 Ein anonymer Reviewer des Visual ScatterUnit Papers in ACM IEEE Models08 35 Bei der Implementierung eines Steuerbefehls f r das Testskript eines Sensorknotens muss zur Beantwortung der zweiten Frage in Betracht gezogen werden dass die vorherige Aktion m glicherweise auf einem anderen Sensorknoten ausgef hrt wurde 36 Visual ScatterUnit wurde bewusst getroffen da Routing in drahtlosen Sensornetzen einen gut erforschten und repr sentativen Bereich darstellt Im Kontext der Ent wicklung von Routingprotokollen ist man im Allgemeinen aber besonders auch im Bereich drahtloser Sensornetze auf Simulationswerkzeuge angewiesen um das Verhalten des Netzes hinsichtlich des entwickelten Protokolls zu testen Daher ist die Entwicklung solcher Simulationswerkzeuge ein Bereich in dem viel geforscht wird Geht man jedoch einen Schritt zur ck so muss zuerst gew hrleistet werden dass die Implementierung des Routingprotokolls getestet werden kann und zwar auf den sich bereits im Betrieb befind
269. orknoten die repr sentierten Ak tionen ausgef hrt werden Daher sollte das in Abbildung 20 gezeigte Diagramm wie folgt gelesen werden Ist der Testfall gestartet werden zwei Aktivit ten nebenl ufig ausgef hrt Sensorknoten 1 versendet das erste Datenpaket und Sensorknoten 4 wartet auf seinen Empfang Nachdem das Paket empfangen wurde ndert sich die Topologie des Netzes Das zweite Paket wird nun vom Sensorknoten 1 versendet und Sensorknoten 4 wartet auf seinen Empfang Wird das Paket erfolgreich von Zielkno ten 4 empfangen terminiert der Testfall 39 endrirstPacket endSecondPacke Abbildung 20 Aktivit tsdiagramm zur Modellierung des Verlaufs des Testszenarios AwaitSecondPacket Dieses Diagramm dient der Darstellung der intuitiven Art der Repr sentation des Testszenarios Um jedoch in der Lage zu sein aus dem besagten Modelldiagramm den entsprechenden Code der Testskripte zu generieren muss sich der Entwickler auch mit den Feinheiten befassen Daher wird zu jeder im Hauptaktivit tsdia gramm modellierten Aktivit t ein zus tzliches detaillierteres Diagramm kon struiert um diejenigen Aktionen feink rniger zu modellieren aus denen die Aktivi t t besteht Ein Beispiel daf r zeigt das Diagramm in Abbildung 21 das die Aktivi t t Change Topology des Aktivit tsdiagramms in Abbildung 20 detaillierter dar stellt el LeaveRangeOfNode3 Topology Change Action Opposite Node 3 Apply On BOTH_NO
270. ort A gt Co MN 7 7 j f Sn Meta ae VOR Metamodell _vor Konkretes Modell gt Code Dko der abstrakte Syntax DSL Spezifikation Generator Realist 4 x x 4 i Instanzen von Abbildung 2 Der AC MDSD Prozess Hent06 Bevor in den n chsten beiden Kapiteln die Architektur der architekturzentrierten generativen Infrastruktur Visual ScatterUnit und ScatterFactory sowie die Zu sammenarbeit der verschiedenen Architekturkomponenten behandelt werden ist es an dieser Stelle unerl sslich sich einen Einblick in die Werkzeuge zu verschaffen aus denen die generative Infrastruktur zusammengebaut ist Wie eingangs erw hnt bildet die modellgetriebene generative Infrastruktur ar chitektonisch betrachtet eine Plugin orientierte Werkzeugkette wobei die Eclipse Plattform als deren Basis fungiert Jede Phase bzw jeder Schritt des modellgetrie benen Softwareentwicklungsprozesses wird von einem Werkzeug der Werkzeugkette ausgef hrt wobei das Resultat eines Werkzeuges oft als Eingabe des darauf folgen den fungiert Auf Basis des mit dem EMF erstellten Metamodells wird ein dom nen spezifischer grafischer Editor mit Hilfe von GMF erzeugt Die durch den Editor mo dellierten Konstrukte werden von openArchitectureWare eingelesen validiert und im Anschluss auf deren korrespondierenden Templates abgebildet um dann den Codegenerierungsprozess anzusto en Mit Hilfe des CDT WebCDT und des Ant Plugins WebANT von Eclipse werden dann die ge
271. ppen Wert darstellt insbesondere wenn man den Speicherbedarf des DSR Routingprotokolls ber cksichtigt 470 Bytes Er ist interessanterweise etwas h her als der Speicherbedarf der wesentlich gr eren Anwendung des Directed Diffusion Routingprotokolls was auf die jeweilige Implementierung zur ck zu f hren ist Man kann zwar durch eine optimierte Implementierung hinsichtlich der Datenorganisation auf dem heap und dem stack den RAM Speicherbedarf reduzieren jedoch macht dies die Realisierung der Anwendung komplexer Alles in allem bleibt also der zwei KB kleine RAM Speicher generell eine Herausforderung da alleine die Firmware bereits 68 der Gesamtkapazit t ben tigt Eine komfortable L sung bieten hingegen die MSBs mit einem 5 KB gro en RAM Speicher wodurch diese Schwierigkeit gel st wurde Dies best tigen die technischen Daten der MSBs Since the 2 KB of RAM available on the ESB were a very tight limitation the MSP430F1612 with 5 KB was selected This MCU offers 60 KB of memory divided into 5 KB RAM and 55 KB Flash ROM Instead of EEPROM an SD MM card slot is included for secondary storage of up to 4 GB It is connected to a UART and accessed using the SPI protocol Baar07 Durch die Untersuchung des Speicherplatzbedarfs der ESBs sollte illustriert werden dass sogar bei einer knappen Speicherkapazit t die Instrumentierung der Laufzeitumgebung des Sensorknotens durch die Testautomatisierung das Verhalten und die Realis
272. prochen werden Somit ist das TOSDev Rahmenwerk lediglich als eine grafische Entwicklungsumgebung anzusehen die keinerlei Methodik f r den Softwareentwicklungsprozesses der Sensoranwendungen aufweist Eine grafische Umgebung f r TinyOS die zus tzlich Simulationsfunktionalit ten unterst tzt ist das an der Universit t Berkeley entwickelte Werkzeug Viptos Visual Ptolemy and TinyOS Cheo05 Das Besondere an diesem Rahmenwerk ist dass die erstellten Modelle auf zweierlei Arten verwendet werden k nnen Einerseits k nnen sie in Quellcode transformiert werden welcher dann kompiliert und auf den Sensorknoten ausgef hrt werden kann Anderseits k nnen aus den Modellen f r die Integration versteht sich GRATIS als die grafische Erweiterung des TinyDT Rahmenwerkes Dies wurde in der Studie leider nicht ber cksichtigt 15 Bei berpr fung des Linkes am 02 08 09 wurde festgestellt dass der Link nicht mehr existiert 136 Simulationsumgebung TOSSIM Levi03 entsprechende Codeartefakte erzeugt werden anhand derer die Merkmale des Sensornetzes sowie die einzelnen Sensorknoten n her beobachtet werden Wie der unteren Vergleichstabelle vgl Tabelle 6 der Studie zu entnehmen ist ist Viptos das einzige Werkzeug das Simulationsfunktionalit ten bei der grafischen Anwendungserstellung mit einbezieht Hierzu st tzt sich die grafische Darstellung auf das Modellierungsrahmenwerk VisualSense Bald04 Dieses Modellierungsrahmenwerk wurde entwickelt
273. r angewandten Informatik ist die komponentenbasierte Entwicklung engl Compo nent Based Development CBD ein aus fr heren Ans tzen entwickeltes und um deren Schwachstellen bereinigtes Paradigma Grundlage dieses Konzeptes sind Software Komponenten die die Wiederverwendbarkeit von Software Artefakten verbessern sollen Der Grundgedanke komponentenbasierter Entwicklung ist die Unterteilung von Anwendun gen in wiederverwendbare Komponenten um m glichst wenig Code neu programmieren zu m ssen Mit der Zeit kann so ein Komponentenmarktplatz entstehen aus dem heraus An wendungen nach dem Baukastenprinzip zusammengestellt werden Zus tzliche Komponen ten m ssen nur f r Funktionalit t entwickelt werden f r die es bisher keine Implementie rung gibt WebComp 72 H Network E Container E Sensor containerName o sensorName E Connection ConnectionType connectionLabel H ESB H ECR E Application EET iiterRule stereotype E Component er namespace componentType componentVerson configParams t H SensorApplicationConnection ComponentConnection H PortConnection 8 ApplicationContainerConnection ComponentConnectionNane B UserdefinedCompanent overridesComponent overriddenComponentVersion componentName H Port ComponentType portName c parameterString er i ConnectionType portType en PROVIDEDPORT 10 REQUIREDPORT Messaging Legende Net String PortType Generalisierung
274. r fungiert somit als Indikator f r die Qualit t der Messung durch die jeweilige Sensorik Des Weiteren k nnen die Gegebenheiten der von den Sensorknoten zu beobachtenden Umgebung durch statistische Gr en pr ziser erforscht und dargestellt werden Ferner lassen sich dadurch bestimmte Beziehungen zwischen den sich in der Sensorumgebung fortlaufend ereignenden Abl ufen erkennen So k nnen Korrelationsbeziehungen zwischen verschiedenen erfassten Daten aufgedeckt und angegeben werden wie die Beziehung zwischen der Lichtst rke und der Temperatur in einem Gebiet Desweiteren kann der Einfluss des Energieverbrauchs Batterie von Modulen angegeben werden Zu diesem Zweck muss der Benutzer in die Lage versetzt werden auf Werkzeugebene s mtliche Knoten aus dem Main View zu selektieren und beliebige statistische Operationen aus den von diesen Sensorknoten gemessenen Daten zu berechnen vgl Abbildung 57 Dies setzt eine Zusammenarbeit zwischen dem Main View und dem Statistik View voraus Das Statistik View muss es dem Benutzer erm glichen zwischen den verschieden statistischen Operationen zu w hlen und diese bez glich einer von ihm festgelegten Zeitspanne auf eine Messserie anzuwenden Da es von gro em Interesse ist die Messwerte der unterschiedlichen Sensorknoten statistisch zu vergleichen und zu untersuchen k nnen unterschiedliche Messserien im Statistik View zu einer einzigen 4 F r die Berechnung der mathematischen Operationen wurde d
275. rWeb Constraints chk i PIM ma i Eclipse CDT i Plattform i ScatterFlasher gt rn i Software Familie Netzwerk laufende Software Abbildung 40 Die Architektur von ScatterFactory Hent06 5 1 Das Metamodell Die Entwicklung des Metamodells unterliegt anlog zu Visual ScatterUnit einem iterativen Prozess Demzufolge wurde das Metamodell entsprechend dem Charakter der ScatterWeb Plattform graduell aufgebaut Abbildung 41 veranschaulicht die E lemente des Metamodells sowie die zwischen ihnen bestehenden Beziehungen Hier bei wurde UML als Notation verwendet Ausgangspunkt bei der Modellierung ist die Netzwerkinstanz Network die das gerade zu modellierende WSN mitsamt seinen Knoten repr sentiert Daher bildet das Network Element die Wurzel des Metamodells Gem dem Metamodell besteht ein drahtloses Netzwerk aus den Sensorknoten Sensor den auf den Knoten lau fenden Softwarecontainern Container und den entsprechenden Relationen Connecti ons welche die verschiedenen Modellinstanzen logisch verkn pfen Folglich besteht eine Aggregation zwischen diesen drei Metamodellelementen einerseits und der Network Klasse andererseits da die Darstellung eines durch das Modellelement re pr sentierten WSNs lediglich aus der Modellierung der bereits genannten drei Mo dellinstanzen besteht Das Hauptanliegen beim Entwurf des Metamodells ist die Konstruktion einer DSL deren Ausdrucksm chtigkeit die Repr
276. rafischen Modellierung der Elemente zugleich deren Attribute konfigurieren Die Zusammenarbeit zwischen dem Editor und der Eclipse Problem View zeigt einen weiteren Vorteil der Eclipse Integration des Rah menwerks das in der ScatterClipse Werkzeugkette verwendet wird Werden die de finierten Modelle gro und somit un bersichtlich so wird in 5 stets eine Gesamt bersicht des Modelldiagramms angezeigt in dem der Benutzer einen bestimmten Teil selektieren kann wodurch er zu diesem Teil in der Modellierungsfl che des E ditors direkt gelangt Der Editor stellt etliche Funktionalit ten zur Verf gung die den Benutzer in die Lage versetzen durch berschaubare Interaktion aussagekr ftige grafische Modelle auf Basis des zuvor definierten Metamodells zu bilden In der Abbildung 43 wird ein mit Hilfe des Editors erstelltes Modellierungsbeispiel einer konkreten Anwendung gezeigt YellowSwitcher ist eine typische Anwendung auf einem Sensorknoten da sie ein g ngiges Szenario der WSN Dom ne realisiert Der Sensorknoten versendet und empf ngt Pakete im WSN Des Weiteren nimmt der Knoten berwachungsak tivit ten im WSN wahr indem er auf bestimmte Ereignisse im Netz durch die Akti vierung entsprechender Funktionalit ten reagiert So wird durch die YellowSwit cher Anwendung die gelbe Lampe ein und ausgeschaltet toggled sofern ein be stimmtes Paket vom Knoten empfangen wird Dieses Szenario fungiert als repr sen tatives Beispiel f r den Ant
277. rbeit Allgemeines stellt in einem Kapitel die verwendeten Technologien und Werkzeuge vor und erl utert die verschiedenen an der Realisierung der Werkzeug kette beteiligten Werkzeuge sowie deren Zusammenarbeit Dieses Kapitel leitet ber zum zweiten Teil Die generative Infrastruktur der sich aus drei Kapiteln zusammensetzt welche die generative Infrastruktur bestehend aus Visual ScatterUnit ScatterFactory und deren Integration behandeln Das dritte Kapitel befasst sich mit der modellgetriebenen Testumgebung Visual ScatterUnit zur Automatisierung des Tests der auf den Sensorknoten laufenden Anwendungen Anschlie end wird im vierten Kapitel die Realisierung und die Zusammenarbeit der verschiedenen Komponenten von Visual ScatterUnit eingehend er rtert Das f nfte besch ftigt sich dann mit der automatisierten Erstellung von Softwarefamilien zur Anwendungsentwicklung mittels des modellgetriebenen Rahmenwerkes ScatterFac tory Hier wird die Integration von Visual Scatter Unit und ScatterFactory darge stellt womit der Testprozess im Kontext der Anwendungsentwicklung in Betracht kommt Der dritte Teil der Arbeit WSN Verwaltung widmet sich in zwei Kapiteln der Verwaltung drahtloser Sensornetze und ihrer Plugin orientierten Realisierung in nerhalb der Werkzeugkette durch welche die angestrebte Zusammenarbeit mit der im vorigen Teil behandelten generativen Infrastruktur erzielt werden soll Gegens tand des sechsten Kapitels ist das ScatterPlug Rahmenw
278. rden Gem dem Routingprotokoll verh lt sich jeder Knoten w hrend des Austauschs der Routinginformationen wie folgt Beim Empfang einer Routinginformation tr gt der Knoten sich selbst als Next Hop ein und inkrementiert im Gegenzug die Distanz Anschlie end leitet er die aktualisierten Eintr ge per Broadcast weiter Demzufolge weist das Routingprotokoll den folgenden Austausch von relevanten Routinginformationen auf vgl Abbildung 77 Zuerst verschickt der Zielknoten die eigenen Routinginformationen per Broadcast an alle in seiner Reichweite befindlichen Knoten 1 Der benachbarte Knoten 3 deklariert sich seinerseits als Next Hop zum Zielknoten und inkrementiert die Distanz Diese aktualisierten Informationen leitet er anschlie end ebenfalls per Broadcast an die restlichen Knoten weiter 2 Knoten 1 Sender des Datenpakets empf ngt nun die aktualisierten Routinginformationen und ndert die eigenen Routinginformationen entsprechend ab Sein bisheriger Kenntnisstand wird gem dem Protokoll per Broadcast versendet und so von Knoten 2 empfangen der dann seine Antr ge entsprechend anpasst 3 Nachdem Knoten 3 seine Routinginformationen aktualisiert hat verschickt er sie per Broadcast weiter was zur Folge hat dass Knoten 1 der Sender die Routinginformationen bez glich des Empf ngers Knoten 4 erneut empf ngt 4 Schritt Empf nger Next Distanz Hop 1 4 4 0 2 4 3 1 3 4 1 2 4 4 2 3
279. rechenden Funktionalit ten zur Vergabe von Zugriffsrechten bzw Verwaltung der angemeldeten Klienten die ihrerseits die Dienste von ScatterUnit mit Hilfe dieser ScatterEditor Serverinstanz internetbasiert im entfernten Modus in Anspruch nehmen wollen Die genaue Funktionsweise wird weiter unten geschildert Wird ScatterEditor im lokalen Modus betrieben so wird eine direkte Verbindung zum angeschlossenen eGate oder SuperNode aufgebaut Anders ist es im Falle der internetbasierten Kommunikation die einer Klient Server Architektur auf Basis der Remote Method Invocation RMI von Java folgt WebRMI Dabei wird das eGate bzw der SuperNode an denjenigen Rechner angeschlossen auf dem der lauschende RMI Server l uft vgl Abbildung 60 Nun k nnen die als Klienten laufenden ScatterEditor Instanzen rechts entfernt durch die als Server laufende Scatter Editor Instanz links verwaltet werden wal 5 wireless ar DE E E Be USB Oo 2 Cema gt B Egate i me amp us 2 Bu Ey ESB ScatterEditor Client Abbildung 60 Internetbasierter Zugriff auf die Dienste von ScatterEditor Ding07 ScatterEditor Server Jeder ScatterEditor kann entweder als Server oder als Klient fungieren Die Konfiguration f r den jeweiligen Modus wird vorgenommen nachdem der Benutzer seine Wahl getroffen hat Der Rechner muss im lokalen Modus laufen und das Programm RMI registry muss gestartet werden so dass der Computer nicht als Server benutz
280. rekte Kommunikation mit dem WSN Des Weiteren erfolgt die Verwaltung der Klientenregistrierung f r das drahtlose Sensornetz zentral durch den Server Ausschlaggebend f r einen robusten Einsatz des eGate Servers sind die daf r notwendigen Sicherheitsma nahmen Es findet eine automatisierte Vergabe von Zugriffsschl sseln statt um den Klienten die Berechtigung der entfernten Nutzung der Scatter Editor Dienste zu erteilen Der Administrator kann nach Belieben einen neuen Schl ssel generieren Von Seiten des Klienten wird f r die Inanspruchnahme der entfernten Dienste wie folgt vorgegangen Zuerst muss eine sichere Verbindung zum eGate Server aufgenommen werden Zu diesem Zweck m ssen der Benutzername und das vom Server generierte Passwort eingegeben werden Hierzu muss im Connection Reiter der entfernte Modus ausgew hlt werden wodurch die Interaktion mit dem Benutzer entsprechend aktiviert wird Dies zeigt Abbildung 67 Mehr zu Benutzerinteraktion im entfernten Modus im Anhang 11 3 5 109 Java Eclipse SDK File Edit Navigate Search Project Run Window Help BO i BEG Oi FES E Java Problems Javadoc Declaration EERE e ScatterServer Connection Type of Communication Olocal IP of eGate Server 192 168 0 1 Remote Password of Connection Status Connection successful Abbildung 67 Einsatz von ScatterEditor als Klient Ding07 7 4 Zusammenfassung In diesem Kapitel wurde ScatterEditor vorgestellt Das Eclipse b
281. rfeinerung des Testfallmodels um die diesbez glich aufgestellten Hypothesen zu verifizieren So wird der angestrebte Nutzen des modellgetriebenen architekturzentrierten Ansatzes beim Testen von Anwendungen drahtloser Sensornetze optimal erreicht Der automatisierte Test und die Codierung der Anwendungen m ssen gemeinsam nah zum jeweiligen Einsatzszenario des Sensornetzes durchgef hrt werden Die Br cke zur Betriebsn he liegt in der Integration von Verwaltungsfunktionalit ten in den automatisierten Softwareentwicklungsprozess so dass dieser nicht isoliert betrachtet wird Durch die integrierte Verwaltung des Sensornetzes kann w hrend der Anwendungstests und der Erstellung der Sensoranwendungen der Status der einzelnen Knoten visualisiert konfiguriert berpr ft und berwacht werden Da die Sensorknoten h ufig an Orten platziert werden zu denen Menschen schwer Zugang haben muss die Verwaltung sowie die Ausbringung der Softwareartefakte entfernt betrieben werden Hier ist ein internetbasierter Zugriff von N ten Um solche Verwaltungsfunktionalit ten zu realisieren wurden die Rahmenwerke ScatterPlug und ScatterEditor entwickelt Durch das Plugin orientierte ScatterEditor werden wichtige Verwaltungsfunktionalit ten zur Verf gung gestellt Beispielsweise k nnen neben der Konfiguration und der berwachung der Sensorknoten Aktualisierungen der auf den Knoten laufenden Softwaremodule per Funk vorgenommen werden Die Funktionalit ten k nnen
282. rialisierung fungiert somit als Austauschmechanismus zwischen den verschiedenen Plugins der gesamten ScatterClipse Werkzeugkette vgl Abbildung 54 Folglich kann jede beliebige Komponente der Werkzeugkette gem ihrer Funktionalit t das WSN bearbeiten und dann im XML Format ablegen exportieren so dass eine weitere Komponente das WSN im Folgenden importieren bearbeiten und im XML Format wiederum exportieren kann usw Dadurch wird auf robuste Art und Weise u a bewirkt dass eine beliebige Synchronisation der Konfiguration des WSNs aufrecht erhalten bleibt was den Grad der Zusammenarbeit zwischen den Plugins der Werkzeugkette erheblich steigert Plugin1 8 Plugin2 Lesen und D Bearbeiten der WSN Speicherung der R 5 Konfiguration WSN ffnen der W SN Konfiguration WSN inXML Konfiguration UO inxXML Dez 7 RS o ZI XM XML Fe E L XML E n Konfiguration XML arser Expo der WSN XML Im 3 Import u Abbildung 54 XML als Austauschformat in der Plugin orientierten Architektur Ding07 93 6 3 Main View Das Main View stellt die Repr sentationsschicht des Rahmenwerks dar in der die Interaktion mit dem mittels des Root Plugins errichteten WSN stattfindet Das Main View erm glicht es dem Benutzer die Sensorknoten zu kreieren zu platzieren und wieder aus dem WSN zu entfernen Ferner kann der Benutzer mit Hilfe des Main Views die Maske der einzelnen Sensorknoten im Grundriss visu
283. richt So steigt die Durchlaufszeit eines Datenpakets auf 54 Millisekunden bei der Aktivierung des ereignisbasierten Wartedienstes was eine Erh hung von insgesamt ca 24 Millisekunden ausmacht Dabei bleibt die ben tigte Zeit pro Verarbeitungsschritt gleich Bei der Durchf hrung dieser Messung wurde auf ein Ereignis gewartet das am Ende nicht eintrifft und so von einem worst case ausgegangen Auf diese Weise wird garantiert dass andere Wartevorg nge bei einer Inanspruchnahme des Wartedienstes keinen gr eren Aufwand als den hier gemessenen beanspruchen Demgem stellen die angegebenen Messungen eine obere Schranke des Verarbeitungsaufwands eines Datenpakets durch den Wartedienst dar Interessanter wird es jedoch wenn der Wartedienst neben einem weiteren Dienst w hrend der Testdurchf hrung benutzt und somit aktiviert wird Dies ist das vierte Szenario in Tabelle 3 bei dem der Dienst zur Simulation der Netztopologie zus tzlich zum Wartedienst aktiviert wird Die gemessene Zeit zeigt eine deutliche Steigerung auf insgesamt ca 153 Millisekunden wobei ca 0 3 Millisekunden f r jeden Bearbeitungsschritt ben tigt werden Ausschlaggebend ist also offensichtlich der Aufwand den der Simulationsdienst verursacht Daher wurde dieser alleine gemessen was im dritten Szenario in Tabelle 3 angegeben wird Hierf r wurde die Einbeziehung von 49 Nachbarn in der Reichweite des Knotens simuliert was ebenfalls einen recht hohen Verarbeitungsaufwan
284. rknoten eines Raumes k nnen somit den gerade von der Person geh rten Sender im benachbarten Raum ermitteln dessen Radioempf nger ausschalten und den ei genen beim Zeitpunkt des Betretens des eigenen Raumes anschalten Um den Zeit punkt des Verlassens des benachbarten und des Betretens des eigenen Raumes zu ermitteln m ssen bestimmte Knoten mit Bewegungssensoren ausgestattet sein Solche Bewegungssensoren k nnen ihrerseits die betreffenden Knoten ber ein sol ches Ereignis benachrichtigen Eine einfache M glichkeit ein solches HiFi System zu testen w re schlicht durch die verschiedenen R ume des Hauses zu wandern und w hrenddessen die Radiosta tionen st ndig zu wechseln um zu sehen ob alles wie erw nscht funktioniert Das Testen eines solchen Systems in der ra des Ubiquitous and Pervasive Computing U amp P Computing Weis91 z B in einem Smart Home muss jedoch automati siert vonstatten gehen Um die angestrebte Testautomatisierung zu erm glichen m ssen bestimmte Ak tionen des Testverlaufs die Bewegung durch das Haus simuliert werden So ist bei diesem Testszenario die Simulation der zu erfassenden Daten des Bewegungs sensors und der Aktion zum Umschalten der Radiostationen vonn ten Ferner muss das Voranschreiten des auf den verschiedenen Sensorknoten verteilten Testverlaufs koordiniert und beobachtet werden Solche Mechanismen zum Zweck der Testauto matisierung ben tigen ein entsprechendes Rahmenwerk
285. rozess 3 6 Zusammenfassung 4 Technische Realisierung des Testrahmenwerks 4 1 Entwurf und Realisierung der Dom nensprache DSL 4 2 Live Validierung der Modelle 4 3 Die Codegenerierung 4 4 Die Dienste der Testschicht ScatterUnit 4 5 Zusammenfassung 5 ScatterFactory Der Pfad zur Anwendungsentwicklung 3 1 Das Metamodell 5 2 Die Modellierungsebene 5 3 Die Modellvalidierung 5 4 Die Codegenerierung 5 5 Kompilierung und Initialisierung der Software Deployment 5 6 ScatterFactory2 5 7 Zusammenfassung aA A N e 14 16 24 26 28 34 36 39 43 49 50 50 58 62 65 69 71 12 74 77 78 82 82 86 III WSN Verwaltung 6 ScatterPlug Der Pfad zur WSN Visualisierung und Analyse 88 6 1 Die Kommunikationsschicht 88 6 2 Das Root Plugin 92 6 3 Main View 94 6 4 Das Statistik View 95 6 5 Zusammenfassung 98 7 ScatterEditor Der Pfad zur WSN Konfiguration Steuerung und berwachung 99 7 1 Architektur und Design von ScatterEditor 99 7 2 Dienste und Komponenten von ScatterEditor 101 7 2 1 Die Verbindungskomponente Connection 101 7 2 2 Visualisierung durch den Property Reiter 103 125 Das Terminal 104 7 2 4 Aktualisierung der Softwaremodule via Funkkanal Over The Air Software Updates 106 7 2 5 Die WSN Uberwachung Alarm 107 7 3 Internetintergration in ScatterEditor 109 7 4 Zusammenfassung 110 IV Bewertung und Positionierung von ScatterClipse 8 Beurteilung und Auswertung der Werkzeu
286. rucht wurde Die Resultate der Zeitmessungen sind in Tabelle 3 aufgelistet Szenario Gemessen Zeit pro e Zeit Bearbeitungsschritt Alle Dienste sind deaktiviert 032 ms lt 0 1 ms Es besteht ein Wartevorgang 054 ms 0 1 ms Die Simulation der Netzwerktopologie ist 133 ms 0 3 ms aktiviert Wartevorgang Simulation der 153 ms 0 3 ms Netzwerktopologie Tabelle 3 Messung des Verarbeitungsaufwands empfangener Datenpakete in ScatterUnit Kame07 Die Messungen wurden in Bezug auf verschiedene Kombinationen der betroffenen ScatterUnit Dienste vorgenommen um unterschiedlich repr sentative Einsatzszenarien bzw Einstellungen der Testautomatisierung bez glich der oben besprochenen Fragestellung abzudecken Wie der ersten Zeile der obigen Tabelle zu entnehmen ist dauert jeder Verarbeitungsschritt im Fall dass s mtliche Dienste der Testautomatisierung 9 Hierzu wurden die Verarbeitungsschritte jeweils 500 mal bez glich der Szenarien in der Tabelle durchgef hrt 115 ausgeschaltet sind weniger als eine Millisekunde Insgesamt betrug die Zeit des Durchlaufs eines Datenpakets bis es der Anwendung verarbeitungsbereit vorliegt siehe Abbildung 69 Teil b weniger als 30 Millisekunden Diese Gr e fungiert als Referenz f r die Steigerung des Verarbeitungsaufwands wenn weitere Dienste zum Zweck der Testdurchf hrung in Anspruch genommen werden was den Einsatzbedingungen der ScatterUnit Testautomatisierungsschicht entsp
287. rung auf Codege nerierungsebene u a dazu spezifische dom nennahe Randbedingungen festzulegen die zugleich den Codegenerierungsprozess optimieren Dieser Aspekt spiegelt sich in der gerade erw hnten engen Zusammenarbeit zwischen Xpand und den Checks Ausdr cken wider Beispielsweise wird in Visual ScatterUnit der Code eines Prozes ses aus dem dazugeh rigen Aktivit tsdiagramm f r Testzwecke generiert Daher wird das Aktivit tsdiagramm traversiert und zwar beginnend vom Startzustand bis zum Endzustand w hrenddessen der Code aus den Templates f r die Zwischenzu st nde emitiert wird Dies setzt jedoch voraus dass keine Zyklen im Diagramm ent halten sind denn in diesem Fall w rde der Codegenerierungsprozess endlos weiter laufen Der gesamte Generierungsprozess kann deshalb nicht gestartet werden wenn die entsprechenden Bedingungen verletzt werden Diese Pr fung w hrend der Codegenerierung aus den Templates zu bewerkstelligen w re sehr komplex und in effizient Anhand von einfachen Checks Ausdr cken kann dies im vorherigen Schritt der Validierung auf einfache und effiziente Weise ausgeschlossen und so eine kor rekte und effiziente Codegenerierung gew hrleistet werden Abbildung 11 zeigt ein Beispiel eines Xpand Templates sowie deren Struktur Hent06 Analog zu Checks wird zuerst das jeweilige Metamodell mit einer entsprechenden IMPORT Anweisung eingebunden Eine Xpand Anweisung beginnt immer mit dem Zeichen lt lt und endet mit
288. rung der Sensorknoten sowie der N he zu den Einsatzgegebenheiten der Sensorknoten Die Randbedingungen denen der Einsatz von Software auf einem Sensornetz sowie dessen Betrieb unterliegen wirken diesen drei Aspekten entgegen Der Forderung nach Produktivit tssteigerung bei der Erstellung der Softwareanwendungen die sich aus der Vielfalt der laufenden Anwendungen und dem Massenbetrieb der Sensorknoten ergibt wird durch einen h heren Grad an Automatisierung begegnet Die Erstellung von Anwendungen erfolgt daher im Kontext von wiederverwendbaren Softwarefamilien Hierzu wurde das architekturzentrierte ScatterFactory 2 Rahmenwerk entwickelt mit dessen Hilfe die Anwendungen der Sensorknoten aus ihren formalen Modellen generiert werden Durch den hohen Grad an Automatisierung beschleunigt sich die Laufzeitkonfiguration der zu realisierenden Anwendungen Ferner k nnen mehrere Anwendungen im gleichen formalen Diagramm modelliert werden wobei deren gemeinsam verwendete Softwaremodule lediglich einmal modelliert werden m ssen Zudem kann eine modellierte Anwendung einer Vielzahl von Sensorknoten gleichzeitig zugewiesen werden so dass die generierten Softwareartefakte anschlie end automatisiert im Einsatzort ausgebracht werden k nnen Des Weiteren steigern sich Ersetzbarkeit und Wiederverwendbarkeit der Softwareartefakte da diese durch die zugeh rigen Modellkonstrukte formal repr sentiert werden Die modellgetriebene Codegenerierung dient zudem der
289. s A Schiller J The ScatterWeb MSB 430 Platform for Wireless Sensor Networks Poster and Abstract In SICS Contiki Hands On Workshop Kista Sweden 2007 URL http www sics se adam contiki workshop 2007 baar07scatterweb pdf Bald04 Baldwin P Kohli S Lee E A Liu X Zhao Y Modeling of Sensor Nets in Ptolemy II In 3rd International Symposium on Information Processing in Sensor Networks pp 359 368 IEEE Xplore 2004 Blum04 Blumenthal J Handy M Timmermann D SeNeTs Test and Validation Environment for Applications in Large Scale Wireless Sensor Networks In 2nd IEEE International Conference on Industrial Informatics pp 69 73 IEEE Xplore 2004 Burr06 Burri N Schuler R Wattenhofer R YETI A TinyOS Plugin for Eclipse In 176 ACM Workshop on Real World Wireless Sensor Networks pp 1 5 ACM New York 2006 Cart06 McCartney W P Nigamanth S TOSDev A rapid development environment for TinyOS In 4th International Conference on Embedded Networked Sensor Systems pp 387 388 ACM New York 2006 Che005 Cheong E Lee E A Zhao Y Viptos A graphical development and simulation environment for TinyOS based wireless sensor networks In 3rd International Conference on Embedded Networked Sensor Systems pp 302 302 ACM New York 2005 Corm90 Cormen T Leiserson C Rivest R Introduction to Algorithms MIT Press Massachusetts 1990 Coul00 Coulouris G Dolli
290. s Hauptziel des von IBM entwickelten Rahmenwerks ist dabei auf Basis des von der OMG spezifizierten Meta modeling Objects MOF WebMOF Standard Modelle zu formulieren mit deren Hilfe editierbare dom nenspezifische Sprachen definiert werden k nnen Editierbar bedeutet in diesem Zusammenhang dass die der DSL zugeh rigen Editoren automatisiert und gem dem definierten Metamodell erzeugt werden Moor04 Zu diesem Zweck stellt EMF Ecore als Be schreibungssprache zur Erstellung von Metamodellen zur Verf gung eine mit XML Model Interchange XMI WebXMI serialisierbare Java Implementierung des MOF Kernes Essential MOF EMOF Die Pr sentation von mit Ecore beschriebe nen Meta Modellen erfolgt durch strukturelle Formalisierungen wie XML Schemata oder UML Notation Abbildung 4 zeigt eine UML orientierte Ubersicht der Elemente von Ecore und deren Relationen 11 Siehe Glossar 12 Siehe Glossar 11 EObject A EModelElenent A ENamedElement EPackage EEnumLiteral EClass EDataType EStructuralFesture EOperation EParameter EEnum EAttribute EReference Abbildung 4 Die Elemente von Ecore als Klassenhierarchie WebEcore EAnnotation EClassifier ETypedE lement Man kann die Klasse EObject mit der Objekt Klasse in Java vergleichen Sie bildet die Basisklasse von der die restlichen Klassen erben bzw die diese erweitern Wie die Erfahrung mit der Modellierung mit Hilfe von UML zeigt
291. s ent spricht dem Open Service Gateway Initiative Standard OSGi Dabei fungiert der Eclipse Kern als OSGi Server WebOSGI bei dem sich die jeweiligen Klienten Plugins eindeutig registrieren m ssen vgl Abbildung 3 Diese Eindeutigkeit spielt eine entscheidende Rolle denn so ist es beispielsweise m glich dass verschie dene Versionen desselben Plugins gleichzeitig in Anspruch genommen werden k n nen Um die Leistungsf higkeit zu optimieren werden die Plugins erst dann akti viert wenn sie bet tigt werden Jedoch m ssen alle Plugins Klienten beim Start registriert bzw erfasst werden was eine l ngere Startphase der Eclipse Plattform verursacht Daum06a Um eine koordinierte und softwaretechnisch konforme Zusammenarbeit der oft zeitlich unabh ngig voneinander entwickelten Plugins zu gew hrleisten kommuni zieren diese mittels spezifischer XML basierter Schnittstellen namens Erweite rungspunkte Extension Points Ein Plugin kann bereits vorhandene Erweite rungspunkte entsprechend erweitern bzw sich an sie anpassen oder eigene Erweite rungspunkte definieren um diese dann von anderen Plugins erweitern zu lassen F r eine standardisierte Entwicklung von eigenen Plugins bietet Eclipse n tzliche Funktionalit ten mit dem Plugin Development Environment PDE an Es ist m glich die Plugins in verschieden Auspr gungen zu realisieren Neben den herk mmlichen Plugins k nnen sie als Actions und Views implementiert wer den Act
292. s erw hnt gibt es bislang keine Entwicklungsumgebung die den Test der zu entwickelnden Anwendung w hrend ihrer Erstellung softwaretechnisch unterst tzt Jedoch existieren mehrere Versuche bzw Werkzeuge die sich mit dem Test drahtloser Sensorknoten auf Basis unterschiedlicher Ans tze besch ftigen Im Folgenden werden diejenigen Ans tze besprochen die insbesondere f r die Testautomatisierungsschicht ScatterUnit und ihre modellgetriebene Erg nzung Visual ScattterUnit von Relevanz sind Da das robuste Routing in drahtlosen Sensornetzen aufgrund ihrer Betriebsbedingungen eine anspruchsvolle Herausforderung ist widmen sich bestimmte Ans tze hinsichtlich des Tests haupts chlich dieser Problemstellung Etliche Simulatoren f r drahtlose Sensornetze WebWSN Simu sind speziell zu diesem Zweck entwickelt worden z B J Sim Sobe05 Avrory Titz05 ns 2 Witt06 Dabei liegt der Fokus berwiegend darauf wie sich das Netz bzw die im Netz agierenden Sensorknoten bei der Ausf hrung des Routing Protokolls verhalten Zwar werden dadurch diverse Aspekte berpr ft was den Einsatz von Simulatoren unverzichtbar macht jedoch bleibt die Anforderung eines Tests unter realen Bedingungen bei Simulationswerkzeugen unerf llt Ferner ger t oft die Untersuchung der Anwendung selbst die das Protokoll realisiert in den Hintergrund So wurde stattdessen der Versuch unternommen Routing Protokolle realit tsn her zu testen z B indem fahrende Fahrzeuge
293. s jeweilige Ecore Modell gebunden Zu diesem Zweck bedient sich die Runtime Component der Eclipse Modeling Technology EMFT Mit dieser werden die OCL Randbedingungen die an den GMF Editor gebunden sind eingelesen und ihre Einhaltung im Modell berwacht Verst t man w hrend der Modellierung gegen bestimmte Randbedingungen wer den die entsprechenden Fehlermeldungen angezeigt Diese sind sowohl visuell als auch verbal Die visuellen Fehlermeldungen werden im Editor bei den betreffenden Modellkonstrukten eingeblendet die verbalen sind die vom Benutzer bzw Dom nenexperten selbst spezifizierten Fehlermeldungen Diese werden dank der Eclipse Integration im Problem View angezeigt Modellinstanzen die gem dem Ecore Metamodell nicht verkn pft werden k nnen lassen sich auch im Editor nicht ver binden Der folgende Bildschirmabzug von ScatterFactory in Abbildung 6 illustriert dieses Vorgehen Hent06 Gem der EMFT werden die blicherweise vom DSL Designer in OCL spezifi zierten Bedingungen an einer zentralen Stelle gehalten dem Audit Container Mit Hilfe der zugeh rigen Werkzeuge werden auf einfache Weise die Bedingungen deren jeweilig korrespondierenden Modellkonstrukten zugewiesen Dabei ist es zum Einen m glich den entsprechenden Kommentar der im Problem View angezeigten Feh lermeldung festzulegen und zum Anderen wird die Art der visuell im DSL Editor 14 Siehe Glossar 15 Oft handelt es sich in diesem Zusammenhang um
294. s not specified this source null context testcase Link ERROR The target node of this link is not specified this target 166 11 5 2 Randbedingungen in ScatterFactory2 Im Folgenden wird eine breite Auswahl der in ScatterFactory2 definierten Checks Ausdr cke aufgelistet Kame08 Die in den Ausdr cken vorkommenden Modellvariablen beziehen sich auf die Entit ten des f r ScatterUnit definierten Metamodells welches in Abbildung 89 dargestellt wurde context WSN WirelessSensorNetworkDiagram ERROR The diagram must contain at least one sensor node this diagramNodes select e e metaType superTypes contains WSN SensorNode size gt 0 context WSN DiagramNode ERROR This node must have a name this metaType superTypes contains WSN SensorNode true this name length gt 0 context WSN Diagram Node ERROR The name must only contain alphabetic and numeric letters this name matches p Alpha p Digit context WSN SensorNode ERROR A sensor node must be linked to exact one application this linkedNodes select e e metaType WSN Application size 1 context WSN SensorNode ERROR The name of a sensor node must be unique this linkedNodes selectFirst e e metaType WSN Application null true this linkedNodes selectFirst e e metaType WSN Application linkedNodes select e e metaType superTypes conta
295. s und dem Zweck der Testautomatisierung der Sensoranwendungen andererseits stellt die Innovation des Rahmenwerkes dar welche im Bereich der Softwaremodellierung positiv aufgenommen wurde the idea of incorporating the test results in the test case model is certainly an interesting contribution that could be of general interest 2 Meiner Ansicht nach handelt es sich hierbei um einen generalisierbaren Ansatz der ber ein gro es Potential verf gt in unterschiedlichsten Dom nen eingesetzt zu werden 19 Ein anonymer Reviewer des Visual ScatterUnit Papers in ACM IEEE Models 08 Paper is interesting subject and interesting application of model driven approach to testing WSNs 20 Ein anonymer Reviewer des Visual ScatterUnit Papers in ACM IEEE Models 08 151 11 Anhang 11 1 Abk rzungsverzeichnis Abk rzung Begriff AC MDSD Architecture Centric Model Driven Software Development DSDV Destination Sequenced Distance Vector Routing DSL Domain Specific Language EMF Eclipse Modeling GMF Graphical Modeling M2M Model to Model Transformation MDA Model Driven Architecture MDSD Model Driven Software Development MOF Meta Object Facility oAW openArchitecture Ware OCL Object Constraint Language OMG Object Management Group PIM Platform Independent Model PSM Platform Specific Model RMI Remote Method Invocation TTCN Testing and Test Control Notati
296. satz auf der Basis beliebiger Modelle Petr06 S 191 Ein pr gnantes Merkmal von oAW ist demnach der Model to Code Ansatz was unserer in ScatterClipse verfolgten architekturzentrierten Methode entgegen kommt wie zu Beginn des Kapitels dargestellt wurde Abbildung 8 zeigt die Archi tektur von oAW und deren Komponenten 16 Design Werkzeug Modell i SMFUML Xtext J Export SSS Tnstanti ator Instanziiertes Modell Templates i G Extensions Pand enerator Xtend Front End Metam odell MF oA W Constraints Checks Back End Artefakte Abbildung 8 Die Architektur und Technologien von oAW Hent06 Im Folgenden werden die Funktionalit ten der verwendeten Technologien und die Komponenten der Architektur sowie deren Zusammenarbeit erl utert Zuerst muss das formale Modell aus dem die korrespondierenden Softwarearte fakte gewonnen werden vom Codegenerator Rahmenwerk korrekt eingelesen wer den um dieses Modell Eingabe den brigen Komponenten des Codegenerator Rahmenwerks zur Weiterverarbeitung zur Verf gung zu stellen Zu diesem Zweck wird das blicherweise in XMI serialisierte Modell importiert und dann vom Par ser als Syntaxbaum zur Verf gung gestellt Der Syntaxbaum ist als Objektgeflecht repr sentiert was im Java basierten oAW bedeutet dass die Knoten des Syntaxbaumes als Java Klassen repr sentiert wer den Diese sind gem dem Metamodel
297. sentation der auf den einzelnen Sen sorknoten laufenden Softwaremodule sowie die zwischen ihnen bestehenden Abh n gigkeiten erfasst Solche Abh ngigkeiten orientieren sich stark an den verwendeten Firmwaremodulen des Sensorknotens Daher fu t die Schl sselidee bei der Darstel lung der einzelnen Module auf dem Komponentenprinzip 52 Ein Container setzt sich aus einer Menge von Komponenten zusammen wobei jede Komponente mehrere voneinander abh ngige Firmwaremodule umfasst Diese gegenseitigen Abh ngig keiten werden gem der Softwarekomponententechnik anhand von Ports ausge dr ckt Dabei wird zwischen Required Ports und Provided Ports unterschieden Bei ersteren wird angegeben welche Funktionalit ten f r eine Komponente von einer anderen ben tigt werden S mtliche von einer Komponente f r andere angebotenen Dienste werden mittels Provided Ports spezifiziert Da ein Port entweder provided oder required sein kann wurde dies im Metamodell durch eine Aggregation angege ben Ferner k nnen gem dem Metamodell f r eine Komponente verschiedene Ver sionen existieren Daher ist es m glich dass f r denselben Komponententyp unter schiedliche Implementierungen existieren die je nach der laufenden Anwendung bzw dem Sensortyp vom Benutzer untereinander ersetzt werden k nnen Ein Bei spiel dazu findet sich in 5 4 51 Das verbale besteht aus wurde anhand der korrespondierenden Aggregation im Meta modell realisiert 52 In de
298. sentlich zur Steigerung der Robust heit des Entwicklungsprozesses beitr gt Das hier angef hrte Beispiel zeigt dass Fehler in fr heren Phasen des Entwicklungsprozesses ausgeschlossen werden k n nen n mlich auf Modellierungsebene und nicht erst auf der fehlerfl chtigen Co dierungsebene Je fr her ein Fehler im Entwicklungsprozess aufgedeckt wird desto unerheblicher sind seine Auswirkungen Zwar wird eine Vielzahl syntaktischer Randbedingungen auf Modellebene durch die Live Validierung berpr ft die Live Validierung kommt jedoch vor allem zum Tragen wenn es sich um die Validierung semantischer Randbedingungen handelt Hier entfaltet sich der wahre Nutzen der Modell berpr fung in Echtzeit So ist es z B unerl sslich Zyklen im Aktivit tsdia gramm auszuschlie en da durch den Baum des Aktivit tsdiagramms der Fluss des Testverlaufs bez glich des zeitlichen Voranschreitens der auf den Knoten verteilten Tests modelliert wird vgl Abbildung 36 Daher setzt sich der Testfall aus einer linearen Sequenz von Aktivit ten zusam men die mit einem Startknoten beginnt und einem Endknoten endet wodurch die Ausf hrung des Testfalls sowie die dazu n tige Codegenerierung gesteuert wird vgl Programmauszug 6 42 Siehe Anhang 11 5 59 ay SendFirstPackets AwaitFirstPacke if at a 4 A control path must have one incoming link Change Topoloay jas Abbildung 36 Live Validierung deckt auf dass
299. size 0 this outgoing size 0 true this incoming size this outgoing size 2 context testcase SyncNode ERROR A sync node to which the initial node is linked to must not have other predecessors this incoming source exists e e metaType testcase InitialNodeOfTheTestCase this incoming size 1 true context testcase SyncNode ERROR A sync node linked to the final node must not have other successors this outgoing target exists ele metaType testcase FinalNodeOfTheTestCase 9 this outgoing size 1 true context testcase SyncNode ERROR The control pathes a sync node is linked to must be executed on distinct sensor nodes List testcase ControlPath this outgoing target select e e metaType testcase ControlPath getDeploymentIdForFirstAction size List testcase ControlPath this outgoing target select e e metaType testcase ControlPath getDeploymentIdForFirstAction toSet size context testcase SyncNode WARNING Some control pathes linked to the sync node are executed on the same sensor node 165 List testcase ControlPath this incoming source select e e metaType testcase ControlPath getDeploymentIdForLastAction size List testcase ControlPath this incoming source select e e metaType testcase ControlPath getDeploymentIdForLastAction toSet size context testcase Link ERROR The source node of this link i
300. stellte Anwendungen betrachtet und dabei das Verh ltnis zwischen generiertem und manuell erstelltem Code genauer untersucht Bei der ersten Anwendung handelt es sich um die Standard Empty Anwendung die s mtliche Firmwarefunktionalit ten zur Verf gung stellt und daher die gesamten Firmwaremodule ben tigt Dies veranschaulicht das Diagramm zur modellierten Anwendung in Abbildung 68 oben wo der Container Full_firmware alle Firmwaremodule beinhaltet Da alle Firmwaremodule in Anspruch genommen werden kommt der Einsatz von Dummy Templates hierbei in Betracht Die Anwendung fungiert somit als Referenz f r die gr te denkbare Menge des erforderlichen Codes Beim zweiten Szenario handelt es sich um die YellowSwitcher Anwendung die in 5 2 diskutiert wurde Bei der dritten Anwendung geht es um eine in der WSN Dom ne gel ufige Aufgabe eines Sensorknotens bei der der Knoten im drahtlosen Sensornetz die Rolle eines Akteurs einnimmt Die auf dem Knoten laufende Anwendung LED bewirkt dass die Lampe in einem periodischen Zeitintervall leuchtet und wieder ausgeschaltet wird Hierf r m ssen Timer Funktionalit ten der Firmware zur Zeitsteuerung zum Einsatz kommen Dies illustriert das Diagramm der modellierten Anwendung im unteren Teil der Abbildung 68 Die Beanspruchung des Timer Moduls wird durch die Modellierung der entsprechenden Ports vgl Kapitel 5 1 erreicht Dementsprechend werden die f r die Realisierung der Timer Funktionalit t zust ndig
301. stik und der gesamte ScatterEditor Dies sehen wir als wichtigstes Merkmal des Entwurfes der WSN Verwaltung bei Scat terClipse an um den Anforderungen an die in der Forschung diskutierte Mensch Maschine Schnittstelle human computer interfaces gerecht zu werden F r die Entwicklung von grafischen Benutzerschnittstellen GUIs bietet Eclipse mit Standard Widgets Toolkit SWT und JFace ein breites Spektrum an Bibliothe ken vergleichbar der von Swing im JDK Das Hauptaugenmerk liegt dabei auf dem look and feel Prinzip Das Ziel ist eine betriebssystemunabh ngige grafische Pro grammierung wobei die Ansicht der Benutzerschnittstellen sich dynamisch dem da runter liegenden Betriebssystem anpasst Zu diesem Zweck wird f r das jeweilige Betriebssystem eine Wrapper Klasse verwendet Dies f hrt jedoch zu einem Leis tungsverlust insbesondere bei anspruchsvollen Grafikanwendungen unter Eclipse Eine Diskussion der Vor und Nachteile von SWT und JFace findet man in Daum06a S 154 156 F r anspruchsvolle grafische Programmierung ist u a auf Daum06b Kapitel 1 und 2 zu verweisen 2 3 Das Eclipse Modeling EMF Wie aus der bisherigen Schilderung deutlich wurde ist die Konstruktion dom nen spezifischer Modellierungssprachen eine anspruchsvolle T tigkeit Damit dieser Prozess mit der n tigen Effizienz vonstatten geht sind angemessene Metamodellie rungsrahmenwerke unerl sslich WebBart Das Eclipse Modeling ist ein solches Rahmenwerk Da
302. sting for the Java programming lan guage Created by Kent Beck and Erich Gamma JUnit is one of the xUnit family of frameworks that originated with Kent Beck s SUnit JUnit has spawned its own ecosystem of JUnit extensions Web JUnit 29 Der Testprozess besteht aus folgenden Aktivit ten e Wahl des passenden Testszenarios f r die zu testende Anwendung e Erstellung des entsprechenden formalen Modells des Testfalls durch den das entworfene Testszenario realisiert wird e Vervollst ndigung der Entwicklung des Testfalls In diesem Schritt wird Co de manuell implementiert e Ausf hrung des Tests auf den Sensorknoten e Analyse und Evaluierung der Testergebnisse e Visualisierung der Testergebnisse im Testfallmodell e Verfeinerung des Testfallmodells um die Fehler zu isolieren bzw zu lokali sieren Hierf r werden auf Basis der visualisierten Testergebnisse Hypothe sen bez glich der Fehlerursache aufgestellt e iteratives Vorgehen bis alle Fehler beseitigt sind Der Entwickler kann w hrend der Analyse der Testergebnisse zwei m gliche In tentionen haben Einerseits liegt sein Fokus generell auf der Feststellung von Feh lern andererseits sind Erkenntnisse von Interesse die die Entstehung von Fehlern nachvollziehbar machen Solche Informationen kann der Entwickler verwenden um die Ursachen von Fehlern zu lokalisieren Beide F higkeiten die Fehlererfassung und deren Lokalisierung m ssen unterst tzt werden und eng zusammen
303. t zeigt wie auf Codegenerie rungsebene beim Durchlaufen des Templates abgefragt wird ob es sich bei der Bele gung des ComponentVersion Attributs um den Wert CSMA CA handelt oder nicht Ist dies der Fall so wird der zugeh rige Code eingebunden lt lt IF comp componentType toString matches Net gt gt lt lt IF comp componentVersion null gt gt lt lt Expand ESB ScatterWebNetc file sensor comp FOR comp gt gt lt lt Expand ESB ScatterWebNeth file sensor comp FOR comp gt gt lt lt ENDIF gt gt lt lt IF comp componentVersion CSMACA gt gt lt lt Expand ESB ScatterWebNetCSMAc file sensor comp FOR comp gt gt lt lt Expand ESB ScatterWebNetCSMAh file sensor comp FOR comp gt gt lt lt ENDIF gt gt lt lt ENDIF gt gt Programmauszug 15 Generierung eines alternativen Firmwaremodules Hent06 57 CSMA CA ist die Abkiirzung fiir Carrier Sense Multiple Access Collision Avoidance CSMA CA vermeidet Kollisionen durch Verwendung eines Priorit tenschemas bei dem das Zugriffsrecht von den Stationen signalisiert wird Ist eine Station sendebereit horcht sie das Ubertragungsmedium fiir eine bestimmte Zeit ab Im Falle von Funk LANs ist das Ubertra gungsmedium der Funkkanal der fiir eine bestimmte Zeit das Inter Frame Spacing IFS abgehort wird Nach Ablauf der IFS sendet die Station bei freiem Medium eine Sendeanfor derung RTS Dieses Signal wird von allen anderen Stationen empfang
304. t werden kann ScatterEditor l uft dann auf den korrespondierenden Klienten im entfernten Modus Um die Verbindung herzustellen muss der Benutzer die korrekte IP und das Server Passwort eingeben Klienten Zugriffsrechte und Passw rter k nnen auf dem Server Configuration Reiter verwaltet werden Dieser Zuschnitt hat den Vorteil dass der Benutzer beide Konfigurationsarten Klient und Server benutzen kann sich aber nur mit einem Programm vertraut machen muss Dies erleichtert den Zugang und die Akzeptanz von ScatterEditor Die folgenden Dienste k nnen internetbasiert im ScatterEditor in Anspruch genommen werden Remote_connection Remote_terminal und Remote Over The Air Flashing 7 2 Dienste und Komponenten von ScatterEditor 7 2 1 Die Verbindungskomponente Connection Abbildung 61 zeigt zwei Bildschirmabz ge des Connection Reiters Die Verbindungskomponente Connection fungiert als Br cke zwischen den Sensorknoten des WSNs und dem Java basierten ScatterEditor Rahmenwerk durch welche die Kommunikation zwischen beiden Seiten aufrecht erhalten wird Analog zu ScatterPlug wird die Kommunikation zwischen beiden Seiten mittels der COM Port Bibliothek des javax comm Pakets abgewickelt Mit Hilfe der Methode eGate connect wird die Verbindung zum WSN aufgebaut Hierzu m ssen die entsprechenden 7 Siehe Glossar 101 Initialisierungsparameter der Methode bergeben werden die individuell vom Benutzer mittels der Felder Type of Communication 1
305. t wurden Daher war es nicht m glich die ScatterClipse Werkzeugkette in der Studie in Betracht zu ziehen 1 2 Zielsetzung und Vorhaben Der Schl sselansatz hierzu liegt in der Automatisierung des Entwicklungsprozesses in den gleichzeitig Verwaltungsfunktionalit ten integriert werden die f r den Sen sornetzbetrieb notwendig sind F r die Automatisierung wird der architekturzent rierte Ansatz des modellgetriebenen Paradigmas eingesetzt Neu ist dabei dass Mo delle nicht nur zum Zweck der Dokumentation bzw Visualisierung eingesetzt wer den Vielmehr fungieren diese semantikbehafteten und ausdrucksstarken formalen Modelle auch als Technik um Schl sselkonzepte und Randbedingungen der Dom ne Plattform vollst ndig und pr gnant zu repr sentieren Solche speziellen aber technologieneutralen Modelle werden in konfigurierbare Codegeneratoren eingef gt um nach deren Validierung die korrespondierenden Software Artefakte automati siert zu generieren und in die entsprechende Plattform Funksensoren zu verteilen Durch den hohen Grad an Automatisierung beschleunigen sich die Entwicklung und der Test der auf den Sensorknoten laufenden Anwendungen Desweiteren stei gern sich Ersetzbarkeit und Wiederverwendbarkeit der Softwareartefakte da diese durch die zugeh rigen Modellkonstrukte formal repr sentiert werden Beides erh ht die Produktivit t des Entwicklungsprozesses Die modellgetriebene Codegenerierung dient weiterhin der ma geschn
306. te k TS Select Zoom Note g Sensor Node Initial Node Final Node Branching Point Control Action t Event FA Log Action Assertion Topology Change Action 7 Await Radio Packet Action i Radio Packet Received Event F Radio Packet Log Action J Link amp Properties RN WR Awalt Radio Packet Action AwaltSecondPacket Property Value Coro Addressed Node i 4 Appearance _ Apply Additional Checking 1 false 0 Event Processing Time iZ AFTER Incoming a Link a Name AwaitSecondPacket r G BIC Abbildung 34 Der generative Editor des Rahmenwerks Kame08 4 2 Live Validierung der Modelle Wie bereits in 2 5 erl utert fu t die Realisierung der Live Validierung auf der Zu sammenarbeit zwischen dem openArchitectureWare Generator Rahmenwerk und dem generativen GMF Editor Die Bindung wird durch den von openArchitecture Ware standardm ig gelieferten GMF Adapter hergestellt durch den jegliche im Editor stattgefundene Modell nderung berwacht und gleichzeitig gegen die in Checks definierten Ausdr cke validiert wird vgl Abbildung 10 in 2 5 Die Verwen dung der Live Validierung wurde im letzten Abschnitt im Kontext der Modellierung des Testverlaufs mittels des Aktivit tsdiagramms er rtert Dabei wurde gezeigt wie durch Checks Ausdr cke ans Modell gebundene semantische Randbedingungen zur robusten Steuerung des Testverlaufs beitragen In diesem Abschnitt soll
307. ten Paradigma die statistische Analyse der WSN Umgebung sowie die Visualisierung der analysierten WSN Daten und des Status der einzelnen Sensorknoten Desweiteren bietet ScatterPlug die M glichkeit WSNs mit Hilfe des Eclipse Rahmenwerks zu planen und einzurichten um eine optimale Inbetriebnahme der Sensoren zu erreichen Zum Zweck der Realisierung der angestrebten Emulation des WSNs wurde das Paket ScatterWeb for Java entwickelt durch das die Einheiten eines WSNs durch ihre jeweils auf dem Rechner laufenden Java Objekte repr sentiert werden Ferner wurde f r die Berechnung der mathematischen Operationen das Paket ScatterWeb math implementiert welches etliche statische Operationen und deren grafische Darstellung zur Verf gung stellt Die statistische Analyse der von einem Sensor erfassten und bearbeiteten Daten kann sehr hilfreich sein um R ckschl sse auf die Messgenauigkeit der Sensorik der einzelnen Sensorknoten ziehen zu k nnen Ein weiteres wichtiges Merkmal von ScatterPlug ist die F higkeit die gesamte Konfiguration des erstellten drahtlosen Netzes im XML Format zu speichern Somit k nnen die verschiedenen Plugins die XML Daten untereinander importieren bzw exportieren Folglich fungiert die XML Serialisierung als Austauschmechanismus zwischen den verschiedenen Plugins der gesamten ScatterClipse Werkzeugkette 98 7 ScatterEditor Der Pfad zur WSN Konfiguration Steuerung und berwachung Neben Texteditoren zum Bearbeiten von
308. ten gehen Da bislang der Fokus der Forschung meist auf den Hardwareeigenschaften und dem Verhalten des Netzes bez glich bestimmter Fragestellungen Energieverbrauch u a liegt wurde die Anwendungsentwicklung f r solche Netze nicht ausreichend ber cksichtigt Dabei besteht selbst f r ein sehr energiebewusstes Routingprotokoll weiterhin eine L cke wenn dessen Software nicht mit entsprechender Leistungsf higkeit Zuverl ssigkeit und Realit tsn he erstellt und getestet werden kann Die Optimierung der Anwendungsentwicklung drahtloser Sensornetze ist umso unentbehrlicher wenn man bedenkt dass ein solches Netz meist mit einer gro en Anzahl von Sensorknoten betrieben wird die gemeinsam den angestrebten Einsatzzweck des Netzes erreichen sollen Die verschiedenen Knoten bernehmen im Netz unterschiedliche Rollen woraus resultiert dass f r die Knoten eines Netzes vielf ltige Anwendungen zu entwickeln sind Die Programmierung solcher Sensornetze muss daher mit einer Produktivit t erfolgen die zugleich ihren Betriebsbedingungen angepasst ist Ein ad quater Softwareentwicklungsprozess muss diesen Bedingungen Rechnung tragen und zudem einen hohen Grad an Agilit t aufweisen Dies ist das Ziel der in der vorliegenden Arbeit vorgestellten ScatterClipse Werkzeugkette Vor diesem Hintergrund ist der Entwurf von ScatterClipse von der Kombination dreier wesentlicher Eigenschaften gepr gt n mlich der Produktivit t und der Robustheit der Programmie
309. ts software beader of image Events of Sensors 8 2090 04 09 22 44 44 VIB DETECT 8 2090 04 09 22 44 45 MIC LOUD 8 2090 04 09 22 44 46 MIC SILENT AY Abbildung 63 Der Terminal bietet eine befehlsgestiitzte Konfiguration der Sensorknoten Ding07 Die Befehle werden zuerst als Text in der Form von Strings mittels des COM Ports zum eGate geschickt Die empfangenen Strings werden anschlieBend von einem spezifischen auf dem eGate lauschenden Parsermodul interpretiert und in einem weiteren Schritt bearbeitet wodurch f r jeden interpretierten Befehl ein zugeh riges Paket erstellt wird das abschlie end zum im Befehl adressierten Knoten ber den Funkkanal verschickt wird Die Erstellung der den Befehlen entsprechenden Pakete wird ebenfalls von einem auf dem eGate befindlichen speziellen Modul realisiert Die Funktionalit t jedes Terminalbefehls wird mit einem C Makro innerhalb der Firmware der Sensorknoten implementiert Damit kann man individuelle Terminalbefehle flexibel definieren und durch ihre Implementierung auf C Ebene ausf hren lassen Dies erleichtert die Durchf hrung von Versuchen das Testen und die Fehlersuche bei neu implementierten Funktionen Das obere Ausgabefenster 1 der obigen Abbildung zeigt die R ckmeldungen der Knoten an welche die jeweiligen Befehle abgesetzt wurden Zus tzlich werden fortlaufend Ereignismeldungen eingeblendet 2 durch die der Benutzer st ndig ber wichtige nder
310. tterUnit dargestellt und geschildert wie diese den verteilten Test auf Sensorebene bewerkstelligen 4 1 Entwurf und Realisierung der Dom nensprache DSL Bei der Betrachtung des Modells f r den Testfall des Routingprotokolls im vorange gangenen Kapitel wurde ersichtlich dass es sich bei der Dom nensprache DSL zur Modellierung eines Testfalls um zwei Arten von Diagrammen handelt Das Aktivi t ts bersichtsdiagramm vgl Abbildung 20 im letzten Kapitel zur Koordination des Testverlaufs einerseits und die Detaillierungsdiagramme der einzelnen Ablauf str nge Aktivit ten andererseits aus denen sich das Aktivit tsdiagramm zusam mensetzt Der Ausgangspunkt f r die Modellierung des Tests ist das Aktivit tsdia gramm anhand dessen der Testverlauf spezifiziert wird Hierf r wird durch die Ab laufstr nge im Aktivit tsdiagramm die Reihenfolge und die Gliederung der ablau fenden Ereignisse w hrend der verteilten Ausf hrung des Testszenarios auf den verschiedenen Sensorknoten festgelegt Zudem wird der Aspekt der Parallelit t aus schlie lich auf dieser Modellierungsebene in Betracht gezogen Dazu muss der Soft waretester Modellierer eine f r seinen Testverlaufsentwurf geeignete Gliederung der Ablaufstr nge zwischen den Synchronisationsbalken entlang des Aktivit tsdia gramms festlegen Sowohl die Semantik als auch die Syntax des Aktivit tsdia gramms m ssen diesen Anforderungen gen gen was auf Metamodellierungsebene dem R
311. tures AS f private f type name f name public f type name get f name toFirstUpper return f name public void set f name toFirstUpper f type name f name this f name f name name String Feature ENDFOREACH ENDFILE ENDDEFINE Abbildung 11 Die Template Sprache Xpand von oAW WeboA WDoc liches Feature das von oAW unterst tzt wird Die Aufgabe von solchen Erweiterun gen mittels Xtends ist die Xpand Sprache auf eine modulare Weise funktional bzw operativ anzureichern daher auch die Bezeichnung Extensions Mit modular ist in diesem Zusammenhang gemeint dass die durch Xtends erzielte Funktionalit t se parat und ohne einen Eingriff in den strukturellen Aufbau der Xpand Sprache von statten geht Die Xtends Anweisungen bewirken dass Operationen definiert wer den deren Resultate per Aufruf den Templates zur Verf gung gestellt werden Die Definition der Operationen und die gesamte damit verbundene Logik bleiben den Templates verborgen Ein Anwendungsbeispiel findet man in 4 3 bei der Behand lung der Codegenerierung in Visual ScatterUnit Vor dem Hintergrund der obigen Schilderungen wird ersichtlich dass die techni sche Umsetzung der automatisierten Codegenerierung ein anspruchsvoller Prozess ist der aus verschiedenen aufeinander abgestimmten Schritten besteht an deren Bewerkstelligung etliche Komponenten unterschiedlicher Werkzeuge beteiligt si
312. tver laufs zu steuern und zu protokollieren Im Laufe der Arbeit wird auf abstrakter Mo 33 Dies sind Befehle jeglicher Art zur Initialisierung Protokollierung etc Normalerweise werden solche Nachrichten st ndig durch einen herk mmlichen zentralistischen polling Ansatz zwischen den Knoten und der Sinke hin und her verschickt 35 dellierungsebene von Aktionen Actions des Tests gesprochen Auf Implementie rungsebene wird der Begriff Steuerbefehl verwendet Somit stellt ein Steuerbefehl auf Codierungsebene die Realisierung einer im formalen Modell modellierten Aktion dar Beispielsweise ist das Versenden eines Pakets auf Modellebene eine Aktion Beim dazu n tigen Steuerbefehl handelt es sich um den Prozeduraufruf des zugrun de liegenden Routingprotokolls bzw der zu testenden Anwendung d h im Allge meinen ein Aufruf einer Funktionalit t des Testobjekts oder eines Dienstes der Scatter Unit Schicht Des Weiteren werden die f r den Test protokollierten Daten z B stattgefundene Aktionen des Tests erst nach Beendigung der Ausf hrung des Testverlaufs einma lig an die Senke verschickt Dies f hrt zu einer weiteren Reduktion der st ndigen wechselseitigen Inanspruchnahme des Funkkanals The problem of sending infor mation over channels has been elegantly solved by local logging and transmission of the information once the test has completed Der Leitfaden zur Implementierung eines Testfalls liegt daher in der dezentralen Ausf
313. twork Application Development An Architecture Centric MDE Approach In Oquendo F ed ECSA 2007 LNCS Vol 4758 pp 179 194 Springer Berlin Heidelberg 2007 Malt00 Maltz D A Broch J Johnson D B Quantitative lessons from a full scale multi hop wireless ad hoc network testbed In IEEE Wireless Communications and Networking Conference vol 3 pp 992 997 IEEE Press New York 2000 Moor04 Moore B Dean D Gerber A Wagenknecht G Vanderheyden P Eclipse Development using the Graphical Editing and the Eclipse Modeling IBM Corp 2004 URL http www redbooks ibm com redbooks pdfs sg246302 pdf Mys106 Mysliwiec L Entwurf und Implementierung eines Monitoring Eclipse Frameworks f r ScatterWeb Unpublizierte Diplomarbeit Betreuer Mohammad Al Saad Freie Universit t Berlin 2006 178 Naum07 Naumowicz T Enabling Wireless Sensor Networks Integration of WSNs into Development Environments Poster presented at Microsoft Research Summer School Cambridge UK 2007 URL http page mi fu berlin de naumowic research naumowicz07MRSC pdf Naum08 Naumowicz T Freeman R Heil A Calsyn M Hellmich E Braendle A Guilford T Schiller J Autonomous Monitoring of Vulnerable Habitats using a Wireless Sensor Network In Workshop on Real world wireless sensor networks European Conference on Computer Systems pp 51 55 ACM New York 2008 Perk01 Perkins C E Ad Hoc Networking Addison
314. ufen dass eine gleiche UUID f r etwas anderes verwendet wird WebUUID 63 Es gibt wie im letzten Kapitel geschildert verschiedene Szenarien in Visual Scat terUnit bei denen der Code nicht vollst ndig automatisiert generiert werden sollte Gerade f r Testzwecke m ssen bestimmte Aspekte bez glich der zu testenden An wendungen spezifisch vom Benutzer eingespeist werden Beispielsweise werden Co deanteile bestimmter Aktionen bzw Ereignisse der Testf lle oft vom Benutzer ma nuell implementiert da diese sich stark an der zu testenden Anwendung orientie ren Dies wird durch den folgenden Programmauszug 10 aus Visual ScatterUnit zur Generierung eines Testfalls f r das DSDV Routing Protokoll demonstriert Der Programmauszug zeigt ein vollst ndiges Codeartefakt bestehend sowohl aus manuellem als auch aus generiertem Code Wie der Programmauszug in den Zeilen 10 13 erkennen l sst findet eine Interaktion zwischen dem manuellen und dem au tomatisiert generierten Code statt Diese Zusammenarbeit wird m glich durch die in Zeile 2 definierte Boolesche Variable Wie man sieht m ssen hier und da gegebe nenfalls kleine Eingriffe vom Entwickler vorgenommen werden bis das Endprodukt des generierten Softwareartefakts vorliegt Programmauszug 11 zeigt das zum obi gen Code geh rende Template Der gesch tzte Bereich im Template wird durch die Tags PROTECT und ENDPROTECT definiert Die TODO Kommentare die sich in nerhalb dieses Bereichs bef
315. um eine komponentenbasierte Konstruktion solcher Modelle zu unterst tzen Es unterst tzt Akteur orientierte Definitionen von Netzwerkknoten drahtlose Kommunikationskan le physikalische Medien wie akustische Kan le und drahtgebundene Subsysteme This modeling is designed to support a component based construction of such models It supports actor oriented definition of network nodes wireless communication channels physical media such as acoustic channels and wired subsystems Bald04 Daher bieten die grafischen Diagramme umfangreiche Funktionalit ten um zahlreiche Aspekte ad quat zu repr sentieren Allerdings ist die Modellierung stark an der Repr sentation des Netzverhaltens orientiert um daraus die entsprechenden Codeartefakte f r den Simulator zu erzeugen So werden Modellkonstrukte zur Verf gung gestellt die Kommunikationskan le Paketverlust Energieverbrauch etc darstellen Das Verhalten der Anwendungen und deren Softwarearchitektur stehen weniger im Fokus der Modellierung die daher auch weniger softwaretechnisch motiviert ist Das Rahmenwerk bleibt lediglich ein grafisches und kein modellgetriebenes Werkzeug in dem Sinne dass kein strukturierter Entwicklungsprozess bei der Anwendungserstellung zugrunde liegt 6 Eine Dom nensprache auf Basis eines beliebig zu erweiternden Metamodells liegt nicht vor Dies beschr nkt die Offenheit der Architektur bez glich der Erweiterbarkeit des Rahmenwerkes und dessen Modellierungstech
316. ung 37 Mit dem Blitz Symbol wird es m glich die von der Pr froutine erzeugte textuelle Fehlermeldung dem Benutzer visuell anzuzeigen und bei Navigation der Maus auf das i Symbol wird die aus dem Test protokollierte Information ebenfalls textuell an gezeigt Neben den benutzerdefinierten Log Actions zur anwendungsspezifischen Protokol lierung erm glicht es der Protokollierungsdienst verschiedene Ereignisse des Test verlaufs automatisch bzw standardm ig zu protokollieren d h der Nutzer muss daf r nicht eigens eine Log Action als Modellentit t definieren Folglich werden beispielsweise der Start und das Ende sei es eine erfolgreiche Terminierung oder ein Abbruch der Testausf hrung protokolliert Desweiteren ist es m glich die ein gehenden Datenpakete nach einem vom Benutzer im Modell konfigurierten Detail lierungsgrad zu protokollieren So kann der Benutzer anhand des parametrisierten Modellkonstruktes selbst angeben ob beispielsweise lediglich der Inhalt des 66 2 W vow default wsn i m default wsn_diagram B MovingDataSource testcase i id MovingDataSource testcase_di i wsn properties H E DSDY S ScatterWeb2 platform IJ Applications H E EMPTY gt CLASSIC gt DataSink bin H E out H B src test MovingDataSource B E Node2 I src h i main c main h E ReceiveDat i d ReceiveDat AppConf h 2 build xml m a makefile
317. ungen im WSN auf dem Laufenden gehalten wird Gegebenenfalls kann der Benutzer auf das Auftreten bestimmter Ereignisse reagieren indem er entsprechende Befehle an die betroffenen Knoten absetzt Die Eingabe der Befehle erfolgt durch die Eingabeleiste 3 Bei der Eingabe des ersten Buchstabens w hrend der Formulierung eines Befehls werden dem Benutzer in 4 alle mit diesem Buchstaben beginnenden Befehle aufgelistet so dass aus dieser Liste ein beliebiger Befehl ausgew hlt werden kann Dabei werden als Zusatzinformation die Bedeutung bzw Wirkung des selektierten Befehles sowie die ihm zu bergebenden Parameter dem Benutzer angezeigt Ferner ist es m glich mittels der Tasten W oder zwischen den bereits eingegebenen Befehlen zu navigieren Zu diesem Zweck wird jeder in der Eingabeleiste abgesetzte Befehl im Hintergrund f r die laufende Sitzung in einer Stapeldatenstruktur 8 F r diesen Zweck wird wie erw hnt die Java COM Bibliothek des Javax Paketes verwendet 105 abgelegt Dies wird im Schritt 1 der Abbildung 64 veranschaulicht Im Falle dass der Befehl durch die Bet tigung der L Taste wiederholt wird wird der Befehl in der Eingabeleiste eingeblendet und zugleich aus dem Stapel A entfernt Schritt 2 und in den Stapel B eingef gt Wird nun die Lt Taste gedr ckt so wird der Befehl wiederum aus dem Stapel B entfernt und in A wieder eingef gt Schritt 4 Hierdurch wird ein schneller Zugriff auf die gespeicherten Befehle gew hrleistet
318. unter liegenden Dom ne pr gnant repr sentieren werden weiter auf die untere Generierungsebene delegiert Solche spezifischen dom nennahen Randbedingungen k nnen dann bei spielsweise im Kontext der Codegenerierung in Betracht gezogen werden was den Codegenerierungsprozess optimiert Zusammenfassend kann man sagen dass sich die Semantikdefinition auf drei E benen erstreckt n mlich die Metamodellebene die Modellierungs Editorebene und die Generatorebene Auf der Metamodellebene wird das Ger st der DSL festgelegt 12 auf der Modellierungsebene werden die Feinheiten des Editierens der Modellkon strukte behandelt und auf der Generatorebene wird die DSL gegen dom nenspezifi sche Eigenschaften validiert Diese schrittweise Unterteilung reduziert zum einen die Komplexit t und zum anderen findet dadurch eine klare Teilung von Belangen statt Bevor wir tiefer auf die generative Schicht von EMF eingehen bleibt zu erw h nen dass EMF eine Option anbietet in XML oder UML pr sentierte Modelle zu im portieren und nach deren Umwandlung weiter zu bearbeiten Dies wird durch die F higkeit erm glicht Modelle in XMI als Austauschformat zu serialisieren Es ist daher nicht verwunderlich dass an der XMI Standardisierung und Optimierung in Forschung und Industrie fortw hrend gearbeitet wird WebJeck Sie erh ht den Grad der Interoperabilit t der verschiedenen MDSD Werkzeuge wodurch deren In tegration deutlich erleichtert wird Dies ste
319. uss die Ausf hrung des Testfalls koordiniert werden was einen zu die sem Zweck eigens zu implementierenden Code ben tigt Um die Arbeit f r den An wender deutlich zu erleichtern wird diese Aufgabe wie bereits erw hnt in den Co degenerator verlagert Zu diesem Zweck wurde ScatterUnit mit der modellgetrie benen Visual ScatterUnit erg nzt wodurch die modellgetriebene Ausf hrung der Testf lle erm glicht wird Des Weiteren reduziert die Modellierung die inh rente Komplexit t der Entwicklung der Testf lle die durch die Steuerung der Verteilung sowie die begleitende Koordination der im Test ablaufenden Aktionen verursacht wird Infolgedessen erh ht sich die Qualit t des Testprozesses erheblich da sich der vom Entwickler manuell implementierte Code massiv reduziert Dies erh ht die Ro bustheit und Effizienz des Testens entsprechend Abbildung 14 zeigt die f r die Rea lisierung des automatisierten Testprozesses notwendige abgestimmte Zusammenar beit zwischen den zwei Ebenen Testfall modell erstellt amp editiert mit Visual ScatterUnit generiert visualisiert Test ergebnis erzeugt ScatterUnit erweitert die Laufzeitumgebung der Sensorknoten Testobjekt Die auf dem Sensorknoten laufende Anwendung Testfall code ausgef hrt von Abbildung 14 Zusammenarbeit zwischen ScatterUnit und Visual ScatterUnit 29 Die Bezeichnung ist von JUnit inspiriert JUnit is a unit te
320. usschnitts aus Abbildung 31 bei dem die Modellentit ten zwecks automatisierter Codegenerierung parametrisiert werden Die Attribute verweisen daher im Allgemeinen auf die h ufig benutzten Dienste der Testschicht ScatterUnit Werden nun die Dienste von ScatterUnit ausgebaut so kann der rele vante Teil des Metamodells problemlos entsprechend erweitert werden Die Funkti onalit t ScatterUnits kann infolgedessen auf flexible Weise um weitere Dienste er g nzt werden Dies tr gt der Dynamik der WSN Dom ne und der damit verbunde nen Vielfalt von zu testenden Anwendungen Rechnung Demzufolge wurde das Metamodell wie das in UML Notation erstellte Diagramm vgl Abbildung 90 im Anhang 11 4 veranschaulicht auf Basis von hierarchischer Generalisierung bzw Vererbung zwischen den Metamodellentit ten derart struktu riert dass das Einflechten beliebiger Steuerbefehle zu einem sp teren Zeitpunkt flexibel m glich ist Werden gewisse Steuerbefehle wiederholt zum Testen unter schiedlicher Anwendung in Anspruch genommen so ist es f r solche Befehle effi zient entsprechende Metamodellinstanzen zu definieren die die ad quate Angabe der f r den Codegenerator erforderlichen Parameter im Testfallmodell erm glichen 55 lt lt Steuerbefehl gt gt lt lt Steuerbefehl gt gt Auf zweites Datenpaket Auf zweites Datenpaket warten warten lt lt Ereignis gt gt lt lt Ereignis gt gt Zweites Datenpaket Zweites Datenpaket empfangen empfangen
321. utoren an gegenw rtige Werkzeuge f r die Anwendungsentwicklung drahtloser Sensorknoten stellen Im Folgenden wird bez glich jeder einzelnen Anforderung dargestellt inwieweit ScatterClipse diese erfiillt 16 Ein Rahmenwerk das hingegen den Softwareentwicklungsprozess modellgetrieben zur automatisierten Generierung von Codeartefakten auf Basis einer Dom nensprache f r eine Simulationsumgebung drahtloser Sensornetze unterst tzt ist in Sadi07 realisiert Dieses wird im weiteren Verlauf des Kapitels behandelt 137 Component Feature IDE for TinyOS nesC TinyDT TinyOSIDE TOSDev YETI Viptos GRATIS Modeling x x PManager Wizard x x x Properties x x x Editor Graphical x x x x Syntax x x x x highlighting Code navigation x x Code completion x x x Code folding x x Spell checker x Syntactic detection x Error location x x Outline x Internal Parser x x Compiler x x x x x x Debugger Simulator Console x Graphical Burner Serial burning x x x x x OTAP Monitor Tabelle 6 Vergleich der WSN Entwicklungsumgebung nach der Studie von Teng Teng08 Modellierung Dies ist das Herzstiick der ScatterClipse Werkzeugkette welches durch die generative architekturzentrierte Infrastruktur bestehend aus Visual ScatterUnit und ScatterFactory realisiert wurde Projekt Manager Dank der Eclipse Integration wird ein Projekt Manager von jedem Rahmenwerk d
322. w wahr so wird die Routine des Dienstes aufgerufen Somit kann man auf einfache Weise beliebige Standarddienste sowie zus tzliche Dienste Add ons aktivieren und deaktivieren wodurch die gesamte Laufzeitumge bung innerhalb des Diagramms sich gem den Anforderungen der jeweiligen An wendung beliebig konfigurieren l sst Beispielsweise bewirkt die Aktivierung des Cachings einen schnelleren Zugriff auf die in der Speicherkarte abgelegten Daten Wird der Dienst hingegen vom Benutzer im Modell deaktiviert so wird dadurch ca 10 des Speicherplatzes gespart der sonst f r das Caching ben tigt w rde Die 60 Hierzu werden die Werte der Attribute im Modell eingelesen und an die darauf folgende Codegenerierung delegiert damit die Templates entsprechend eingebunden werden Im Gro en und Ganzen hnelt dieser Mechanismus den in ScatterFactory eingesetzten Filterregeln 83 Wahl der passenden Konfiguration f r die zugrunde liegende Anwendung obliegt dem Benutzer und er kann sie durch einfache Interaktion im Modell treffen Ein weiteres im obigen Modell illustriertes Beispiel f r die flexible Konfiguration der Laufzeitumgebung mehrerer Anwendungen in einem einzigen Modelldiagramm ist die Konfiguration der Funktionalit t des FAT Filesystems der Speicherkarte Hier wird das FAT Filesystem allerdings lediglich f r die Anwendung MyAppU singFAT aktiviert Bei der automatisierten Generierung der ben tigten Artefakte zur dynamischen
323. zlast Radio Packet Log Action NutzlastVerfaelscht Assertion NobruchWennTimeout Control Action 5 8 i 5 e Ablaufstrang Diagramm des Ablaufstrangs ZweitesPaketErwarten Abbildung 73 Diagramme des entwickelten Testfalls Fortsetzung Kame08 Die Durchf hrung der Fallstudie dauerte ca zehn Stunden wobei eine halbe Stunde f r die Erstellung des Testfallmodells ben tigt wurde und der Rest der Zeit f r die Lokalisierung der Versagensursachen deren Fortgang die folgenden chronologischen Schritte ausmachen Kame08 121 Schritt 1 ben tigte Zeit ca 45 Minuten Das Versenden des Datenpakets von Knoten 1 nach 4 scheiterte Daher hat die betroffene Methode false als R ckgabeparameter zur ckgeliefert Gem der Spezifikation der Methode wird false als R ckgabewert genau dann zur ckgeliefert wenn die entsprechende Routeninformation in der Routingtabelle zur Weiterleitung des Pakets bis zum Empf nger nicht korrekt vorliegen Zu diesem Zweck wurde die erste Verfeinerung des Testfallmodells vorgenommen indem eine Log Aktion vgl Abbildung 74 definiert wurde um die Routingtabelle zum Zeitpunkt der Versendung des Pakets zu protokollieren Anhand der protokollierten Informationen der Routingtabelle stellte sich heraus dass die betroffenen Informationen in der Tabelle vorhanden waren Dies impliziert dass das Versagen auf deren Interpretation bzw Bearbeitung zur ck zu f hren ist EmpfaengerNichtBekan
324. zt werden wobei sie sich gegenseitig erg nzen und ein koh rentes Ganzes bilden Es folgt eine Darstellung der verschiedenen Dienste bzw Reiter des Scatter Editors und ihrer jeweiligen Funktionalit t 1 Connection Steuert den Verbindungsaufbau und die Kommunikation via eGate oder Supernode zum drahtlosen Sensornetz WSN 2 Property Visualisierung des Status jedes sich im Betrieb befindenden Sensorknotens im WSN zu dem im vorherigen Schritt die Verbindung aufgebaut wurde 3 Terminal Erm glicht eine befehlsorientierte Konfiguration der Sensorknoten im WSN w hrend ihres Betriebs 4 Alarm Erm glicht eine benutzerdefinierte berwachung ausgew hlter Sensorknoten im Netz sowie der von ihnen erfassten Umgebung 5 Over The Air Flashing Die Aktualisierung bestimmter Softwaremodule auf ausgew hlten Sensorknoten im WSN Ein weiterer oben nicht angef hrter Dienst ist die Server Configuration der nicht als Standarddienst konfiguriert ist und auf Anforderung des Benutzers aktiviert wird Der Dienst wird somit erst zur Verf gung gestellt wenn der Benutzer die entsprechende Einstellung im ScatterEditor bet tigt woraufhin diese laufende ScatterEditor Instanz 6 Diese sind in der Regel die automatisiert generierten Softwareartefakte des architekturzentrierten modellgetriebenen Prozesses in Visual ScatterUnit und ScatterFactory 100 zugleich als Server anderer ScatterEditor Klienten fungiert Dazu bietet dieser Dienst die entsp
325. zu steuern Um die Produktivit t der Plattform zu erh hen kann auf die Hauptdienste sowohl im lokalen als auch im entfernten internetbasierten Modus zugegriffen werden Die Eclipse basierte Plugin orientierte Architektur f rdert die Erweiterung der Werkzeugkette wenn neue Anforderungen an WSN auftauchen Einerseits kann der Benutzer bestimme Plugins Funktionalit ten unabh ngig voneinander verwenden so dass eine Trennung der Belange separation of concerns erreicht wird Andererseits kann er gleichzeitig zwischen den verschiedenen Plugins kooperativ navigieren wodurch Koh renz erreicht wird ScatterClipse basiert vollst ndig auf Open Source Komponenten die ohne zus tzliche Kosten erh ltlich sind Abstract ScatterClipse is a plugin oriented toolchain for the automated testing development and management of applications running on Wireless Sensor Networks The main goal is the furthermost automated generation of software system families for the ScatterWeb sensor boards The architecture centric method of the model driven paradigm is used for automation The ScatterClipse s novel approach lies in the accomplishment of the integration of visual automated application debugging and WSN management features in the model driven application development process of the sensor boards In addition to automation the focus lies here with the aspect of human computer interfaces for WSN Thus ScatterClipse provides the opportunity to test and manage

ScatterClipse: Architekturzentrierte Plattform und Werkzeuge für

Contents

Download Pdf Manuals

Related Search

Related Contents

ScatterClipse: Architekturzentrierte Plattform und Werkzeuge f&uuml;r

Contents

Download Pdf Manuals

Related Search

Related Contents

ScatterClipse: Architekturzentrierte Plattform und Werkzeuge für